Re: [BUG] 2.4.x RT signal leak with kupdated (and maybe others)

From: Benjamin Herrenschmidt (benh_at_kernel.crashing.org)
Date: 09/30/03

  • Next message: Andreas Schwarz: "Re: ERR in /proc/interrupts" 
    To: Andrea Arcangeli <andrea@suse.de>
Date:	Tue, 30 Sep 2003 19:47:09 +0200

    > When I wrote the kupdate code, only the real time signals could be
    > queued. Now things have changed to carry the siginfo for non-RT too. The
    > fact we clear the pending by hand is what allows more than a RT signal
    > to be stacked, we shouldn't clear the bitflag unless we dequeue the
    > signal too. That's definitely a bug (though a minor one ;)

    "Minor" but leads to interesting results in the end when coupled
    with something like noflushd that regulary send those signals ;)

    Not only we leak them, but we also get nr_queued_signals reaching
    nr_max_signals. This has the side effect of making do_notify_parent()
    silently fail when a pthread is dead (libpthread use an RT signal).

    The end result is that after a few days, a machine running noflushd
    and thread intensive apps like evolution and gkrellm will have dozens
    (or even hundreds) of zombies as the child threads are never reclaimed
    by libpthread "manager" thread since it never gets the signal...

    > I sure agree it should be fixed with a dequeue_signal in kupdate.

    I'll cook something tomorrow (I'm away from any 2.4 machine tonight).

    > BTW, things like this in daemonize don't protect against allocating
    > signals (the kernel deamon should flush_signals once in a while in the
    > main loop to do that):
    >
    > /* Block and flush all signals */
    > sigfillset(&blocked);
    > sigprocmask(SIG_BLOCK, &blocked, NULL);
    > flush_signals(current);
    >
    > But it's not a big problem you shouldn't send signals to daemons
    > anyways, only kupdate gives a semantic to signals.

    Interesting... though hopefully, I didn't see anybody else causing
    such a constant increase of nr_queued_signals so far on this laptop...

    Ben.

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

  • Next message: Andreas Schwarz: "Re: ERR in /proc/interrupts"

    Relevant Pages