All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] [PATCH] mm, slub: enable slub_debug static key when creating cache with explicit debug flags
@ 2021-03-15 15:34 Vlastimil Babka
  2021-03-15 17:16   ` David Rientjes
  0 siblings, 1 reply; 7+ messages in thread
From: Vlastimil Babka @ 2021-03-15 15:34 UTC (permalink / raw)
  To: Andrew Morton, Christoph Lameter, Pekka Enberg, David Rientjes,
	Joonsoo Kim
  Cc: linux-mm, linux-kernel, Paul E . McKenney, linux-btrfs,
	David Sterba, Vlastimil Babka, Oliver Glitta

Commit ca0cab65ea2b ("mm, slub: introduce static key for slub_debug()")
introduced a static key to optimize the case where no debugging is enabled for
any cache. The static key is enabled when slub_debug boot parameter is passed,
or CONFIG_SLUB_DEBUG_ON enabled.

However, some caches might be created with one or more debugging flags
explicitly passed to kmem_cache_create(), and the commit missed this. Thus the
debugging functionality would not be actually performed for these caches unless
the static key gets enabled by boot param or config.

This patch fixes it by checking for debugging flags passed to
kmem_cache_create() and enabling the static key accordingly.

Note such explicit debugging flags should not be used outside of debugging and
testing as they will now enable the static key globally. btrfs_init_cachep()
creates a cache with SLAB_RED_ZONE but that's a mistake that's being corrected
[1]. rcu_torture_stats() creates a cache with SLAB_STORE_USER, but that is a
testing module so it's OK and will start working as intended after this patch.

Also note that in case of backports to kernels before v5.12 that don't have
59450bbc12be ("mm, slab, slub: stop taking cpu hotplug lock"),
static_branch_enable_cpuslocked() should be used.

[1] https://lore.kernel.org/linux-btrfs/20210315141824.26099-1-dsterba@suse.com/

Reported-by: Oliver Glitta <glittao@gmail.com>
Fixes: ca0cab65ea2b ("mm, slub: introduce static key for slub_debug()")
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
---
 mm/slub.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/mm/slub.c b/mm/slub.c
index 350a37f30e60..cd6694ad1a0a 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -3827,6 +3827,15 @@ static int calculate_sizes(struct kmem_cache *s, int forced_order)
 
 static int kmem_cache_open(struct kmem_cache *s, slab_flags_t flags)
 {
+#ifdef CONFIG_SLUB_DEBUG
+	/*
+	 * If no slub_debug was enabled globally, the static key is not yet
+	 * enabled by setup_slub_debug(). Enable it if the cache is being
+	 * created with any of the debugging flags passed explicitly.
+	 */
+	if (flags & SLAB_DEBUG_FLAGS)
+		static_branch_enable(&slub_debug_enabled);
+#endif
 	s->flags = kmem_cache_flags(s->size, flags, s->name);
 #ifdef CONFIG_SLAB_FREELIST_HARDENED
 	s->random = get_random_long();
-- 
2.30.1


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] [PATCH] mm, slub: enable slub_debug static key when creating cache with explicit debug flags
  2021-03-15 15:34 [PATCH] [PATCH] mm, slub: enable slub_debug static key when creating cache with explicit debug flags Vlastimil Babka
@ 2021-03-15 17:16   ` David Rientjes
  0 siblings, 0 replies; 7+ messages in thread
From: David Rientjes @ 2021-03-15 17:16 UTC (permalink / raw)
  To: Vlastimil Babka
  Cc: Andrew Morton, Christoph Lameter, Pekka Enberg, Joonsoo Kim,
	linux-mm, linux-kernel, Paul E . McKenney, linux-btrfs,
	David Sterba, Oliver Glitta

On Mon, 15 Mar 2021, Vlastimil Babka wrote:

