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

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090831090406.GA29228@linux-sh.org>
Date:	Mon, 31 Aug 2009 18:04:07 +0900
From:	Paul Mundt <lethal@...ux-sh.org>
To:	Catalin Marinas <catalin.marinas@....com>
Cc:	x86@...nel.org, linux-kernel@...r.kernel.org,
	Ingo Molnar <mingo@...hat.com>
Subject: Re: [PATCH 1/2] kmemleak: Inform kmemleak about kernel stack allocation

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@....com>
> Cc: Ingo Molnar <mingo@...hat.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. 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/