Jason Wessel wrote: > Jan Kiszka wrote: >> >> 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) >> >> > > > Hi Jan, > > This issue was fixed in a generic way in the patch set that is in the > -mm tree. Had you tried your test case in the current -mm tree? Nope, I have unfortunately no adequate test setup at hand right now. > > The problem you mentioned was fixed by saving and restoring the preempt > count as a part of the fault handling from the kgdb core and not in the > arch specific portion. Ah, OK, that was the piece I missed. Then /me is just curious to finally learn why that hack I once proposed (which unfortunately never received some feedback) is not the right way to go. In other words, what is the reason for this special fault_setjmp/fault_longjmp? Jan
Attachment:
signature.asc
Description: OpenPGP digital signature
- 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]>
- preemption counter havoc on kgdb-taken faults (was: kgdb Bad IO access)
- From: Jan Kiszka <[email protected]>
- Re: preemption counter havoc on kgdb-taken faults
- From: Jason Wessel <[email protected]>
- kgdb Bad IO access (was: 2.6.22-rc6-mm1)
- Prev by Date: Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)
- Next by Date: Re: [2.6 patch] mm/vmstat.c: possible cleanups
- Previous by thread: Re: preemption counter havoc on kgdb-taken faults
- Next by thread: Re: 2.6.21-rt2..8 troubles
- Index(es):
 |