All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vlastimil Babka <vbabka@suse.cz>
To: Hyeonggon Yoo <42.hyeyoo@gmail.com>, Marco Elver <elver@google.com>
Cc: David Rientjes <rientjes@google.com>,
	Christoph Lameter <cl@linux.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Pekka Enberg <penberg@kernel.org>,
	Roman Gushchin <roman.gushchin@linux.dev>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, patches@lists.linux.dev,
	linux-kernel@vger.kernel.org, Oliver Glitta <glittao@gmail.com>,
	Faiyaz Mohammed <faiyazm@codeaurora.org>,
	Dmitry Vyukov <dvyukov@google.com>,
	Eric Dumazet <edumazet@google.com>,
	Jarkko Sakkinen <jarkko@kernel.org>,
	Johannes Berg <johannes.berg@intel.com>,
	Yury Norov <yury.norov@gmail.com>, Arnd Bergmann <arnd@arndb.de>,
	James Bottomley <James.Bottomley@hansenpartnership.com>,
	Matteo Croce <mcroce@microsoft.com>,
	Andrey Konovalov <andreyknvl@gmail.com>,
	Imran Khan <imran.f.khan@oracle.com>,
	Zqiang <qiang.zhang@windriver.com>
Subject: Re: [PATCH] mm/slub: initialize stack depot in boot process
Date: Tue, 1 Mar 2022 01:28:31 +0100	[thread overview]
Message-ID: <d1bf599d-d680-192c-e7b8-12af7f4f5430@suse.cz> (raw)
In-Reply-To: <Yhzlw0GGBeuCALJp@ip-172-31-19-208.ap-northeast-1.compute.internal>

