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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 6 Jun 2012 08:14:48 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Ming Lei <ming.lei@...onical.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	USB list <linux-usb@...r.kernel.org>,
	Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] driver core: fix shutdown races with probe/remove

On Wed, Jun 06, 2012 at 10:44:05AM -0400, Alan Stern wrote:
> On Wed, 6 Jun 2012, Ming Lei wrote:

[ . . . ]

> > There are some similar examples(check on global variable is moved) with
> > ACCESS_ONCE usage in Documentation/atomic_ops.txt. (from line 88)
> 
> Most of those examples involve repeatedly reading a global variable.  
> In your case there is no repetition, and you are writing rather than 
> reading.
> 
> Furthermore, I think some of those examples go a little too far.  
> Here's an extract from the file:
> 
> -------------------------------------------------------------------
> For a final example, consider the following code, assuming that the
> variable a is set at boot time before the second CPU is brought online
> and never changed later, so that memory barriers are not needed:
> 
> 	if (a)
> 		b = 9;
> 	else
> 		b = 42;
> 
> The compiler is within its rights to manufacture an additional store
> by transforming the above code into the following:
> 
> 	b = 42;
> 	if (a)
> 		b = 9;
> 
> This could come as a fatal surprise to other code running concurrently
> that expected b to never have the value 42 if a was zero.  To prevent
> the compiler from doing this, write something like:
> 
> 	if (a)
> 		ACCESS_ONCE(b) = 9;
> 	else
> 		ACCESS_ONCE(b) = 42;
> -------------------------------------------------------------------
> 
> 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".  If you don't use ACCESS_ONCE(), the compiler really
is permitted to insert the "b = 999".  So, why would the compiler do
such a thing?  One possible reason would be from optimizations using
large registers to hold multiple values.  A store from such a register
could clobber unrelated variables, but as long as the compiler fixes
up the clobbering after the fact, it is within its rights to do so.

The sad fact is that the C standard really does permit the compiler
to assume that it is generating sequential code.

							Thanx, Paul

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/