On Fri, May 27, 2005 at 03:48:40AM -0400, Jeff Garzik wrote:
Christoph Hellwig wrote:
On Fri, May 27, 2005 at 12:32:07AM -0400, Jeff Garzik wrote:
SCSI EH processing already serializes things during EH, so this spinlock isn't really needed.
Removing the spinlock outright would break drivers that surround logic with spin_unlock_irq()..spin_lock_irq(), so I introduced ->unlocked_eh option.
Linus has vetoed such conditional locking in the past. However if you do
it don't make it EH specific but introduce a ->concurrent flag that disables
taking host_lock for ->queuecommand aswell.
Such a 'concurrent' flag violates Linus credo "do what you must, and no more." It's also silly and much too invasive.
Removing the locking from the EH routines (only), and fixing up all necessary drivers, is much more appealing.
No, hav ing the host_lock only held for ->queuecommand which doesn't need that locking doesn't make any sense. An API like the current one
It makes a lot of sense: LLDs are written with the assumption that paths called from ->queuecommand will not be interrupted by their own interrupt handler, whereas error handling paths are typically written with precisely the -opposite- assumption.
Removing spin_lock_irq() from queuecommand in SCSI EH causes problems, and solves nothing.
Jeff
- : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
