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: [email protected] 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) + args->regs->flags |= X86_EFLAGS_RF; /* * The counter may be concurrently released but that can only -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
