linux-kernel - Re: [patch/rfc] Make poll/select report error (POLLNVAL and EBADF) for unsupported files

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 for Android: free password hash cracker in your pocket

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

Date:	Wed, 17 Feb 2010 10:16:57 -0800 (PST)
From:	Davide Libenzi <davidel@...ilserver.org>
To:	THIELL Stephane <stephane.thiell@....fr>
cc:	Eric Dumazet <eric.dumazet@...il.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [patch/rfc] Make poll/select report error (POLLNVAL and EBADF)
 for unsupported files

On Wed, 17 Feb 2010, THIELL Stephane wrote:

> 
> > On Mon, 15 Feb 2010, Eric Dumazet wrote:
> > 
> >   
> > > Hmm, according to POSIX :
> > > 
> > > 	The poll() function shall support regular files, terminal and
> > > pseudo-terminal devices, FIFOs, pipes, sockets ...
> > > 
> > > 	Regular files shall always poll TRUE for reading and writing.
> > > 
> > >     
> As POSIX says poll(2) have to support regular files (and it seems all possible
> user file descriptors), then wouldn't it be better/more coherent to have
> epoll(7) behave the same way (ie. support regular files instead of
> epoll_ctl(2) returning EPERM), in order to allow generic code handling both
> very common situations like:
> 
> $ cat replay_file | application
> and
> $ application < replay_file
> 
> ...where for instance the application doesn't know the origine of its fd 0
> (pipe, file, or something else).

Most definitely no. POSIX behavior is just stupid, and should have been 
implemented by not having to report things/events that are not true.
Now, that's POSIX, and we cannot break its APIs.
New ones though, do not need to be necessarily stupid.
Besides, epoll needs an f_op->poll to work, and this would require all FS 
files to implement a bogus f_op->poll which simply returns the full event 
mask.
Which is just plain silly.
For things like epoll ET, this will simply not work, and even for LT, 
you'd get every time out of epoll_wait() because you have something there 
that always reports every event you ask, even though it is not true.

- Davide

--
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/