Discussion:
[Bug 260449] incorrect PRIV_REQUEST() uses in iscsi target code
(too old to reply)
b***@freebsd.org
2021-12-16 01:35:24 UTC
Permalink
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260449

Mark Linimon <***@FreeBSD.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Assignee|***@FreeBSD.org |***@FreeBSD.org
--
You are receiving this mail because:
You are the assignee for the bug.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
b***@freebsd.org
2021-12-22 18:10:59 UTC
Permalink
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260449

John Baldwin <***@FreeBSD.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@FreeBSD.org

--- Comment #1 from John Baldwin <***@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.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
b***@freebsd.org
2022-01-26 21:40:41 UTC
Permalink
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260449

John Baldwin <***@FreeBSD.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Assignee|***@FreeBSD.org |***@FreeBSD.org
Status|New |In Progress

--- Comment #2 from John Baldwin <***@FreeBSD.org> ---
Candidate fix up for review at https://reviews.freebsd.org/D34055
--
You are receiving this mail because:
You are the assignee for the bug.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Loading...