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

[Nigel Cunningham <ncunningham@clear.net.nz>]

Hi.

For what it's worth, Software Suspend sends signals to daemons, but it
uses flush_signals() to ensure they don't have any other effect than
getting the process stopped during the cycle.

Nigel

On Wed, 2003-10-01 at 21:24, 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.
> 
> 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-- 
Nigel Cunningham
495 St Georges Road South, Hastings 4201, New Zealand

You see, at just the right time, when we were still powerless,
Christ died for the ungodly.
	-- Romans 5:6, NIV.