From: "Valdis Klētnieks" <valdis.kletnieks@vt.edu>
To: noloader@gmail.com
Cc: kernelnewbies <kernelnewbies@kernelnewbies.org>
Subject: Re: Kernel TLS
Date: Sat, 30 Nov 2019 01:40:07 -0500 [thread overview]
Message-ID: <50226.1575096007@turing-police> (raw)
In-Reply-To: <CAH8yC8np0MGf2oJMq=DXj6XX1ZNyYuwiUeGdv-kKmv1JR0x5QQ@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1727 bytes --]
On Fri, 29 Nov 2019 23:37:35 -0500, Jeffrey Walton said:
repl: bad addresses:
Valentin VidiD\a <vvidic@valentin-vidic.from.hr> -- no mailbox in address, only a phrase (Valentin VidiD\a)
> On Fri, Nov 29, 2019 at 3:04 PM Jeffrey Walton <noloader@gmail.com> wrote:
> > ...
> > So now I am at:
> >
> > $ gcc -Wall -g2 -O1 ktls.c -o ktls
> > $ ./ktls
> > setsockopt failed, 524, Unknown error 524
>
> Now open in the Fedora bug tracker:
> https://bugzilla.redhat.com/show_bug.cgi?id=1778348
Looks like the 'unknown error' issue is a glibc strerror() problem. On the
kernel side, git blame says:
[/usr/src/linux-next] git blame include/linux/errno.h | grep -C 5 524
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 22)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 23) /* Defined for the NFSv3 protocol */
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 24) #define EBADHANDLE 521 /* Illegal NFS file handle */
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 25) #define ENOTSYNC 522 /* Update synchronization mismatch */
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 26) #define EBADCOOKIE 523 /* Cookie is stale */
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 27) #define ENOTSUPP 524 /* Operation is not supported */
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 28) #define ETOOSMALL 525 /* Buffer or request is too small */
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 29) #define ESERVERFAULT 526 /* An untranslatable error occurred */
So I'm mystified why glibc's strerror() doesn't handle it.
Though I think Alexander is correct on why the kernel returns ENOTSUPP.
I've updated the bugzilla entry.
[-- Attachment #1.2: Type: application/pgp-signature, Size: 832 bytes --]
[-- Attachment #2: Type: text/plain, Size: 170 bytes --]
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
next prev parent reply other threads:[~2019-11-30 6:40 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-29 19:36 Kernel TLS Jeffrey Walton
2019-11-29 19:46 ` Alexander Mihalicyn
2019-11-29 19:48 ` Valentin Vidić
2019-11-29 19:57 ` Jeffrey Walton
2019-11-29 20:04 ` Jeffrey Walton
2019-11-30 4:37 ` Jeffrey Walton
2019-11-30 6:16 ` Alexander Mihalicyn
2019-11-30 6:40 ` Valdis Klētnieks [this message]
2019-11-30 8:13 ` Bjørn Mork
2019-11-30 9:11 ` Valdis Klētnieks
2019-11-30 10:10 ` Bjørn Mork
2019-11-30 10:34 ` 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=50226.1575096007@turing-police \
--to=valdis.kletnieks@vt.edu \
--cc=kernelnewbies@kernelnewbies.org \
--cc=noloader@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.