> Commit ca0cab65ea2b ("mm, slub: introduce static key for slub_debug()")
> introduced a static key to optimize the case where no debugging is enabled for
> any cache. The static key is enabled when slub_debug boot parameter is passed,
> or CONFIG_SLUB_DEBUG_ON enabled.
> 
> However, some caches might be created with one or more debugging flags
> explicitly passed to kmem_cache_create(), and the commit missed this. Thus the
> debugging functionality would not be actually performed for these caches unless
> the static key gets enabled by boot param or config.
> 
> This patch fixes it by checking for debugging flags passed to
> kmem_cache_create() and enabling the static key accordingly.
> 
> Note such explicit debugging flags should not be used outside of debugging and
> testing as they will now enable the static key globally. btrfs_init_cachep()
> creates a cache with SLAB_RED_ZONE but that's a mistake that's being corrected
> [1]. rcu_torture_stats() creates a cache with SLAB_STORE_USER, but that is a
> testing module so it's OK and will start working as intended after this patch.
> 
> Also note that in case of backports to kernels before v5.12 that don't have
> 59450bbc12be ("mm, slab, slub: stop taking cpu hotplug lock"),
> static_branch_enable_cpuslocked() should be used.
> 

Since this affects 5.9+, is the plan to propose backports to stable with 
static_branch_enable_cpuslocked() once this is merged?  (I notice the 
absence of the stable tag here, which I believe is intended.)

> [1] https://lore.kernel.org/linux-btrfs/20210315141824.26099-1-dsterba@suse.com/
> 
> Reported-by: Oliver Glitta <glittao@gmail.com>
> Fixes: ca0cab65ea2b ("mm, slub: introduce static key for slub_debug()")
> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>

Acked-by: David Rientjes <rientjes@google.com>

> ---
>  mm/slub.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/mm/slub.c b/mm/slub.c
> index 350a37f30e60..cd6694ad1a0a 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -3827,6 +3827,15 @@ static int calculate_sizes(struct kmem_cache *s, int forced_order)
>  
>  static int kmem_cache_open(struct kmem_cache *s, slab_flags_t flags)
>  {
> +#ifdef CONFIG_SLUB_DEBUG
> +	/*
> +	 * If no slub_debug was enabled globally, the static key is not yet
> +	 * enabled by setup_slub_debug(). Enable it if the cache is being
> +	 * created with any of the debugging flags passed explicitly.
> +	 */
> +	if (flags & SLAB_DEBUG_FLAGS)
> +		static_branch_enable(&slub_debug_enabled);
> +#endif
>  	s->flags = kmem_cache_flags(s->size, flags, s->name);
>  #ifdef CONFIG_SLAB_FREELIST_HARDENED
>  	s->random = get_random_long();

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] [PATCH] mm, slub: enable slub_debug static key when creating cache with explicit debug flags
@ 2021-03-15 17:16   ` David Rientjes
  0 siblings, 0 replies; 7+ messages in thread
From: David Rientjes @ 2021-03-15 17:16 UTC (permalink / raw)
  To: Vlastimil Babka
  Cc: Andrew Morton, Christoph Lameter, Pekka Enberg, Joonsoo Kim,
	linux-mm, linux-kernel, Paul E . McKenney, linux-btrfs,
	David Sterba, Oliver Glitta

On Mon, 15 Mar 2021, Vlastimil Babka wrote:

> Commit ca0cab65ea2b ("mm, slub: introduce static key for slub_debug()")
> introduced a static key to optimize the case where no debugging is enabled for
> any cache. The static key is enabled when slub_debug boot parameter is passed,
> or CONFIG_SLUB_DEBUG_ON enabled.
> 
> However, some caches might be created with one or more debugging flags
> explicitly passed to kmem_cache_create(), and the commit missed this. Thus the
> debugging functionality would not be actually performed for these caches unless
> the static key gets enabled by boot param or config.
> 
> This patch fixes it by checking for debugging flags passed to
> kmem_cache_create() and enabling the static key accordingly.
> 
> Note such explicit debugging flags should not be used outside of debugging and
> testing as they will now enable the static key globally. btrfs_init_cachep()
> creates a cache with SLAB_RED_ZONE but that's a mistake that's being corrected
> [1]. rcu_torture_stats() creates a cache with SLAB_STORE_USER, but that is a
> testing module so it's OK and will start working as intended after this patch.
> 
> Also note that in case of backports to kernels before v5.12 that don't have
> 59450bbc12be ("mm, slab, slub: stop taking cpu hotplug lock"),
> static_branch_enable_cpuslocked() should be used.
> 

Since this affects 5.9+, is the plan to propose backports to stable with 
static_branch_enable_cpuslocked() once this is merged?  (I notice the 
absence of the stable tag here, which I believe is intended.)

> [1] https://lore.kernel.org/linux-btrfs/20210315141824.26099-1-dsterba@suse.com/
> 
> Reported-by: Oliver Glitta <glittao@gmail.com>
> Fixes: ca0cab65ea2b ("mm, slub: introduce static key for slub_debug()")
> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>

Acked-by: David Rientjes <rientjes@google.com>

> ---
>  mm/slub.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/mm/slub.c b/mm/slub.c
> index 350a37f30e60..cd6694ad1a0a 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -3827,6 +3827,15 @@ static int calculate_sizes(struct kmem_cache *s, int forced_order)
>  
>  static int kmem_cache_open(struct kmem_cache *s, slab_flags_t flags)
>  {
> +#ifdef CONFIG_SLUB_DEBUG
> +	/*
> +	 * If no slub_debug was enabled globally, the static key is not yet
> +	 * enabled by setup_slub_debug(). Enable it if the cache is being
> +	 * created with any of the debugging flags passed explicitly.
> +	 */
> +	if (flags & SLAB_DEBUG_FLAGS)
> +		static_branch_enable(&slub_debug_enabled);
> +#endif
>  	s->flags = kmem_cache_flags(s->size, flags, s->name);
>  #ifdef CONFIG_SLAB_FREELIST_HARDENED
>  	s->random = get_random_long();


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] [PATCH] mm, slub: enable slub_debug static key when creating cache with explicit debug flags
  2021-03-15 17:16   ` David Rientjes
  (?)
