Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Fri, 6 Dec 2019 00:08:35 +0100
From:   Valentin =?utf-8?B?VmlkacSH?= <vvidic@valentin-vidic.from.hr>
To:     Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Cc:     Jakub Kicinski <jakub.kicinski@netronome.com>,
        Boris Pismenny <borisp@mellanox.com>,
        Aviad Yehezkel <aviadye@mellanox.com>,
        John Fastabend <john.fastabend@gmail.com>,
        Daniel Borkmann <daniel@iogearbox.net>,
        "David S. Miller" <davem@davemloft.net>,
        Network Development <netdev@vger.kernel.org>,
        linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3] net/tls: Fix return values to avoid ENOTSUPP
Message-ID: <20191205230835.GB20116@valentin-vidic.from.hr>
References: <20191204.165528.1483577978366613524.davem@davemloft.net>
 <20191205064118.8299-1-vvidic@valentin-vidic.from.hr>
 <20191205113411.5e672807@cakuba.netronome.com>
 <CA+FuTSe=GSP41GG+QYKEmQ0eDUEoFeQ+oGAsgGJEZTe=hJq4Tw@mail.gmail.com>
 <20191205204343.GA20116@valentin-vidic.from.hr>
 <CA+FuTSeu-ouuT37d9r40o62=_PcGBUmE_HaOAr9EsNPzpTw=ag@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CA+FuTSeu-ouuT37d9r40o62=_PcGBUmE_HaOAr9EsNPzpTw=ag@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, Dec 05, 2019 at 04:26:14PM -0500, Willem de Bruijn wrote:
> > I based these on the description from the sendmsg manpage, but you decide:
> >
> > EOPNOTSUPP
> >     Some bit in the flags argument is inappropriate for the socket type.
> 
> Interesting. That is a narrower interpretation than asm-generic/errno.h
> 
>   #define EOPNOTSUPP      95      /* Operation not supported on
> transport endpoint */
> 
> which is also the string that strerror() generates.

Found one interesting example where EINVAL seems to mean "this value will never work"
and EOPNOTSUPP means "this value will not work in the current state/type of socket":

        case TCP_FASTOPEN_CONNECT:
                if (val > 1 || val < 0) {
                        err = -EINVAL;
                } else if (net->ipv4.sysctl_tcp_fastopen & TFO_CLIENT_ENABLE) {
                        if (sk->sk_state == TCP_CLOSE)
                                tp->fastopen_connect = val;
                        else
                                err = -EINVAL;
                } else {
                        err = -EOPNOTSUPP;
                }
                break;

> I think there is a fundamental difference between, say, passing an
> argument of incorrect length (optlen < sizeof(..)) and asking for a
> possibly unsupported cipher mode. But consistency trumps that.
> 
> I don't mean to drag this out by bike-shedding.
> 
> Happy to defer to maintainers on whether the errno on published code
> can and should be changed, which is the more fundamental issue than
> the exact errno.
> 
> FWIW, I also did not see existing openssl and gnutls callers test the
> specific errno. The calls just fail on any setsockopt return value -1.

Right, I'm also fine with whatever the maintainer decides to take :)

-- 
Valentin