Re: [PATCH v2 2/8] io_uring/cmd: Introduce SOCKET_URING_OP_GETSOCKOPT

[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