From: Vlastimil Babka <vbabka@suse.cz> To: Mike Rapoport <rppt@kernel.org>, Hyeonggon Yoo <42.hyeyoo@gmail.com> Cc: kernel test robot <oliver.sang@intel.com>, Oliver Glitta <glittao@gmail.com>, lkp@lists.01.org, lkp@intel.com, LKML <linux-kernel@vger.kernel.org>, linux-mm@kvack.org Subject: Re: [mm/slub] ae107fa919: BUG:unable_to_handle_page_fault_for_address Date: Sat, 12 Mar 2022 14:08:16 +0100 [thread overview] Message-ID: <ff4daab3-0ae6-65b9-dbc6-8033cf7ad6a7@suse.cz> (raw) In-Reply-To: <YiyMvBouXGLk/xWP@kernel.org> 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 :-) >
WARNING: multiple messages have this Message-ID (diff)
From: Vlastimil Babka <vbabka@suse.cz> To: lkp@lists.01.org Subject: Re: [mm/slub] ae107fa919: BUG:unable_to_handle_page_fault_for_address Date: Sat, 12 Mar 2022 14:08:16 +0100 [thread overview] Message-ID: <ff4daab3-0ae6-65b9-dbc6-8033cf7ad6a7@suse.cz> (raw) In-Reply-To: <YiyMvBouXGLk/xWP@kernel.org> [-- Attachment #1: Type: text/plain, Size: 1586 bytes --] 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 :-) >
next prev parent reply other threads:[~2022-03-12 13:09 UTC|newest] Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-03-09 2:15 [mm/slub] ae107fa919: BUG:unable_to_handle_page_fault_for_address kernel test robot 2022-03-09 2:15 ` kernel test robot 2022-03-11 14:54 ` Hyeonggon Yoo 2022-03-11 14:54 ` Hyeonggon Yoo 2022-03-11 15:36 ` Vlastimil Babka 2022-03-11 15:36 ` Vlastimil Babka 2022-03-11 16:46 ` Hyeonggon Yoo 2022-03-11 16:46 ` Hyeonggon Yoo 2022-03-12 1:10 ` Hyeonggon Yoo 2022-03-12 1:10 ` Hyeonggon Yoo 2022-03-12 9:21 ` Vlastimil Babka 2022-03-12 9:21 ` Vlastimil Babka 2022-03-12 11:04 ` Hyeonggon Yoo 2022-03-12 11:04 ` Hyeonggon Yoo 2022-03-12 12:06 ` Mike Rapoport 2022-03-12 12:06 ` Mike Rapoport 2022-03-12 13:08 ` Vlastimil Babka [this message] 2022-03-12 13:08 ` Vlastimil Babka 2022-03-14 16:20 ` Vlastimil Babka 2022-03-14 16:20 ` Vlastimil Babka
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=ff4daab3-0ae6-65b9-dbc6-8033cf7ad6a7@suse.cz \ --to=vbabka@suse.cz \ --cc=42.hyeyoo@gmail.com \ --cc=glittao@gmail.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=lkp@intel.com \ --cc=lkp@lists.01.org \ --cc=oliver.sang@intel.com \ --cc=rppt@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.