Re: [PATCH] io_uring: Add IORING_OP_DUP

[Pavel Begunkov <asml.silence@gmail.com>]

On 3/10/26 18:42, Daniele Di Proietto wrote:
> On Tue, Mar 10, 2026 at 4:24 PM Jens Axboe <axboe@kernel.dk> wrote:
>>
>> 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.
> 
> As implemented, the operation supports:
> 1. src: direct, dst: normal (this is the use case I mostly care about)
> 2. src: normal, dst: normal ()
> 
> I can extend it to also support
> 3. src: direct, dst: direct
> 4, src: normal, dst: direct
> 
> I can use IOSQE_FIXED_FILE to pick the source and I guess I can use a
> bit in dup_flags (something like IORING_DUP_DIRECT) to decide whether
> the destination is a direct descriptor or normal.
> 
> Does that make sense?

Let's not try to reuse IOSQE_FIXED_FILE for that. We may want to
operate with io_uring's filetable entries and not just files you get
from there. Two separate IORING_DUP_* flags should be better. And
you can extract a helper function out of

io_uring/splice.c::io_splice_get_file()

It might also be better to make it a part of IORING_OP_FILES_UPDATE
instead of wasting another opcode, and liburing can provide a
prep_dup helper for convenience.

-- 
Pavel Begunkov