Re: SOCKET_URING_OP_GETSOCKOPT SOL_SOCKET restriction

[Pavel Begunkov <asml.silence@gmail.com>]

On 3/28/25 14:30, Jens Axboe wrote:
> On 3/28/25 8:27 AM, Stefan Metzmacher wrote:
>> Hi Jens,
>>
>> while playing with the kernel QUIC driver [1],
>> I noticed it does a lot of getsockopt() and setsockopt()
>> calls to sync the required state into and out of the kernel.
>>
>> My long term plan is to let the userspace quic handshake logic
>> work with SOCKET_URING_OP_GETSOCKOPT and SOCKET_URING_OP_SETSOCKOPT.
>>
>> The used level is SOL_QUIC and that won't work
>> as io_uring_cmd_getsockopt() has a restriction to
>> SOL_SOCKET, while there's no restriction in
>> io_uring_cmd_setsockopt().
>>
>> What's the reason to have that restriction?
>> And why is it only for the get path and not
>> the set path?
> 
> There's absolutely no reason for that, looks like a pure oversight?!

Cc Breno, he can explain better, but IIRC that's because most
of set/get sockopt options expect user pointers to be passed in,
and io_uring wants to use kernel memory. It's plumbed for
SOL_SOCKET with sockptr_t, but there was a push back against
converting the rest.

The implications are not the uapi side. For example, io_uring
get/setsockopt returns err / len in a cqe->res. We can't do
that for SOL_SOCKET without the kernel pointer support, otherwise
io-uring uapi would need to get hacky. E.g. you'd need to
pass another user pointer is an SQE for socklen and read it
after completion.

-- 
Pavel Begunkov