netdev - Re: [PATCH 2/4] net/tls: handle MSG_EOR for tls

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20230613095942.2b3063cb@kernel.org>
Date: Tue, 13 Jun 2023 09:59:42 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Hannes Reinecke <hare@...e.de>
Cc: Sagi Grimberg <sagi@...mberg.me>, Christoph Hellwig <hch@....de>, Keith
 Busch <kbusch@...nel.org>, linux-nvme@...ts.infradead.org,
 netdev@...r.kernel.org
Subject: Re: [PATCH 2/4] net/tls: handle MSG_EOR for tls_device TX flow

On Tue, 13 Jun 2023 10:11:01 +0200 Hannes Reinecke wrote:
> >> +    if ((msg->msg_flags & MSG_MORE) &&
> >> +        (msg->msg_flags & MSG_EOR))
> >> +        return -EOPNOTSUPP;  
> > 
> > EINVAL is more appropriate I think...
> >   
> Guess what, that's what I did initially.
> But then when returning EINVAL we would arguably introduce a regression
> (as suddenly we'll be returning a different error code as previously).
> So with this patch we're backwards compatible.
> 
> But that's really a quesion for Jakub: what's more appropriate here?
> Return a new error code (which describes the situation better) or stick
> with the original one (and retain compability)?

EINVAL sounds better, EOPNOTSUPP means not implemented yet, once the
thing is implemented it's natural that we'll start returning more
precise error codes.

BTW you need to respin on top of net-next, David's multi-page sendpage
has rejigged this code quite a bit.