Messages in this thread | | | Date | Thu, 05 Feb 2015 16:02:45 -0500 | From | Sasha Levin <> | Subject | Re: sched: memory corruption on completing completions |
| |
On 02/05/2015 03:59 PM, Davidlohr Bueso wrote: > On Wed, 2015-02-04 at 16:16 -0800, Linus Torvalds wrote: >> And looking at the arch version, I think the paravirtualized code is crap. >> >> It does: >> >> prev = *lock; >> add_smp(&lock->tickets.head, TICKET_LOCK_INC); >> >> /* add_smp() is a full mb() */ >> >> if (unlikely(lock->tickets.tail & TICKET_SLOWPATH_FLAG)) >> __ticket_unlock_slowpath(lock, prev); >> >> >> which is *exactly* the kind of things you cannot do with spinlocks, >> because after you've done the "add_smp()" and released the spinlock >> for the fast-path, you can't access the spinlock any more. Exactly >> because a fast-path lock migth come in, and release the whole data >> structure. >> >> As usual, the paravirt code is a horribly buggy heap of crud. Film at 11. > > Per http://lwn.net/Articles/495597/ which clearly describes the intent > of the slowpath unlocking. Cc'ing Raghavendra.
Interestingly enough, according to that article this behaviour seems to be "by design":
""" This version of the patch uses a locked add to do this, followed by a test to see if the slowflag is set. The lock prefix acts as a full memory barrier, so we can be sure that other CPUs will have seen the unlock before we read the flag """
Thanks, Sasha
| |