From: Mike Christie <michaelc@cs.wisc.edu>
To: James.Smart@Emulex.Com
Cc: David C Somayajulu <david.somayajulu@qlogic.com>,
James Bottomley <James.Bottomley@SteelEye.com>,
linux-scsi@vger.kernel.org, open-iscsi@googlegroups.com,
Doug Maxey <dwm@enoyolf.org>,
David Wagner <david.wagner@qlogic.com>,
Ravi Anand <ravi.anand@qlogic.com>,
Duane Grigsby <duane.grigsby@qlogic.com>
Subject: Re: [RFC] [PATCH] qla4xxx driver resubmission
Date: Thu, 21 Sep 2006 13:25:31 -0500 [thread overview]
Message-ID: <4512D91B.1020507@cs.wisc.edu> (raw)
In-Reply-To: <451297C7.4000007@emulex.com>
James Smart wrote:
> Why does your LLD need to reach up into the block layer to find an i/o ?
>
> Even if you are using tags as an index into something... I would think that
> having to go up to the blk layer to retrieve a something that should have
> already been known lower in the driver leaves room for race conditions.
>
This is how the blk and scsi tag api work for queue based tagging. We
have the scsi_find_tag() function which takes a scsi device and than
calls blk_queue_find_tag to get the request. It then does all the magic
sdev to request_queue and request to scsi command work and pass the LLD
the scsi command for the tag. So we can either add a driver array and do
some tag to scsi command or driver stucture mapping or we can use the
array already created in the scsi host block queue tag. And as you see
Dave's patch did the latter in the spirit of not duplicating what
scsi-ml or the block layer already do.
I think there are some basic races though. For example, scsi_request_fn
calls blk_queue_start_tag with only the queue lock held and so if the
request_fn was called for two devices on the same host at the same time
they both could call find_first_zero_bit on the shared bqt->tag_map and
end up getting the same tag.
next prev parent reply other threads:[~2006-09-21 18:25 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-20 0:08 [RFC] [PATCH] qla4xxx driver resubmission David C Somayajulu
2006-09-21 13:46 ` James Smart
2006-09-21 17:35 ` David Somayajulu
2006-09-21 18:11 ` James Smart
2006-09-21 18:35 ` Mike Christie
2006-09-21 18:25 ` Mike Christie [this message]
2006-09-21 18:35 ` Jens Axboe
2006-09-21 18:37 ` Mike Christie
2006-09-21 18:45 ` Jens Axboe
2006-09-21 18:47 ` Jens Axboe
2006-09-21 18:55 ` David Somayajulu
2006-09-21 19:00 ` Jens Axboe
2006-09-25 16:56 ` David Somayajulu
2006-09-30 0:42 ` David Somayajulu
2006-10-04 15:49 ` James Bottomley
2006-10-04 16:30 ` David Somayajulu
2006-10-04 16:39 ` James Bottomley
2006-10-04 16:44 ` Matthew Wilcox
-- strict thread matches above, loose matches on Subject: below --
2006-07-27 18:30 David Somayajulu
2006-07-27 19:11 ` David C Somayajulu
2006-07-27 22:09 ` Doug Maxey
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=4512D91B.1020507@cs.wisc.edu \
--to=michaelc@cs.wisc.edu \
--cc=James.Bottomley@SteelEye.com \
--cc=James.Smart@Emulex.Com \
--cc=david.somayajulu@qlogic.com \
--cc=david.wagner@qlogic.com \
--cc=duane.grigsby@qlogic.com \
--cc=dwm@enoyolf.org \
--cc=linux-scsi@vger.kernel.org \
--cc=open-iscsi@googlegroups.com \
--cc=ravi.anand@qlogic.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox