[PATCH] nvmet-tcp: Enforce update ordering between queue->cmd and rcv_state
Sagi Grimberg
sagi at grimberg.me
Mon Feb 17 00:23:32 PST 2025
On 16/02/2025 17:08, Meir Elisha wrote:
> The order in which queue->cmd and rcv_state are updated is crucial.
> If these assignments are reordered by the compiler, the worker might not
> get queued in nvmet_tcp_queue_response(), hanging the IO. to enforce the
> the correct reordering, set rcv_state using smp_store_release().
>
> Signed-off-by: Meir Elisha <meir.elisha at volumez.com>
Hey Meir, thanks for addressing this.
> ---
> drivers/nvme/target/tcp.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/nvme/target/tcp.c b/drivers/nvme/target/tcp.c
> index 7c51c2a8c109..b66aa93baaf4 100644
> --- a/drivers/nvme/target/tcp.c
> +++ b/drivers/nvme/target/tcp.c
> @@ -848,7 +848,8 @@ static void nvmet_prepare_receive_pdu(struct nvmet_tcp_queue *queue)
> queue->offset = 0;
> queue->left = sizeof(struct nvme_tcp_hdr);
> queue->cmd = NULL;
> - queue->rcv_state = NVMET_TCP_RECV_PDU;
> + // Ensure rcv_state is visible only after queue->cmd is set
Nit: let's stick to c-style comments.
> + smp_store_release(&queue->rcv_state, NVMET_TCP_RECV_PDU);
Isn't WRITE_ONCE() enough in this case? We don't really need smp barrier
here afaict...
More information about the Linux-nvme
mailing list