Message ID | CAPcyv4g1dGC2YMN+JZPKhzbCm8PQJ7nJqV4JGjJ3w1PAf12v+Q@mail.gmail.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
>> I do select it, but by randconfig I still need to handle the >> CONFIG_X86_MCE=n case. >> >>> I'm seriously wondering whether the ifdef still makes sense. Now I don't have an extra exception table and routines to sort/search/fixup, it doesn't seem as useful as it was a few iterations ago. >> >> Either way is ok with me. That said, the extra definitions to allow >> it compile out when not enabled don't seem too onerous. > > This works for me, because all we need is the definitions. As long as > we don't attempt to link to mcsafe_copy() we get the benefit of > compiling this out when de-selected: It seems that Kconfig's "select" statement doesn't auto-select other things that are dependencies of the symbol you choose. CONFIG_MCE_KERNEL_RECOVERY really is dependent on CONFIG_X86_MCE ... having the code for the __mcsafe_copy() linked into the kernel won't do you any good without a machine check handler that jumps to the fixup code. So I think you have to select X86_MCE as well (or Kconfig needs to be taught to do it automatically ... but I have a nagging feeling that this is known behavior). -Tony
On Wed, Jan 6, 2016 at 8:57 AM, Luck, Tony <tony.luck@intel.com> wrote: >>> I do select it, but by randconfig I still need to handle the >>> CONFIG_X86_MCE=n case. >>> >>>> I'm seriously wondering whether the ifdef still makes sense. Now I don't have an extra exception table and routines to sort/search/fixup, it doesn't seem as useful as it was a few iterations ago. >>> >>> Either way is ok with me. That said, the extra definitions to allow >>> it compile out when not enabled don't seem too onerous. >> >> This works for me, because all we need is the definitions. As long as >> we don't attempt to link to mcsafe_copy() we get the benefit of >> compiling this out when de-selected: > > It seems that Kconfig's "select" statement doesn't auto-select other things > that are dependencies of the symbol you choose. > > CONFIG_MCE_KERNEL_RECOVERY really is dependent on > CONFIG_X86_MCE ... having the code for the __mcsafe_copy() > linked into the kernel won't do you any good without a machine > check handler that jumps to the fixup code. > > So I think you have to select X86_MCE as well (or Kconfig needs > to be taught to do it automatically ... but I have a nagging feeling > that this is known behavior). > I don't want to force it on, otherwise we might as well remove the ability to configure it. Instead I have this: config BLK_DEV_PMEM select MCE_KERNEL_RECOVERY if X86_MCE && X86_64 ...that way if you turn on X86_MCE and BLK_DEV_PMEM you get MCE_KERNEL_RECOVERY by default.
diff --git a/arch/x86/include/asm/string_64.h b/arch/x86/include/asm/string_64.h index 16a8f0e56e4a..5b24039463a4 100644 --- a/arch/x86/include/asm/string_64.h +++ b/arch/x86/include/asm/string_64.h @@ -78,7 +78,6 @@ int strcmp(const char *cs, const char *ct); #define memset(s, c, n) __memset(s, c, n) #endif -#ifdef CONFIG_MCE_KERNEL_RECOVERY struct mcsafe_ret { u64 trapnr; u64 remain; @@ -86,7 +85,6 @@ struct mcsafe_ret { struct mcsafe_ret __mcsafe_copy(void *dst, const void __user *src, size_t cnt); extern void __mcsafe_copy_end(void); -#endif #endif /* __KERNEL__ */ _______________________________________________