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

[Andrea Arcangeli <andrea@suse.de>]

On Tue, Sep 30, 2003 at 07:47:09PM +0200, Benjamin Herrenschmidt wrote:
> > 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...

for noflushd users it's major (for everybody else is minor)

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

That's because nobody else sends signals to the daemons I guess. And
even if they do the daemon won't clear the pending bitflag, so there's
no risk to queue more than 1 non-RT entry per signal per daemon like it
happened with kupdate.

Andrea - If you prefer relying on open source software, check these links:
	    rsync.kernel.org::pub/scm/linux/kernel/bkcvs/linux-2.[45]/
	    http://www.cobite.com/cvsps/