aboutsummaryrefslogtreecommitdiff
path: root/drivers/power
diff options
context:
space:
mode:
authorMatthew Wilcox <matthew@wil.cx>2007-06-26 15:18:51 -0600
committerJames Bottomley <jejb@mulgrave.localdomain>2007-10-12 14:38:24 -0400
commit6b7f123f378743d739377871c0cbfbaf28c7d25a (patch)
treeada283aaa62629e09b9edb7c351eaa62cdf3ccce /drivers/power
parentafd9a033ca1354e95c95201f5d21a097da9f7fb2 (diff)
[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. - If the host changes state to deleted while we're in the middle of a scan, we'll end up with some devices on the host's list which must be deleted. Add a check to scsi_sysfs_add_devices() to ensure the host is still running. - To avoid the async_scan bit being protected by three locks, the async_scan_lock now only protects the scanning_list. Signed-off-by: Matthew Wilcox <matthew@wil.cx> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Diffstat (limited to 'drivers/power')
0 files changed, 0 insertions, 0 deletions