lkml.org 
[lkml]   [2015]   [Dec]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 1/1] Fix int1 recursion when no perf_bp_event is registeredy
From
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


\
 
 \ /
  Last update: 2015-12-14 10:01    [W:0.050 / U:0.168 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site