linux-kernel - Re: [PATCHv3] mm: use stack_depot for recording kmemleak's backtrace

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <f53653bd-aab1-637e-c034-62761f262a03@suse.cz>
Date:   Mon, 31 Oct 2022 11:15:15 +0100
From:   Vlastimil Babka <vbabka@...e.cz>
To:     "zhaoyang.huang" <zhaoyang.huang@...soc.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Matthew Wilcox <willy@...radead.org>,
        Zhaoyang Huang <huangzhaoyang@...il.com>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, ke.wang@...soc.com,
        steve.kang@...soc.com
Subject: Re: [PATCHv3] mm: use stack_depot for recording kmemleak's backtrace

On 10/30/22 04:42, zhaoyang.huang wrote:
> From: Zhaoyang Huang <zhaoyang.huang@...soc.com>
> 
> Using stack_depot to record kmemleak's backtrace which has been implemented
> on slub for reducing redundant information.
> 
> Signed-off-by: Zhaoyang Huang <zhaoyang.huang@...soc.com>
> Acked-by: Catalin Marinas <catalin.marinas@....com>
> Cc: ke.wang <ke.wang@...soc.com>
> Cc: Matthew Wilcox (Oracle) <willy@...radead.org>
> Cc: Vlastimil Babka <vbabka@...e.cz>
> Cc: Zhaoyang Huang <huangzhaoyang@...il.com>
> Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
> ---
> changes of v2: fix bugs of stack_depot_init related issue
> changes of v3: have DEBUG_KMEMLEAK select STACK_DEPOT by default
>                remove unuse functions
> ---
> ---
>  lib/Kconfig.debug |  1 +
>  mm/kmemleak.c     | 48 +++++++++++++++++++++++++++++-------------------
>  2 files changed, 30 insertions(+), 19 deletions(-)
> 
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index bcbe60d..0def8e0 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -717,6 +717,7 @@ config DEBUG_KMEMLEAK
>  	select STACKTRACE if STACKTRACE_SUPPORT
>  	select KALLSYMS
>  	select CRC32
> +	select STACKDEPOT

Should be also "if STACKTRACE_SUPPORT" as for the "select STACKTRACE" above,
but then you would have to deal with the case that stackdepot isn't
available - e.g. like in mm/slub.c use #ifdef CONFIG_STACKDEPOT where needed.

However, the "select STACKTRACE if STACKTRACE_SUPPORT" above was AFAICS
already subtly broken as the existing stacktrace handling calls in kmemleak
would also fail to compile/link on architectures/configs where
STACKTRACE_SUPPORT was not available and thus STACKTRACE not selected.
I assume it all relies on "depends on DEBUG_KERNEL && HAVE_DEBUG_KMEMLEAK"
where HAVE_DEBUG_KMEMLEAK is explicitly selected in a number of
arch/$arch/Kconfig files, and I assume all those have STACKTRACE_SUPPORT
selected as well.

But it's subtle and in that case we could just be more explicit, like
page_owner is, which just requires STACKTRACE/STACKDEPOT explicitly on
Kconfig level:

depends on DEBUG_KERNEL && STACKTRACE_SUPPORT
  (for kmemleak we would add HAVE_DEBUG_KMEMLEAK too)
select STACKTRACE
select STACKDEPOT

bonus points for moving the kmemleak config from lib/Kconfig.debug to
mm/Kconfig.debug - looks like we missed it in the cleanups earlier this year.

>  	help
>  	  Say Y here if you want to enable the memory leak
>  	  detector. The memory allocation/freeing is traced in a way

...

>  
> -/*
> - * Save stack trace to the given array of MAX_TRACE size.
> - */
> -static int __save_stack_trace(unsigned long *trace)
> +static noinline depot_stack_handle_t set_track_prepare(void)
>  {
> -	return stack_trace_save(trace, MAX_TRACE, 2);
> +	depot_stack_handle_t trace_handle;
> +	unsigned long entries[MAX_TRACE];
> +	unsigned int nr_entries;
> +
> +	if (!kmemleak_initialized)
> +		return 0;

I suspect this check might not be necessary if you switched from
stack_depot_init() to stack_depot_want_early_init(), see how page_owner does
this in early_page_owner_param().

Here we have kmemleak_boot_config() but it's more tricky as not having any
kmemleak param means it should be enabled by default and then the function
is not called at all, hm. Maybe use an early_initcall()?

> +	nr_entries = stack_trace_save(entries, ARRAY_SIZE(entries), 3);
> +	trace_handle = stack_depot_save(entries, nr_entries, GFP_NOWAIT);
> +
> +	return trace_handle;
>  }
>  
>  /*
> @@ -654,7 +664,7 @@ static struct kmemleak_object *__create_object(unsigned long ptr, size_t size,
>  	}
>  
>  	/* kernel backtrace */
> -	object->trace_len = __save_stack_trace(object->trace);
> +	object->trace_handle = set_track_prepare();
>  
>  	raw_spin_lock_irqsave(&kmemleak_lock, flags);
>  
> @@ -694,7 +704,6 @@ static struct kmemleak_object *__create_object(unsigned long ptr, size_t size,
>  	rb_link_node(&object->rb_node, rb_parent, link);
>  	rb_insert_color(&object->rb_node, is_phys ? &object_phys_tree_root :
>  					  &object_tree_root);
> -
>  	list_add_tail_rcu(&object->object_list, &object_list);
>  out:
>  	raw_spin_unlock_irqrestore(&kmemleak_lock, flags);
> @@ -1094,7 +1103,7 @@ void __ref kmemleak_update_trace(const void *ptr)
>  	}
>  
>  	raw_spin_lock_irqsave(&object->lock, flags);
> -	object->trace_len = __save_stack_trace(object->trace);
> +	object->trace_handle = set_track_prepare();
>  	raw_spin_unlock_irqrestore(&object->lock, flags);
>  
>  	put_object(object);
> @@ -2064,6 +2073,7 @@ void __init kmemleak_init(void)
>  	if (kmemleak_error)
>  		return;
>  
> +	stack_depot_init();
>  	jiffies_min_age = msecs_to_jiffies(MSECS_MIN_AGE);
>  	jiffies_scan_wait = msecs_to_jiffies(SECS_SCAN_WAIT * 1000);
>