[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1423169986.6835.24.camel@stgolabs.net>
Date: Thu, 05 Feb 2015 12:59:46 -0800
From: Davidlohr Bueso <dave@...olabs.net>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Sasha Levin <sasha.levin@...cle.com>,
Waiman Long <Waiman.Long@...com>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Andrey Ryabinin <a.ryabinin@...sung.com>,
Dave Jones <davej@...emonkey.org.uk>,
LKML <linux-kernel@...r.kernel.org>,
Raghavendra K T <raghavendra.kt@...ux.vnet.ibm.com>
Subject: Re: sched: memory corruption on completing completions
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.
Thanks,
Davidlohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists