[Bug 260449] incorrect PRIV_REQUEST() uses in iscsi target code

From: <bugzilla-noreply_at_freebsd.org>
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.