From: Ingo Molnar <mingo@elte.hu>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
Ingo Molnar <mingo@redhat.com>
Subject: Re: [PATCH 1/2] kmemleak: Inform kmemleak about kernel stack allocation
Date: Fri, 4 Sep 2009 08:57:45 +0200 [thread overview]
Message-ID: <20090904065745.GE29829@elte.hu> (raw)
In-Reply-To: <1251797114.10349.28.camel@pc1117.cambridge.arm.com>
* Catalin Marinas <catalin.marinas@arm.com> wrote:
> On Mon, 2009-08-31 at 10:45 +0200, Ingo Molnar wrote:
> > * Catalin Marinas <catalin.marinas@arm.com> wrote:
> >
> > > On Sat, 2009-08-29 at 15:29 +0200, Ingo Molnar wrote:
> > > > * Catalin Marinas <catalin.marinas@arm.com> wrote:
> [...]
> > > > > 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; \
> > > > > +})
> > > >
> > > > Sidenote:this used to be a trivial wrapper to gfp so it was
> > > > borderline OK as a CPP macro - now it's a non-trivial CPP wrapper
> > > > macro which is not OK. Mind converting it to an inline function?
> > >
> > > I tried this first but got compilation errors in files that didn't
> > > even call this function. To make it workable, thread_info.h would
> > > need to include additional headers. If that's acceptable, I can
> > > post an updated patch.
> >
> > I havent tried the patch myself, but by your description those build
> > problems seem to be pre-existing include file dependency problems
> > that should be tracked down and resolved - instead of widening them
> > by adding even more hidden dependencies via CPP macros.
>
> I tried to move to an inline function and linux/gfp.h is needed for
> __get_free_pages() and GFP_* macros. This leads to some complicated
> circular dependencies like below:
>
> CC arch/x86/kernel/asm-offsets.s
> In file included from /work/Linux/2.6/linux-2.6-arm/include/linux/mmzone.h:9,
> from /work/Linux/2.6/linux-2.6-arm/include/linux/gfp.h:4,
> from /work/Linux/2.6/linux-2.6-arm/arch/x86/include/asm/thread_info.h:22,
> from /work/Linux/2.6/linux-2.6-arm/include/linux/thread_info.h:56,
> from /work/Linux/2.6/linux-2.6-arm/include/linux/preempt.h:9,
> from /work/Linux/2.6/linux-2.6-arm/include/linux/spinlock.h:50,
> from /work/Linux/2.6/linux-2.6-arm/include/linux/seqlock.h:29,
> from /work/Linux/2.6/linux-2.6-arm/include/linux/time.h:8,
> from /work/Linux/2.6/linux-2.6-arm/include/linux/stat.h:60,
> from /work/Linux/2.6/linux-2.6-arm/include/linux/module.h:10,
> from /work/Linux/2.6/linux-2.6-arm/include/linux/crypto.h:21,
> from /work/Linux/2.6/linux-2.6-arm/arch/x86/kernel/asm-offsets_32.c:7,
> from /work/Linux/2.6/linux-2.6-arm/arch/x86/kernel/asm-offsets.c:2:
> include/linux/wait.h|51| error: expected specifier-qualifier-list before ???spinlock_t???
>
> The linux/mmzone.h file normally includes linux/spinlock.h but the
> reverse is also true when the latter includes the former via
> thread_info.h and gfp.h. Because of the (correct) guards in the
> header files, the spinlock_t definition is no longer available in
> mmzone.h.
mmzone.h probably should not include spinlock.h (which is heavy) -
it should include spinlock_types.h (which is lighter). It only needs
the type definitions and none of the API definitions.
Ingo
next prev parent reply other threads:[~2009-09-04 6:58 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-27 17:02 [PATCH 0/2] kmemleak: x86-related patches Catalin Marinas
2009-08-27 17:02 ` [PATCH 1/2] kmemleak: Inform kmemleak about kernel stack allocation Catalin Marinas
2009-08-29 13:29 ` Ingo Molnar
2009-08-29 14:28 ` Catalin Marinas
2009-08-29 15:08 ` Catalin Marinas
2009-08-31 8:45 ` Ingo Molnar
2009-09-01 9:25 ` Catalin Marinas
2009-09-04 6:57 ` Ingo Molnar [this message]
2009-09-04 14:45 ` Catalin Marinas
2009-08-31 9:04 ` Paul Mundt
2009-08-27 17:02 ` [PATCH 2/2] kmemleak: Ignore the aperture memory hole on x86_64 Catalin Marinas
2009-08-29 13:31 ` Ingo Molnar
2009-08-29 14:30 ` Catalin Marinas
2009-08-31 8:38 ` Ingo Molnar
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=20090904065745.GE29829@elte.hu \
--to=mingo@elte.hu \
--cc=catalin.marinas@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=x86@kernel.org \
/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.