From: Jim Ramsay <jim.ramsay@gmail.com>
To: Linux-ide <linux-ide@vger.kernel.org>
Subject: Re: [PATCH 3/3] Add disk hotswap support to libata RESEND #2
Date: Mon, 29 Aug 2005 13:45:03 -0600 [thread overview]
Message-ID: <4789af9e0508291245709eca2f@mail.gmail.com> (raw)
In-Reply-To: <4789af9e0508291223435f174@mail.gmail.com>
Another interesting issue with hotplug which may need SCSI-layer changes:
If you unplug a device that some process already has open (for
example, md), the device is removed, but the internal scsi_device
struct is not actually freed until ALL references to this device
(including that still held by md) release it.
When you re-plugin the device at this time (scsi_device has been
marked as 'deleted' but not actually freed), the code properly detects
that while there is still a scsi_device for this host/channel/id/lun
combination, it is marked as "SDEV_DEL" and so should not be used.
Fine - a new scsi_device struct is allocated and added to the back of
the Scsi_Host->__devices list.
The problem: From now on, whenever someone wants to use this scsi
device, they will end up calling scsi_device_lookup, which calls
__scsi_device_lookup, which will always return the first scsi_device
struct, the one which is now SDEV_DEL, so scsi_device_lookup will
return NULL. This means that subsequent hot-unplugs will not remove
the most-recently-allocated scsi_device struct, so no hotplug events
are sent and no udev devices are removed. This is bad -> a memory
leak.
The workaround: This probably has ramifications I'm not considering,
but the following replacement for __scsi_device_lookup in scsi.c seems
to work for me. It returns the LAST matching scsi_device (and
therefore most-recently allocated), as opposed to the old code which
returned the FIRST matching scsi_device:
struct scsi_device *__scsi_device_lookup(struct Scsi_Host *shost,
uint channel, uint id, uint lun)
{
struct scsi_device *found_sdev = NULL;
struct scsi_device *sdev;
list_for_each_entry(sdev, &shost->__devices, siblings) {
printk( "device lookup checking %d:%d:%d:%d against
%d:%d:%d:%d\n",
shost->host_no, channel, id, lun,
shost->host_no, sdev->channel,
sdev->id, sdev->lun );
if (sdev->channel == channel && sdev->id == id &&
sdev->lun ==lun)
{
found_sdev = sdev;
}
}
return found_sdev;
}
How else could this be solved? I suppose adding newly allocated
scsi_device structs to the FRONT of the Scsi_Host->__devices list
would have the same effect as my alternate search routine, but I don't
know which would be better. I can't think of any solution that
wouldn't touch the existing SCSI layer, though.
--
Jim Ramsay
"Me fail English? That's unpossible!"
next prev parent reply other threads:[~2005-08-29 19:45 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-01 10:02 [PATCH 3/3] Add disk hotswap support to libata RESEND #2 Lukasz Kosewski
2005-08-23 19:41 ` Jim Ramsay
2005-08-23 22:43 ` Jim Ramsay
2005-08-23 22:56 ` George Anzinger
2005-08-24 1:20 ` Stefan Richter
2005-08-24 14:03 ` Lukasz Kosewski
2005-08-24 15:11 ` Jim Ramsay
2005-08-24 16:12 ` Jim Ramsay
[not found] ` <4789af9e0508291223435f174@mail.gmail.com>
2005-08-29 19:45 ` Jim Ramsay [this message]
2005-09-06 19:02 ` Jim Ramsay
2005-09-15 4:40 ` Lukasz Kosewski
2005-09-16 16:11 ` Mark Lord
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=4789af9e0508291245709eca2f@mail.gmail.com \
--to=jim.ramsay@gmail.com \
--cc=linux-ide@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.