public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@SteelEye.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: SCSI development list <linux-scsi@vger.kernel.org>
Subject: Re: [PATCH 4/5] SCSI scanning and removal fixes
Date: Thu, 15 Sep 2005 16:09:53 -0400	[thread overview]
Message-ID: <1126814993.4821.56.camel@mulgrave> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0507261020540.4746-100000@iolanthe.rowland.org>

On Tue, 2005-07-26 at 10:27 -0400, Alan Stern wrote:
> This patch (as545) fixes the list traversals in __scsi_remove_target and 
> scsi_forget_host.  In each case the existing code list_for_each_entry_safe 
> in an _unsafe_ manner, because the list was not protected from outside 
> modification while the iteration was running.

Yes, but all you're doing is trying to close a race between add and
remove by trying the remove until there's nothing left.  That still
won't close the race window.

The solution is to enforce the state model:  Once the host goes into
cancel or del, no further additions may be made to the host list and if
we add the other patch to enforce the state model on removal then only
one process could be in remove as well.

> The new scsi_forget_host routine takes the moderately controversial step 
> of iterating over devices for removal rather than iterating over targets.  
> This makes more sense to me because the current scheme treats targets as 
> second-class citizens, created and removed on demand, rather than as 
> objects corresponding to actual hardware.  (Also I couldn't figure out any 
> safe way to iterate over the target list, since it's not so easy to tell 
> when a target has already been removed.)

Actually, in doing that, the target now never gets reaped, which would
leave us with dangling target objects.

James



      reply	other threads:[~2005-09-15 20:09 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-26 14:27 [PATCH 4/5] SCSI scanning and removal fixes Alan Stern
2005-09-15 20:09 ` James Bottomley [this message]

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=1126814993.4821.56.camel@mulgrave \
    --to=james.bottomley@steeleye.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=stern@rowland.harvard.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox