Re: pselect/etc semantics
From: Eric Wong
Date: Thu May 30 2019 - 17:06:59 EST
"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 :>