[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090612112258.GA14123@elte.hu>
Date: Fri, 12 Jun 2009 13:22:58 +0200
From: Ingo Molnar <mingo@...e.hu>
To: Wu Fengguang <fengguang.wu@...el.com>,
Thomas Gleixner <tglx@...utronix.de>,
"H. Peter Anvin" <hpa@...or.com>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>,
Nick Piggin <npiggin@...e.de>,
Hugh Dickins <hugh.dickins@...cali.co.uk>,
Andi Kleen <andi@...stfloor.org>,
"riel@...hat.com" <riel@...hat.com>,
"chris.mason@...cle.com" <chris.mason@...cle.com>,
"linux-mm@...ck.org" <linux-mm@...ck.org>
Subject: Re: [PATCH 1/5] HWPOISON: define VM_FAULT_HWPOISON to 0 when
feature is disabled
* Wu Fengguang <fengguang.wu@...el.com> wrote:
> So as to eliminate one #ifdef in the c source.
>
> Proposed by Nick Piggin.
>
> CC: Nick Piggin <npiggin@...e.de>
> Signed-off-by: Wu Fengguang <fengguang.wu@...el.com>
> ---
> arch/x86/mm/fault.c | 3 +--
> include/linux/mm.h | 7 ++++++-
> 2 files changed, 7 insertions(+), 3 deletions(-)
>
> --- sound-2.6.orig/arch/x86/mm/fault.c
> +++ sound-2.6/arch/x86/mm/fault.c
> @@ -819,14 +819,13 @@ do_sigbus(struct pt_regs *regs, unsigned
> tsk->thread.error_code = error_code;
> tsk->thread.trap_no = 14;
>
> -#ifdef CONFIG_MEMORY_FAILURE
> if (fault & VM_FAULT_HWPOISON) {
> printk(KERN_ERR
> "MCE: Killing %s:%d due to hardware memory corruption fault at %lx\n",
> tsk->comm, tsk->pid, address);
> code = BUS_MCEERR_AR;
> }
> -#endif
Btw., anything like this should happen in close cooperation with the
x86 tree, not as some pure MM feature. I dont see Cc:s and nothing
that indicates that realization. What's going on here?
It is not at all clear to me whether propagating hardware failures
this widely is desired from a general design POV. Most desktop
hardware wont give a damn about this (and if a hardware fault
happens you want to get as far from the crappy hardware as possible)
so i'm not sure how relevant it is and how well tested it will
become in practice.
I.e. really some wider discussion needs to happen on this.
Ingo
--
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/
Powered by blists - more mailing lists