Messages in this thread | | | From | Andy Lutomirski <> | Date | Thu, 10 Dec 2015 11:09:21 -0800 | Subject | Re: [PATCH 1/1] Fix int1 recursion when no perf_bp_event is registered |
| |
On Thu, Dec 10, 2015 at 10:55 AM, Thomas Gleixner <tglx@linutronix.de> wrote: > Jeff, > > On Thu, 10 Dec 2015, Jeff Merkey wrote: > >> If an int1 hardware breakpoint exception is triggered, but no perf bp >> pevent block was registered from arch_install_hw_breakpoint, the >> system will hard hang with the CPU stuck constantly re-interrupting at >> the same execution address because the resume flag never gets set, and >> the NOTIFY_DONE state prevents other int1 handlers, including the >> default handler in do_debug, from running to handle the condition. >> Can be reproduced by writing a program that sets an execute breakpoint >> at schedule() without calling arch_install_hw_breakpoint. >> >> The proposed fix checks the dr7 register and sets the resume flag in >> pt->regs if it determines an executed breakpoint was triggered just in >> case the check lower down fails. I have seen this bug and its a bug. > >> Signed-off-by: jeffmerkey@gmail.com >> diff --git a/arch/x86/kernel/hw_breakpoint.c b/arch/x86/kernel/hw_breakpoint.c >> index 50a3fad..6effcae 100644 >> --- a/arch/x86/kernel/hw_breakpoint.c >> +++ b/arch/x86/kernel/hw_breakpoint.c >> @@ -475,6 +475,14 @@ static int hw_breakpoint_handler(struct die_args *args) >> for (i = 0; i < HBP_NUM; ++i) { >> if (likely(!(dr6 & (DR_TRAP0 << i)))) >> continue; >> + /* >> + * Set up resume flag to avoid breakpoint recursion when >> + * returning back to origin in the event an int1 >> + * exception is triggered and no event handler >> + * is present. >> + */ >> + if ((dr7 & (3 << ((i * 4) + 16))) == 0) > > We have proper defines for all of this. See __encode_dr7(). > >> + args->regs->flags |= X86_EFLAGS_RF; > > If there is a break point installed, then we do the same thing after > calling perf_bp_event() again.
On brief inspection, this smells like a microcode bug. Can you send /proc/cpuinfo output?
For example, this CPU and microcode combination is known bad:
processor : 7 vendor_id : AuthenticAMD cpu family : 21 model : 2 model name : AMD Opteron(tm) Processor 3380 stepping : 0 microcode : 0x6000832
If this is the issue, I'm not sure we want to be in the business of working around localized microcode bugs and, if we do, then I think we should explicitly detect the bug and log about it.
--Andy
| |