Andi Kleen wrote:

quoted

I could just force all of the seqbegins to hit the slowpath by hacking
the code and see what happens (aside from slowing down, of course ;)
    

Only if you don't believe it will really crash? I think it's pretty
clear even without trying it.
  

Well, I guess it was just to prove to myself that I broke something
because I dont understand how the vsyscall interface works.  But given
your expertise here, I have no problem with just taking your word for it.

quoted

Question: Which seqlock_t does userspace use?  I assume it uses
seqlock_t and not raw_seqlock_t. 
    

quoted

But the only reason that I ask is that
I converted raw_seqlock_t to use the new style as well to be consistent,
    

There's no raw_seqlock_t anywhere in mainline?
  

Yeah, understood.  There is both in -rt and I was just saying that we
technically only need the seqlock_t fix in -rt.  So if raw_seqlock_t
could be left pristine and solve this problem, that is an acceptable
compromise to me.

Anyways the variable is declared (in mainline) in asm-x86/vgtod.h 

  

quoted

even though it is not strictly necessary for the same reasons.  So if
perchance userspace uses the raw variant, I could solve this issue by
only re-working the seqlock_t variant.  Kind of a long shot, but figured
I would mention it :)
    

I guess you could define a new seqlock_t which is explicitely user space
safe. That might avoid such issues in the future. But then
that would likely require some code duplication and be ugly.

On the other hand whatever problem you fixing in the kernel
(to be honest it's still unclear to me what the problem is)
needs to be likely fixed for the userland lock too.
  

Yeah, it would possibly be a problem in both cases.

The problem I am addressing only exists in -rt since it has seqlock_t
and raw_seqlock_t (with the former using preemptible spinlock_t's). 
Since the underlying seqlock_t->spinlock_t is preemptible, you can see
that one thread that does:

{
    write_seqlock();
    /* asl */
    write_sequnlock();
}

while other high-prio threads do

do { read_seqbegin(); /* asl */; } while (read_seqretry());

The readers could preempt the writer mid critical section and enter a
live-locked loop.

raw_seqlock_t (which is equivalent to a mainline seqlock_t) do not have
this problem because the spinlock acquisition inside the write_seqlock
disables preemption.

HTH

-Greg