On Thu, 2006-04-20 at 16:46 -0700, Andrew Vasquez wrote: > On Wed, 19 Apr 2006, Arjan van de Ven wrote: > > > a question about qla2xxx lock ordering since it trips up with Ingo's > > lock depenceny tool: > > > > in qla2x00_mailbox_command() the code first grabs the mbx_reg_lock lock, > > then the hardware_lock. So far so good. But then... > > it drops the mbx_reg_lock, does stuff, and regrabs the mbx_reg_lock > > lock, while keeping the hardware_lock held! > > > > This appears to be an AB-BA deadlock risk since for the second part you > > are taking the locks in the wrong order... or am I missing something > > here? > > Actually the code is a bit convoluted, but I believe we are OK. There > are two scenarios we need to consider: ok found the real culprits ;) in qla2x00_reset_chip the driver first takes the hardware lock, and then later on takes the mbx lock. In the mailbox_command code.. it goes the other way around. Now I don't know if reset_chip can in theory race with the mailbox code, but I'd not be surprised since reset_chip is called in error recovery iirc... - : 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