@ 2021-03-15 17:28   ` Vlastimil Babka
  2021-03-15 17:32     ` Paul E. McKenney
  -1 siblings, 1 reply; 7+ messages in thread
From: Vlastimil Babka @ 2021-03-15 17:28 UTC (permalink / raw)
  To: David Rientjes
  Cc: Andrew Morton, Christoph Lameter, Pekka Enberg, Joonsoo Kim,
	linux-mm, linux-kernel, Paul E . McKenney, linux-btrfs,
	David Sterba, Oliver Glitta

On 3/15/21 6:16 PM, David Rientjes wrote:
> On Mon, 15 Mar 2021, Vlastimil Babka wrote:
> 
>> Commit ca0cab65ea2b ("mm, slub: introduce static key for slub_debug()")
>> introduced a static key to optimize the case where no debugging is enabled for
>> any cache. The static key is enabled when slub_debug boot parameter is passed,
>> or CONFIG_SLUB_DEBUG_ON enabled.
>> 
>> However, some caches might be created with one or more debugging flags
>> explicitly passed to kmem_cache_create(), and the commit missed this. Thus the
>> debugging functionality would not be actually performed for these caches unless
>> the static key gets enabled by boot param or config.
>> 
>> This patch fixes it by checking for debugging flags passed to
>> kmem_cache_create() and enabling the static key accordingly.
>> 
>> Note such explicit debugging flags should not be used outside of debugging and
>> testing as they will now enable the static key globally. btrfs_init_cachep()
>> creates a cache with SLAB_RED_ZONE but that's a mistake that's being corrected
>> [1]. rcu_torture_stats() creates a cache with SLAB_STORE_USER, but that is a
>> testing module so it's OK and will start working as intended after this patch.
>> 
>> Also note that in case of backports to kernels before v5.12 that don't have
>> 59450bbc12be ("mm, slab, slub: stop taking cpu hotplug lock"),
>> static_branch_enable_cpuslocked() should be used.
>> 
> 
> Since this affects 5.9+, is the plan to propose backports to stable with 
> static_branch_enable_cpuslocked() once this is merged?  (I notice the 
> absence of the stable tag here, which I believe is intended.)

I was thinking about it, and since the rcutorture user is only in -next (AFAICS)
and btrfs user was unintended, it didn't seem to meet stable criteria to me. But
I won't mind if it's backported.

>> [1] https://lore.kernel.org/linux-btrfs/20210315141824.26099-1-dsterba@suse.com/
>> 
>> Reported-by: Oliver Glitta <glittao@gmail.com>
>> Fixes: ca0cab65ea2b ("mm, slub: introduce static key for slub_debug()")
>> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
> 
> Acked-by: David Rientjes <rientjes@google.com>

Thanks!

