Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751533AbbBEVDc (ORCPT ); Thu, 5 Feb 2015 16:03:32 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:19042 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750903AbbBEVDb (ORCPT ); Thu, 5 Feb 2015 16:03:31 -0500 Message-ID: <54D3DA75.70402@oracle.com> Date: Thu, 05 Feb 2015 16:02:45 -0500 From: Sasha Levin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Davidlohr Bueso , Linus Torvalds CC: Waiman Long , Peter Zijlstra , Ingo Molnar , Andrew Morton , Andrey Ryabinin , Dave Jones , LKML , Raghavendra K T Subject: Re: sched: memory corruption on completing completions References: <54D2AA16.6030706@oracle.com> <1423169986.6835.24.camel@stgolabs.net> In-Reply-To: <1423169986.6835.24.camel@stgolabs.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Source-IP: acsinet22.oracle.com [141.146.126.238] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1603 Lines: 44 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 -- 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/