Re: [PATCH] show message when exceeded rlimit of pending signals

[Ingo Molnar <mingo@elte.hu>]

* Naohiro Ooiwa <nooiwa@miraclelinux.com> wrote:

> Hi Ingo,
> 
> Now that you mention it, I think so, too.
> I update my patch.
> 
> How is the following patch.
> Could you please review it.
> 
> Thanks you.
> Naohiro Ooiwa
> 
> 
> 
> Signed-off-by: Naohiro Ooiwa <nooiwa@miraclelinux.com>
> ---
>  Documentation/kernel-parameters.txt |    9 ++++++++-
>  kernel/signal.c                     |   16 +++++++++++++---
>  2 files changed, 21 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/kernel-parameters.txt
> b/Documentation/kernel-parameters.txt
> index 9107b38..01c2723 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -2032,8 +2032,15 @@ and is between 256 and 4096 characters. It is
> defined in the file
> 
>  	print-fatal-signals=
>  			[KNL] debug: print fatal signals
> +			If you would like to know what the cause of a coredump
> +			by signal number, if your working system may have
> +			too many POSIX.1 timers, and when during the system
> +			test,you may as well to enable this parameter.
>  			print-fatal-signals=1: print segfault info to
> -			the kernel console.
> +			the kernel console, and print caution that reached the
> +			limit of pending signals to the kernel console.
> +			When printed the caution messages, you can try
> +			"ulimit -i unlimited".
>  			default: off.
> 

Here's a slightly improved version of the text:

 	print-fatal-signals=
 			[KNL] debug: print fatal signals

			If enabled, warn about various signal handling 
			related application anomalies: too many signals, 
			too many POSIX.1 timers, fatal signals causing a 
			coredump - etc.

			If you hit the warning due to signal overflow, 
			you might want to try "ulimit -i unlimited".

			default: off.

> +int print_fatal_signals;

i'd suggest __read_mostly.

Plus please move variables to the top of the file. (i know this comes 
from the previous code but we can improve it while we are touching it)

With these things addressed it looks good to me:

Acked-by: Ingo Molnar <mingo@elte.hu>

	Ingo