Linux SCSI subsystem development
 help / color / mirror / Atom feed
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

  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