Messages in this thread |  | | Date | Sat, 12 Mar 2022 14:08:16 +0100 | Subject | Re: [mm/slub] ae107fa919: BUG:unable_to_handle_page_fault_for_address | From | Vlastimil Babka <> |
| |
On 3/12/22 13:06, Mike Rapoport wrote: >>>> Ideas? implementing something like kmem_cache_init_early() again? >>> >>> I think we could simply make CONFIG_SLUB_DEBUG_ON select/depend on >>> STACKDEPOT_ALWAYS_INIT? >> >> Oh, sounds better. >> >> If we make CONFIG_SLUB_DEBUG_ON select STACK_DEPOT_ALWAYS_INIT, >> that is simple solution. but stackdepot will be initialized on >> slub_debug=- too.
Valid point.
>> But I think no one will set CONFIG_SLUB_DEBUG_ON=y if not debugging... > > If memory wasted by stack_table is a real concern, we may free it after > parsing slub_debug or add a condition taking into account > CONFIG_SLUB_DEBUG_ON and slub_debug=- to the > > if (slub_debug & SLAB_STORE_USER) > stack_depot_want_early_init(); > > But I agree that if somebody runs a kernel with CONFIG_SLUB_DEBUG_ON=y, the > goal is to have slub debugging on, so making CONFIG_SLUB_DEBUG_ON select > STACK_DEPOT_ALWAYS_INIT totally makes sense to me.
Agree. We had to decouple stackdpepot init from CONFIG_SLUB_DEBUG because almost everyone enables CONFIG_SLUB_DEBUG by default, but on smaller systems doesn't want to always pay the price even if unused. But I don't expect anyone to enable CONFIG_SLUB_DEBUG_ON and then run with slub_debug=- by default, and complain. If anyone like that exists, they could also add the stackdepot_disable parameter.
>> I don't think making CONFIG_SLUB_DEBUG_ON depend on >> CONFIG_STACKDEPOT_ALWAYS_INIT is good solution. only KASAN selects it. >> >> -- >> Thank you, You are awesome! >> Hyeonggon :-) >
|  |