Re: aio_read2() and aio_write2()

On Sun, Jan 14, 2024 at 10:07 AM Vinícius dos Santos Oliveira
<vini.ipsmaker@gmail.com> wrote:
>
> Em dom., 14 de jan. de 2024 às 13:30, Alan Somers
> <asomers@freebsd.org> escreveu:
> > I don't understand.  What are you worried about that would block?
> > lseek never does.  It never actually goes to disk; it just retrieves a
> > variable from within the kernel.  So while the expense of a syscall is
> > non-zero, you don't have to worry about lseek blocking.
>
> Sorry, that was a lot of condensed information that I dumped together.
>
> We can use lseek to get the offset and use AIO specifying the offset
> we just queried. However the untrusted sandboxed process might
> actually send as a socket file descriptor (we don't control what we
> get from the untrusted sandboxed process), and lseek is then
> inappropriate.

In that case, I believe lseek should return ESPIPE.

From what I've read from the source code, we can pass
> these bogus offsets to AIO, and it'll just work. However we're still
> paying an extra syscall (and code doesn't feel right anyway).
>
> Anyway, the kernel *already* has this thread pool (AIO daemons), and
> the only change required here is a flag that controls whether
> FOF_OFFSET is passed along. That's a pretty non-invasive change. What
> is the problem? Again, the model already works fine on Windows and
> Linux.

The problem is that this flag would be almost impossible to use
correctly for the intended use cases of POSIX AIO.  Your application
is actually pretty unusual in that it only has one operation in-flight
at a time.  I think it would be better to use the lseek solution
rather than add a footgun to POSIX AIO.

-Alan