linux-kernel - pselect semantics - no EINTR with pending signals

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 9 Sep 2011 15:25:50 +0200
From:	Maciek Borzecki <maciek.borzecki@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: pselect semantics - no EINTR with pending signals

I'm running a deamon application, which listens on a number of
sockets, and occasionally spawns gzip to compress some data. It does
happen so, that pselect is used for mutliplexing IO. It also doest
happen so that on one of the fds there is always data to be read (just
a peculiarity of the application, a lot of clients are constantly
writing to a datagram socket and once the daemon is started there is
always data to be read).
That's more less how the code goes:
int main(..)
{
    sigset_t blockset;
    sigset_t oldset;
    ...
    signal(SIGCHLD, ...);
    sigemptyset(&blockset);
    sigaddset(&blockset, SIGCHLD);
    sigprocmask(SIG_SETMASK, &blockset, &oldset);
    ...

    while (1)
    {
        int ret = pselect(maxfd, fdset, NULL, NULL, NULL, &oldset);
        /* ret is always > 0 */

        {
            sigset_t pendset;
            sigpending(&pendset);
            /* apparenty SIGCHLD is present in pending set */
        }
    }
}

What happens is that once a child is spawned, and exists emitting a
SIGCHLD, the signal remains in the pending set. It can only be
determined that the signal was raised by looking at the pending mask.
It is also the case, that SIGCHLD is present in pending set before
entering pselect at some point. However none of the signal handlers
are called.
I looked 2.6.39 do_pselect and it seems that the signal handlers would
only be delivered once core_sys_select returns ERESTARTNOHAND, however
since there is always something to be read on the fds, core_sys_select
always returns value > 0. In that case set_restore_sigmask is never
called, and TIF_SIGPENDING is never set.
So it seems that there is no chance of having the signals delivered
unless pselect blocks waiting for I/O

Now, I'm not sure about the semantics of pselect. I'm not saying that
the current version is right or wrong, but raising a question if this
is really expected (and it did happen to be quite unexpected for me).

--
Maciek Borzecki
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/