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 | org.kernel.vger.dccp,dev.linux.lists.mptcp,dev.linux.lists.virtualization,org.kernel.vger.bpf,org.kernel.vger.io-uring,org.kernel.vger.linux-bluetooth,org.kernel.vger.linux-can,org.kernel.vger.linux-hams,org.kernel.vger.linux-kernel,org.kernel.vger.linux-rdma,org.kernel.vger.linux-s390,org.kernel.vger.linux-sctp,org.kernel.vger.linux-wpan,org.kernel.vger.linux-x25,org.kernel.vger.netdev |
|---|---|
| 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?