Mike Christie wrote: > James Smart wrote: >>> Actually, maybe, I should not have brought this up as it could just be >>> more of a workaround of the core problem. For FC in fc_user_scan() do >>> you need some sort of lock around the rport loop? >> Yes, I had noticed this as well. However, I don't think this is influencing >> the deadlock. >> > > iscsi needed a lock too. And so we ended up just adding a semaphore > around the addition and deletion and scanning of sessions. We also do Do what can happen is that we go from iscs_user_scan() grab iscsi lock around sessions scsi-ml scan() grab scsi scan lock delete session grab iscsi lock remove session from sessions list scsi ml host/decice deletion grab scsi scan lock and I am just saying I think we are duplicating some of the locking in the transport class (due to some weirdness with the userspace workarounds this is more or less true). - : 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
