Re: [linux-usb-devel] [PATCH] base/class.c: prevent ooops due toinsert/remove race (v3)

[Linus Torvalds]

On Thu, 29 Nov 2007, Alan Stern wrote:
> 
> Yes indeed.  I wish I could point you to the exact patch containing the 
> fix, but the git software seems to have lost track of it (it's combined
> in with a large number of other patches with no obvious way to separate 
> it out).  It's also available in the various mailing list archives, but 
> I don't have a pointer to it and there's no reasonable way to search 
> for it.
> 
> The patch in question was written by Matthew Wilcox; it added code to 
> the SCSI async-scanning routines to utilize the scan_mutex.  IMO it 
> should have been applied to 2.6.23 but it wasn't.

Heh. It definitely hasn't gotten lost by "the git software". In fact, with 
the kinds of hints you already gave, git makes it really _trivial_ to find 
it.

Here's what you do:

	git log v2.6.23.. --author=Wilcox

and then just search for "scan_mutex", in the hope that Matthew wrote a 
nice commit message. And yes, he did, so in less than a blink you get:

	commit 6b7f123f378743d739377871c0cbfbaf28c7d25a
	Author: Matthew Wilcox <matthew@xxxxxx>
	Date:   Tue Jun 26 15:18:51 2007 -0600
	
	    [SCSI] Fix async scanning double-add problems

	    Stress-testing and some thought has revealed some places where
	    asynchronous scanning needs some more attention to locking.
	
	     - Since async_scan is a bit, we need to hold the host_lock while
	       modifying it to prevent races against other CPUs modifying the word
	       that bit is in.  This is probably a theoretical race for the moment,
	       but other patches may change that.
	     - The async_scan bit means not only that this host is being scanned
	       asynchronously, but that all the devices attached to this host are not
	       yet added to sysfs.  So we must ensure that this bit is always in sync.
	       I've chosen to do this with the scan_mutex since it's already acquired
	       in most of the right places.
		...

which I assume is the commit you're talking about.

		Linus
-
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/