On Mon, Jun 27, 2011 at 09:31:39AM -0700, Roland Dreier wrote: > From: Roland Dreier <roland@xxxxxxxxxxxxxxx> > > Trying to drop hardware_lock in qla24xx_send_cmd_to_target() is not > safe, because sometimes we are in process context and sometimes we are > called from the qla2xxx interrupt handler, and so we don't know > whether to enable irqs or not. This leads to lockdep warnings among > other problems. Even more so using spin_is_locked to check whether we need to grab a look is completely bugger. The whole point of the lock is that someone else could be holding it. > The simplest fix seems to be to just keep hardware_lock held when > calling ->handle_cmd(). Then when tcm_qla2xxx_handle_cmd() knows that > it is going to call back into qla2xxx, it can simply clear locked_rsp > unconditionally, getting rid of the unsafe spin_is_locked() test > (unsafe because spin_is_locked() could return true when _some other_ > context is holding the lock). > > This also makes the locking for ->handle_cmd the same between > qla24xx_send_cmd_to_target() and qla2xxx_send_cmd_to_target() (since > the qla2xxx_ version never dropped the lock). Looks good to me. -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
