Re: SOCKET_URING_OP_GETSOCKOPT SOL_SOCKET restriction

[Breno Leitao <leitao@debian.org>]

Hello Stefan,

On Fri, Mar 28, 2025 at 04:02:35PM +0100, Stefan Metzmacher wrote:
> 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.

Correct. That is because Linus detests sockptr and didn't recommend
adding new code to use it.

 > New code does *not* have that excuse.

  https://lore.kernel.org/all/CAHk-=wgGV61xrG=gO0=dXH64o2TDWWrXn1mx-CX885JZ7h84Og@mail.gmail.com/

This was raised by Jakub in:

  https://lore.kernel.org/all/20230905154951.0d0d3962@kernel.org/

So, in order to implement the missing part, we need to move this to
something else. The initial suggestion was to use iovec, but, I found it
very hard to move that code to iovec.