Hi folks,
I've been working on a kernel crash dump of an ancient kernel recently, and I
have come to the conculsion that walking the scsi devices via
bus_find_device() is completely flawed. While looking for an upstream fix, I
didn't find any, so the same flaw is probably still there. However, let me ask
here to check how this is supposed to work.
First, this is how I understand the issue. The "/proc/scsi/scsi" file is
handled as a pretty standard seqfile, iterating over the devices with the
following function:
static inline struct device *next_scsi_device(struct device *start)
{
struct device *next = bus_find_device(&scsi_bus_type, start, NULL,
always_match);
put_device(start);
return next;
}
The returned value is used for the next iteration. Now, bus_find_device()
assumes that the device is still attached to the knode_bus klist, because
that's how it initializes the klist iterator. When it finds the next device,
it increments the reference count on the device with get_device(), but it
doesn't do anything about the knode_bus field. So, when somebody calls
scsi_remove_device() on the current device between two calls to
next_scsi_device, then it does:
if (sdev->is_visible) {
[...]
device_del(dev);
which in turn calls:
bus_remove_device(dev);
which does:
if (klist_node_attached(&dev->p->knode_bus))
klist_del(&dev->p->knode_bus);
So, even though the struct device has a non-zero refcount, the code in
next_scsi_device cannot continue, because it only has a stale pointer to an
already detached klist, right?
At least that's what I saw in 2.6.16, and I can still see the same thing
possible in 3.1.
Please, include my mail in your replies, because I'm not subscribed to linux-
scsi.
Petr Tesarik
SUSE LINUX
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
