From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965480AbbKDNyr (ORCPT ); Wed, 4 Nov 2015 08:54:47 -0500 Received: from e37.co.us.ibm.com ([32.97.110.158]:57891 "EHLO e37.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754937AbbKDNyp (ORCPT ); Wed, 4 Nov 2015 08:54:45 -0500 X-IBM-Helo: d03dlp01.boulder.ibm.com X-IBM-MailFrom: paulmck@linux.vnet.ibm.com X-IBM-RcptTo: linux-kernel@vger.kernel.org Date: Wed, 4 Nov 2015 05:54:31 -0800 From: "Paul E. McKenney" To: Ingo Molnar Cc: Linus Torvalds , Dmitry Vyukov , Linux Kernel Mailing List , Peter Zijlstra , Thomas Gleixner , Andrew Morton Subject: Re: [GIT PULL] locking changes for v4.4 Message-ID: <20151104135431.GS29027@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <20151103091636.GA23350@gmail.com> <20151104114850.GA30862@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151104114850.GA30862@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15110413-0025-0000-0000-00001E7F04F9 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 04, 2015 at 12:48:50PM +0100, Ingo Molnar wrote: > > * 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 > > Thanks! > > > > 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. [...] > > Acked-by: Ingo Molnar > > > + dependency into nonexistence. Careful use of READ_ONCE() or > > + atomic{,64}_read() can help to preserve your control dependency. > > + Please see the Compiler Barrier section for more information. > > So technically it's the "COMPILER BARRIER" section, but this is a pre-existing > formulation and the document doesn't use such references consistently so I guess > it doesn't matter much. I will take a pass through and fix these up. I don't see this as urgent, so will add it to my patches for the next merge window. Thanx, Paul