From: Roland McGrath <roland@redhat.com>
To: Andrew Morton <akpm@osdl.org>, Linus Torvalds <torvalds@osdl.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Jeremy Fitzhardinge <jeremy@goop.org>,
Chris Wright <chrisw@osdl.org>
Subject: [PATCH] set RLIMIT_SIGPENDING limit based on RLIMIT_NPROC
Date: Wed, 23 Feb 2005 18:24:52 -0800 [thread overview]
Message-ID: <200502240224.j1O2OqHL010736@magilla.sf.frob.com> (raw)
In-Reply-To: Jeremy Fitzhardinge's message of Wednesday, 23 February 2005 15:09:51 -0800 <421D0D3F.40902@goop.org>
While looking into the issues Jeremy had with the RLIMIT_SIGPENDING limit,
it occurred to me that the normal setting of this limit is bizarrely low.
The initial hard limit setting (MAX_SIGPENDING) was taken from the old
max_queued_signals parameter, which was for the entire system in aggregate.
But even as a per-user limit, the 1024 value is incongruously low for this.
On my machine, RLIMIT_NPROC allows me 8192 processes, but only 1024 queued
signals, i.e. fewer even than one pending signal in each process. (To me,
this really puts in doubt the sensibility of using a per-user limit for
this rather than a per-process one, i.e. counted in sighand_struct or
signal_struct, which could have a much smaller reasonable value. I don't
recall the rationale for making this new limit per-user in the first place.)
This patch sets the default RLIMIT_SIGPENDING limit at boot time, using the
calculation that decides the default RLIMIT_NPROC limit. This uses the
same value for those two limits, which I think is still pretty conservative
on the RLIMIT_SIGPENDING value.
Thanks,
Roland
Signed-off-by: Roland McGrath <roland@redhat.com>
--- linux-2.6/include/asm-generic/resource.h
+++ linux-2.6/include/asm-generic/resource.h
@@ -51,7 +51,7 @@
[RLIMIT_MEMLOCK] = { MLOCK_LIMIT, MLOCK_LIMIT }, \
[RLIMIT_AS] = { RLIM_INFINITY, RLIM_INFINITY }, \
[RLIMIT_LOCKS] = { RLIM_INFINITY, RLIM_INFINITY }, \
- [RLIMIT_SIGPENDING] = { MAX_SIGPENDING, MAX_SIGPENDING }, \
+ [RLIMIT_SIGPENDING] = { 0, 0 }, \
[RLIMIT_MSGQUEUE] = { MQ_BYTES_MAX, MQ_BYTES_MAX }, \
}
--- linux-2.6/include/linux/signal.h
+++ linux-2.6/include/linux/signal.h
@@ -8,8 +8,6 @@
#ifdef __KERNEL__
-#define MAX_SIGPENDING 1024
-
/*
* Real Time signals may be queued.
*/
--- linux-2.6/kernel/fork.c
+++ linux-2.6/kernel/fork.c
@@ -129,6 +129,8 @@ void __init fork_init(unsigned long memp
init_task.signal->rlim[RLIMIT_NPROC].rlim_cur = max_threads/2;
init_task.signal->rlim[RLIMIT_NPROC].rlim_max = max_threads/2;
+ init_task.signal->rlim[RLIMIT_SIGPENDING] =
+ init_task.signal->rlim[RLIMIT_NPROC];
}
static struct task_struct *dup_task_struct(struct task_struct *orig)
next prev parent reply other threads:[~2005-02-24 2:25 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-23 6:42 [PATCH] Always send siginfo for synchronous signals Jeremy Fitzhardinge
2005-02-23 20:19 ` Chris Wright
2005-02-23 23:09 ` Jeremy Fitzhardinge
2005-02-23 23:46 ` Chris Wright
2005-02-24 0:50 ` Jeremy Fitzhardinge
2005-02-24 2:07 ` [PATCH] show RLIMIT_SIGPENDING usage in /proc/PID/status Roland McGrath
2005-02-24 2:33 ` Chris Wright
2005-02-24 2:55 ` Roland McGrath
2005-02-24 3:06 ` Chris Wright
2005-02-24 2:24 ` Roland McGrath [this message]
2005-02-24 3:07 ` [PATCH] set RLIMIT_SIGPENDING limit based on RLIMIT_NPROC Chris Wright
2005-02-25 2:05 ` Jeremy Fitzhardinge
2005-02-25 2:10 ` Chris Wright
2005-02-23 23:44 ` [PATCH] Always send siginfo for synchronous signals Jeremy Fitzhardinge
2005-02-24 1:45 ` [PATCH] override RLIMIT_SIGPENDING for non-RT signals Roland McGrath
2005-02-24 2:32 ` Chris Wright
2005-02-24 2:43 ` Roland McGrath
2005-02-24 3:12 ` Chris Wright
2005-02-25 2:01 ` Jeremy Fitzhardinge
2005-02-25 2:12 ` Chris Wright
2005-02-25 2:16 ` Roland McGrath
2005-02-25 3:02 ` Chris Wright
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=200502240224.j1O2OqHL010736@magilla.sf.frob.com \
--to=roland@redhat.com \
--cc=akpm@osdl.org \
--cc=chrisw@osdl.org \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.org \
/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