[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.