Date: Sun, 14 Jan 2024 19:41:46 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Alan Somers <asomers@freebsd.org> Cc: =?utf-8?B?Vmluw61jaXVz?= dos Santos Oliveira <vini.ipsmaker@gmail.com>, freebsd-threads@freebsd.org, Konstantin Belousov <kib@freebsd.org> Subject: Re: aio_read2() and aio_write2() Message-ID: <ZaQc2jNbaeBrGHwi@kib.kiev.ua> In-Reply-To: <CAOtMX2gbJ6jBSBdyQuwJqPrwDom25=LgrApCBiy5oFuVXL5nQA@mail.gmail.com> References: <CAOtMX2haq%2BErvqD2PDYKUGRgdCrk2SDjtoPL-W5jR8q8_4denA@mail.gmail.com> <CAK9RveJLK9uU0twM%2BKznUNnUnsqzwoqidPN8dzNptMQ50Z7r1Q@mail.gmail.com> <CAOtMX2ijQ=KsccMyqH-yAn6SJPR7MD_yy6CF0R2vNrQ-fhUq2Q@mail.gmail.com> <ZaMsUn8xFKrDkJb_@kib.kiev.ua> <CAK9Rve%2BuYpxWyRPwh6gxjRkisU7WPKjXicU9%2BYiqFG-=c3trvg@mail.gmail.com> <CAOtMX2h7vmwKHWUm7aHAfJ0QGPYfaWUmriu%2BxpwA2yK8O2YOoA@mail.gmail.com> <CAK9RveK-sjLxCkKpkSTYkecRQVwT%2BuoOSsaW3xD130Hnwb=cog@mail.gmail.com> <CAOtMX2gbJ6jBSBdyQuwJqPrwDom25=LgrApCBiy5oFuVXL5nQA@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
On Sun, Jan 14, 2024 at 10:13:43AM -0700, Alan Somers wrote: > 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. You need seek cap rights to do lseek(2) on fd, which are specifically not included into cap rights needed for e.g. read(2) and write(2). > > >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. > > -Alanhelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ZaQc2jNbaeBrGHwi>