Messages in this thread | | | Date | Mon, 14 Dec 2015 01:13:10 -0700 | Subject | Re: [PATCH 1/1] Fix int1 recursion when no perf_bp_event is registeredy | From | Jeff Merkey <> |
| |
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
| |