All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Christie <michaelc@cs.wisc.edu>
To: Bart Van Assche <bvanassche@acm.org>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>,
	Tomas Henzl <thenzl@redhat.com>,
	"'linux-scsi@vger.kernel.org'" <linux-scsi@vger.kernel.org>,
	Stanislaw Gruszka <sgruszka@redhat.com>
Subject: Re: [RFC] How to fix an async scan - rmmod race?
Date: Wed, 11 Apr 2012 13:17:46 -0500	[thread overview]
Message-ID: <4F85CACA.8060803@cs.wisc.edu> (raw)
In-Reply-To: <4F81CCF9.8010408@acm.org>

On 04/08/2012 12:38 PM, Bart Van Assche wrote:
> On 04/06/12 17:15, James Bottomley wrote:
> 
>> Consider where the command came from: either it's come from startup (the
>> current problem), operation (in which case the device must be open to
>> send and receive it) or teardown (which is synchronous).
> 
> 
> And what about e.g. sd_check_events() or sr_check_events() ?

Are those setup to run from the open functions, so we will have done a
get on the module (sd_open() -> check_disk_change()) for those.

> 
> Maybe I should explain why I started looking at the SCSI error handler
> in so much detail. While running disk removal tests against ib_srp I
> found out that the SCSI error handler thread can invoke the LLD's abort
> and reset handlers long after scsi_remove_host() finished. That's why I
> came up with this patch: "[PATCH 05/15] ib_srp: Avoid that SCSI error
> handling triggers a crash"
> (http://www.mail-archive.com/linux-rdma@vger.kernel.org/msg11234.html).
> But I'm still wondering whether that's the right approach. Should this
> issue be addressed in each LLD or in the SCSI core ?
> 

I would like scsi core to handle this, but I think right now drivers are
doing work arounds like your patch.

For example FC drivers will call fc_remove_host which sets things up so
no new IO can be sent to the device after that function has completed
and will call some callouts like dev_loss_tmo_callbk to cleanup
outstanding IO. The problem is that when it calls scsi_remove_host that
could cause commands like cache sync from sd.c's shutdown to get failed
(the queuecommand function will call the fc check ready function which
will fail the IO immediately).

iSCSI drivers will call scsi_remove_target, do a iscsi logout and
cleanup outstanding commands if needed, set things up so new IO is
failed (I do not think there should be new IO because scsi_remove_target
should have removed the devices and the iscsi logout/shutdown code made
sure the iscsi queues were empty), then call scsi_remove_host.

  reply	other threads:[~2012-04-11 18:17 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-05 13:58 [RFC] How to fix an async scan - rmmod race? Tomas Henzl
2012-04-05 15:57 ` Mike Christie
2012-04-05 16:05   ` Mike Christie
2012-04-05 18:00 ` Bart Van Assche
2012-04-05 21:29   ` Mike Christie
2012-04-06  9:24     ` Bart Van Assche
2012-04-06 17:22       ` Mike Christie
2012-04-06 18:37         ` Bart Van Assche
2012-04-11 21:46         ` Mike Christie
2012-04-06  9:54     ` Tomas Henzl
2012-04-06 15:20       ` James Bottomley
2012-04-06 16:15         ` Bart Van Assche
2012-04-06 16:35           ` James Bottomley
2012-04-06 17:01             ` Bart Van Assche
2012-04-06 17:15               ` James Bottomley
2012-04-06 17:59                 ` Bart Van Assche
2012-04-08 17:38                 ` Bart Van Assche
2012-04-11 18:17                   ` Mike Christie [this message]
2012-04-11 18:30                     ` Mike Christie
2012-04-11 19:47                     ` Bart Van Assche
2012-04-11 22:28                       ` Mike Christie
2012-04-12 10:48                         ` Bart Van Assche
2012-04-06  9:39 ` Bart Van Assche
2012-04-06 10:14   ` Tomas Henzl
2012-04-06 13:13     ` Tomas Henzl
2012-04-06 14:38       ` Bart Van Assche
2012-04-06 15:32         ` Tomas Henzl
2012-04-12 12:48 ` [RFC] How to fix an async scan - rmmod race? try_module_get Tomas Henzl
2012-04-18 16:48   ` [RFC] How to fix an async scan - 'rmmod --wait' race? Tomas Henzl
2012-04-18 18:18     ` Bart Van Assche
2012-05-17  8:42     ` James Bottomley
2012-05-17  8:55       ` Bart Van Assche
2012-05-17  9:01         ` James Bottomley
2012-05-17 14:51           ` Tomas Henzl
2012-05-22 10:05             ` James Bottomley
2012-05-25 15:13               ` Tomas Henzl
2012-05-25 18:46                 ` Dan Williams
2012-05-28 11:58                   ` Tomas Henzl

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=4F85CACA.8060803@cs.wisc.edu \
    --to=michaelc@cs.wisc.edu \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=bvanassche@acm.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=sgruszka@redhat.com \
    --cc=thenzl@redhat.com \
    /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.