[QUESTION] RDMA/srpt: is target_send_busy() safe before target_init_cmd()?

[QUESTION] RDMA/srpt: is target_send_busy() safe before target_init_cmd()?

[kensanya]

Hi,

While working on an unrelated target/stat change, Sashiko flagged a
pre-existing issue in ib_srpt.c:
  https://lore.kernel.org/all/20260709073426.5E7021F000E9@smtp.kernel.org/

I would like to confirm with RDMA/srpt maintainers whether this is a real
bug.

In srpt_handle_cmd():
  rc = srpt_get_desc_tbl(...);
  if (rc)
          goto busy;
  rc = target_init_cmd(...);
  if (rc != 0)
          goto busy;
  ...
busy:
  target_send_busy(cmd);
srpt_get_send_ioctx() zero-initializes se_cmd with memset(). cmd->se_tfo
appears to be set only later in target_init_cmd() -> __target_init_cmd().

So if srpt_get_desc_tbl() fails, target_send_busy() may run with
cmd->se_tfo still NULL:
  target_send_busy()
    -> cmd->se_tfo->queue_status(cmd)
Also, target_send_busy() is documented as:
  "Only call this function if target_submit_cmd*() failed."

That seems to cover the target_init_cmd() failure path, but not the
srpt_get_desc_tbl() failure path before init.

This goes back to:
  8b8807b9e982 ("scsi: RDMA/srpt: Fix handling of command / TMF submission failure")

Questions:
1. Is calling target_send_busy() before target_init_cmd() intentional /
   known-safe?
2. If not, should ib_srpt.c send a fabric-local SRP_RSP BUSY (or otherwise
   free the send ioctx) when se_tfo is unset, and keep target_send_busy()
   only for the post-init failure path?

I have not reproduced a crash on hardware yet; this is from code review of
the Sashiko report.

Thanks,
TanZheng

Re: [QUESTION] RDMA/srpt: is target_send_busy() safe before target_init_cmd()?

[Bart Van Assche]

On 7/16/26 7:54 PM, kensanya@163.com wrote:
> 1. Is calling target_send_busy() before target_init_cmd() intentional /
>     known-safe?

I think that's a bug.

> 2. If not, should ib_srpt.c send a fabric-local SRP_RSP BUSY (or otherwise
>     free the send ioctx) when se_tfo is unset, and keep target_send_busy()
>     only for the post-init failure path?

How about swapping the order of the target_init_cmd() and
srp_get_desc_tbl() calls and initializing .data_length and 
.data_direction after the srp_get_desc_tbl() call?

Thanks,

Bart.

Re:Re: [QUESTION] RDMA/srpt: is target_send_busy() safe before target_init_cmd()?

[kensanya]

At 2026-07-18 01:59:35, "Bart Van Assche" <bvanassche@acm.org> wrote:
>On 7/16/26 7:54 PM, kensanya@163.com wrote:
>> 1. Is calling target_send_busy() before target_init_cmd() intentional /
>>     known-safe?
>
>I think that's a bug.
>
>> 2. If not, should ib_srpt.c send a fabric-local SRP_RSP BUSY (or otherwise
>>     free the send ioctx) when se_tfo is unset, and keep target_send_busy()
>>     only for the post-init failure path?
>
>How about swapping the order of the target_init_cmd() and
>srp_get_desc_tbl() calls and initializing .data_length and 
>.data_direction after the srp_get_desc_tbl() call?
>
>Thanks,
>
>Bart.

Hi，
Bart

This plan involves fewer changes. Perhaps I could submit a fix patch.

Thanks
TanZheng

Re:Re:Re: [QUESTION] RDMA/srpt: is target_send_busy() safe before target_init_cmd()?

[kensanya]

At 2026-07-20 10:10:34, "kensanya" <kensanya@163.com> wrote:
>
>At 2026-07-18 01:59:35, "Bart Van Assche" <bvanassche@acm.org> wrote:
>>On 7/16/26 7:54 PM, kensanya@163.com wrote:
>>> 1. Is calling target_send_busy() before target_init_cmd() intentional /
>>>     known-safe?
>>
>>I think that's a bug.
>>
>>> 2. If not, should ib_srpt.c send a fabric-local SRP_RSP BUSY (or otherwise
>>>     free the send ioctx) when se_tfo is unset, and keep target_send_busy()
>>>     only for the post-init failure path?
>>
>>How about swapping the order of the target_init_cmd() and
>>srp_get_desc_tbl() calls and initializing .data_length and 
>>.data_direction after the srp_get_desc_tbl() call?
>>
>>Thanks,
>>
>>Bart.
>
>Hi，
>Bart
>
>This plan involves fewer changes. Perhaps I could submit a fix patch.
>
>Thanks
>TanZheng
>
Hi 
Bart

How about this? 
https://lore.kernel.org/all/20260720025941.69809-1-kensanya@163.com/

Thanks
TanZheng