"Eric W. Biederman" ebiederm@xmission.com 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@80x24.org/
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 :>