Re: [WIP PATCH] io_uring: Support opening a file into the fixed-file table

[Jens Axboe <axboe@kernel.dk>]

On 7/14/20 3:08 PM, Josh Triplett wrote:
> Add a new operation IORING_OP_OPENAT2_FIXED_FILE, which opens a file
> into the fixed-file table rather than installing a file descriptor.
> Using a new operation avoids having an IOSQE flag that almost all
> operations will need to ignore; io_openat2_fixed_file also has
> substantially different control-flow than io_openat2, and it can avoid
> requiring the file table if not needed for the dirfd.
> 
> (This intentionally does not use the IOSQE_FIXED_FILE flag, because
> semantically, IOSQE_FIXED_FILE for openat2 should mean to interpret the
> dirfd as a fixed-file-table index, and that would be useful future
> behavior for both IORING_OP_OPENAT2 and IORING_OP_OPENAT2_FIXED_FILE.)
> 
> Create a new io_sqe_files_add_new function to add a single new file to
> the fixed-file table. This function returns -EBUSY if attempting to
> overwrite an existing file.
> 
> Provide a new field to pass along the fixed-file-table index for an
> open-like operation; future operations such as
> IORING_OP_ACCEPT_FIXED_FILE can use the same index.

I like this, I think it's really nifty! Private fds are fast fds, and
not only does this allow links to propagate the fds nicely, it also
enables you go avoid the expensive fget/fput for system calls if you
stay within the realm of io_uring for the requests that you are doing.

We do need to preface this with a cleanup that moves the file assignment
out of the prep side of the op handling and into the main part of it
instead. That'll fix those issues associated with needing to do two
bundles in your test case, it could all just be linked at that point.

Some of this is repeats of what we discussed outside of the list emails,
repeating it here for the general audience as well.

-- 
Jens Axboe