Skip to content

Commit 89f974a

Browse files
committed
lib: Correctly handle ppoll pfds.events == 0
The frrevent system is spitting out this message in bgpd: 20:40:15 mem1-roc-f2-b1-r5-t2-d4 bgpd[13166]: [XETTR-D5MR0][EC 100663316] Attempting to process an I/O event but for fd: 214(8) no thread to handle this! This is because as each io event is processed, it is possible that a .events is set to 0. This can leave a situation where we ask ppoll to handle anything that happens on a fd with a .events of 0, in this situation ppoll can return POLLERR, which indicates that something bad has happened on the fd. Let's cleanup the pfds after io events are handled that can be cleaned up. Signed-off-by: Donald Sharp <[email protected]>
1 parent c10e4d3 commit 89f974a

File tree

1 file changed

+29
-0
lines changed

1 file changed

+29
-0
lines changed

lib/event.c

+29
Original file line numberDiff line numberDiff line change
@@ -1690,6 +1690,35 @@ static void thread_process_io(struct event_loop *m, unsigned int num)
16901690
for (i = 0; i < last_read && ready < num; ++i)
16911691
thread_process_io_inner_loop(m, num, pfds, &i, &ready);
16921692

1693+
/*
1694+
* At this point any fd's that were processed
1695+
* have possibly had their .events == 0
1696+
* so we should remove them now from the list
1697+
* in it's entirety. This is being done
1698+
* because if we leave a fd in the poll even
1699+
* with a .events of 0, if the fd is closed
1700+
* poll will return a .revents of POLLERR
1701+
* This is not desirable, as that we are attempting
1702+
* to handle something we have absolutely no
1703+
* way to handle it at all.
1704+
*/
1705+
i = 0;
1706+
while (i < m->handler.pfdcount) {
1707+
if (m->handler.pfds[i].events != 0) {
1708+
i++;
1709+
} else {
1710+
memmove(m->handler.pfds + i, m->handler.pfds + i + 1,
1711+
(m->handler.pfdcount - i - 1) * sizeof(struct pollfd));
1712+
m->handler.pfdcount--;
1713+
m->handler.pfds[m->handler.pfdcount].fd = 0;
1714+
m->handler.pfds[m->handler.pfdcount].events = 0;
1715+
/*
1716+
* Intentionally keeping i the same
1717+
* We need to look at it again
1718+
*/
1719+
}
1720+
}
1721+
16931722
m->last_read++;
16941723
}
16951724

0 commit comments

Comments
 (0)