[PATCHv6 0/5] net/tls: fixes for NVMe-over-TLS
Hannes Reinecke
hare at suse.de
Mon Jul 3 06:15:37 PDT 2023
On 7/3/23 14:33, Sagi Grimberg wrote:
>
>> Hannes Reinecke <hare at suse.de> wrote:
>>
>>>> 'discover' and 'connect' works, but when I'm trying to transfer data
>>>> (eg by doing a 'mkfs.xfs') the whole thing crashes horribly in
>>>> sock_sendmsg() as it's trying to access invalid pages :-(
>>
>> Can you be more specific about the crash?
>
> Hannes,
>
> See:
> [PATCH net] nvme-tcp: Fix comma-related oops
Ah, right. That solves _that_ issue.
But now I'm deadlocking on the tls_rx_reader_lock() (patched as to your
suggestion). Investigating.
But it brought up yet another can of worms: what _exactly_ is the return
value of ->read_sock()?
There are currently two conflicting use-cases:
-> Ignore the return value, and assume errors etc are signalled
via 'desc.error'.
net/strparser/strparser.c
drivers/infiniband/sw/siw
drivers/scsi/iscsi_tcp.c
-> use the return value of ->read_sock(), ignoring 'desc.error':
drivers/nvme/host/tcp.c
net/ipv4/tcp.c
So which one is it?
Needless to say, implementations following the second style do not
set 'desc.error', causing any errors there to be ignored for callers
from the first style...
Jakub?
Cheers,
Hannes
More information about the Linux-nvme
mailing list