[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <f61afa55-f610-478b-9079-d37ad9c2f232@kernel.dk>
Date: Sat, 25 Oct 2025 07:27:01 -0600
From: Jens Axboe <axboe@...nel.dk>
To: Gabriel Krisman Bertazi <krisman@...e.de>
Cc: netdev@...r.kernel.org, io-uring@...r.kernel.org,
Jakub Kicinski <kuba@...nel.org>, "David S . Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>
Subject: Re: [PATCH 3/3] io_uring: Introduce getsockname io_uring cmd
On 10/24/25 9:49 AM, Gabriel Krisman Bertazi wrote:
> Introduce a socket-specific io_uring_cmd to support
> getsockname/getpeername via io_uring. I made this an io_uring_cmd
> instead of a new operation to avoid polluting the command namespace with
> what is exclusively a socket operation. In addition, since we don't
> need to conform to existing interfaces, this merges the
> getsockname/getpeername in a single operation, since the implementation
> is pretty much the same.
>
> This has been frequently requested, for instance at [1] and more
> recently in the project Discord channel. The main use-case is to support
> fixed socket file descriptors.
Just two nits below, otherwise looks good!
> diff --git a/io_uring/cmd_net.c b/io_uring/cmd_net.c
> index 27a09aa4c9d0..092844358729 100644
> --- a/io_uring/cmd_net.c
> +++ b/io_uring/cmd_net.c
> @@ -132,6 +132,28 @@ static int io_uring_cmd_timestamp(struct socket *sock,
> return -EAGAIN;
> }
>
> +static int io_uring_cmd_getsockname(struct socket *sock,
> + struct io_uring_cmd *cmd,
> + unsigned int issue_flags)
> +{
> + const struct io_uring_sqe *sqe = cmd->sqe;
> +
Random newline.
> + struct sockaddr_storage address;
> + struct sockaddr __user *uaddr;
> + int __user *ulen;
> + unsigned int peer;
> +
> + uaddr = u64_to_user_ptr(READ_ONCE(sqe->addr));
> + ulen = u64_to_user_ptr(sqe->addr3);
> + peer = READ_ONCE(sqe->optlen);
> +
> + if (sqe->ioprio || sqe->__pad1 || sqe->len || sqe->rw_flags)
> + return -EINVAL;
Most/all prep handlers tend to check these first, then proceed with
setting up if not set. Would probably make sense to mirror that here
too.
--
Jens Axboe
Powered by blists - more mailing lists