public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Naohiro Ooiwa <nooiwa@miraclelinux.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com>,
	roland@redhat.com, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Thomas Gleixner <tglx@linutronix.de>,
	LKML <linux-kernel@vger.kernel.org>,
	oleg@redhat.com, akpm@linux-foundation.org
Subject: [PATCH] show message when exceeded rlimit of pending signals
Date: Fri, 30 Oct 2009 20:36:31 +0900	[thread overview]
Message-ID: <4AEACFBF.4060108@miraclelinux.com> (raw)

Hi Ingo,

I wrote proper changelog entry.
And I resent the patch. I added KERN_INFO to printk.



When the system has too many timers or too many aggregate
queued signals, the EAGAIN error is returned to application
from kernel, including timer_create().
It means that exceeded limit of pending signals at all.
But we can't imagine it.

This patch show the message when reached limit of pending signals.
If you see this message and your system behaved unexpectedly,
you can run following command.
   # ulimit -i unlimited

With help from Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com>.

Signed-off-by: Naohiro Ooiwa <nooiwa@miraclelinux.com>
Acked-by: Ingo Molnar <mingo@elte.hu>
---
 Documentation/kernel-parameters.txt |   11 +++++++++--
 kernel/signal.c                     |   20 ++++++++++++++++----
 2 files changed, 25 insertions(+), 6 deletions(-)

diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 9107b38..3bbd92f 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
-			print-fatal-signals=1: print segfault info to
-			the kernel console.
+
+			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.

 	printk.time=	Show timing data prefixed to each printk message line
diff --git a/kernel/signal.c b/kernel/signal.c
index 6705320..50e10dc 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -41,6 +41,8 @@

 static struct kmem_cache *sigqueue_cachep;

+int print_fatal_signals __read_mostly;
+
 static void __user *sig_handler(struct task_struct *t, int sig)
 {
 	return t->sighand->action[sig - 1].sa.sa_handler;
@@ -188,6 +190,14 @@ int next_signal(struct sigpending *pending, sigset_t *mask)
 	return sig;
 }

+static void show_reach_rlimit_sigpending(void)
+{
+	if (!printk_ratelimit())
+		return;
+	printk(KERN_INFO "%s/%d: reached the limit of pending signals.\n",
+				current->comm, current->pid);
+}
+
 /*
  * allocate a new signal queue record
  * - this may be called without locks if and only if t == current, otherwise an
@@ -209,8 +219,12 @@ static struct sigqueue *__sigqueue_alloc(struct task_struct *t, gfp_t flags,
 	atomic_inc(&user->sigpending);
 	if (override_rlimit ||
 	    atomic_read(&user->sigpending) <=
-			t->signal->rlim[RLIMIT_SIGPENDING].rlim_cur)
+			t->signal->rlim[RLIMIT_SIGPENDING].rlim_cur) {
 		q = kmem_cache_alloc(sigqueue_cachep, flags);
+	} else {
+		if (print_fatal_signals)
+			show_reach_rlimit_sigpending();
+	}
 	if (unlikely(q == NULL)) {
 		atomic_dec(&user->sigpending);
 		free_uid(user);
@@ -925,11 +939,9 @@ static int send_signal(int sig, struct siginfo *info, struct task_struct *t,
 	return __send_signal(sig, info, t, group, from_ancestor_ns);
 }

-int print_fatal_signals;
-
 static void print_fatal_signal(struct pt_regs *regs, int signr)
 {
-	printk("%s/%d: potentially unexpected fatal signal %d.\n",
+	printk(KERN_INFO "%s/%d: potentially unexpected fatal signal %d.\n",
 		current->comm, task_pid_nr(current), signr);

 #if defined(__i386__) && !defined(__arch_um__)

             reply	other threads:[~2009-10-30 11:36 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-30 11:36 Naohiro Ooiwa [this message]
2009-10-30 21:33 ` [PATCH] show message when exceeded rlimit of pending signals Andrew Morton
2009-10-30 21:45   ` Joe Perches
2009-10-30 23:21     ` [PATCH] kernel.h: Add printk_ratelimited and pr_<level>_rl Joe Perches
2009-11-02 15:58       ` Ingo Molnar
2009-11-05 14:16         ` Naohiro Ooiwa
2009-11-05 14:44           ` Naohiro Ooiwa
2009-11-09 21:49       ` Andrew Morton
2009-11-09 22:05         ` Joe Perches
2009-11-09 22:28           ` Randy Dunlap
2009-11-10  5:18           ` Ingo Molnar
2009-11-10  5:17         ` Ingo Molnar
2009-11-10  7:34           ` Peter Zijlstra
2009-11-10  7:39             ` Ingo Molnar
2009-11-10  7:54               ` Joe Perches
2009-11-10  8:21               ` Peter Zijlstra
2009-10-31  7:58   ` [PATCH] show message when exceeded rlimit of pending signals Naohiro Ooiwa
2009-10-31  8:50     ` Naohiro Ooiwa
2009-10-31  8:57       ` Andrew Morton
2009-10-31 11:05         ` Naohiro Ooiwa
  -- strict thread matches above, loose matches on Subject: below --
2009-10-23 10:07 Naohiro Ooiwa
2009-10-23 11:46 ` Ingo Molnar
2009-10-24  7:02   ` Naohiro Ooiwa
2009-10-24  8:56     ` Naohiro Ooiwa
2009-10-24  8:58       ` Ingo Molnar
2009-10-26 10:17         ` nooiwa
2009-10-26 11:38           ` Ingo Molnar
2009-10-26 16:37             ` Roland McGrath
2009-10-26 16:39             ` Naohiro Ooiwa
2009-10-26 20:28               ` Ingo Molnar
2009-10-27  2:58                 ` Naohiro Ooiwa
2009-10-27  4:36                   ` Hiroshi Shimamoto
2009-10-27  8:27                     ` nooiwa
2009-10-23 21:07 ` Roland McGrath
2009-10-24  8:27   ` Naohiro Ooiwa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4AEACFBF.4060108@miraclelinux.com \
    --to=nooiwa@miraclelinux.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=h-shimamoto@ct.jp.nec.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=oleg@redhat.com \
    --cc=roland@redhat.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox