[PATCH 2/2] nvme-tcp: consume TLS records without application data

[Martin Belanger]

On 11/9/26 14:21, sashiko-bot at kernel.org wrote:
> [Severity: Medium]
> Can dropping the socket lock here let concurrent callers of
> nvme_tcp_try_recv() race on the same TLS control record?

The report is correct. On a poll queue, nvme_tcp_io_work() and
nvme_tcp_poll() both call nvme_tcp_try_recv(). This patch releases the
socket lock before recvmsg(), so both callers can see the same record.
The second caller then fails the queue, and the controller reconnects.

Without this patch, every such record leads to a reconnect. So the race
does not make the result worse than today, but it is a bug in this
patch.

v2 will add a queue flag. The caller that gets -EINVAL from read_sock()
sets it with test_and_set_bit() before it releases the socket lock, and
clears it after it takes the lock again. A caller that finds the flag
set returns 0 and leaves the record to the first one. The flag is set
and tested only under the socket lock, so its owner knows the record at
the head of the queue is the one read_sock() reported.

v2 will also include the cmsg buffer fix from the report on patch 1,
and a test with poll queues.

Martin