[lkml]   [2001]   [Jun]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Patch in this message
Subject[PATCH] fix RLIMIT_NPROC accounting

due to something which I consider to be a kernel bug it's
impossible for pam to do its job and set the per-user
RLIMIT_NPROC (number of processes limit) to something which
is lower than the amount of processes root is running at that

At least, it fails with all programs which set RLIMIT_NPROC
and fork()+exec() afterwards.

The attached patch should bring us back to the behaviour we
had in 2.2. Comments?


Executive summary of a recent Microsoft press release:
"we are concerned about the GNU General Public License (GPL)"

--- kernel/fork.c.orig Fri Jun 22 20:27:27 2001
+++ kernel/fork.c Fri Jun 22 20:52:41 2001
@@ -576,7 +576,14 @@
*p = *current;

retval = -EAGAIN;
- if (atomic_read(&p->user->processes) >= p->rlim[RLIMIT_NPROC].rlim_cur)
+ /*
+ * Check if we are over our maximum process limit, but be sure to
+ * exclude root. This is needed to make it possible for login and
+ * friends to set the per-user process limit to something lower
+ * than the amount of processes root is running. -- Rik
+ */
+ if (atomic_read(&p->user->processes) >= p->rlim[RLIMIT_NPROC].rlim_cur
+ && !capable(CAP_SYS_ADMIN) && !capable(CAP_SYS_RESOURCE))
goto bad_fork_free;
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:55    [W:0.037 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site