Both the TX (iscsi_queuecommand, iscsi_xmit_task, iscsi_conn_send_pdu)
and the RX (iscsi_complete_pdu and iser/tcp as well) code flows compete
on the session lock. Since the RX flow runs in softirq/bh/tasklet context,
if it cuts the TX flow on the same cpu, a deadlock may happen. To prevent
that,
Mike, I am debugging some enhancement to iser and came a cross this.
I really don't see why it haven't hit anyone in the past, any idea?
One more thing which I'd be happy to understand are what the rational behind
the
spin_unlock(host-host_lock) call in iscsi_queuecommand beginning and
Or Gerlitz wrote:
Both the TX (iscsi_queuecommand, iscsi_xmit_task, iscsi_conn_send_pdu)
and the RX (iscsi_complete_pdu and iser/tcp as well) code flows compete
on the session lock. Since the RX flow runs in softirq/bh/tasklet context,
if it cuts the TX flow on the same cpu, a deadlock may
Mike Christie micha...@cs.wisc.edu wrote:
The scsi_host_template-queuecommand function is called by scsi-ml with
irqs disabled spin_lock_irqsave(host-host_lock, flags)
thanks for clarifying that, specifically do you refer to scsi.c ::
scsi_dispatch_cmd()? at some point I was LXR-ing for
Or Gerlitz wrote:
Mike Christie micha...@cs.wisc.edu wrote:
The scsi_host_template-queuecommand function is called by scsi-ml with
irqs disabled spin_lock_irqsave(host-host_lock, flags)
thanks for clarifying that, specifically do you refer to scsi.c ::
scsi_dispatch_cmd()? at some point
