Re: [PATCH v4 2/3] fs: openat2: Extend open_how to allow userspace-selected fds

[Aleksa Sarai <cyphar@cyphar.com>]

[-- Attachment #1: Type: text/plain, Size: 1545 bytes --]

On 2020-04-19, Jens Axboe <axboe@kernel.dk> wrote:
> On 4/19/20 4:44 AM, Aleksa Sarai wrote:
> > On 2020-04-13, Josh Triplett <josh@joshtriplett.org> wrote:
> >> Inspired by the X protocol's handling of XIDs, allow userspace to select
> >> the file descriptor opened by openat2, so that it can use the resulting
> >> file descriptor in subsequent system calls without waiting for the
> >> response to openat2.
> >>
> >> In io_uring, this allows sequences like openat2/read/close without
> >> waiting for the openat2 to complete. Multiple such sequences can
> >> overlap, as long as each uses a distinct file descriptor.
> > 
> > I'm not sure I understand this explanation -- how can you trigger a
> > syscall with an fd that hasn't yet been registered (unless you're just
> > hoping the race goes in your favour)?
> 
> io_uring can do chains of requests, where each link in the chain isn't
> started until the previous one has completed. Hence if you know what fd
> that openat2 will return, you can submit a chain ala:
> 
> <open file X, give me fd Y><read from fd Y><close fd Y>
> 
> as a single submission. This isn't possible to do currently, as the read
> will depend on the output of the open, and we have no good way of
> knowing what that fd will be.

Ah! I was aware of io_uring's chaining feature but thought it had access
to the return of the previous stage -- now this makes much more sense.
Thanks.

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]