[lkml]   [2008]   [Aug]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] seqlock: serialize against writers
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?


[unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2008-08-29 18:47    [W:0.039 / U:6.580 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site