Details
- Reviewers
mav
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 44072 Build 40960: arc lint + arc unit
Event Timeline
| sys/dev/iscsi/iscsi.c | ||
|---|---|---|
| 258 | So I ran into a panic for this case due to passing NULL to xpt_freeze_simq() in a test for Chelsio's QA that did link flaps in a loop while testing multipath over two connections to the same target. | |
| 347 | I haven't seen this panic, but it is based on code reading. My comment above is also based on code reading, and I think it is some sort of bug. | |
I suppose the idea was that iscsi_pdu_queue_locked should not receive new PDUs after SIM is destroyed. xpt_freeze_simq() uses different locks than the SIM, so there is a window between xpt_freeze_simq() in iscsi_session_cleanup() and iscsi_action(), which is closed by is->is_simq_frozen == true check in the last. I see iscsi_session_cleanup() sets is->is_simq_frozen = false at the end before destroying SIM, so if some request is already waiting for SIM lock, it will get into iscsi_action() before the SIM destruction and slip through that check. But that I suppose should be covered by is->is_terminating || (is->is_connected == false && fail_on_disconnection) check. At least with sleepy eyes I can't see how else the PDU may get there from CAM side via iscsi_action_scsiio(), so I I suspect it may be some other iscsi_pdu_queue_locked() from inside the iSCSI code.