All of lore.kernel.org
 help / color / mirror / Atom feed
From: Juergen Gross <jgross@suse.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: target-devel@vger.kernel.org, JBottomley@parallels.com,
	linux-scsi@vger.kernel.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH V2 2/4] Introduce xen-scsifront module
Date: Fri, 01 Aug 2014 15:06:04 +0200	[thread overview]
Message-ID: <53DB90BC.8000302@suse.com> (raw)
In-Reply-To: <20140801120847.GB17864@infradead.org>

On 08/01/2014 02:08 PM, Christoph Hellwig wrote:
> On Wed, Jul 30, 2014 at 06:53:59AM +0200, Juergen Gross wrote:
>> Hmm, I looked into scsi_add_device(). It seems as if the caller can't
>> distinguish between a new created and an already existing device. Am I
>> missing something?
>
> That's right.  If you need that I still think it's better to add a
> variant of scsi_add_device helping you with that.

I'm open to that solution.

Do you have preferences how to do it (IOW: can you give me a hint)?

>> The race is not existing: scsi_add_device() (and scsi_remove_device()
>> as well) for this scsi_host is called in scsifront_do_lun_hotplug()
>> only, and this function is always called in the same thread (xenbus
>> watch). A comment seems to be a good idea.
>
> Do you disable scanning through procfs and sysfs as well?

No, I don't.

OTOH I don't think I see the problem. What could go wrong? Either
scsi_device_lookup() does find an existing device, then I refuse to add
it again. If I don't find it, it will be added. I can't see how any harm
would be done in either case when the device is added/removed between
the check and the action. What am I missing?

Juergen

  reply	other threads:[~2014-08-01 13:06 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-25 11:37 [PATCH V2 0/4] Add XEN pvSCSI support jgross
2014-07-25 11:37 ` [PATCH V2 1/4] Add XEN pvSCSI protocol description jgross
2014-07-28 14:28   ` [Xen-devel] " David Vrabel
2014-07-29  7:39     ` Juergen Gross
2014-07-25 11:37 ` [PATCH V2 2/4] Introduce xen-scsifront module jgross
2014-07-29 13:53   ` Christoph Hellwig
2014-07-29 14:57     ` [Xen-devel] " Juergen Gross
2014-07-30  4:53       ` Juergen Gross
2014-08-01 12:08         ` Christoph Hellwig
2014-08-01 13:06           ` Juergen Gross [this message]
2014-08-01 13:41             ` Christoph Hellwig
2014-07-25 11:37 ` [PATCH V2 3/4] Introduce XEN scsiback module jgross
2014-07-26 15:23   ` Christoph Hellwig
2014-07-28  3:35     ` [Xen-devel] " Jürgen Groß
2014-07-29 12:28       ` Christoph Hellwig
2014-07-25 11:37 ` [PATCH V2 4/4] add xen pvscsi maintainer jgross
2014-07-25 17:38 ` [PATCH V2 0/4] Add XEN pvSCSI support Konrad Rzeszutek Wilk
2014-07-26  7:28   ` Juergen Gross

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=53DB90BC.8000302@suse.com \
    --to=jgross@suse.com \
    --cc=JBottomley@parallels.com \
    --cc=hch@infradead.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=target-devel@vger.kernel.org \
    --cc=xen-devel@lists.xen.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.