All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Miller <davem@davemloft.net>
To: willemdebruijn.kernel@gmail.com
Cc: jakub.kicinski@netronome.com, vvidic@valentin-vidic.from.hr,
	borisp@mellanox.com, aviadye@mellanox.com,
	john.fastabend@gmail.com, daniel@iogearbox.net,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] net/tls: Fix return values for setsockopt
Date: Wed, 04 Dec 2019 12:51:35 -0800 (PST)	[thread overview]
Message-ID: <20191204.125135.750458923752225025.davem@davemloft.net> (raw)
In-Reply-To: <CA+FuTSdhtGZtTnuncpYaoOROF7L=coGawCPSLv7jzos2Q+Tb=Q@mail.gmail.com>

From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Date: Wed, 4 Dec 2019 15:43:00 -0500

> On Wed, Dec 4, 2019 at 2:36 PM Jakub Kicinski
> <jakub.kicinski@netronome.com> wrote:
>>
>> (there is a v2, in case you missed)
> 
> Thanks. I meant to respond to your comment. (but should have done sooner :)
> 
>> On Wed, 4 Dec 2019 14:22:55 -0500, Willem de Bruijn wrote:
>> > On Tue, Dec 3, 2019 at 6:08 PM Jakub Kicinski wrote:
>> > > On Tue,  3 Dec 2019 23:44:58 +0100, Valentin Vidic wrote:
>> > > > ENOTSUPP is not available in userspace:
>> > > >
>> > > >   setsockopt failed, 524, Unknown error 524
>> > > >
>> > > > Signed-off-by: Valentin Vidic <vvidic@valentin-vidic.from.hr>
>> > >
>> > > I'm not 100% clear on whether we can change the return codes after they
>> > > had been exposed to user space for numerous releases..
>> >
>> > This has also come up in the context of SO_ZEROCOPY in the past. In my
>> > opinion the answer is no. A quick grep | wc -l in net/ shows 99
>> > matches for this error code. Only a fraction of those probably make it
>> > to userspace, but definitely more than this single case.
>> >
>> > If anything, it may be time to define it in uapi?
>>
>> No opinion but FWIW I'm toying with some CI for netdev, I've added a
>> check for use of ENOTSUPP, apparently checkpatch already sniffs out
>> uses of ENOSYS, so seems appropriate to add this one.
> 
> Good idea if not exposing this in UAPI.

I'm trying to understand this part of the discussion.

If we have been returning a non-valid error code, this 524 internal
kernel thing, it is _NOT_ an exposed UAPI.

It is a kernel bug and we should fix it.

If userspace anywhere is checking for 524, that is what needs to be fixed.

Do we agree on this point?

  reply	other threads:[~2019-12-04 20:51 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-03 22:44 [PATCH] net/tls: Fix return values for setsockopt Valentin Vidic
2019-12-03 22:55 ` Jakub Kicinski
2019-12-04 18:29   ` [PATCH v2] " Valentin Vidic
2019-12-04 19:22   ` [PATCH] " Willem de Bruijn
2019-12-04 19:35     ` Jakub Kicinski
2019-12-04 20:43       ` Willem de Bruijn
2019-12-04 20:51         ` David Miller [this message]
2019-12-04 23:01           ` Jakub Kicinski
2019-12-05  0:55             ` David Miller
2019-12-05  6:41               ` [PATCH v3] net/tls: Fix return values to avoid ENOTSUPP Valentin Vidic
2019-12-05 19:34                 ` Jakub Kicinski
2019-12-05 20:06                   ` Willem de Bruijn
2019-12-05 20:43                     ` Valentin Vidić
2019-12-05 20:45                       ` Jakub Kicinski
2019-12-05 21:26                       ` Willem de Bruijn
2019-12-05 23:08                         ` Valentin Vidić
2019-12-07  4:17                 ` David Miller
  -- strict thread matches above, loose matches on Subject: below --
2019-11-30 10:34 Kernel TLS Valdis Klētnieks
2019-11-30 12:54 ` [PATCH] net/tls: Fix return values for setsockopt Valentin Vidic
2019-11-30 13:15   ` Jeffrey Walton
2019-11-30 13:31     ` Valentin Vidić

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191204.125135.750458923752225025.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=aviadye@mellanox.com \
    --cc=borisp@mellanox.com \
    --cc=daniel@iogearbox.net \
    --cc=jakub.kicinski@netronome.com \
    --cc=john.fastabend@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=vvidic@valentin-vidic.from.hr \
    --cc=willemdebruijn.kernel@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.