summaryrefslogtreecommitdiff
path: root/tools/lib/python/kdoc/python_version.py
diff options
context:
space:
mode:
authorAndrea Parri <parri.andrea@gmail.com>2026-10-22 15:29:30 +0200
committerKeith Busch <kbusch@kernel.org>2026-10-28 08:11:19 -0700
commit94f93c61b1a5dd08d011be58172ce4392b849008 (patch)
tree4b4fa788424dc07b86b75e22c879238c5a1e72e8 /tools/lib/python/kdoc/python_version.py
parentd1512773a0d539669440bd9f6d050b8e12923b5f (diff)
nvmet-fc: only send read data for successful commands
When a read command completes with an error, __nvmet_fc_fcp_nvme_cmd_done() still pushes the whole data buffer to the host before the response. nvmet_fc_alloc_tgt_pgs() allocates that buffer with sgl_alloc() and no __GFP_ZERO, and a command rejected by nvmet_check_transfer_len() leaves it untouched, so the host receives stale target memory. The buffer is as large as the data length in the command IU, so the amount of stale memory returned is up to the host. The tcp and rdma targets send data only when cqe->status is zero (see nvmet_tcp_need_data_out() and nvmet_rdma_need_data_out()), so no nvmet command can rely on returning data with an error status. Do the same for fc. The ERSP then reports a transferred length of fod->offset, which is 0, matching what nvme_fc_fcpio_done() checks on the host. Tested over nvme-fcloop: a failed read command no longer transfers data and still completes with its error status, and successful reads are unaffected. Fixes: c53432030d86 ("nvme-fabrics: Add target support for FC transport") Cc: stable@vger.kernel.org Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Andrea Parri <parri.andrea@gmail.com> Signed-off-by: Keith Busch <kbusch@kernel.org>
Diffstat (limited to 'tools/lib/python/kdoc/python_version.py')
0 files changed, 0 insertions, 0 deletions