From: Hannes Reinecke <hare@suse.de>
To: Petr Tesarik <ptesarik@suse.cz>
Cc: linux-scsi@vger.kernel.org
Subject: Re: Locking scheme of /proc/scsi/scsi
Date: Tue, 22 Nov 2011 09:59:35 +0100 [thread overview]
Message-ID: <4ECB6477.4050703@suse.de> (raw)
In-Reply-To: <201111211832.35865.ptesarik@suse.cz>
On 11/21/2011 06:32 PM, Petr Tesarik wrote:
> 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.
>
Hmm. Looks like we need to increase the refcount to knode_bus when
we iterate devices.
Let me check ...
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2011-11-22 8:59 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-21 17:32 Locking scheme of /proc/scsi/scsi Petr Tesarik
2011-11-22 8:59 ` Hannes Reinecke [this message]
2011-11-22 9:16 ` Hannes Reinecke
2011-11-22 10:57 ` Petr Tesarik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4ECB6477.4050703@suse.de \
--to=hare@suse.de \
--cc=linux-scsi@vger.kernel.org \
--cc=ptesarik@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox