From: Mike Christie <michaelc@cs.wisc.edu>
To: Pete Wyckoff <pw@osc.edu>
Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>,
linux-scsi@vger.kernel.org, Erez Zilber <erezz@voltaire.com>
Subject: Re: [BUG 1/3] bsg queue oops with iscsi logout
Date: Tue, 11 Mar 2008 00:36:51 -0500 [thread overview]
Message-ID: <47D61A73.3000803@cs.wisc.edu> (raw)
In-Reply-To: <47D5766C.3020206@cs.wisc.edu>
[-- Attachment #1: Type: text/plain, Size: 1507 bytes --]
Mike Christie wrote:
> Pete Wyckoff wrote:
>> I think this used not to happen; not sure. But I changed two things
>
> This most likely did not happen before 2.6.25-rc* or it broke in
> slightly different ways, because iscsi used to try and do
>
> echo 1 > /sys/block/sdX/device/delete
>
> from userspace instead of calling scsi_remove_target from the kernel.
>
> As you know around 2.6.21, the behavior of doing the echo to the delete
> file changed due to a driver model and scsi change and that broke the
> iscsi tools. The iscsi tools userspace removal was sort of hack in the
> first place and was racey, so we switched to removing devices/target
> like the FC class.
>
>
>> lately. 2.6.25-rc1 to -rc4 and fedora 8 iscsi-initiator-utils (865) to
>> fedora devel (868). Bidi and varlen patches always too.
>>
>> I'll follow with some more variations on this theme. Looks like bsg
>> needs to protect more carefully against the device going away. Any
>> ideas how best to do this? What was the approach in sg?
>>
>
> I think sg is broken in similar ways. The iser guys have some tests
> cases that have broken sg while IO is outstanding. I am ccing Erez.
Actually one of the problems looks a little different than some of the
problems hit with sg and are caused because we remove the bsg device too
soon. I think we want to wait until all the references from the
commands/requests are released. The attached patch (untested) moves the
bsg unreg call to the scsi device release fn.
[-- Attachment #2: delay-bsg-unreg.patch --]
[-- Type: text/x-patch, Size: 907 bytes --]
Delay bsg unregistration, because we want to wait until all the request/cmds
have released their reference.
Signed-off-by: Mike Christie <michaelc@cs.wisc.edu>
diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
index ed83cdb..b9b09a7 100644
--- a/drivers/scsi/scsi_sysfs.c
+++ b/drivers/scsi/scsi_sysfs.c
@@ -294,6 +294,7 @@ static void scsi_device_dev_release_usercontext(struct work_struct *work)
}
if (sdev->request_queue) {
+ bsg_unregister_queue(sdev->request_queue);
sdev->request_queue->queuedata = NULL;
/* user context needed to free queue */
scsi_free_queue(sdev->request_queue);
@@ -857,7 +858,6 @@ void __scsi_remove_device(struct scsi_device *sdev)
if (scsi_device_set_state(sdev, SDEV_CANCEL) != 0)
return;
- bsg_unregister_queue(sdev->request_queue);
class_device_unregister(&sdev->sdev_classdev);
transport_remove_device(dev);
device_del(dev);
next prev parent reply other threads:[~2008-03-11 5:37 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-09 16:53 [BUG 1/3] bsg queue oops with iscsi logout Pete Wyckoff
2008-03-09 16:54 ` [BUG 2/3] bsg null sdev " Pete Wyckoff
2008-03-09 16:55 ` [BUG 3/3] bsg mutex hang " Pete Wyckoff
2008-03-10 17:57 ` [BUG 1/3] bsg queue oops " Mike Christie
2008-03-11 5:36 ` Mike Christie [this message]
2008-03-11 22:46 ` FUJITA Tomonori
2008-03-15 0:45 ` Pete Wyckoff
2008-03-22 16:06 ` Serious regression caused by fix for " James Bottomley
2008-03-24 9:23 ` FUJITA Tomonori
2008-03-26 14:22 ` FUJITA Tomonori
2008-03-26 14:36 ` James Bottomley
2008-03-26 14:59 ` FUJITA Tomonori
2008-03-27 1:32 ` Mike Christie
2008-03-27 11:11 ` FUJITA Tomonori
2008-03-27 20:46 ` Mike Christie
2008-03-27 1:51 ` Mike Christie
2008-03-27 2:18 ` Mike Christie
2008-03-27 11:11 ` FUJITA Tomonori
2008-03-27 11:11 ` FUJITA Tomonori
2008-03-27 12:18 ` FUJITA Tomonori
2008-03-30 17:39 ` James Bottomley
2008-03-31 0:20 ` FUJITA Tomonori
2008-04-02 18:41 ` Boaz Harrosh
2008-04-02 21:00 ` FUJITA Tomonori
2008-04-03 7:58 ` Boaz Harrosh
2008-03-27 1:59 ` Mike Christie
2008-03-27 0:25 ` Mike Christie
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=47D61A73.3000803@cs.wisc.edu \
--to=michaelc@cs.wisc.edu \
--cc=erezz@voltaire.com \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=linux-scsi@vger.kernel.org \
--cc=pw@osc.edu \
/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.