Messages in this thread | | | From | "Yu, Fenghua" <> | Subject | RE: [PATCH v3 10/10] x86/split_lock: Handle #AC exception for split lock | Date | Wed, 13 Feb 2019 14:37:11 +0000 |
| |
> From: Ingo Molnar [mailto:mingo.kernel.org@gmail.com] On Behalf Of Ingo Molnar > > On Mon, Feb 11, 2019 at 11:53:39AM +0100, Ingo Molnar wrote: > > > > + do_trap(trapnr, signr, str, regs, error_code, BUS_ADRALN, > NULL); > > > > + } > > > > +} > > > > > > Is there any experience with how frequently this signal is killing > > > user-space processes on a modern distro? Any expectation of how > > > frequent such SIGBUS task terminations are going to be in the field? > > > > We did pretty intensive testing internally (zero day tests, many > > engineers and testers use the patches in their dailly work, etc). So > > far I'm not aware of any user space process hiting split lock issue. I > > guess GCC or other compilers takes care of the issue already. Inline > > assembly code may hit the issue if code is not right, but there are > > fewer inline assembly code in user space. > > > > So far we only find two kernel split lock issues and fix them in the > > first two patches in this patch set. We also find one BIOS split lock > > issue internally which has been fixed in production BIOS. > > > > Thanks. > > Ok, still, for binary compatibility's sake, could you please add a sysctl knob > (root-only, etc.) and a kernel boot parameter that disables this check?
In this patch set, we already extend kernel option "clearcpuid=" to support CPU cap flags. So "clearcpuid=split_lock_detection" can disable this split lock check during boot time.
In next version, I will add "/sys/kernel/split_lock_detection" to enable or disable the split lock check during run time.
Hopefully these work.
Thanks.
-Fenghua
| |