> -----Original Message----- > From: Jitendra Bhivare [mailto:jitendra.bhiv...@broadcom.com] > Sent: Friday, September 23, 2016 8:38 PM > To: 'Mike Christie'; 'Martin K. Petersen' > Cc: 'linux-scsi@vger.kernel.org' > Subject: RE: [PATCH 02/28] be2iscsi: Replace _bh with _irqsave/irqrestore > > Hi Mike, > > I could reproduce hard lockup using for-next kernel only in > iscsi_eh_cmd_timeout path due to spin_lock_irqsave taken in > blk_timeout_work > Please refer stack trace below. > > The _bh version used for frwd_lock and back_lock does not seem to be > causing > any issue similar to seen with be2iscsi after replacing _bh versions in > be2iscsi. > > I am testing it further, to confirm in all possible scenarios... NOPs, > error > recovery, resets and reconnects. > On my setup, I affined all EQ interrupts on a single CPU. > Along with heavy IO, few of the invocations of fio were pinned to run on > same > CPU. > > Any call to unlock_bh with another spin_lock already held, invoking > do_softirq, > might cause deadlock if bottom half used by driver calls function which > needs > that another spin_lock. > Is there a code which prevents this issue? > The only place, I think, libiscsi can have issues is__iscsi_complete_pdu which should be protected under _bh version for frwd and back locks. If the function is executed in process context there is a good chance the base version of spin_lock used for frwd/back locks could cause deadlocks when lld uses _bh version in alloc_pdu path (__iscsi_complete_pdu->iscsi_send_nopout... alloc_pdu).
Thanks, JB -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
