[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b7dae79b-4c5f-65f6-0960-617070357201@kernel.dk>
Date: Sun, 19 Apr 2020 16:22:52 -0600
From: Jens Axboe <axboe@...nel.dk>
To: Aleksa Sarai <cyphar@...har.com>,
Josh Triplett <josh@...htriplett.org>
Cc: linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
io-uring@...r.kernel.org, linux-arch@...r.kernel.org,
Alexander Viro <viro@...iv.linux.org.uk>,
Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCH v4 2/3] fs: openat2: Extend open_how to allow
userspace-selected fds
On 4/19/20 4:44 AM, Aleksa Sarai wrote:
> On 2020-04-13, Josh Triplett <josh@...htriplett.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.
--
Jens Axboe
Powered by blists - more mailing lists