Andi Kleen wrote: > On Fri, Aug 29, 2008 at 12:29:42PM -0400, Gregory Haskins wrote: > >> Andi Kleen wrote: >> >>>> Im running it on a x86_64 box as we speak. How can I tell if there is a >>>> certain mode that is permitting this? >>>> >>>> >>> If the boot up says you're running with PMtimer then it uses the fallback >>> (usually happens on pre Fam10h AMD boxes). A typical Intel box >>> would use the faster ring 3 only TSC path and then explode with your >>> change I bet. >>> >>> >> Thinking about this some more, perhaps the issue is I am not hitting the >> contended path in vsyscall? >> > > Yes it will be only contended when gettimeofday() races with the timer > interrupt. You could try to run gettimeofday() in a loop and see how > long it holds up. > > But anyways from the theory you should crash when it happens. > Writes to kernel data are not allowed in vsyscalls and your read_lock clearly > does a write. > Oh I don't deny that it does. The compiler neatly reminded me that it could no longer be "const". I just was ignorant of the userspace requirement ;) But we *do* have a serious problem here. A non-preemptible seqlock_t will do bad things if it preempts the writer, so we need some kind of solution here, one way or the other. So suggestions welcome :) I realize this is only an issue currently in PREEMPT_RT so perhaps most will not care... but I do need to solve this at least for this branch. I currently do not see a way to solve this problem that doesn't involve some heavier involvement in the read path (read: const seqlock_t need not apply). Given that, we either need to address the const requirement for userspace, alter userspace's usage, or find another way to address the deadlock. Any ideas? -Greg
Attachment:
signature.asc
Description: OpenPGP digital signature
