Re: [PATCH] 6/7 add and use a per-scsi_device queue_lock

James Bottomley
2003-03-25T21:20:32Z

On Mon, 2003-03-24 at 20:03, Patrick Mansfield wrote:
> Add and use a per scsi_device queue_lock.

In doing this, you're introducing a locking heirarchy, which would need
to be documented. If you need both the host and queue locks, which do
you take first? The code implies that it's queue_lock and then
host_lock, which is a bit counter intuitive and leads to awful problems
for your starved_list: the host_lock is actually protecting the starved
list, so the way you currently have it, you have to drop the host lock
to acquire the queue_lock to run the block queue. Unfortunately, doing
this could lead to the device being readded when running the queue.
Thus, the queue_next_request can spin removing and adding the device to
the starved list---probably working from a copy of the starved list will
help with this.

I'd also like to see avoidance of the locking hierarchy where possible.
i.e. in the scsi_request_fn for instance, can we move the actions that
need the host_lock outside the queue_lock?

James