[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CA+8MBbK1mCteGxkKS-3_9=ivrX0LJUC_hMrU6wPMf7+2cXnMUQ@mail.gmail.com>
Date: Sat, 17 Dec 2011 11:25:31 -0800
From: Tony Luck <tony.luck@...el.com>
To: Borislav Petkov <bp@...64.org>
Cc: linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
Chen Gong <gong.chen@...ux.intel.com>,
"Huang, Ying" <ying.huang@...el.com>,
Hidetoshi Seto <seto.hidetoshi@...fujitsu.com>
Subject: Re: [PATCH 5/6] x86, mce: handle "action required" errors (unjumbled version)
On Fri, Dec 16, 2011 at 8:35 AM, Borislav Petkov <bp@...64.org> wrote:
>> #ifndef CONFIG_MEMORY_FAILURE
>> int memory_failure(unsigned long pfn, int vector, int flags)
>> {
>> + if (flags & MF_ACTION_REQUIRED)
>> + return -ENXIO; /* panic? */
>
> Yes, an AR error _is_ an uncorrectable error so in order to stay
> backwards-compatible, we should panic here unconditionally IMO.
I just thought of a better way ... I'll change part 6 of this patch set to
put the severity recognition entries for "AR" errors inside of #ifdef
CONFIG_MEMORY_FAILURE. It makes no sense to mark these
as action required severity if we don't have the code configured that
can take the action. It makes more sense for the severity analysis
to just flag them as "PANIC" events (which the catch-all AR=1 case
in the severity table will do without the MCACOD=0x134 entries).
Then I can simplify here ... perhaps put:
BUG_ON(flags & MF_ACTION_REQUIRED);
here so if a future change to the severity parser does let an action
required error slip through, we'll be able to see that was the problem
was in the severity analysis.
-Tony
--
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