On Sun, Aug 10, 2025 at 10:00:58PM +0100, Al Viro wrote: > 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 13 > xtensa: > 0 1 2 3 4 5 6 7 =OUT 8 10 11 12 Ugh... My apologies - messed table above in the last two columns. REMOVE is 10 for sparc, 11 for xtensa and 12 for everybody else. RDHUP is 11 for sparc and 13 for everybody else. 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 12 13 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 12 13 xtensa: 0 1 2 3 4 5 6 7 =OUT 8 10 11 13
