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