All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergey Vlasov <vsu@altlinux.ru>
To: James Bottomley <James.Bottomley@SteelEye.com>
Cc: Andrew Morton <akpm@osdl.org>, linux-scsi@vger.kernel.org
Subject: Re: [SCSI] fix scsi_reap_target() device_del from atomic context
Date: Sat, 24 Dec 2005 00:26:04 +0300	[thread overview]
Message-ID: <20051223212604.GA9382@procyon.home> (raw)
In-Reply-To: <1135371219.3728.50.camel@mulgrave>

[-- Attachment #1: Type: text/plain, Size: 1978 bytes --]

On Fri, Dec 23, 2005 at 02:53:39PM -0600, James Bottomley wrote:
> On Fri, 2005-12-23 at 23:43 +0300, Sergey Vlasov wrote:
> > So if that GFP_ATOMIC allocation ever fails, the target is leaked
> > forever - does not look nice.
> 
> Yes, but it will print a warning.
> 
> > Does anything depend on starget->siblings being empty after we had
> > removed it from the shost->__targets list it was on?  Seems that all
> > other uses of this field are:
> >
> > drivers/scsi/scsi_scan.c:313:   list_for_each_entry(starget, &shost->__targets, siblings) {
> > drivers/scsi/scsi_scan.c:365:   INIT_LIST_HEAD(&starget->siblings);
> > drivers/scsi/scsi_scan.c:373:   list_add_tail(&starget->siblings, &shost->__targets);
> > 
> > So probably we can reuse this field and do deferred reaping without any
> > memory allocation at all.  The following patch should be applied
> > _instead_ of the James' patch, not on top of it (I can make a combined
> > patch if it is desired).  The difference with the previous patch is that
> > scsi_target_reap() still removes the target from shost->__targets
> > immediately - only device_del() and subsequent actions are deferred to a
> > workqueue.
> 
> No, you can't.
> 
> If you do this, the target namespace will potentially be in use in sysfs
> after the system thinks the target is gone.  Thus, any reallocation
> fails because you can't add a new target with the same name as an
> existing one.

Ah, I see now... scsi_alloc_target() checks if a target with the same
channel/id combination is on the list and adds new target only if
there was no such one before.

However, what prevents a race between scsi_target_reap_work() and
scsi_alloc_target()?  If the worker thread is interrupted/preempted
just after releasing host_lock (when it has already removed the target
from the list, but before it has called device_del()),
scsi_alloc_target() might consider the target as new and get to
device_add() faster.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

      reply	other threads:[~2005-12-23 21:26 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200512212359.jBLNxluV016971@hera.kernel.org>
2005-12-23  6:13 ` [SCSI] fix scsi_reap_target() device_del from atomic context Andrew Morton
2005-12-23 12:15   ` Matthew Wilcox
2005-12-23 15:27     ` James Bottomley
2005-12-23 15:38       ` Andrew Morton
2005-12-23 15:58         ` James Bottomley
2005-12-24  3:54           ` Andrew Morton
2005-12-23 20:05   ` Andrew Vasquez
2005-12-23 20:30     ` James Bottomley
2005-12-23 20:46       ` Andrew Vasquez
2005-12-23 20:43   ` Sergey Vlasov
2005-12-23 20:53     ` James Bottomley
2005-12-23 21:26       ` Sergey Vlasov [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=20051223212604.GA9382@procyon.home \
    --to=vsu@altlinux.ru \
    --cc=James.Bottomley@SteelEye.com \
    --cc=akpm@osdl.org \
    --cc=linux-scsi@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.