| Message ID | 1555536851-17462-19-git-send-email-fenghua.yu@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | x86/split_lock: Enable split lock detection | expand |
On Wed, 17 Apr 2019, Fenghua Yu wrote: > The kernel option clearcpuid currently only takes feature bit which > can be changed from kernel to kernel. > > Extend clearcpuid to use cap flag string, which is defined in > x86_cap_flags[] and won't be changed from kernel to kernel. > And user can easily get the cap flag string from /proc/cpuinfo. If your machine dies because init triggers #AC then please explain how that easily can be read from /proc/cpuinfo and how the sysadmin can figure out what the heck he needs to write on the kernel command line. The whole 'clearcpuid' thing should have never been merged. It's a pure testing/debugging thing. And no, we are not going to proliferate it and extend it for dubious value. Quite the contrary, we should simply rip it out. Add a simple 'noac' or whatever command line option, which is documented proper and can easily be mapped to a #AC crash during boot. Thanks, tglx
On Thu, Apr 18, 2019 at 01:19:41AM +0200, Thomas Gleixner wrote: > On Wed, 17 Apr 2019, Fenghua Yu wrote: > > > The kernel option clearcpuid currently only takes feature bit which > > can be changed from kernel to kernel. > > > > Extend clearcpuid to use cap flag string, which is defined in > > x86_cap_flags[] and won't be changed from kernel to kernel. > > And user can easily get the cap flag string from /proc/cpuinfo. > > If your machine dies because init triggers #AC then please explain how that > easily can be read from /proc/cpuinfo and how the sysadmin can figure out > what the heck he needs to write on the kernel command line. > > The whole 'clearcpuid' thing should have never been merged. It's a pure > testing/debugging thing. And no, we are not going to proliferate it and > extend it for dubious value. Quite the contrary, we should simply rip it > out. So I can remove the four 'clearcpuid' related patches 0018-0021 in the next version, right? > > Add a simple 'noac' or whatever command line option, which is documented > proper and can easily be mapped to a #AC crash during boot. OK. I will do this. Thanks. -Fenghua
On Wed, 17 Apr 2019, Fenghua Yu wrote: > On Thu, Apr 18, 2019 at 01:19:41AM +0200, Thomas Gleixner wrote: > > On Wed, 17 Apr 2019, Fenghua Yu wrote: > > > > > The kernel option clearcpuid currently only takes feature bit which > > > can be changed from kernel to kernel. > > > > > > Extend clearcpuid to use cap flag string, which is defined in > > > x86_cap_flags[] and won't be changed from kernel to kernel. > > > And user can easily get the cap flag string from /proc/cpuinfo. > > > > If your machine dies because init triggers #AC then please explain how that > > easily can be read from /proc/cpuinfo and how the sysadmin can figure out > > what the heck he needs to write on the kernel command line. > > > > The whole 'clearcpuid' thing should have never been merged. It's a pure > > testing/debugging thing. And no, we are not going to proliferate it and > > extend it for dubious value. Quite the contrary, we should simply rip it > > out. > > So I can remove the four 'clearcpuid' related patches 0018-0021 in the next > version, right? Yes please. They are unrelated to this problem and 'noac' is way more admin friendly than that. Thanks, tglx
diff --git a/arch/x86/include/asm/cpufeature.h b/arch/x86/include/asm/cpufeature.h index 0e56ff7e4848..823c4ab82e12 100644 --- a/arch/x86/include/asm/cpufeature.h +++ b/arch/x86/include/asm/cpufeature.h @@ -133,6 +133,7 @@ extern const char * const x86_bug_flags[NBUGINTS*32]; extern void setup_clear_cpu_cap(unsigned int bit); extern void clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int bit); +bool find_cpu_cap(char *cap_flag, unsigned int *pfeature); #define setup_force_cpu_cap(bit) do { \ set_cpu_cap(&boot_cpu_data, bit); \ diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-deps.c index 3d633f67fbd7..1a71434f7b46 100644 --- a/arch/x86/kernel/cpu/cpuid-deps.c +++ b/arch/x86/kernel/cpu/cpuid-deps.c @@ -120,3 +120,29 @@ void setup_clear_cpu_cap(unsigned int feature) { do_clear_cpu_cap(NULL, feature); } + +/** + * find_cpu_cap - Given a cap flag string, find its corresponding feature bit. + * @cap_flag: cap flag string as defined in x86_cap_flags[] + * @pfeature: feature bit + * + * Return: true if the feature is found. false if not found + */ +bool find_cpu_cap(char *cap_flag, unsigned int *pfeature) +{ +#ifdef CONFIG_X86_FEATURE_NAMES + unsigned int feature; + + for (feature = 0; feature < NCAPINTS * 32; feature++) { + if (!x86_cap_flags[feature]) + continue; + + if (strcmp(cap_flag, x86_cap_flags[feature]) == 0) { + *pfeature = feature; + + return true; + } + } +#endif + return false; +} diff --git a/arch/x86/kernel/fpu/init.c b/arch/x86/kernel/fpu/init.c index 88bbba7ee96a..99b895eea166 100644 --- a/arch/x86/kernel/fpu/init.c +++ b/arch/x86/kernel/fpu/init.c @@ -256,7 +256,8 @@ static void __init clear_cpuid(void) /* Chang command line range for next search. */ cmdline_size = option_pos - boot_command_line + 1; argptr = arg; - if (get_option(&argptr, &bit) && + /* cpu cap can be specified by either feature bit or string */ + if ((get_option(&argptr, &bit) || find_cpu_cap(arg, &bit)) && bit >= 0 && bit < NCAPINTS * 32) setup_clear_cpu_cap(bit); }
The kernel option clearcpuid currently only takes feature bit which can be changed from kernel to kernel. Extend clearcpuid to use cap flag string, which is defined in x86_cap_flags[] and won't be changed from kernel to kernel. And user can easily get the cap flag string from /proc/cpuinfo. Signed-off-by: Fenghua Yu <fenghua.yu@intel.com> --- arch/x86/include/asm/cpufeature.h | 1 + arch/x86/kernel/cpu/cpuid-deps.c | 26 ++++++++++++++++++++++++++ arch/x86/kernel/fpu/init.c | 3 ++- 3 files changed, 29 insertions(+), 1 deletion(-)