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

* 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?
>
> Any process that can get access to the debug registers can trigger this
> condition. [...]

A process on an unmodified Linux kernel can only modify debug registers via the
proper APIs:

> [...] As it stands, if restricted to the established API in hw_breakpoint.c
> this bug should not occur unless someone triggers an errant breakpoint. [...]

So am I interpreting your report correctly:

"If the Linux kernel is modified to change debug registers without using the
proper APIs (such as loading a module that changes hardware registers in a raw
fashion), things may break and a difficult to debug hang may occur."

right?

This key piece of information should have been part of the original report.

So I'm wondering, why does your module modify debug registers in a raw fashion?
Why doesn't it use the proper APIs?

Thanks,

Ingo


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