From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757422AbdJKM7H (ORCPT ); Wed, 11 Oct 2017 08:59:07 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:47101 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751991AbdJKM7G (ORCPT ); Wed, 11 Oct 2017 08:59:06 -0400 Date: Wed, 11 Oct 2017 05:58:57 -0700 From: "Paul E. McKenney" To: David Howells Cc: linux-kernel@vger.kernel.org, mingo@kernel.org, torvalds@linux-foundation.org, mark.rutland@arm.com, linux-arch@vger.kernel.org, peterz@infradead.org, will.deacon@arm.com, Jonathan Corbet , Alexander Kuleshov Subject: Re: [PATCH RFC tip/core/rcu 12/15] lib/assoc_array: Remove smp_read_barrier_depends() Reply-To: paulmck@linux.vnet.ibm.com References: <20171010155042.GD3521@linux.vnet.ibm.com> <1507594969-8347-12-git-send-email-paulmck@linux.vnet.ibm.com> <20171010001951.GA6476@linux.vnet.ibm.com> <8079.1507628146@warthog.procyon.org.uk> <26455.1507724399@warthog.procyon.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <26455.1507724399@warthog.procyon.org.uk> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 x-cbid: 17101112-0008-0000-0000-0000028EFDAA X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00007878; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000235; SDB=6.00929589; UDB=6.00467880; IPR=6.00709860; BA=6.00005634; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00017490; XFM=3.00000015; UTC=2017-10-11 12:59:00 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17101112-0009-0000-0000-000036F8CB3D Message-Id: <20171011125857.GY3521@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-10-11_05:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710110179 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 11, 2017 at 01:19:59PM +0100, David Howells wrote: > Paul E. McKenney wrote: > > > - node = result.terminal_node.node; > > - smp_read_barrier_depends(); > > + node = READ_ONCE(result.terminal_node.node); /* Address dependency. */ > > The main problem I have with this method of annotation is that it's not > obvious there's a barrier there or which side the barrier is. > > I think one of the trickiest issues is that a barrier is typically between two > things and we're not making it clear what those two things actually are. > > Also, I would say that the most natural interpretation of READ_ONCE() is that > the implicit barrier comes after the read, e.g.: > > f = READ_ONCE(stuff->foo); > /* Implied barrier */ > look_at(f->a); > look_at(f->b); > > I.e. READ_ONCE() prevents stuff->foo from being reread whilst you access f and > orders LOAD(stuff->foo) before LOAD(f->a) and LOAD(f->b). Placing the comment on the same line makes it less likely that some later change will move the comment away from the load that it applies to. Which appears to have happened on some of the other instances of smp_read_barrier_depends() in other parts of the kernel. It is not at all clear what load they go with, or if that load is even still present in the kernel. :-/ Thanx, Paul