Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1290907 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 1/1] Fix int1 recursion when no perf_bp_event is  registeredy Ingo Molnar <mingo@kernel.org> - 2015-12-14 09:10 +0100
    Re: [PATCH 1/1] Fix int1 recursion when no perf_bp_event is registeredy Jeff Merkey <linux.mdb@gmail.com> - 2015-12-14 09:20 +0100
      Re: [PATCH 1/1] Fix int1 recursion when no perf_bp_event is registeredy Jeff Merkey <linux.mdb@gmail.com> - 2015-12-14 09:30 +0100
      Re: [PATCH 1/1] Fix int1 recursion when no perf_bp_event is  registeredy Ingo Molnar <mingo@kernel.org> - 2015-12-14 10:30 +0100
        Re: [PATCH 1/1] Fix int1 recursion when no perf_bp_event is registeredy Jeff Merkey <linux.mdb@gmail.com> - 2015-12-14 19:00 +0100
          Re: [PATCH 1/1] Fix int1 recursion when no perf_bp_event is registeredy Andy Lutomirski <luto@amacapital.net> - 2015-12-14 19:00 +0100
            Re: [PATCH 1/1] Fix int1 recursion when no perf_bp_event is registeredy Jeff Merkey <linux.mdb@gmail.com> - 2015-12-14 19:20 +0100
            Re: [PATCH 1/1] Fix int1 recursion when no perf_bp_event is registeredy Jeff Merkey <linux.mdb@gmail.com> - 2015-12-14 19:20 +0100

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

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

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

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

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

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1291003

* 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

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

On 12/14/15, Ingo Molnar <mingo@kernel.org> wrote:
>
> * 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
>

Hi Ingo,

This will be a lengthy reply to properly explain this to you.  First
some fundamental assumptions to clear up.

1.  The MDB Debugger Module does not cause this problem.  This is an
existing bug in the kernel in an exception code path.
2.  This bug was discovered and triggered while running a TEST HARNESS
I use to test the debugger.  Among other things, I check for
unregistered breakpoints while performing tests of debugging
blacked-out sections of the OS in a special mode the debugger can
employ called DIRECT MODE.  In normal mode the MDB Debugger uses the
established breakpoint API.
3.  The Breakpoint API in linux was not designed for debuggers.  It
was designed for probe and application profiling.  It has no concept
of global SMP breakpoints, no facilities to manage them, no on/off
settings for debugger entry conditions, requiring kernel debuggers to
do it themselves.
4.  I handle all of these cases correctly as does kgdb and kdb and
have to use this severely deficient interface if not in direct mode.
5.  Direct mode in a debugger allows the debugger to essentially be a
sliding window over sections of code that are normally blacked out.
For example, if placed in direct mode, MDB can debug the linux
debugger API itself because it is not calling it and is using the
registers directly without a software layer the debugger is dependent
on.  Using this mode, its possible to debug across interrupts,
syscalls, and areas of the OS normally "blacked out" to the debugger.
6.  This interface has a bug in its main execution path for handling
int1 exceptions.  It asks the OS whether or not a breakpoint is an
execute breakpoint rather than querying the hardware dr7 register
which just delivered the interrupt, and since no bp is present, the
system hangs at the same address getting the interrupt over and over
again because the resume flag was never set.
7.  The way an int1 exception works ingo is when the address of an
execute breakpoint is hit, the processor will interrupt through the
int1 handler and will keep asserting the same interrupt over and over
again unless the resume flag is set and reloaded into the processor.
This is how intel processors are designed to work.
8.  If any process or module sets a breakpoint outside of linux
breakpoint API in this code path the system will crash.  Its A BUG,
and it's been in linux 13 years.  I am certain people have seen it
while running perf stuff but since it provides no diagnostic info,
someone would just reset the system.
9.  This breakpoint  API needs to be rewritten to be global breakpoint
aware, have an on/off switch so when a debugger enters an int1
exception, breakpoints are globally disabled (a requirement), among
other things.

The patch simply fixes the bug in the int handler that will cause a
lockup.  The perf event system, kgdb, kdb, and any one of a number of
programs can trigger this bug, and probably have.  People would blame
the debugger when its a bug in the int handler.

Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

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

On Mon, Dec 14, 2015 at 9:52 AM, Jeff Merkey <linux.mdb@gmail.com> wrote:
> On 12/14/15, Ingo Molnar <mingo@kernel.org> wrote:
>>
>> * 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
>>
>
> Hi Ingo,
>
> This will be a lengthy reply to properly explain this to you.  First
> some fundamental assumptions to clear up.
>
> 1.  The MDB Debugger Module does not cause this problem.  This is an
> existing bug in the kernel in an exception code path.

> 8.  If any process or module sets a breakpoint outside of linux
> breakpoint API in this code path the system will crash.  Its A BUG,
> and it's been in linux 13 years.  I am certain people have seen it
> while running perf stuff but since it provides no diagnostic info,
> someone would just reset the system.

Putting "BUG" in caps doesn't make it so.  What's wrong with it?

