"Eric W. Biederman" <ebiederm@xxxxxxxxxxxx> wrote: > Frankly the only reason this appears to be worth touching is that we > have a userspace regression. Otherwise I would call the current > behavior more correct and desirable than ignoring the signal longer. > > If I am reading sitaution properly I suggest we go back to resoring the > sigmask by hand in epoll_pwait, and put in a big fat comment about a > silly userspace program depending on that behavior. > > That will be easier to backport and it will just fix the regression and > not overfix the problem for reasonable applications. Fwiw, the cmogstored (userspace program which regressed) only hit this regression in an obscure code path for tuning; that code path probably sees no use outside of the test suite. Add to that, cmogstored is an unofficial and optional component to the obscure, largely-forgotten MogileFS. Finally, the main users of cmogstored are on FreeBSD. They hit the kqueue+self-pipe code path instead of epoll_pwait. I only used epoll_pwait on Linux since I figured I could save a few bytes of memory by skipping eventfd/self-pipe... Anyways, I updated cmogstored a few weeks back to call `note_run' (the signal dispatcher) if epoll_pwait (wrapped by `mog_idleq_wait_intr') returns 0 instead of -1 (EINTR) to workaround this kernel change: https://bogomips.org/cmogstored-public/20190511075630.17811-1-e@xxxxxxxxx/ I could easily make a change to call `note_run' unconditionally when `mog_idleq_wait_intr' returns, too. But that said, there could be other users hitting the same problem I did. So maybe cmogstored's primary use on Linux these days is finding regressions :>
