On 2020-04-19, Jens Axboe <axboe@xxxxxxxxx> wrote: > On 4/19/20 4:44 AM, Aleksa Sarai wrote: > > On 2020-04-13, Josh Triplett <josh@xxxxxxxxxxxxxxxx> 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:
signature.asc
Description: PGP signature
