[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 1 Jan 2016 14:19:52 -0800
From: Tony Luck <tony.luck@...il.com>
To: Andy Lutomirski <luto@...capital.net>
Cc: Borislav Petkov <bp@...en8.de>,
linux-nvdimm <linux-nvdimm@...1.01.org>, X86 ML <x86@...nel.org>,
"elliott@....com" <elliott@....com>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
Andrew Morton <akpm@...ux-foundation.org>,
"Williams, Dan J" <dan.j.williams@...el.com>,
Ingo Molnar <mingo@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCHV5 3/3] x86, ras: Add __mcsafe_copy() function to recover
from machine checks
Somehow this didn't get sent ... found it in the "Drafts" folder. But
it's rubbish, skip to the
bottom.
On Thu, Dec 31, 2015 at 12:30 PM, Tony Luck <tony.luck@...il.com> wrote:
> I switched to BIAS 0xC0000000 ... and now I should get class 1 entries
> (bit31=0, bit30=1).
>
> New patch series coming soon.
Or not :-(
arch/x86/lib/lib.a(memcpy_64.o):(__ex_table+0x4): relocation truncated
to fit: R_X86_64_PC32 against `.fixup'
arch/x86/lib/lib.a(memcpy_64.o):(__ex_table+0xc): relocation truncated
to fit: R_X86_64_PC32 against `.fixup'
...
I guess it was something like this that made you do the 0x20000000 and
subtract the BIAS?
I have a bad feeling that we may not really have four classes, just three:
00: no funny arithmetic
10: BIAS = 0x80000000 ... doesn't trigger truncation warning because
sign bit is set
11: BIAS = 0x40000000 ... ditto
01: BIAS = ? ... Is there some magic value for BIAS that gets this?
--- end of Draft ... now to the real bit
Not sure why I was hung up on *subtracting* values to get the desired
class bits. Just
blindly copying the initial case from your patch?
If you can't get from A to B one way, try going around the other
direction. Subtracting
0xC0000000 is the same as adding 0x40000000 (when playing with u32 values).
That doesn't upset the linker.
I rebased:
git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras.git mcsafev6
still needs a little cleanup, but it all works, and seems to be a much
cleaner approach. So clean that I wonder whether I really need
the CONFIG_MCE_KERNEL_RECOVERY any more?? The only
place it is used now is around the __mcsafe_copy()
-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