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
