From: Breno Leitao <leitao@debian.org>
To: "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>,
Paolo Abeni <pabeni@redhat.com>, Simon Horman <horms@kernel.org>,
Kuniyuki Iwashima <kuniyu@google.com>,
Willem de Bruijn <willemb@google.com>,
metze@samba.org, axboe@kernel.dk,
Stanislav Fomichev <sdf@fomichev.me>
Cc: io-uring@vger.kernel.org, bpf@vger.kernel.org,
netdev@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>,
linux-kernel@vger.kernel.org, kernel-team@meta.com,
Breno Leitao <leitao@debian.org>
Subject: [PATCH net-next RFC 0/3] net: move .getsockopt away from __user buffers
Date: Fri, 30 Jan 2026 10:46:16 -0800 [thread overview]
Message-ID: <20260130-getsockopt-v1-0-9154fcff6f95@debian.org> (raw)
Currently, .getsockopt callback cannot be called with kernel buffers
because it requires userspace addresses:
int (*getsockopt)(struct socket *sock, int level,
int optname, char __user *optval, int __user *optlen);
This prevents kernel callers (io_uring, BPF, etc) from using getsockopt
on levels other than SOL_SOCKET, since they pass kernel pointers rather
than __user pointers.
Following Linus' suggestion [0], this series introduces a wrapper
around iov_iter (sockopt_t) and a temporary getsockopt_iter callback:
typedef struct sockopt {
struct iov_iter iter;
int optlen;
} sockopt_t;
Note: optlen was not suggested by Linus' but I believe it is needed, given
random values could be passed by protocols back to userspace.
And the callback becomes:
int (*getsockopt_iter)(struct socket *sock, int level,
int optname, sockopt_t *opt);
The sockopt_t structure encapsulates:
- An iov_iter for reading/writing option data (works with both user
and kernel buffers)
- An optlen field for buffer size (input) and returned data size
(output)
The plan is to enable getsockopt to leverage kernel buffers initially,
but then move .setsockopt from sockptr_t into this as well.
This series:
1. Adds the sockopt_t type and getsockopt_iter callback to proto_ops
2. Adds do_sock_getsockopt_iter() helper that prefers getsockopt_iter
3. Converts one protocol (netlink) to use getsockopt_iter as a proof of
concept
This is what I have in mind for this work stream, to make it more
digestible:
* Keep the temporary getsockopt_iter callback allows protocols to
migrate gradually.
* Once all protocols have been converted, getsockopt can be removed and
getsockopt_iter renamed back to getsockopt with the new API.
* Once the protocols are converted, the SOL_SOCKET limitation in
io_uring_cmd_getsockopt() will be removed.
* Covert setsockopt() to also use a similar strategy, moving it away
from sockptr_t.
* Remove sockptr_t in the front end (do_sock_getsockopt(),
io_uring_cmd_getsockopt()) and start with sockopt_t (instead of
sockptr_t) in __sys_getsockopt() and io_uring_cmd_getsockopt()
Link: https://lore.kernel.org/all/CAHk-=whmzrO-BMU=uSVXbuoLi-3tJsO=0kHj1BCPBE3F2kVhTA@mail.gmail.com/ [0]
---
Breno Leitao (3):
net: add getsockopt_iter callback to proto_ops
net: prefer getsockopt_iter in do_sock_getsockopt
netlink: convert to getsockopt_iter
include/linux/net.h | 19 +++++++++++++++++++
net/netlink/af_netlink.c | 22 ++++++++++++----------
net/socket.c | 42 +++++++++++++++++++++++++++++++++++++++---
3 files changed, 70 insertions(+), 13 deletions(-)
---
base-commit: 4d310797262f0ddf129e76c2aad2b950adaf1fda
change-id: 20260130-getsockopt-9f36625eedcb
Best regards,
--
Breno Leitao <leitao@debian.org>
next reply other threads:[~2026-01-30 18:47 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-30 18:46 Breno Leitao [this message]
2026-01-30 18:46 ` [PATCH net-next RFC 1/3] net: add getsockopt_iter callback to proto_ops Breno Leitao
2026-01-30 18:46 ` [PATCH net-next RFC 2/3] net: prefer getsockopt_iter in do_sock_getsockopt Breno Leitao
2026-01-30 18:46 ` [PATCH net-next RFC 3/3] netlink: convert to getsockopt_iter Breno Leitao
2026-01-30 20:52 ` [PATCH net-next RFC 0/3] net: move .getsockopt away from __user buffers David Laight
2026-01-31 1:19 ` Linus Torvalds
2026-01-31 15:37 ` David Laight
2026-01-31 15:53 ` Jens Axboe
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=20260130-getsockopt-v1-0-9154fcff6f95@debian.org \
--to=leitao@debian.org \
--cc=axboe@kernel.dk \
--cc=bpf@vger.kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=io-uring@vger.kernel.org \
--cc=kernel-team@meta.com \
--cc=kuba@kernel.org \
--cc=kuniyu@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=metze@samba.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sdf@fomichev.me \
--cc=torvalds@linux-foundation.org \
--cc=willemb@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox