Re: [BUG] 2.4.x RT signal leak with kupdated (and maybe others)
From: Benjamin Herrenschmidt
Date: Wed Oct 01 2003 - 04:24:57 EST
> 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.
And any daemon can cause the same leak by sending it RT signals... I just
verified sending for example a bunch of 33's (SIGRTMIN) to khubd, that
increased the count permanently.
I agree this should not happen normally, and I suppose only root can do
that and we aren't here to prevent root from shooting itself in the
foot, are we ?
The question is should I spend some time adding some flush_signals() to
the loop of those various kernel daemons I can find or that isn't worth ?
Regarding kupated, dequeue_signal is a better option as we actually care
about the signal, I'm testing a patch it will be there in a few minutes.
Ben.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/