> I could just force all of the seqbegins to hit the slowpath by hacking
quoted text
> 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.

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

quoted text
> 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?

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

quoted text
> 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.

-Andi

--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/