Jason Wessel wrote: > The only place I could foresee that kgdb could be eating extra cycles in > the runtime case is from the die_notifier processing. Any kind of > exception such as a page fault, trap etc... will have a few extra ops > and checks of variables so as to determine if the debugger should take > the exception. It looks to me like it would even benefit to add the > check at the top of the notify hook for kgdb to exit immediately if the > debugger is not attached. > > I have contemplated making some changes to KGDB so as to make the > registration to the die_notifier to be dynamic with attaching and > detaching of the debugger. If this is done, I would also make a change > to allow for the case where the kernel would wait for the debugger to > attach on any fatal fault. At this chance... Reminds me that this old issue still seems to be unsolved in current kgdb: http://www.mail-archive.com/[email protected]/msg00442.html I'm only looking at that spot in kgdb right now and /may/ oversee new border conditions elsewhere. But my feeling is there are none. Jan (looking forward to see kgdb merged)
Attachment:
signature.asc
Description: OpenPGP digital signature
- Follow-Ups:
- Re: preemption counter havoc on kgdb-taken faults
- From: Jason Wessel <[email protected]>
- Re: preemption counter havoc on kgdb-taken faults
- References:
- kgdb Bad IO access (was: 2.6.22-rc6-mm1)
- From: Tilman Schmidt <[email protected]>
- Re: kgdb Bad IO access
- From: Jason Wessel <[email protected]>
- kgdb Bad IO access (was: 2.6.22-rc6-mm1)
- Prev by Date: Re: [2.6 patch] mm/vmstat.c: possible cleanups
- Next by Date: Re: preemption counter havoc on kgdb-taken faults
- Previous by thread: Re: kgdb Bad IO access
- Next by thread: Re: preemption counter havoc on kgdb-taken faults
- Index(es):
 |