[PATCH 0/2] nvme,tls: minimal handling for TLS records

[Hannes Reinecke]

Hi all,

TLS 1.3 can send additional TLS records while the connection is established,
and typically one would evaluate these records with passing in a control message
buffer for recvmsg(). But nvme-tcp is using the read_sock() interface which
does not allow for handling of control messages.
So as the lazy way out I opted for resetting the queue on any non-data TLS records
as this would be the default action anyway for most non-data TLS records.
But turns out that this does not work as planned, as the TLS records are evaluated
(and errors generated) before ->read_sock() is called, so nvme-tcp would receive
the error but not start error recovery.

This patchset is the minimal fix to handle it, start error recovery when a non-data
TLS record is received and also return a distinct error code from tls to indicate
the situation.

The 'real' fix will of course involve actually reading the control message and take
action based on the type, but that is a rather involved operation which will be addressed
later. So for now this simple fix should be sufficient.

Martin Belanger (2):
  nvme-tcp: start error recovery when read_sock fails
  tls: return a distinct error for control records from read_sock

 drivers/nvme/host/tcp.c | 18 +++++++++++++++++-
 net/tls/tls_sw.c        |  4 ++--
 2 files changed, 19 insertions(+), 3 deletions(-)

-- 
2.51.0