[PATCH 07/18] net/tls: sanitize MSG_EOR handling

Hannes Reinecke hare at suse.de
Tue Apr 18 03:24:12 PDT 2023


On 4/18/23 12:07, Sagi Grimberg wrote:
> 
>>>> The TLS stack is using MSG_EOR internally, so the flag cannot be
>>>> set for sendmsg()/sendpage(). But to avoid having the caller to
>>>> check whether TLS is active modify the code to clear the MSG_EOR
>>>> flag. And blank out MSG_MORE / MSG_SENDPAGE_NOTLAST, too, as they
>>>> conflict with MSG_EOR anyway.
>>>
>>> This looks like a temporary workaround to me.
>>>
>>> The networking folks really need to be CC'd on this (same for patch 6).
>>
>> Thanks, when I said "we can support EOR" I obviously meant support
>> not ignore it :(  No ack.
> 
> Obviously neither Hannes or I have sufficient tls knowledge to properly
> support it... It needs to be done by someone who knows the
> implementation.
> 
> Is this a large scope to add support for it? Because if it is, I'd
> simply change nvme to clear MSG_EOR when tls is used (despite my
> preference to not do special things for tls).

There's a rather simple patch for tls_sw. It already paces the data 
internally by an 'eor' variable, which is currently set to !MSG_MORE.
So evaluating MSG_EOR here is really trivial, and doesn't seem to cause 
any issues.

Or, at least, none which would show up with NVMe-over-TLS :-)

Cheers,

Hannes




More information about the Linux-nvme mailing list