[PATCH 11/18] nvme-tcp: control message handling for recvmsg()

[Sagi Grimberg]

>>> kTLS is sending TLS ALERT messages as control messages for recvmsg().
>>> As we can't do anything sensible with it just abort the connection
>>> and let the userspace agent to a re-negotiation.
>>
>> Is this a problem if we do end up adding read_sock to tls?
>> Although I do see that the tls code does manage this in the
>> sk_buff control buffer, so I assume there is access to this info.
>>
>> CC'ing Boris here as well.
>>
> Yeah, that was the other reason; cmsg aka TLS alerts are only available 
> for recvmsg().
> 
> However, for TLS 1.3 the only TLS alert which does not trigger a 
> connection reset would the the ominous 'new session ticket' alert.
> But during TLS handshake development we already decided to _disable_
> session tickets as they are pretty meaningless for our us.
> Consequently all TLS alerts will trigger a connection reset, and 
> realistically we don't _need_ to know which alert type has triggered
> the reset.
> 
> So 'read_sock()' could be implemented by closing the connection on
> any TLS alert, and not giving us access to any of the alerts via
> control messages. If that makes life easier ...

Most likely read_sock() is the wrong place to ignore alerts. Probably
the better way is to do this in nvme, although its a bit harder.