>> ---
>>  mm/slub.c | 9 +++++++++
>>  1 file changed, 9 insertions(+)
>> 
>> diff --git a/mm/slub.c b/mm/slub.c
>> index 350a37f30e60..cd6694ad1a0a 100644
>> --- a/mm/slub.c
>> +++ b/mm/slub.c
>> @@ -3827,6 +3827,15 @@ static int calculate_sizes(struct kmem_cache *s, int forced_order)
>>  
>>  static int kmem_cache_open(struct kmem_cache *s, slab_flags_t flags)
>>  {
>> +#ifdef CONFIG_SLUB_DEBUG
>> +	/*
>> +	 * If no slub_debug was enabled globally, the static key is not yet
>> +	 * enabled by setup_slub_debug(). Enable it if the cache is being
>> +	 * created with any of the debugging flags passed explicitly.
>> +	 */
>> +	if (flags & SLAB_DEBUG_FLAGS)
>> +		static_branch_enable(&slub_debug_enabled);
>> +#endif
>>  	s->flags = kmem_cache_flags(s->size, flags, s->name);
>>  #ifdef CONFIG_SLAB_FREELIST_HARDENED
>>  	s->random = get_random_long();
> 


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] [PATCH] mm, slub: enable slub_debug static key when creating cache with explicit debug flags
  2021-03-15 17:28   ` Vlastimil Babka
@ 2021-03-15 17:32     ` Paul E. McKenney
  2021-03-15 17:36       ` Vlastimil Babka
  0 siblings, 1 reply; 7+ messages in thread
From: Paul E. McKenney @ 2021-03-15 17:32 UTC (permalink / raw)
  To: Vlastimil Babka
  Cc: David Rientjes, Andrew Morton, Christoph Lameter, Pekka Enberg,
	Joonsoo Kim, linux-mm, linux-kernel, linux-btrfs, David Sterba,
	Oliver Glitta

On Mon, Mar 15, 2021 at 06:28:42PM +0100, Vlastimil Babka wrote:
> On 3/15/21 6:16 PM, David Rientjes wrote:
> > On Mon, 15 Mar 2021, Vlastimil Babka wrote:
> > 
> >> Commit ca0cab65ea2b ("mm, slub: introduce static key for slub_debug()")
> >> introduced a static key to optimize the case where no debugging is enabled for
> >> any cache. The static key is enabled when slub_debug boot parameter is passed,
> >> or CONFIG_SLUB_DEBUG_ON enabled.
> >> 
> >> However, some caches might be created with one or more debugging flags
> >> explicitly passed to kmem_cache_create(), and the commit missed this. Thus the
> >> debugging functionality would not be actually performed for these caches unless
> >> the static key gets enabled by boot param or config.
> >> 
> >> This patch fixes it by checking for debugging flags passed to
> >> kmem_cache_create() and enabling the static key accordingly.
> >> 
> >> Note such explicit debugging flags should not be used outside of debugging and
> >> testing as they will now enable the static key globally. btrfs_init_cachep()
> >> creates a cache with SLAB_RED_ZONE but that's a mistake that's being corrected
> >> [1]. rcu_torture_stats() creates a cache with SLAB_STORE_USER, but that is a
> >> testing module so it's OK and will start working as intended after this patch.
> >> 
> >> Also note that in case of backports to kernels before v5.12 that don't have
> >> 59450bbc12be ("mm, slab, slub: stop taking cpu hotplug lock"),
> >> static_branch_enable_cpuslocked() should be used.
> >> 
> > 
> > Since this affects 5.9+, is the plan to propose backports to stable with 
> > static_branch_enable_cpuslocked() once this is merged?  (I notice the 
> > absence of the stable tag here, which I believe is intended.)
> 
> I was thinking about it, and since the rcutorture user is only in -next (AFAICS)
> and btrfs user was unintended, it didn't seem to meet stable criteria to me. But
> I won't mind if it's backported.

I had better ask...  Should rcutorture be doing something different?

							Thanx, Paul

> >> [1] https://lore.kernel.org/linux-btrfs/20210315141824.26099-1-dsterba@suse.com/
> >> 
> >> Reported-by: Oliver Glitta <glittao@gmail.com>
> >> Fixes: ca0cab65ea2b ("mm, slub: introduce static key for slub_debug()")
> >> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
> > 
> > Acked-by: David Rientjes <rientjes@google.com>
> 
> Thanks!
> 
> >> ---
> >>  mm/slub.c | 9 +++++++++
> >>  1 file changed, 9 insertions(+)
> >> 
> >> diff --git a/mm/slub.c b/mm/slub.c
> >> index 350a37f30e60..cd6694ad1a0a 100644
> >> --- a/mm/slub.c
> >> +++ b/mm/slub.c
> >> @@ -3827,6 +3827,15 @@ static int calculate_sizes(struct kmem_cache *s, int forced_order)
> >>  
> >>  static int kmem_cache_open(struct kmem_cache *s, slab_flags_t flags)
> >>  {
> >> +#ifdef CONFIG_SLUB_DEBUG
> >> +	/*
> >> +	 * If no slub_debug was enabled globally, the static key is not yet
> >> +	 * enabled by setup_slub_debug(). Enable it if the cache is being
> >> +	 * created with any of the debugging flags passed explicitly.
> >> +	 */
> >> +	if (flags & SLAB_DEBUG_FLAGS)
> >> +		static_branch_enable(&slub_debug_enabled);
> >> +#endif
> >>  	s->flags = kmem_cache_flags(s->size, flags, s->name);
> >>  #ifdef CONFIG_SLAB_FREELIST_HARDENED
> >>  	s->random = get_random_long();
> > 
> 

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] [PATCH] mm, slub: enable slub_debug static key when creating cache with explicit debug flags
  2021-03-15 17:32     ` Paul E. McKenney
