diff options
author | Vasu Dev <vasu.dev@intel.com> | 2009-07-28 17:33:37 -0700 |
---|---|---|
committer | James Bottomley <James.Bottomley@HansenPartnership.com> | 2009-07-30 08:50:02 -0500 |
commit | a0cc1ecc098e31d03b3265712a3e280a7fabf438 (patch) | |
tree | c35828c5b9c9c7beb4f52dbe4163d9a087d60a0a /drivers/scsi/iscsi_tcp.h | |
parent | 16ed55f9de6743ceece9bf528362cadff10f1c5c (diff) | |
download | kernel-crypto-a0cc1ecc098e31d03b3265712a3e280a7fabf438.tar.gz kernel-crypto-a0cc1ecc098e31d03b3265712a3e280a7fabf438.tar.xz kernel-crypto-a0cc1ecc098e31d03b3265712a3e280a7fabf438.zip |
[SCSI] libfc: fix a circular locking warning during sending RRQ
Currently the fc_exch_rrq is called with fc_exch's ex_lock held.
The fc_exch_rrq allocates new exch and that requires taking
ex_lock again after EM lock. This locking order causes warning,
see more details on this warning at :-
http://www.open-fcoe.org/pipermail/devel/2009-July/003251.html
This patch fixes this by dropping the ex_lock before calling
fc_exch_rrq().
The fc_exch_rrq needs to grab ex_lock lock again to schedule
RRQ retry and in the meanwhile fc_exch_reset could occur before
ex_lock is grabbed inside fc_exch_rrq. So to handle this case,
this patch adds additional check to detect fc_exch_reset after
ex_lock acquired and in case the fc_exch_reset occurred then
abandons the RRQ retry and releases the exch.
Signed-off-by: Vasu Dev <vasu.dev@intel.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Diffstat (limited to 'drivers/scsi/iscsi_tcp.h')
0 files changed, 0 insertions, 0 deletions