Re: [PATCH v3] net/tls: Fix return values to avoid ENOTSUPP
flat view
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Date: 2019-12-05 21:26:57
Also in:
lkml
On Thu, Dec 5, 2019 at 3:44 PM Valentin Vidić [off-list ref] wrote:
On Thu, Dec 05, 2019 at 03:06:55PM -0500, Willem de Bruijn wrote:quoted
On Thu, Dec 5, 2019 at 2:34 PM Jakub Kicinski [off-list ref] wrote:quoted
On Thu, 5 Dec 2019 07:41:18 +0100, Valentin Vidic wrote:quoted
ENOTSUPP is not available in userspace, for example: setsockopt failed, 524, Unknown error 524 Signed-off-by: Valentin Vidic <redacted>quoted
diff --git a/net/tls/tls_device.c b/net/tls/tls_device.c index 0683788bbef0..cd91ad812291 100644 --- a/net/tls/tls_device.c +++ b/net/tls/tls_device.c@@ -429,7 +429,7 @@ static int tls_push_data(struct sock *sk, if (flags & ~(MSG_MORE | MSG_DONTWAIT | MSG_NOSIGNAL | MSG_SENDPAGE_NOTLAST)) - return -ENOTSUPP; + return -EOPNOTSUPP; if (unlikely(sk->sk_err)) return -sk->sk_err;@@ -571,7 +571,7 @@ int tls_device_sendpage(struct sock *sk, struct page *page, lock_sock(sk); if (flags & MSG_OOB) { - rc = -ENOTSUPP; + rc = -EOPNOTSUPP;Perhaps the flag checks should return EINVAL? Willem any opinions?No strong opinion. Judging from do_tcp_sendpages MSG_OOB is a supported flag in general for sendpage, so signaling that the TLS variant cannot support that otherwise valid request sounds fine to me.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.
quoted
quoted
quoted
diff --git a/net/tls/tls_main.c b/net/tls/tls_main.c index bdca31ffe6da..5830b8e02a36 100644 --- a/net/tls/tls_main.c +++ b/net/tls/tls_main.c@@ -496,7 +496,7 @@ static int do_tls_setsockopt_conf(struct sock *sk, char __user *optval, /* check version */ if (crypto_info->version != TLS_1_2_VERSION && crypto_info->version != TLS_1_3_VERSION) { - rc = -ENOTSUPP; + rc = -EINVAL;This one I think Willem asked to be EOPNOTSUPP OTOH.Indeed (assuming no one disagrees). Based on the same rationale: the request may be valid, it just cannot be accommodated (yet).In this case other checks in the same function like crypto_info->cipher_type return EINVAL, so I used the same here.
That makes sense. 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.