poll() is buggy for duplicate file descriptors inquired for different events

[Takashi Yano]

On Sun, 26 Jun 2022 17:04:58 +0000
"Lavrentiev, Anton \(NIH/NLM/NCBI\) \[C\] wrote:
> It looks like if a file descriptor is inquired a few times in a poll() call with different events (and for one of those events the file descriptor is "ready"),
> only that occurrence gets reported correctly, and all other occurrences get the returned event just "copied over" (and thus, it may be incompatible with the
> query for that occurrence).
> 
> The following simple test case demonstrates this:
> 
> $ cat poll.c 
> #include <poll.h>
> #include <stdio.h>
> #include <string.h>
> 
> int main()
> {
>     int n;
>     struct pollfd pfd[2];
>     memset(pfd, 0, sizeof(pfd));
> 
>     pfd[0].fd = 1;
>     pfd[0].events = POLLOUT;
>     pfd[1].fd = 1;
>     pfd[1].events = POLLIN;
>     
>     n = poll(pfd, 2, 1000);
>     printf("n = %d\n"
>     "[0].fd = %d\n"
>     "[0].event = %d\n"
>     "[0].revent = %d\n"
>     "[1].fd = %d\n"
>     "[1].event = %d\n"
>     "[1].revent = %d\n",
>     n,
>     pfd[0].fd,
>     pfd[0].events,
>     pfd[0].revents,
>     pfd[1].fd,
>     pfd[1].events,
>     pfd[1].revents);
> 
>     pfd[1].revents = 0;
>     n = poll(&pfd[1], 1, 1000);
>     printf("n = %d\n"
>     "[1].fd = %d\n"
>     "[1].event = %d\n"
>     "[1].revent = %d\n",
>     n,
>     pfd[1].fd,
>     pfd[1].events,
>     pfd[1].revents);
> 
>     return 0;
> }
> 
> $ gcc -Wall -o poll poll.c
> 
> $ ./poll
> n = 2
> [0].fd = 1
> [0].event = 4
> [0].revent = 4
> [1].fd = 1
> [1].event = 1
> [1].revent = 4
> n = 0
> [1].fd = 1
> [1].event = 1
> [1].revent = 0
> 
> Note that "stdout" is inquired about ready-to-write (in [0]) and ready-to-read (in [1]).
> Because it is ready-to-write, poll() returns immediately, but also having the response
> ready-to-write in [1], where only "read"-compatible status (POLLIN, or POLLHUP, or POLLERR,
> or just 0, if nothing of sorts was available) should have been posted -- but *never* POLLOUT!
> 
> Also note that [1] should have never been flagged as "ready", either, so the return code should have been 1, not 2.
> 
> Finally note that if [0] and [1] were swapped so that [0] was inquired for POLLIN, and [1] was inquired for POLLOUT,
> the result would have still been incorrect on Cygwin ([0] returning POLLOUT for POLLIN inquired).
> 
> For the second invocation, when inquired just singly, the response is correct.
> 
> Now compare it with the correct behavior of the same code, all through, on Linux:
> 
> $ ./poll
> n = 1
> [0].fd = 1
> [0].event = 4
> [0].revent = 4
> [1].fd = 1
> [1].event = 1
> [1].revent = 0
> n = 0
> [1].fd = 1
> [1].event = 1
> [1].revent = 0
> 
> P.S. The manual page for poll(2) says:
> 
> The bits returned in revents can include any of those specified in events, or one of the values POLLERR, POLLHUP, or POLLNVAL.
> 
> So returning POLLOUT(4) for POLLIN(1) violates the rule: bit 0 is NOT set in the binary representation of 4.

Thanks for the report.

I will submit a patch to cygwin-patches@cygwin.com for this issue.

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>