Re: [PATCH] scsi, mptsas : drop scsi_host lock when calling mptsas_qcmd

[Joe Eykholt <jeykholt@cisco.com>]

On 9/16/10 2:25 PM, Andi Kleen wrote:
>> I asked James about getting Vasu's unlocked_qcmds=1 patch merged, but he
>> convinced me that doing conditional locking while is very simple, is not
>> the proper way for getting this resolved in mainline code.  I think in
>> the end this will require a longer sit down to do a wholesale conversion
>> of all existing SCSI LLD drivers, and identifing the broken ones that
>> still need a struct Scsi_Host->host_lock'ed SHT->queuecommand() for
>> whatever strange & legacy reasons.
> 
> The standard way to do that would be to first move the lock down
> into the drivers (similar to how it has been done with the BKL).
> This would be a fairly mechanic mindless patch. Lots of typing,
> but not really a lot of real code review needed.
> 
> Then next step the drivers who know they don't want it can remove it.
> 
> -Andi

I see problems with this, but maybe I'm missing something.

It seems to me we can't completely move the host lock down into the
drivers since its a shared lock between SCSI and the drivers now.

If we just have SCSI drop the lock and have the LLD reacquire it,
that may open up a hole that some LLDs might not tolerate.
It also hurts performance for the LLDs that want to keep
the lock for the duration of queuecommand() by adding an extra
unlock/lock.

Obviously, some LLDs may depend on that shared lock being held,
without a drop just before the call.

So, I think the flag approach is OK, or wait until the wholesale
approach can be done.

	Regards,
	Joe