linux-kernel - pipe/fifo, set exception for select() when read end is not open

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>] [day] [month] [year] [list]

Date:	Sun, 19 May 2013 18:54:29 -0400
From:	Neal Murphy <neal.p.murphy@...m.wpi.edu>
To:	linux-kernel@...r.kernel.org
Subject: pipe/fifo, set exception for select() when read end is not open

I've been looking at the gule hacks I have to use to get inotifywait to work 
in shell scripts. So I figgered I would hack inotifywait to look at exceptions 
in its select() loop. No joy.

inotifywait loops using select() to look for changes to at least one inotify 
FD. Whenever it sees a change, it reads the event and sends it to stdout. 
Cool. This works well and uses little CPU time. But there's a problem.

Suppose you have inotifywait monitoring a specific file for a change, such as 
"wait for this file to be deleted." And you have piped inotifywait to "while 
read a b c". The problem is that when the 'while' loop gets the DELETE event, 
it does what is needed and exits. And it is expected that inotifywait will 
exit.

But because the file it was watching has been deleted and can cause no more 
events, inotifywait will never receive another event, never return from 
select(), never write to the pipe, and never know that the pipe's reader 
exitted. It will never know that it should exit. Then I got to wondering why 
it is that writing to a pipe is the *only* way to know that the reader end is 
or has been closed (other than via complicated signalling). And wondering why.

Would it be possible to set an exception on a pipe's or fifo's writer FD when 
the reader FD is not open (when there are no readers or when there are none 
left)? Would it be reasonable to do this? I imagine a pipe should have a 'last 
reader closed' exception, while fifos could benefit from that and/or a 'no 
readers' exception.

If this exception existed, inotifywait could watch for read and exception 
changes using select(). An exception on stdout would almost certainly mean 
that the pipe has been welded shut, so inotifywait should just exit. This 
can't be the only example of a program that could benefit from knowing that 
one of its output pipes is closed without needing to write to the pipe to find 
out.

Thanks,
N

(Please CC me on replies.)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/