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

[kensanya@163.com]

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