linux-kernel - Re: splice(-> FIFO) never wakes up inotify IN

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <sw26o55ax3cfaaqhlbd2qxkdroujnfxtbxrmt2rpjztmedz3mn@uauqn6hexwdq>
Date:   Mon, 26 Jun 2023 17:15:23 +0200
From:   Ahelenia Ziemiańska 
        <nabijaczleweli@...ijaczleweli.xyz>
To:     Jan Kara <jack@...e.cz>
Cc:     Amir Goldstein <amir73il@...il.com>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Christian Brauner <brauner@...nel.org>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: splice(-> FIFO) never wakes up inotify IN_MODIFY?

On Mon, Jun 26, 2023 at 05:00:01PM +0200, Jan Kara wrote:
> On Mon 26-06-23 16:25:41, Ahelenia Ziemiańska wrote:
> > On Mon, Jun 26, 2023 at 03:51:59PM +0200, Jan Kara wrote:
> > > On Mon 26-06-23 14:57:55, Ahelenia Ziemiańska wrote:
> > > > On Mon, Jun 26, 2023 at 02:19:42PM +0200, Ahelenia Ziemiańska wrote:
> > > > > > splice(2) differentiates three different cases:
> > > > > >         if (ipipe && opipe) {
> > > > > > ...
> > > > > >         if (ipipe) {
> > > > > > ...
> > > > > >         if (opipe) {
> > > > > > ...
> > > > > > 
> > > > > > IN_ACCESS will only be generated for non-pipe input
> > > > > > IN_MODIFY will only be generated for non-pipe output
> > > > > >
> > > > > > Similarly FAN_ACCESS_PERM fanotify permission events
> > > > > > will only be generated for non-pipe input.
> > > > Sorry, I must've misunderstood this as "splicing to a pipe generates
> > > > *ACCESS". Testing reveals this is not the case. So is it really true
> > > > that the only way to poll a pipe is a sleep()/read(O_NONBLOCK) loop?
> > > So why doesn't poll(3) work? AFAIK it should...
> > poll returns instantly with revents=POLLHUP for pipes that were closed
> > by the last writer.
> > 
> > Thus, you're either in a hot loop or you have to explicitly detect this
> > and fall back to sleeping, which defeats the point of polling:
> I see. There are two ways around this:
> 
> a) open the file descriptor with O_RDWR (so there's always at least one
> writer).
Not allowed in the general case, since you need to be able to tail -f
files you can't write to.

> b) when you get POLLHUP, just close the fd and open it again.
Not allowed semantically, since tail -f follows the file, not the name.

> In these cases poll(3) will behave as you need (tested)...
Alas, those are not applicable to the standard use-case.
If only linux exposed a way to see if a file was written to!

For reference with other implementations,
this just works and is guaranteed to work under kqueue(2) EVFILT_READ
(admittedly, kqueue(2) is an epoll(7)-style system and not an
 inotify(7)-style one, but it solves the issue,
 and that's what NetBSD tail -f uses).

Maybe this is short-sighted but I don't actually really see why inotify
is... expected? To only generate file-was-written events only for some
writes?

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)