public inbox for io-uring@vger.kernel.org
 help / color / mirror / Atom feed
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

  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