Re: [PATCH 1/1] Fix int1 recursion when no perf_bp_event is registeredy

[Ingo Molnar]

* Jeff Merkey <linux.mdb@xxxxxxxxx> wrote:

> On 12/14/15, Ingo Molnar <mingo@xxxxxxxxxx> 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@xxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/