All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.