@ 2021-03-15 17:36       ` Vlastimil Babka
  2021-03-15 17:59         ` Paul E. McKenney
  0 siblings, 1 reply; 7+ messages in thread
From: Vlastimil Babka @ 2021-03-15 17:36 UTC (permalink / raw)
  To: paulmck
  Cc: David Rientjes, Andrew Morton, Christoph Lameter, Pekka Enberg,
	Joonsoo Kim, linux-mm, linux-kernel, linux-btrfs, David Sterba,
	Oliver Glitta

On 3/15/21 6:32 PM, Paul E. McKenney wrote:
> On Mon, Mar 15, 2021 at 06:28:42PM +0100, Vlastimil Babka wrote:
>> On 3/15/21 6:16 PM, David Rientjes wrote:
>> > On Mon, 15 Mar 2021, Vlastimil Babka wrote:
>> > 
>> >> Commit ca0cab65ea2b ("mm, slub: introduce static key for slub_debug()")
>> >> introduced a static key to optimize the case where no debugging is enabled for
>> >> any cache. The static key is enabled when slub_debug boot parameter is passed,
>> >> or CONFIG_SLUB_DEBUG_ON enabled.
>> >> 
>> >> However, some caches might be created with one or more debugging flags
>> >> explicitly passed to kmem_cache_create(), and the commit missed this. Thus the
>> >> debugging functionality would not be actually performed for these caches unless
>> >> the static key gets enabled by boot param or config.
>> >> 
>> >> This patch fixes it by checking for debugging flags passed to
>> >> kmem_cache_create() and enabling the static key accordingly.
>> >> 
>> >> Note such explicit debugging flags should not be used outside of debugging and
>> >> testing as they will now enable the static key globally. btrfs_init_cachep()
>> >> creates a cache with SLAB_RED_ZONE but that's a mistake that's being corrected
>> >> [1]. rcu_torture_stats() creates a cache with SLAB_STORE_USER, but that is a
>> >> testing module so it's OK and will start working as intended after this patch.
>> >> 
>> >> Also note that in case of backports to kernels before v5.12 that don't have
>> >> 59450bbc12be ("mm, slab, slub: stop taking cpu hotplug lock"),
>> >> static_branch_enable_cpuslocked() should be used.
>> >> 
>> > 
>> > Since this affects 5.9+, is the plan to propose backports to stable with 
>> > static_branch_enable_cpuslocked() once this is merged?  (I notice the 
>> > absence of the stable tag here, which I believe is intended.)
>> 
>> I was thinking about it, and since the rcutorture user is only in -next (AFAICS)
>> and btrfs user was unintended, it didn't seem to meet stable criteria to me. But
>> I won't mind if it's backported.
> 
> I had better ask...  Should rcutorture be doing something different?
> 
> 							Thanx, Paul

