On Mon, Aug 11, 2025 at 01:01:01AM +0530, Ujwal Kundur wrote: > > It took me about 60 seconds to prove the POLLERR change was wrong, and > > i know nothing about this code base. So it is in fact not a lot of > > effort. > I looked up the definition of POLLERR on Elixir [1] and it seemed like > a valid Sparse report to me. I wasn't aware of EPOLLERR, and now > realize all the other operations are prefixed with EPOLL* in af_rds.c. > I look forward to reviews/critiques to learn from them but being > accused of using LLMs is kinda disheartening. As for the POLLERR part of that, the thing about POLL* constants is that beyond the first 6 (IN/PRI/OUT/ERR/HUP/NVAL) they are arch-dependent, and not just in a sense of bit assignments. generic: IN PRI OUT ERR HUP NVAL RDNORM RDBAND WRNORM WRBAND MSG REMOVE RDHUP 0 1 2 3 4 5 6 7 8 9 10 11 12 sparc: 0 1 2 3 4 5 6 7 =OUT 8 9 10 11 mips,m68k: 0 1 2 3 4 5 6 7 =OUT 8 10 11 12 xtensa: 0 1 2 3 4 5 6 7 =OUT 8 10 13 12 So these get mapped from/to by poll(2) (mangle_poll() and demangle_poll() resp.) and __poll_t serves as a tool for catching the places that might be confused. The internal values (also used by eventpoll(2)) are 0 1 2 3 4 5 6 7 8 9 10 --- 12 POLLREMOVE is Solaris-only thing and we do not even attempt to implement it. So's POLLMSG, but there's a bit of a twist - nobody ever returns that shit from ->poll(), but SIGIO from dnotify and from lease breaking comes with ->si_band in siginfo set to POLLIN|POLLRDNORM|POLLMSG; Warning about __poll_t is usually "mixing POLL... and EPOLL... is a bad idea". Here it's not a bug (note that ERR gets the same bit in all of the above), but it's trivial to annotate properly...