On 2/28/22 16:09, Hyeonggon Yoo wrote:
> commit ba10d4b46655 ("mm/slub: use stackdepot to save stack trace in
> objects") initializes stack depot while creating cache if SLAB_STORE_USER
> flag is set.
> 
> This can make kernel crash because a cache can be created in various
> contexts. For example if user sets slub_debug=U, kernel crashes
> because create_boot_cache() calls stack_depot_init(), which tries to
> allocate hash table using memblock_alloc() if slab is not available.
> But memblock is also not available at that time.
> 
> This patch solves the problem by initializing stack depot early
> in boot process if SLAB_STORE_USER debug flag is set globally
> or the flag is set to at least one cache.
> 
> [ elver@google.com: initialize stack depot depending on slub_debug
>   parameter instead of allowing stack_depot_init() can be called
>   in kmem_cache_init() for simplicity. ]
> 
> Link: https://lkml.org/lkml/2022/2/28/238
> Fixes: ba10d4b46655 ("mm/slub: use stackdepot to save stack trace in objects")
> Signed-off-by: Hyeonggon Yoo <42.hyeyoo@gmail.com>

I think a much easier approach would be to do this checking in
setup_slub_debug(). There we may either detect SLAB_STORE_USER in
global_flags, or check the flags returned by parse_slub_debug_flags() in the
while (str) cycle, in the 'else' case where slab_list is present. Both cases
would just set some variable that stack_depot_early_init() (the
!CONFIG_STACKDEPOT_ALWAYS_INIT version, or a newly consolidated one) would
check. So that would be another way to request the stack_depot_init() at a
well-defined point of boot, similar to CONFIG_STACKDEPOT_ALWAYS_INIT.
Because setup_slub_debug() is called by __setup, which is processed from
start_kernel() -> parse_args() before mm_init() -> stack_depot_early_init().

> ---
>  include/linux/slab.h |  1 +
>  init/main.c          |  1 +
>  mm/slab.c            |  4 ++++
>  mm/slob.c            |  4 ++++
>  mm/slub.c            | 28 +++++++++++++++++++++++++---
>  5 files changed, 35 insertions(+), 3 deletions(-)
> 
> diff --git a/include/linux/slab.h b/include/linux/slab.h
> index 37bde99b74af..023f3f71ae35 100644
> --- a/include/linux/slab.h
> +++ b/include/linux/slab.h
> @@ -139,6 +139,7 @@ struct mem_cgroup;
>  /*
>   * struct kmem_cache related prototypes
>   */
> +void __init kmem_cache_init_early(void);
>  void __init kmem_cache_init(void);
>  bool slab_is_available(void);
>  
> diff --git a/init/main.c b/init/main.c
> index 65fa2e41a9c0..4fdb7975a085 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -835,6 +835,7 @@ static void __init mm_init(void)
>  	kfence_alloc_pool();
>  	report_meminit();
>  	stack_depot_early_init();
> +	kmem_cache_init_early();
>  	mem_init();
>  	mem_init_print_info();
>  	kmem_cache_init();
> diff --git a/mm/slab.c b/mm/slab.c
> index ddf5737c63d9..80a6d01aab06 100644
> --- a/mm/slab.c
> +++ b/mm/slab.c
> @@ -1196,6 +1196,10 @@ static void __init set_up_node(struct kmem_cache *cachep, int index)
>  	}
>  }
>  
> +void __init kmem_cache_init_early(void)
> +{
> +}
> +
>  /*
>   * Initialisation.  Called after the page allocator have been initialised and
>   * before smp_init().
> diff --git a/mm/slob.c b/mm/slob.c
> index 60c5842215f1..00e323af8be4 100644
> --- a/mm/slob.c
> +++ b/mm/slob.c
> @@ -715,6 +715,10 @@ struct kmem_cache kmem_cache_boot = {
>  	.align = ARCH_KMALLOC_MINALIGN,
>  };
>  
> +void __init kmem_cache_init_early(void)
> +{
> +}
> +
>  void __init kmem_cache_init(void)
>  {
>  	kmem_cache = &kmem_cache_boot;
> diff --git a/mm/slub.c b/mm/slub.c
> index a74afe59a403..40bcd18143b6 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -4221,9 +4221,6 @@ static int kmem_cache_open(struct kmem_cache *s, slab_flags_t flags)
>  	s->remote_node_defrag_ratio = 1000;
>  #endif
>  
> -	if (s->flags & SLAB_STORE_USER && IS_ENABLED(CONFIG_STACKDEPOT))
> -		stack_depot_init();
> -
>  	/* Initialize the pre-computed randomized freelist if slab is up */
>  	if (slab_state >= UP) {
>  		if (init_cache_random_seq(s))
> @@ -4810,6 +4807,31 @@ static struct kmem_cache * __init bootstrap(struct kmem_cache *static_cache)
>  	return s;
>  }
>  
> +/* Initialize stack depot if needed */
> +void __init kmem_cache_init_early(void)
> +{
> +#ifdef CONFIG_STACKDEPOT
> +	slab_flags_t block_flags;
> +	char *next_block;
> +	char *slab_list;
> +
> +	if (slub_debug & SLAB_STORE_USER)
> +		goto init_stack_depot;
> +
> +	next_block = slub_debug_string;
> +	while (next_block) {
> +		next_block = parse_slub_debug_flags(next_block, &block_flags, &slab_list, false);
> +		if (block_flags & SLAB_STORE_USER)
> +			goto init_stack_depot;
> +	}
> +
> +	return;
> +
> +init_stack_depot:
> +	stack_depot_init();
> +#endif
> +}
> +
>  void __init kmem_cache_init(void)
>  {
>  	static __initdata struct kmem_cache boot_kmem_cache,


  parent reply	other threads:[~2022-03-01  0:28 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-25 18:03 [PATCH 0/5] SLUB debugfs improvements based on stackdepot Vlastimil Babka
2022-02-25 18:03 ` [PATCH 1/5] mm/slub: move struct track init out of set_track() Vlastimil Babka
2022-02-26 10:41   ` Hyeonggon Yoo
2022-02-25 18:03 ` [PATCH 2/5] mm/slub: use stackdepot to save stack trace in objects Vlastimil Babka
2022-02-26 10:24   ` Hyeonggon Yoo
2022-02-28 18:44     ` Vlastimil Babka
2022-02-27  3:08   ` [PATCH] lib/stackdepot: Use page allocator if both slab and memblock is unavailable Hyeonggon Yoo
2022-02-27  5:06     ` kernel test robot
2022-02-27  9:23     ` [PATCH v2] " Hyeonggon Yoo
2022-02-27 10:00     ` [PATCH] " kernel test robot
2022-02-28  7:00     ` Marco Elver
2022-02-28 10:05       ` Hyeonggon Yoo
2022-02-28 10:50         ` Marco Elver
2022-02-28 11:48           ` Hyeonggon Yoo
2022-02-28 15:09           ` [PATCH] mm/slub: initialize stack depot in boot process Hyeonggon Yoo
2022-02-28 16:28             ` Marco Elver
2022-03-01  2:12               ` Hyeonggon Yoo
2022-03-01  0:28             ` Vlastimil Babka [this message]
2022-02-27  9:44   ` [PATCH 2/5] mm/slub: use stackdepot to save stack trace in objects Hyeonggon Yoo
2022-03-02 16:51     ` Vlastimil Babka
2022-03-02 17:22       ` Hyeonggon Yoo
2022-02-25 18:03 ` [PATCH 3/5] mm/slub: aggregate and print stack traces in debugfs files Vlastimil Babka
2022-02-27  0:18   ` Hyeonggon Yoo
2022-02-27  0:22   ` Hyeonggon Yoo
2022-02-25 18:03 ` [PATCH 4/5] mm/slub: sort debugfs output by frequency of stack traces Vlastimil Babka
2022-02-26 11:03   ` Hyeonggon Yoo
2022-02-25 18:03 ` [PATCH 5/5] slab, documentation: add description of debugfs files for SLUB caches Vlastimil Babka
2022-02-27  3:49   ` Hyeonggon Yoo
2022-03-02 16:31     ` Vlastimil Babka
2022-02-26  7:19 ` [PATCH 0/5] SLUB debugfs improvements based on stackdepot Hyeonggon Yoo
2022-02-28 19:10   ` Vlastimil Babka
2022-02-28 20:01     ` Mike Rapoport
2022-02-28 21:20       ` Hyeonggon Yoo
2022-02-28 23:38       ` Vlastimil Babka
2022-03-01  9:21         ` Mike Rapoport
2022-03-01  9:41           ` Vlastimil Babka
2022-03-01 14:52             ` Mike Rapoport
2022-02-28 21:27     ` Hyeonggon Yoo
2022-03-01  9:23       ` Mike Rapoport
2022-03-02  8:37       ` Mike Rapoport
2022-03-02  9:09         ` Vlastimil Babka
2022-03-02 12:30           ` Mike Rapoport
2022-03-02 17:02             ` Hyeonggon Yoo
2022-03-02 17:27               ` Marco Elver
2022-02-26 12:18 ` Hyeonggon Yoo
2022-03-04 17:25   ` 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=d1bf599d-d680-192c-e7b8-12af7f4f5430@suse.cz \
    --to=vbabka@suse.cz \
    --cc=42.hyeyoo@gmail.com \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=akpm@linux-foundation.org \
    --cc=andreyknvl@gmail.com \
    --cc=arnd@arndb.de \
    --cc=cl@linux.com \
    --cc=dvyukov@google.com \
    --cc=edumazet@google.com \
    --cc=elver@google.com \
    --cc=faiyazm@codeaurora.org \
    --cc=glittao@gmail.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=imran.f.khan@oracle.com \
    --cc=jarkko@kernel.org \
    --cc=johannes.berg@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mcroce@microsoft.com \
    --cc=patches@lists.linux.dev \
    --cc=penberg@kernel.org \
    --cc=qiang.zhang@windriver.com \
    --cc=rientjes@google.com \
    --cc=roman.gushchin@linux.dev \
    --cc=yury.norov@gmail.com \
    /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: link
Be 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.