No, I think it's fine if a testing module such as rcutorture flips the static
key for the rest of the kernel's uptime. I only CC'd you as FYI in case you were
wondering why you can't see any alloc/free stacks in its output :)

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] [PATCH] mm, slub: enable slub_debug static key when creating cache with explicit debug flags
  2021-03-15 17:36       ` Vlastimil Babka
@ 2021-03-15 17:59         ` Paul E. McKenney
  0 siblings, 0 replies; 7+ messages in thread
From: Paul E. McKenney @ 2021-03-15 17:59 UTC (permalink / raw)
  To: Vlastimil Babka
  Cc: David Rientjes, Andrew Morton, Christoph Lameter, Pekka Enberg,
	Joonsoo Kim, linux-mm, linux-kernel, linux-btrfs, David Sterba,
	Oliver Glitta

On Mon, Mar 15, 2021 at 06:36:34PM +0100, Vlastimil Babka wrote:
> On 3/15/21 6:32 PM, Paul E. McKenney wrote:
> > On Mon, Mar 15, 2021 at 06:28:42PM +0100, Vlastimil Babka wrote:
> >> On 3/15/21 6:16 PM, David Rientjes wrote:
> >> > On Mon, 15 Mar 2021, Vlastimil Babka wrote:
> >> > 
> >> >> Commit ca0cab65ea2b ("mm, slub: introduce static key for slub_debug()")
> >> >> introduced a static key to optimize the case where no debugging is enabled for
> >> >> any cache. The static key is enabled when slub_debug boot parameter is passed,
> >> >> or CONFIG_SLUB_DEBUG_ON enabled.
> >> >> 
> >> >> However, some caches might be created with one or more debugging flags
> >> >> explicitly passed to kmem_cache_create(), and the commit missed this. Thus the
> >> >> debugging functionality would not be actually performed for these caches unless
> >> >> the static key gets enabled by boot param or config.
> >> >> 
> >> >> This patch fixes it by checking for debugging flags passed to
> >> >> kmem_cache_create() and enabling the static key accordingly.
> >> >> 
> >> >> Note such explicit debugging flags should not be used outside of debugging and
> >> >> testing as they will now enable the static key globally. btrfs_init_cachep()
> >> >> creates a cache with SLAB_RED_ZONE but that's a mistake that's being corrected
> >> >> [1]. rcu_torture_stats() creates a cache with SLAB_STORE_USER, but that is a
> >> >> testing module so it's OK and will start working as intended after this patch.
> >> >> 
> >> >> Also note that in case of backports to kernels before v5.12 that don't have
> >> >> 59450bbc12be ("mm, slab, slub: stop taking cpu hotplug lock"),
> >> >> static_branch_enable_cpuslocked() should be used.
> >> >> 
> >> > 
> >> > Since this affects 5.9+, is the plan to propose backports to stable with 
> >> > static_branch_enable_cpuslocked() once this is merged?  (I notice the 
> >> > absence of the stable tag here, which I believe is intended.)
> >> 
> >> I was thinking about it, and since the rcutorture user is only in -next (AFAICS)
> >> and btrfs user was unintended, it didn't seem to meet stable criteria to me. But
> >> I won't mind if it's backported.
> > 
> > I had better ask...  Should rcutorture be doing something different?
> > 
> > 							Thanx, Paul
> 
> No, I think it's fine if a testing module such as rcutorture flips the static
> key for the rest of the kernel's uptime. I only CC'd you as FYI in case you were
> wondering why you can't see any alloc/free stacks in its output :)

Ah, all of my recent tests have been for sufficient duration that all
was well by the time that that code was invoked.  But thank you for the
heads up -- someone will hit this sooner or later, and I freely confess
that I would have been clueless.

							Thanx, Paul

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2021-03-15 18:00 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-15 15:34 [PATCH] [PATCH] mm, slub: enable slub_debug static key when creating cache with explicit debug flags Vlastimil Babka
2021-03-15 17:16 ` David Rientjes
2021-03-15 17:16   ` David Rientjes
2021-03-15 17:28   ` Vlastimil Babka
2021-03-15 17:32     ` Paul E. McKenney
2021-03-15 17:36       ` Vlastimil Babka
2021-03-15 17:59         ` Paul E. McKenney

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.