Messages in this thread | ![/](/images/icornerl.gif) | | From | Benjamin Herrenschmidt <> | Date | Tue, 30 Sep 2003 19:47:09 +0200 | Subject | Re: [BUG] 2.4.x RT signal leak with kupdated (and maybe others) |
| |
> 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/
| ![\](/images/icornerr.gif) |