Messages in this thread | | | Date | Thu, 10 Aug 2023 13:57:54 +0100 | Subject | Re: [PATCH v2 2/8] io_uring/cmd: Introduce SOCKET_URING_OP_GETSOCKOPT | From | Pavel Begunkov <> |
| |
On 8/9/23 14:21, Willem de Bruijn wrote: > Breno Leitao wrote: >> Add support for getsockopt command (SOCKET_URING_OP_GETSOCKOPT), where >> level is SOL_SOCKET. This is leveraging the sockptr_t infrastructure, >> where a sockptr_t is either userspace or kernel space, and handled as >> such. >> >> Function io_uring_cmd_getsockopt() is inspired by __sys_getsockopt(). >> >> Differently from the getsockopt(2), the optlen field is not a userspace >> pointers. In getsockopt(2), userspace provides optlen pointer, which is >> overwritten by the kernel. In this implementation, userspace passes a >> u32, and the new value is returned in cqe->res. I.e., optlen is not a >> pointer. >> >> Important to say that userspace needs to keep the pointer alive until >> the CQE is completed. > > What bad things can happen otherwise? > > The kernel is not depending on a well behaved process for its > correctness here, is it? Any user pages have to be pinned while
Right, it's the user api thing. There are always userspace progs that would try to do:
submit_async() { char buf[20]; do_submit(sqe = {buf = buf, ...}); }
submit_async(); wait_completions();
> kernel might refer to them, for instance.
fwiw, it's passed down as a user ptr, which will be eventually used in copy_[from,to]_user() or so.
-- Pavel Begunkov
| |