Hey Jann, On Tue, Apr 19, 2022 at 6:38 PM Jann Horn <jannh@xxxxxxxxxx> wrote: > This is a bit of a weird API, because normally .poll is supposed to be > level-triggered rather than edge-triggered... and AFAIK things like > epoll also kinda assume that ->poll() doesn't modify state (but that > only _really_ matters in weird cases). But at the same time, it looks > like the existing proc_sys_poll() already goes against that? So I > don't know what the right thing to do there is... Doesn't the level vs edge distinction apply to POLLIN/POLLOUT events? In this case, the event generated is actually POLLERR. On one hand, this is sort of weird. On the other hand, it perhaps makes sense, since nothing changes respect to its readability/writeability. And it also happens to be how the sysctl poll() infrastructure was designed; I didn't need to change anything for this behavior, and it comes as a result of this rather trivial commit only. Looking at where else it's used, it appears to be the intended use case for changes to hostname/domainname. So while it's unusual, it also appears to be the usual way that sysctl poll() works. So perhaps we're quite lucky here in that sysctl poll() winds up being the correct interface for what we want? Jason
