From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7AFDCC47255 for ; Mon, 11 May 2020 16:52:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5665D2070B for ; Mon, 11 May 2020 16:52:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1589215943; bh=b/yxjgJC2CuxHj+5rql56i3dEt86BgH3xwqCAuAIF9M=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=oBU+5vEg+5zvb1QcADvk2ZMRicuuAw0fzPPI9wO6XyrCIMxThz5dyGgbkCbCm9O5N kOqmWaovSt+z4MvdkVvG+2Uxiucb3DoLU5wdDfxGoWrI9A+5Vi7Y9l3TIFLdqJqXA0 k4aWkD9ORYHeE0ck0cYmr6NyV/xWaw9KQLMKuZDw= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730728AbgEKQwW (ORCPT ); Mon, 11 May 2020 12:52:22 -0400 Received: from mail.kernel.org ([198.145.29.99]:59908 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729143AbgEKQwW (ORCPT ); Mon, 11 May 2020 12:52:22 -0400 Received: from willie-the-truck (236.31.169.217.in-addr.arpa [217.169.31.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 66D75206D7; Mon, 11 May 2020 16:52:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1589215941; bh=b/yxjgJC2CuxHj+5rql56i3dEt86BgH3xwqCAuAIF9M=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=TE6o75wLdo/KppzMxATQ0XogQnqrpmH3VGgJVIfprF/zLj1RhAdH1vRUEjim/Bt5S nsRFEPcxFaft8RBBLV0BJEreD5eUD/NQwLrgbamFBkiNOMJihz1Db4A0D+nnvmRhhl zCxe1EKi9NG3bkd+wN24IlGduwRBUkwqnECqdm64= Date: Mon, 11 May 2020 17:52:17 +0100 From: Will Deacon To: "Paul E. McKenney" Cc: Qian Cai , Elver Marco , LKML , Ingo Molnar , "Peter Zijlstra (Intel)" Subject: Re: [PATCH -next v2] locking/osq_lock: annotate a data race in osq_lock Message-ID: <20200511165216.GA23081@willie-the-truck> References: <20200509161217.GN2869@paulmck-ThinkPad-P72> <45D9EEEB-D887-485D-9045-417A7F2C6A1A@lca.pw> <20200509213654.GO2869@paulmck-ThinkPad-P72> <20200511155812.GB22270@willie-the-truck> <20200511164319.GV2869@paulmck-ThinkPad-P72> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200511164319.GV2869@paulmck-ThinkPad-P72> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 11, 2020 at 09:43:19AM -0700, Paul E. McKenney wrote: > On Mon, May 11, 2020 at 04:58:13PM +0100, Will Deacon wrote: > > On Sat, May 09, 2020 at 02:36:54PM -0700, Paul E. McKenney wrote: > > > diff --git a/kernel/locking/osq_lock.c b/kernel/locking/osq_lock.c > > > index 1f77349..1de006e 100644 > > > --- a/kernel/locking/osq_lock.c > > > +++ b/kernel/locking/osq_lock.c > > > @@ -154,7 +154,11 @@ bool osq_lock(struct optimistic_spin_queue *lock) > > > */ > > > > > > for (;;) { > > > - if (prev->next == node && > > > + /* > > > + * cpu_relax() below implies a compiler barrier which would > > > + * prevent this comparison being optimized away. > > > + */ > > > + if (data_race(prev->next) == node && > > > cmpxchg(&prev->next, node, NULL) == node) > > > break; > > > > I'm fine with the data_race() placement, but I don't find the comment > > very helpful. We assign the result of a READ_ONCE() to 'prev' in the > > loop, so I don't think that the cpu_relax() is really relevant. > > Suppose that the compiler loaded a value that was not equal to "node". > In that case, the cmpxchg() won't happen, so something else must force > the compiler to do the reload in order to avoid an infinite loop, right? > Or am I missing something here? Then we just go round the loop and reload prev: prev = READ_ONCE(node->prev); which should be enough to stop the compiler, no? Will