From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755049AbbKDEQx (ORCPT ); Tue, 3 Nov 2015 23:16:53 -0500 Received: from e32.co.us.ibm.com ([32.97.110.150]:37120 "EHLO e32.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751112AbbKDEQw (ORCPT ); Tue, 3 Nov 2015 23:16:52 -0500 X-IBM-Helo: d03dlp03.boulder.ibm.com X-IBM-MailFrom: paulmck@linux.vnet.ibm.com X-IBM-RcptTo: linux-kernel@vger.kernel.org Date: Tue, 3 Nov 2015 20:16:44 -0800 From: "Paul E. McKenney" To: Linus Torvalds Cc: Ingo Molnar , Dmitry Vyukov , Linux Kernel Mailing List , Peter Zijlstra , Thomas Gleixner , Andrew Morton Subject: Re: [GIT PULL] locking changes for v4.4 Message-ID: <20151104041644.GO29027@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <20151103091636.GA23350@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15110404-0005-0000-0000-000019874DB0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 03, 2015 at 05:30:29PM -0800, Linus Torvalds wrote: > On Tue, Nov 3, 2015 at 3:58 PM, Linus Torvalds > wrote: > > > > I think I'll pull this, but then just make a separate commit to remove > > all the bogus games with "control" dependencies that seem to have no > > basis is reality. > > So the attached is what I committed in my tree. It took much longer to > try to write the rationale than it took to actually remove the > atomic_read_ctrl() functions, and even so I'm not sure how good that > commit message is. But at least it tries to explain what's going on. > > Note the final part of the rationale: > > I may have to eat my words at some point, but in the absense of clear > proof that alpha actually needs this, or indeed even an explanation of > how alpha could _possibly_ need it, I do not believe these functions are > called for. > > And if it turns out that alpha really _does_ need a barrier for this > case, that barrier still should not be "smp_read_barrier_depends()". > We'd have to make up some new speciality barrier just for alpha, along > with the documentation for why it really is necessary. For whatever it is worth, the patch looks good to me. The reasons I could imagine why we might want to mark control dependencies are things like documentation and tooling, but given that we currently only have a very small number of them, it is hard to argue that this is of immediate concern, if it is ever of concern. Thanx, Paul