Messages in this thread | | | Date | Mon, 14 Dec 2015 01:26:45 -0700 | Subject | Re: [PATCH 1/1] Fix int1 recursion when no perf_bp_event is registeredy | From | Jeff Merkey <> |
| |
On 12/14/15, Jeff Merkey <linux.mdb@gmail.com> wrote: > On 12/14/15, Ingo Molnar <mingo@kernel.org> wrote: >> >> A: Because it messes up the order in which people normally read text. >> Q: Why is top-posting such a bad thing? >> A: Top-posting. >> Q: What is the most annoying thing in e-mail? >> >> * Jeff Merkey <linux.mdb@gmail.com> wrote: >> >>> I trigger it by writing to the dr7 and dr1, 2, 3 or four register and >>> set an execute breakpoint without going through >>> arch_install_hw_breakpoint. When the breakpoint fires, the system >>> crashes and hangs on the processor stuck in an endless loop inside the >>> int1 handler in hw_breakpoint.c -- >> >> What is still not clear to me, can you trigger the hang not via some >> special >> >> kernel driver that goes outside regular APIs and messes with the state of >> the >> debug registers, but via the proper access methods, i.e. various >> user-space >> ABIs? >> >> Thanks, >> >> Ingo >> > > Any process that can get access to the debug registers can trigger > this condition. As it stands, if restricted to the established API in > hw_breakpoint.c this bug should not occur unless someone triggers an > errant breakpoint. That being said, there is a severe bug in the code > path if for some reason an application triggers a breakpoint exception > and no event has been registered, the system will crash with no logged > output of any kind indicating why it happened. It's not severe enough > for a panic but does need to be handled gracefully just as exception > handling 101. > > Sorry about the top posting. I forget sometimes. > > Jeff >
What's more problematic is that debuggers MUST zero dr7 upon entry then restore it to prevent breakpoints while inside a debugger console. kgdb/kdb both fiddle with dr7 directly and bypass the API in many cases. Any kernel module can trigger a breakpoint including userspace debuggers. Most of these cases are handled at the bottom of do_debug and in the perf handlers. The problem here is that the normal handling in do_debug gets short circuited when this bug gets hit that causes the system to get stuck in an endless interrupt cycle with int1 firing off at the same address because the resume flag never gets set.
The v2 patch fixes the bug, prints a message. Disabling the breakpoint in dr7 is also worrisome since bp can be null in this code path, but when that happens there is a singaling via the thread.debugreg6 variable that keeps the system from locking up unless you trigger a breakpoint outside the API (which kgdb/kdb do in some cases, though they seem to keep a "dummy" bp registered while they fiddle with dr7).
Jeff
| |