DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0E7FD3858C56
To: "'cygwin AT cygwin DOT com'" <cygwin AT cygwin DOT com>
Subject: poll() is buggy for duplicate file descriptors inquired for different
 events
Thread-Topic: poll() is buggy for duplicate file descriptors inquired for
 different events
Thread-Index: AdiJfM3OzZaW3H5sS+uh4gnASgxp6g==
Date: Sun, 26 Jun 2022 17:04:58 +0000
Message-ID: <DM8PR09MB7095D0733CD9A00FC0847434A5B69@DM8PR09MB7095.namprd09.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?wxHfrz2ebR69HvpkaDXzGTjgd93xPcp4wAbQIFax+mFIlH3BD7LzoIMKL1IG?=
 =?us-ascii?Q?v6LP1zTe8XAiYwxKH/EstwfGF1naEXJkUA221ZYL6OiUvDXri2OqB0wVEEt3?=
 =?us-ascii?Q?W36Fqg9bbUt4VZw2/bjDAlcdHo3YOUqhJBpLvlEFk4Hjtrtxs/yKxJvlGYSw?=
 =?us-ascii?Q?QW6DgfVB7AsoM8qsuyYu5AonEH9eTnB9CmUVkaGBHhqUWvbJ0pGlV+bgWO4E?=
 =?us-ascii?Q?2vXjRQccWxj709mjY0VnuDPleOZCIOFNa/ZBIEI38q3Ex10vGrhGMyI/GnlT?=
 =?us-ascii?Q?z9SFZ0/Olxj7H67hCdfUnahlA7bDhfrQIGfwv8fkzXwp/HllPgzDpdnC/e7x?=
 =?us-ascii?Q?yfwszvRpMCX2hYLlVlbkxvGIXTzE2Vdo+G8rDDAU9Tfm7/+L3/uvSo+uaNp+?=
 =?us-ascii?Q?nlsbbFPDx5ZguBJcK5+09dxiw4Uqz0h4ltwePoQQQHjmlVFL6giW9XNTNW1R?=
 =?us-ascii?Q?SDN1fU/njMtl8XW5hp3tW5B02LRWC5Eu7RGR32xZ5h1G+ET7FTdGZomyHdUJ?=
 =?us-ascii?Q?aNFWMhBOycMk3xCrEfRha6w+VEZPfvwPeib1AyxcGHQFHA90AvqG4RK8LRUa?=
 =?us-ascii?Q?4JuDY3c34HJqvSmZu/JXcqcu6ZJ+yJhCd1QIIpm6v+WyU82LdNOddYbwI3eV?=
 =?us-ascii?Q?e4by/qE332HcUTCSgjIzdP0xpNwSTLf77JvGYgSBcOsebvmteQUwDpY3uZyM?=
 =?us-ascii?Q?oO9iWchzfMNrOpmlHB2V8RzxGiPVeqjFHf8STE/MNpJrw4rLjZnATFORuold?=
 =?us-ascii?Q?Z8pdo4zD+qadNH31Uk7rB56GSyOxBxZhlcvb9QMeLXOfr/cEgJEG05wsyp9Z?=
 =?us-ascii?Q?5I8WMRJurY/JTOOmLEYmcjMWy7c3sg6IB+VlLdOazk2KtroI//VoADjSE27W?=
 =?us-ascii?Q?Z1f7XdPDhhPdpaohTd9V2uq8R+LXPoRZzur1o0ZqtACnpOpa+/UYyWnsjmEo?=
 =?us-ascii?Q?p1zqB4Rpo2jV7y2iQ8JwnBY0BFzVBqhE8uXFiOWenbh7mhclnAGdhCvRpjrd?=
 =?us-ascii?Q?IR8YNpNXKvgHjp7XGMgvUo+8a/6QsuiNko4lFPHVSvUMF2WBeox5hf0I/BdA?=
 =?us-ascii?Q?rZRlGZNlabiiw6f+P2xLL5LQLru+Xzop9aBOTabCHI6iQs/UEbU/VTcRJatx?=
 =?us-ascii?Q?r3joNH4ziT3fPPV2lLb4D+8mdN1Q9J42diSCIx0lP32BD0Ffcaq3OxgSR0HT?=
 =?us-ascii?Q?UJ/V4IwL3WzKLYvE6R9bf1DxW2D6ukv9ZJA9G9KsFt5c/+gi5CnaB/Coub4X?=
 =?us-ascii?Q?Y1YZ9Lya5uYUUROqzwiewF7JfpX7t67gwnZD8RfUgFvhD0B09NMJ2JBGpJjH?=
 =?us-ascii?Q?QtDnf/ALoQCADcTpotE4ZOgq5jK7ipgxZUI6AtIHUcMDZGz+tZkmdoVqlQIX?=
 =?us-ascii?Q?c26qxeBuhgpuuKt+tZGg/Ww5l/V7X2Y4zm0kOLx4+mQcUN2g6rav4DES3t+P?=
 =?us-ascii?Q?IU/dvPWxR0MfFN3D9Ia1A8i5sRxDUnfRLoahkFWXcCxLHpuYreLKsWXqLFGM?=
 =?us-ascii?Q?tRQCB6NYunwUNN3pzsVb4MDcpHQaJDpFK0b4xIqIJaBrBjhlr/dE8+EomW6a?=
 =?us-ascii?Q?YyEz4Yp+gkJY44tukKU=3D?=
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM8PR09MB7095.namprd09.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f4012f5d-a9c5-4123-10f6-08da57960029
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jun 2022 17:04:58.5123 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 14b77578-9773-42d5-8507-251ca2dc2b06
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR09MB4822
X-OriginatorOrg: ncbi.nlm.nih.gov
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00, DKIM_SIGNED,
 DKIM_VALID, DKIM_VALID_EF, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE,
 T_SPF_HELO_PERMERROR autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
 server2.sourceware.org
X-BeenThere: cygwin AT cygwin DOT com
X-Mailman-Version: 2.1.29
List-Id: General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Archive: <https://cygwin.com/pipermail/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe: <https://cygwin.com/mailman/listinfo/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From: "Lavrentiev, Anton \(NIH/NLM/NCBI\) \[C\] via Cygwin" <cygwin AT cygwin DOT com>
Reply-To: "Lavrentiev, Anton \(NIH/NLM/NCBI\) \[C\]" <lavr AT ncbi DOT nlm DOT nih DOT gov>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: "Cygwin" <cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com>

Hi,

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.

Anton Lavrentiev
Contractor NIH/NLM/NCBI


-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple