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