From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: aboo <aboo@aboo.org>
Cc: dougg@torque.net, linux-scsi@vger.kernel.org
Subject: Re: Linux Virtual SCSI HBAs and Virtual disks
Date: Mon, 22 Jan 2007 17:47:40 +0100 [thread overview]
Message-ID: <45B4EAAC.5000008@s5r6.in-berlin.de> (raw)
In-Reply-To: <b43c8fc9882e65d397a6465e6cb7c998@aboo.org>
aboo wrote:
> Can I use the following method safely to know if a scsi_device is
> open or not?
>
> if ( atomic_read(&sdev->sdev_gendev.kobj.kref.refcount) > 14 ) {
> //sdev is in use
> }
No, this too relies far too much on implementation details of upper
layers. (Besides, what if the device is opened right after that? The
atomic refcount is not enough, something mutex-like would be necessary
to do anything useful with the information "open"/"not open".) Ideally,
your LLD sticks with what the Linux SCSI mid-low API has to offer. Thus
your LLD is only aware of this API, but *not* of implementation details
of the SCSI core, let alone SCSI high-level drivers or block I/O
subsystem or whatever other upper layer.
And in the end, why should vscsihba care whether a scsi_device is in use
or not? If a userspace device server quits or got killed or crashed,
"simply" let vscsihba request the removal of the scsi_device (or the
entire host if there is only one device per host). Whoever opened the
device cannot do anything useful with it anymore anyway when there is no
device server.
Of course it is not entirely as "simple" as it sounds. As mentioned, if
vscsihba becomes aware that a device server quit or crashed, let your
queuecommand hook finish all newly incoming commands immediately instead
of enqueueing them. Dequeue and finish all outstanding commands. Make
sure the eh hooks don't wait for something that can't happen anymore.
Note that when the removal of a device is requested, shutdown methods of
high-level drivers like sd become active and may try to issue new
commands (such as to synchronize disk caches). Therein lies potential
for deadlocks or, less critically, for minutes and minutes spent in
futile error recovery attempts.
So, I said you should ignore the in-use state of a scsi_device. Of
course that way you cannot give the userspace device server a status
notification from vscsihba which says "keep running for now, somebody is
using your device", or vice versa: "your last user went away, you can
safely quit now if you feel like it". But in my opinion you don't really
need such status notification in foreseeable future. vscsihba would
primarily or exclusively be used in controlled setups where the
administrator knows very well when it is safe to terminate a userspace
device server. Besides, you have to take into account anyway that a
userspace device server is killed or crashed when its device was in use.
As I wrote before, deal with it like with hot-unplug. A kernel driver
cannot prevent the user from pulling a cable.
--
Stefan Richter
-=====-=-=== ---= =-==-
http://arcgraph.de/sr/
next prev parent reply other threads:[~2007-01-22 16:47 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-16 10:22 Linux Virtual SCSI HBAs and Virtual disks Aboo Valappil
2007-01-16 21:52 ` Erik Mouw
2007-01-16 23:01 ` aboo
2007-01-17 1:50 ` Douglas Gilbert
2007-01-17 8:36 ` Stefan Richter
2007-01-17 10:24 ` Aboo Valappil
2007-01-17 22:20 ` Douglas Gilbert
2007-01-17 21:59 ` aboo
2007-01-18 0:38 ` Stefan Richter
2007-01-21 9:48 ` Aboo Valappil
2007-01-21 9:53 ` Aboo Valappil
2007-01-21 11:24 ` Stefan Richter
2007-01-22 0:43 ` aboo
2007-01-22 2:23 ` aboo
2007-01-22 16:47 ` Stefan Richter [this message]
2007-01-22 16:58 ` Stefan Richter
2007-01-22 18:07 ` James Bottomley
2007-01-23 13:11 ` Aboo Valappil
2007-01-23 16:36 ` Randy Dunlap
2007-01-23 17:22 ` Stefan Richter
2007-01-24 9:47 ` Aboo Valappil
2007-01-25 22:02 ` Aboo Valappil
2007-01-23 17:16 ` Stefan Richter
2007-01-23 22:12 ` Aboo Valappil
2007-01-24 0:09 ` Stefan Richter
2007-01-24 3:24 ` Douglas Gilbert
2007-01-24 9:40 ` Aboo Valappil
2007-01-25 21:41 ` Aboo Valappil
2007-01-25 22:01 ` Stefan Richter
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=45B4EAAC.5000008@s5r6.in-berlin.de \
--to=stefanr@s5r6.in-berlin.de \
--cc=aboo@aboo.org \
--cc=dougg@torque.net \
--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.