Re: SOCKET_URING_OP_GETSOCKOPT SOL_SOCKET restriction

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

On 3/28/25 16:34, Jens Axboe wrote:
> On 3/28/25 9:02 AM, 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.
> 
> Gah yes, now I remember. What's pretty annoying though, as it leaves the
> get/setsockopt parts less useful than they should be, compared to the
> regular syscalls.
> 
> Did we ever ponder ways of getting this sorted out on the net side?

I remember Breno looking at several different options.

Breno, can you remind me, why can't we convert ->getsockopt to
take a normal kernel ptr for length while passing a user ptr
for value as before?

-- 
Pavel Begunkov