From: Jens Axboe <axboe@kernel.dk>
To: Daniele Di Proietto <daniele.di.proietto@gmail.com>,
io-uring@vger.kernel.org
Subject: Re: [PATCH] io_uring: Add IORING_OP_DUP
Date: Tue, 10 Mar 2026 10:24:40 -0600 [thread overview]
Message-ID: <c29a339d-67c5-4e8a-a1c9-2388aa9f28d5@kernel.dk> (raw)
In-Reply-To: <20260310154933.2500971-1-daniele.di.proietto@gmail.com>
On 3/10/26 9:49 AM, Daniele Di Proietto wrote:
> The new operation is like dup3(). The source file can be a regular file
> descriptor or a direct descriptor. The destination is a regular file
> descriptor.
>
> The direct descriptor variant is useful to move a descriptor to an fd
> and close the existing fd with a single acquisition of the `struct
> files_struct` `file_lock`. Combined with IORING_OP_ACCEPT or
> IORING_OP_OPENAT2 with direct descriptors, it can reduce lock contention
> for multithreaded applications.
Overall comment - how does this interact with direct descriptors? Feels
like this should support both, rather than just normal file descriptors.
> @@ -446,3 +452,46 @@ int io_pipe(struct io_kiocb *req, unsigned int issue_flags)
> fput(files[1]);
> return ret;
> }
> +
> +int io_dup_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe)
> +{
> + unsigned int flags;
> + struct io_dup *id;
> + int new_fd;
> +
> + if (sqe->off || sqe->addr || sqe->len || sqe->buf_index || sqe->addr3)
> + return -EINVAL;
> +
> + flags = READ_ONCE(sqe->dup_flags);
> + if (flags & ~IORING_DUP_NO_CLOEXEC)
> + return -EINVAL;
> +
> + new_fd = READ_ONCE(sqe->dup_new_fd);
> + if (new_fd < 0)
> + return -EBADF;
Is this necessary? Yes it'll help fail early, but do we care about that?
> + /* ensure the task's creds are used when installing/receiving fds */
> + if (req->flags & REQ_F_CREDS)
> + return -EPERM;
Not sure that's sane. Let's say you mark this request as IOSQE_ASYNC,
then it'd fail even if REQ_F_CREDS would then be set, and creds would
match the original task.
> +
> + id = io_kiocb_to_cmd(req, struct io_dup);
> + id->o_flags = O_CLOEXEC;
> + if (flags & IORING_DUP_NO_CLOEXEC)
> + id->o_flags = 0;
> + id->new_fd = new_fd;
> +
> + return 0;
> +}
> +
> +int io_dup(struct io_kiocb *req, unsigned int issue_flags)
> +{
> + struct io_dup *id;
> + int ret;
> +
> + id = io_kiocb_to_cmd(req, struct io_dup);
> + ret = replace_fd(id->new_fd, id->file, id->o_flags);
> + if (ret < 0)
> + req_set_fail(req);
> + io_req_set_res(req, ret, 0);
> + return IOU_COMPLETE;
And like Keith said here, we might need to punt it to io-wq if the file
has a ->flush() method.
--
Jens Axboe
next prev parent reply other threads:[~2026-03-10 16:24 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-10 15:49 [PATCH] io_uring: Add IORING_OP_DUP Daniele Di Proietto
2026-03-10 16:14 ` Keith Busch
2026-03-10 18:42 ` Daniele Di Proietto
2026-03-10 16:24 ` Jens Axboe [this message]
2026-03-10 18:42 ` Daniele Di Proietto
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c29a339d-67c5-4e8a-a1c9-2388aa9f28d5@kernel.dk \
--to=axboe@kernel.dk \
--cc=daniele.di.proietto@gmail.com \
--cc=io-uring@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox