Re: [PATCH] driver core: fix shutdown races with probe/remove

[Paul E. McKenney]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/