Locking scheme of /proc/scsi/scsi

[Petr Tesarik <ptesarik@suse.cz>]

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