Messages in this thread | | | Date | Tue, 30 Sep 2003 20:22:55 +0200 | From | Andrea Arcangeli <> | Subject | Re: [BUG] 2.4.x RT signal leak with kupdated (and maybe others) |
| |
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/ - 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/
| |