nvmet-tcp: fix possible list corruption for unexpected command failure
nvmet_tcp_handle_req_failure needs to understand weather to prepare for incoming data or the next pdu. However if we misidentify this, we will wait for 0-length data, and queue the response although nvmet_req_init already did that. The particular command was namespace management command with no data, which was incorrectly categorized as a command with incapsule data. Also, add a code comment of what we are trying to do here. Signed-off-by: Sagi Grimberg <sagi@grimberg.me> Reviewed-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Christoph Hellwig <hch@lst.de>
This commit is contained in:
parent
8b77fa6fdc
commit
30e32f300b
|
@ -922,7 +922,14 @@ static void nvmet_tcp_handle_req_failure(struct nvmet_tcp_queue *queue,
|
|||
size_t data_len = le32_to_cpu(req->cmd->common.dptr.sgl.length);
|
||||
int ret;
|
||||
|
||||
if (!nvme_is_write(cmd->req.cmd) ||
|
||||
/*
|
||||
* This command has not been processed yet, hence we are trying to
|
||||
* figure out if there is still pending data left to receive. If
|
||||
* we don't, we can simply prepare for the next pdu and bail out,
|
||||
* otherwise we will need to prepare a buffer and receive the
|
||||
* stale data before continuing forward.
|
||||
*/
|
||||
if (!nvme_is_write(cmd->req.cmd) || !data_len ||
|
||||
data_len > cmd->req.port->inline_data_size) {
|
||||
nvmet_prepare_receive_pdu(queue);
|
||||
return;
|
||||
|
|
Loading…
Reference in New Issue