From: Ingo Molnar <mingo@elte.hu>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andi Kleen <andi@firstfloor.org>,
fengguang.wu@intel.com, linux-kernel@vger.kernel.org,
akpm@linux-foundation.org, "H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>,
Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: [PATCH] x86: Fix hwpoison code related build failure on 32-bit NUMAQ
Date: Sat, 26 Sep 2009 20:10:37 +0200 [thread overview]
Message-ID: <20090926181037.GA4666@elte.hu> (raw)
In-Reply-To: <alpine.LFD.2.01.0909261038510.3303@localhost.localdomain>
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Sat, 26 Sep 2009, Ingo Molnar wrote:
> > >
> > > +config X86_SUPPORTS_MEMORY_FAILURE
> > > + bool
> > > + depends on !X86_NUMAQ
> > > + select ARCH_SUPPORTS_MEMORY_FAILURE
> > > + default y
> >
> > Thanks Linus, this patch fixed the NUMAQ build problem.
>
> I think it's slightly buggy still.
>
> I think the X86_SUPPORTS_MEMORY_FAILURE thing should also have a
>
> depends on X86_MCE
>
> line, because we still depend on MCE.
Yeah.
( Note, it should not necessarily depend on it: while the only hw
mechanism that calls memory_failure() is indeed MCE, the act of having
a memory-failures subsystem does not depend on the presence of an x86
MCE subsystem. There's for example the injection debug-code which
allows the injection of memory_failure() calls. That should work fine
without having MCE build in as well.
But that is a separate change. )
> And as you found out, there's also the sparsemem thing.
>
> Don't make it one huge ugly thing, just split out the requirements like
>
> depends on X86_MCE
> depends on !X86_NUMAQ
> depends on X86_64 || !SPARSEMEM
>
> because I think the requirements are fairly independent, and it makes
> it easier to read (you could even comment each line on why _that_
> particular issue needs to disable X86_SUPPORTS_MEMORY_FAILURE)
Good idea, have done that too.
> But yeah, with that, and some testing, please add my sign-off (or
> acked-by, if you end up changing the patch so much that it has little
> to do with my original one)
It's still mostly your patch so i've added your SOB, thanks. Below is
the updated patch.
btw., i think mm/memory-failure.c needs similar cleanups to
ARCH_SUPPORTS_MEMORY_FAILURE.
Right now it is full of x86 details, not sure that is right. 'MCE' for
example is an x86 expression and goes way beyond just memory errors - it
stands for 'Machine Check Exception' and covers IO/bus errors, etc.
We even put 'MCE' into new ABI details in include/asm-generic/siginfo.h:
/* hardware memory error consumed on a machine check: action required */
#define BUS_MCEERR_AR (__SI_FAULT|4)
/* hardware memory error detected in process but not consumed: action optional*/
#define BUS_MCEERR_AO (__SI_FAULT|5)
#define NSIGBUS 5
That should be fixed to be something like:
BUS_MEMERR_MANDATORY
BUS_MEMERR_OPTIONAL
before such a kernel is released, IMHO.
In mm/memory-failure.c i find the 'ao' / 'ar' abbreviations rather
unreadable as well - they are totally meaningless (to me at least),
even if i know the code.
Same goes for the me_*() prefixes.
Also, 'struct to_kill' ....
Ingo
next prev parent reply other threads:[~2009-09-26 18:10 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-16 12:51 [PULL] Please pull hwpoison code for 2.6.32 Andi Kleen
2009-09-26 14:13 ` [origin tree build failure] " Ingo Molnar
2009-09-26 15:17 ` Andi Kleen
2009-09-26 16:20 ` Andi Kleen
2009-09-26 17:28 ` Andi Kleen
2009-09-26 18:20 ` Andi Kleen
2009-09-26 16:35 ` Linus Torvalds
2009-09-26 17:35 ` [PATCH] x86: Fix hwpoison code related build failure on 32-bit NUMAQ Ingo Molnar
2009-09-26 17:43 ` Linus Torvalds
2009-09-26 18:10 ` Ingo Molnar [this message]
2009-09-26 18:12 ` Ingo Molnar
2009-09-26 18:11 ` [origin tree build failure] Re: [PULL] Please pull hwpoison code for 2.6.32 Andi Kleen
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=20090926181037.GA4666@elte.hu \
--to=mingo@elte.hu \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=fengguang.wu@intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.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.