Messages in this thread | | | Date | Wed, 29 Jul 2020 20:40:57 +0000 | From | Fenghua Yu <> | Subject | Re: [PATCH RFC] x86/bus_lock: Enable bus lock detection |
| |
Hi, Peter,
On Wed, Jul 29, 2020 at 10:49:47AM +0200, peterz@infradead.org wrote: > On Fri, Jul 17, 2020 at 02:35:00PM -0700, Fenghua Yu wrote: > > > #DB for bus lock detect fixes all issues in #AC for split lock detect: > > 1) It's architectural ... just need to look at one CPUID bit to know it > > exists > > 2) The IA32_DEBUGCTL MSR, which reports bus lock in #DB, is per-thread. > > So each process or guest can have different behavior. > > And it generates a whole new problem due to #DB being an IST, and > > > diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c > > index b038695f36c5..58725567da39 100644 > > --- a/arch/x86/kernel/traps.c > > +++ b/arch/x86/kernel/traps.c > > @@ -812,6 +812,16 @@ static void handle_debug(struct pt_regs *regs, unsigned long dr6, bool user) > > if (!user && !dr6) > > return; > > > > + /* Handle bus lock. */ > > + if (!(dr6 & DR_BUS_LOCK)) { > > + cond_local_irq_enable(regs); > > + if (user) > > + handle_user_bus_lock(regs); > > + else > > + handle_kernel_bus_lock(regs); > > + goto out; > > + } > > + > > /* > > * If dr6 has no reason to give us about the origin of this trap, > > * then it's very likely the result of an icebp/int01 trap. > > we very much rely on #DB never recursing, which we carefully crafted by > disallowing hardare breakpoints on noinstr code and clearing DR7 early. > > But now it can... please keep the pieces.
Can we disable Bus Lock Detection before handle it and re-enable it after handle it? Will that resolve the recursion issue?
Thanks.
-Fenghua
| |