Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759308Ab2FFXZQ (ORCPT ); Wed, 6 Jun 2012 19:25:16 -0400 Received: from e37.co.us.ibm.com ([32.97.110.158]:35265 "EHLO e37.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758916Ab2FFXZO (ORCPT ); Wed, 6 Jun 2012 19:25:14 -0400 Date: Wed, 6 Jun 2012 16:24:06 -0700 From: "Paul E. McKenney" To: Alan Stern Cc: Ming Lei , Greg Kroah-Hartman , USB list , Kernel development list Subject: Re: [PATCH] driver core: fix shutdown races with probe/remove Message-ID: <20120606232406.GP19601@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <20120606155515.GM19601@linux.vnet.ibm.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-Content-Scanned: Fidelis XPS MAILER x-cbid: 12060623-7408-0000-0000-000005A4BDDB Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1716 Lines: 45 On Wed, Jun 06, 2012 at 12:58:29PM -0400, Alan Stern wrote: > On Wed, 6 Jun 2012, Paul E. McKenney wrote: > > > On Wed, Jun 06, 2012 at 11:44:50AM -0400, Alan Stern wrote: > > > On Wed, 6 Jun 2012, Paul E. McKenney wrote: > > > > > > > > That just seems wrong. By the same reasoning, the compiler is within > > > > > its rights to transform either the original code or the code using > > > > > ACCESS_ONCE into: > > > > > > > > > > b = 999; > > > > > if (a) > > > > > b = 9; > > > > > else > > > > > b = 42; > > > > > > > > > > and again, other code would be confused. The simple fact is that > > > > > SMP-safe code is not likely to be produced by a compiler that assumes > > > > > everything is single-threaded. > > > > > > > > If you use ACCESS_ONCE(), the compiler is prohibited from inserting > > > > the "b = 999". > > > > > > What prohibits it? > > > > The compiler cannot move a volatile access across a sequence point, for > > example, across a statement boundary. > > How does inserting a store to a non-volatile value qualify as moving a > volatile access? Assuming that there is no access to "b" prior to the "if", then any access to or modification of "b" would have to be associated with the two assignments, which could not precede the volatile (at least as I understand the sequencing rules). If there is some use of "b" prior to the "if", then yes, the "b = 999" might be associated with those prior accesses. Thanx, Paul -- 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/