> 9.  This breakpoint  API needs to be rewritten to be global breakpoint
> aware, have an on/off switch so when a debugger enters an int1
> exception, breakpoints are globally disabled (a requirement), among
> other things.

A "requirement" for what?

>
> The patch simply fixes the bug in the int handler that will cause a
> lockup.  The perf event system, kgdb, kdb, and any one of a number of
> programs can trigger this bug, and probably have.  People would blame
> the debugger when its a bug in the int handler.

You ignored feedback from me and from tglx, and you still haven't
explained why this is a bug in the first place.   Maybe the code could
degrade more gracefully if you use it wrong, but the int1 handler and
the rest of the kernel are very much aware of each other, and the int1
handler's failure to do what something that isn't in the kernel wants
it to do isn't a bug.

If you submit a clean patch to improve robustness of the handler and
if the new code is at least as clean as the old code, that might be a
different story.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

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

On 12/14/15, Andy Lutomirski <luto@amacapital.net> wrote:
> On Mon, Dec 14, 2015 at 9:52 AM, Jeff Merkey <linux.mdb@gmail.com> wrote:
>> On 12/14/15, Ingo Molnar <mingo@kernel.org> wrote:
>>>
>>> * 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
>>>
>>
>> Hi Ingo,
>>
>> This will be a lengthy reply to properly explain this to you.  First
>> some fundamental assumptions to clear up.
>>
>> 1.  The MDB Debugger Module does not cause this problem.  This is an
>> existing bug in the kernel in an exception code path.
>
>> 8.  If any process or module sets a breakpoint outside of linux
>> breakpoint API in this code path the system will crash.  Its A BUG,
>> and it's been in linux 13 years.  I am certain people have seen it
>> while running perf stuff but since it provides no diagnostic info,
>> someone would just reset the system.
>
> Putting "BUG" in caps doesn't make it so.  What's wrong with it?

Sorry about that.

>
>> 9.  This breakpoint  API needs to be rewritten to be global breakpoint
>> aware, have an on/off switch so when a debugger enters an int1
>> exception, breakpoints are globally disabled (a requirement), among
>> other things.
>
> A "requirement" for what?
>

When you enter a debugger console you must disable all breakpoints
globally or you will get nested breakpoints inside the debugger.  kgdb
and kdb do not handle this well.  MDB handles it but sooner or later
you will run out of stack space if you allow it.  Intel documentation
says it's a no no based on how they designed the debug facilities in
their processors ...

>>
>> The patch simply fixes the bug in the int handler that will cause a
>> lockup.  The perf event system, kgdb, kdb, and any one of a number of
>> programs can trigger this bug, and probably have.  People would blame
>> the debugger when its a bug in the int handler.
>
> You ignored feedback from me and from tglx, and you still haven't
> explained why this is a bug in the first place.   Maybe the code could
> degrade more gracefully if you use it wrong, but the int1 handler and
> the rest of the kernel are very much aware of each other, and the int1
> handler's failure to do what something that isn't in the kernel wants
> it to do isn't a bug.
>
> If you submit a clean patch to improve robustness of the handler and
> if the new code is at least as clean as the old code, that might be a
> different story.
>
> --Andy
>

Responded to the rest of it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

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

On 12/14/15, Andy Lutomirski <luto@amacapital.net> wrote:
> On Mon, Dec 14, 2015 at 9:52 AM, Jeff Merkey <linux.mdb@gmail.com> wrote:
>> On 12/14/15, Ingo Molnar <mingo@kernel.org> wrote:
>>>
>>> * 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
>>>
>>
>> Hi Ingo,
>>
>> This will be a lengthy reply to properly explain this to you.  First
>> some fundamental assumptions to clear up.
>>
>> 1.  The MDB Debugger Module does not cause this problem.  This is an
>> existing bug in the kernel in an exception code path.
>
>> 8.  If any process or module sets a breakpoint outside of linux
>> breakpoint API in this code path the system will crash.  Its A BUG,
>> and it's been in linux 13 years.  I am certain people have seen it
>> while running perf stuff but since it provides no diagnostic info,
>> someone would just reset the system.
>
> Putting "BUG" in caps doesn't make it so.  What's wrong with it?
>
>> 9.  This breakpoint  API needs to be rewritten to be global breakpoint
>> aware, have an on/off switch so when a debugger enters an int1
>> exception, breakpoints are globally disabled (a requirement), among
>> other things.
>
> A "requirement" for what?
>
>>
>> The patch simply fixes the bug in the int handler that will cause a
>> lockup.  The perf event system, kgdb, kdb, and any one of a number of
>> programs can trigger this bug, and probably have.  People would blame
>> the debugger when its a bug in the int handler.
>
> You ignored feedback from me and from tglx, and you still haven't
> explained why this is a bug in the first place.


It crashes the system -- crash = bug -- right?

Maybe the code could
> degrade more gracefully if you use it wrong, but the int1 handler and
> the rest of the kernel are very much aware of each other, and the int1
> handler's failure to do what something that isn't in the kernel wants
> it to do isn't a bug.
>
> If you submit a clean patch to improve robustness of the handler and
> if the new code is at least as clean as the old code, that might be a
> different story.
>
> --Andy
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web