Re: [PATCH 1/2] kmemleak: Inform kmemleak about kernel stack allocation

[Paul Mundt <lethal@linux-sh.org>]

On Thu, Aug 27, 2009 at 06:02:53PM +0100, Catalin Marinas wrote:
> Traversing all the tasks in the system for scanning the kernel stacks
> requires locking which increases the kernel latency considerably. This
> patch informs kmemleak about newly allocated or freed stacks so that
> they are treated as any other allocated object. Subsequent patch will
> remove the explicit stack scanning from mm/kmemleak.c.
> 
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Ingo Molnar <mingo@redhat.com>
> ---
>  arch/x86/include/asm/thread_info.h |    7 ++++++-
>  arch/x86/kernel/process.c          |    2 ++
>  kernel/fork.c                      |    7 ++++++-
>  3 files changed, 14 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/include/asm/thread_info.h b/arch/x86/include/asm/thread_info.h
> index fad7d40..f26432a 100644
> --- a/arch/x86/include/asm/thread_info.h
> +++ b/arch/x86/include/asm/thread_info.h
> @@ -162,7 +162,12 @@ struct thread_info {
>  #define __HAVE_ARCH_THREAD_INFO_ALLOCATOR
>  
>  #define alloc_thread_info(tsk)						\
> -	((struct thread_info *)__get_free_pages(THREAD_FLAGS, THREAD_ORDER))
> +({									\
> +	struct thread_info *ti = (struct thread_info *)			\
> +		__get_free_pages(THREAD_FLAGS, THREAD_ORDER);		\
> +	kmemleak_alloc(ti, THREAD_SIZE, 1, THREAD_FLAGS);		\
> +	ti;								\
> +})
>
This looks like something that every __HAVE_ARCH_THREAD_INFO_ALLOCATOR
user is going to want to implement. Does it make sense to make this
addition prior to your removal of explicit scanning, or should folks hold
off on this until later in 2.6.32? In any event, this would probably be
worthwhile Cc'ing linux-arch on if you are posting an updated version,
given that there are 9 other architectures that will probably want to do
this, too.