Re: [RFC PATCH 0/4] net/io_uring: pass a kernel pointer via optlen_t to proto[_ops].getsockopt()

Stanislav Fomichev <[email protected]> Mon, 31 Mar 2025 14:04:51 -0700
Newsgroups gmane.linux.can,gmane.linux.network,gmane.linux.kernel,gmane.linux.hams,gmane.linux.bluez.kernel,gmane.linux.drivers.rdma,gmane.network.tipc.general,gmane.linux.x25,gmane.linux.kernel.bpf,gmane.linux.isdn.i4l.user,gmane.linux.kernel.io-uring
Message-ID <Z-sDc-0qyfPZz9lv@mini-arch>
On 03/31, Stefan Metzmacher wrote:
> The motivation for this is to remove the SOL_SOCKET limitation
> from io_uring_cmd_getsockopt().
> 
> The reason for this limitation is that io_uring_cmd_getsockopt()
> passes a kernel pointer as optlen to do_sock_getsockopt()
> and can't reach the ops->getsockopt() path.
> 
> The first idea would be to change the optval and optlen arguments
> to the protocol specific hooks also to sockptr_t, as that
> is already used for setsockopt() and also by do_sock_getsockopt()
> sk_getsockopt() and BPF_CGROUP_RUN_PROG_GETSOCKOPT().
> 
> But as Linus don't like 'sockptr_t' I used a different approach.
> 
> @Linus, would that optlen_t approach fit better for you?

[..]

> Instead of passing the optlen as user or kernel pointer,
> we only ever pass a kernel pointer and do the
> translation from/to userspace in do_sock_getsockopt().

At this point why not just fully embrace iov_iter? You have the size
now + the user (or kernel) pointer. Might as well do
s/sockptr_t/iov_iter/ conversion?