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

[Andrea Arcangeli <andrea@suse.de>]

On Wed, Oct 01, 2003 at 11:24:01AM +0200, Benjamin Herrenschmidt wrote:
> 
> > 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.

Yes I know. I was only talking about non-RT, I was concerned about
sigterm/sigkill primarly, that is the only realistic scenario. If you
send SIGRTMIN that is a pilot error, the system will never attempt to do
that, while it's not so obvious for sigterm. That's why I said at least
not more than 1 signal will be queued.

> 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 ?

It's up to you, I believe what we have to fix is the kupdate, the
SIGRTMIN can't matter. At most we can care about the sigterm, but even
the sigterm if it happens, it happens at shutdown time, so at the end it
doesn't matter much either for most systems (and that one isn't a leak,
only some minor memory lost).

So I guess you can fix only kupdate, and care to add the flush_signals
only in 2.6 that has the very same problem.

> 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.

thanks

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/