[PATCH v4] nvmet-tcp: fix a segmentation fault during io parsing error

[Grupi, Elad]

Not sure I'm following.

Once req_init is failed, nvmet_tcp_handle_req_failure is called and changes the state to NVMET_TCP_RECV_DATA.
In state NVMET_TCP_RECV_DATA we should not queue the response before it is get off from the list.

Am I missing something here?

-----Original Message-----
From: Hou Pu <houpu.main at gmail.com> 
Sent: Wednesday, 31 March 2021 10:49
To: Grupi, Elad
Cc: linux-nvme at lists.infradead.org; sagi at grimberg.me
Subject: Re: [PATCH v4] nvmet-tcp: fix a segmentation fault during io parsing error


[EXTERNAL EMAIL] 

On Tue, 30 Mar 2021 20:24:07 +0300, Elad wrote:
> @@ -960,7 +981,7 @@ static int nvmet_tcp_done_recv_pdu(struct nvmet_tcp_queue *queue)
>  			le32_to_cpu(req->cmd->common.dptr.sgl.length));
> 
>  		nvmet_tcp_handle_req_failure(queue, queue->cmd, req);
> -		return -EAGAIN;
> +		return 0;
>  	}
> 
>  	ret = nvmet_tcp_map_data(queue->cmd);

Hi Elad
By returning 0, the response is queued twice before it is get off from the list. Even still returning -EAGAIN, the cmd still could be queued twice potentially.

I think we'd better not queue the failed cmd in first place.
Please see my following fix later.

Thanks,
Hou