[Bug 260449] incorrect PRIV_REQUEST() uses in iscsi target code
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 22 Dec 2021 18:10:59 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260449 John Baldwin <jhb@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ken@FreeBSD.org --- Comment #1 from John Baldwin <jhb@FreeBSD.org> --- So I think the issue is that in cfiscsi_terminate_tasks() there is no request to store in PRIV_REQUEST() so it instead stores the session directly. However, it is possible to send a request on the wire that also results in CTL_IO_TASK and and CTL_TASK_I_T_NEXUS_RESET in cfiscsi_pdu_handle_task_request: case BHSTMR_FUNCTION_I_T_NEXUS_RESET: #if 0 CFISCSI_SESSION_DEBUG(cs, "BHSTMR_FUNCTION_I_T_NEXUS_RESET"); #endif io->taskio.task_action = CTL_TASK_I_T_NEXUS_RESET; break; And in this case, PRIV_REQUEST() is the request instead. Your test program constructs a normal CDB inquiry but then xors the first two bytes with 0x4b03 to generate 0x8b02 (little endian). 0x2 == ISCSI_BHS_OPCODE_TASK_REQUEST and 0x8b as the function == 0x80 | BHSTMR_FUNCTION_I_T_NEXUS_RESET. I think the bug is we need a clean way to differentiate between an on-the-wire reset vs the internally-initiatired reset. One way may be to allocate a new CTL_TASK_INTERNAL_RESET or some such that terminate_tasks would use instead of of CTL_TASK_I_T_NEXUS_RESET, and ctl_run_task would treat as identical to CTL_TASK_I_T_NEXUS_RESET. The only thing I don't yet understand for that is cfumass_done() in the usb storage driver checking for this opcode. Nothing in the cfumass driver schedules a CTL_IO_TASK, so I suspect the code in cfumass_done is just stale copy/paste from cfiscsi_done? -- You are receiving this mail because: You are the assignee for the bug.