diff options
| author | Andrea Parri <parri.andrea@gmail.com> | 2026-10-22 15:29:30 +0200 |
|---|---|---|
| committer | Keith Busch <kbusch@kernel.org> | 2026-10-28 08:11:19 -0700 |
| commit | 94f93c61b1a5dd08d011be58172ce4392b849008 (patch) | |
| tree | 4b4fa788424dc07b86b75e22c879238c5a1e72e8 /tools/lib/python/kdoc/python_version.py | |
| parent | d1512773a0d539669440bd9f6d050b8e12923b5f (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
