Re: [PATCH] 2.5.x use list_head to handle scsi starved request queues

[Luben Tuikov <luben@splentec.com>]

Patrick Mansfield wrote:
> 
> The lock has to be held while checking shost->host_busy and then when
> removing the starved entry, we can have multiple cpu's in the function for
> the same adapter at the same time. Plus the lock has to be acquired prior
> to any __blk_run_queue call.

If scsi_queue_next_request(q, cmd) is running on more than one CPU
and q != q1 then you have a problem with the starved devices list.

I.e. the lock for an object should NOT depend on the circumstances --
an object (or set of objects) should _always_ use the same lock, if
any.

For this reason, when you obtain the q->queue_lock, just use it
around your critical section and __blk_run_queue(), in a minimalistic
approach, then release it.

Then have a starved_list_lock, or use the host->lock (extreme and I do NOT
recommend it) to lock your starved_list.

So, obtain the starved_list_lock, go over the devices, get their request
queues's lock and call __blk_run_queue(sdev->request_queue), then release
the sdev->request_queue->queue_lock and loop over again if needed,
when done, release the starved_list_lock.

Remember that, someone else might want to *rearrange* the order of
devices in the starved list for, say, _prioritization_, at some other
time when there is no queue in context! (thus a starved_list_lock would
make most sense)

> I am still working patches for the lock split up in this area.

Good!

-- 
Luben