nvme: fix handling of tls alerts

[Paul Moses]

> Not sure about a reproducer, but we certainly need to handle TLS
> messages (including TLS Alerts) correctly. There is a patchset
> to implement REPLACETLSPSK which basically requires us to handle
> TLS messages.
> 

I don't think so, they were porting the fix from sunrpc. What I 
removed is what does not apply here.

From: https://lore.kernel.org/stable/CACSpFtDo+Bo0Dre-c9yxf7OEJNUUDesk-Lf+6sCdmMBQH=_JvQ@mail.gmail.com/

This is where my patch deviates from original:

> Yes we certainly can do something like what you had previously
> if (len == 0 || len == -EIO) {
>   pr_err("queue %d: unhandled control message\n", queue->idx);
>   return -EAGAIN;
> }

> But not that in that case TLS alert bytes would still be unconsumed
> staying in the socket. If what follows is a prompt closing of the
> connection, then who cares. What has been worrying me (even in the
> NFS) code is what happens when TLS alert (though we do consume it)
> isn't followed by the connection closing.

> Now let me know if you want me to re-do this patch based on what you
> suggested and ignore when len=-EIO. And then I can redo the patch#4
> based on that.

This only matters if we intend to continue on that socket after the 
control record, nvmet does not. Any negative recv tears the queue down 
immediately. For nvmet, detecting MSG_CTRUNC and aborting is best choice.

Thanks,
Paul