Re: SOCKET_URING_OP_GETSOCKOPT SOL_SOCKET restriction

[Stefan Metzmacher <metze@samba.org>]

Am 28.03.25 um 15:30 schrieb Jens Axboe:
> 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?!

It seems RFC had the limitation on both:
https://lore.kernel.org/io-uring/20230724142237.358769-1-leitao@debian.org/

v0 had it only for get because of some userpointer restrictions:
https://lore.kernel.org/io-uring/20230724142237.358769-1-leitao@debian.org/

The merged v7 also talks about the restriction:
https://lore.kernel.org/all/20231016134750.1381153-1-leitao@debian.org/

Adding Breno ...

It seems proto_ops->getsockopt is the problem as it's not changed
to sockptr_t yet.

metze