On Thu, Jan 6, 2022 at 10:41 AM Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> What do_pollfd() does if there's no file associated with the fd is to
> use EPOLLNVAL (an actual negative fd is ignored):
>
> mask = EPOLLNVAL;
> f = fdget(fd);
> if (!f.file)
> goto out;
>
> and I wonder if we should try something equivalent for select() as a
> slightly less drastic change.
>
> Of course, select() doesn't actually have EPOLLNVAL, but it does have
> EPOLLERR and EPOLLPRI, which would set all the bits for that fd.
Actually, it would probably be better to actually use EPOLLNVAL
exactly to be consistent with epoll() on a code level, and just also
add that bit to the POLL{IN,OUT,ERR}_SET collections, so that an fd
that has been closed will set all the in/out/ex bits.
I suspect that not only is the most consistent we can be with
'poll()', putting a bit in the output bitmap is less likely to break
existing apps, and is at least a useful situation: anybody who then
walks the output bitmaps to see what's going on will get EBADF when
actually trying to read/write from the file descriptor.
So it's actually _useful_ semantics, although obviously nobody can
rely on it (since we've never set those bits before, and presumably no
other unix does either).
The advantage of the EBADF return value is obviously that it's
ostensibly the portable thing to do, but considering that we've never
actually done that, I really do get the feeling that it's very likely
to break applications that do "select()" in one thread, and do
concurrent file management in another.
Regardless, I feel either change might cause subtle enough user
semantic breakage that I'd be inclined to leave this for 5.17, and
back-port it to stable after we've seen more testing, rather than
apply it this late in the development series.
Linus
