Re: SOCKET_URING_OP_GETSOCKOPT SOL_SOCKET restriction

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

On 3/28/25 15:02, Pavel Begunkov wrote:
> 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

s/not/on/

> 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