Re: Bug in ulimit ?

[Tom Alsberg <alsbergt@cs.huji.ac.il>]

[-- Attachment #1: Type: text/plain, Size: 1946 bytes --]

I checked the problem earlier today (by reference of David who pointed
it out to me - thanks, David).  The problem is apparently in the Linux
kernel, where the check for trying to set RLIMIT_CPU = 0 is done a bit
too late, and has nothing to do with zsh.  Specifically, the same
symptoms were visible with other shells (ash, bash) too.

I checked the Linux kernel sources and found the solution in
kernel/sys.c.  Attached is a copy of my message with the patch to the
Linux-Kernel Mailing List.

One issue that may be relevant within zsh, though, is that it appears
that zsh caches the limits set, and since that check in Linux "cheats"
by setting the value to 1 when 0 is requested, entering "ulimit -a"
does not call getrlimit(...) at all and does show 0 after issuing the
command "ulimit -t 0", although getrlimit(RLIMIT_CPU, ...) would
return 1.  The correct limit is seen in a subshell where this is not
yet cached.

I expect my patch to be in the next Linux 2.6.21 release candidate.

  Cheers,
  -- Tom

On Tue, Apr 17, 2007 at 02:30:40AM -0700, Micah Cowan wrote:
> David Peer wrote:
> > If the user run: ulimit -t 0, he can run jobs without any cputime
> > limitation:
> 
> This sounds more like a kernel problem to me than a zsh bug. I get the
> same behavior on my Ubuntu 7.04 (beta) system, in _bash_.
> 
> I note that getrlimit(2) says:
> 
>  In 2.6.x kernels before 2.6.17, a RLIMIT_CPU  limit  of  0  is  wrongly
>  treated  as "no limit" (like RLIM_INFINITY).  Since kernel 2.6.17, set‐
>  ting a limit of 0 does have an effect, but is  actually  treated  as  a
>  limit of 1 second.
> 
> However, I'm running 2.6.20(-14-generic), and still experiencing that
> symptom.

-- 
  Tom Alsberg - hacker (being the best description fitting this space)
  Web page:	http://www.cs.huji.ac.il/~alsbergt/
DISCLAIMER:  The above message does not even necessarily represent what
my fingers have typed on the keyboard, save anything further.

[-- Attachment #2: lkml-cpulimit.mail --]
[-- Type: message/rfc822, Size: 4265 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 2092 bytes --]

Hi there.

As discovered here today, the change in Kernel 2.6.17 intended to
inhibit users from setting RLIMIT_CPU to 0 (as that is equivalent to
unlimited) by "cheating" and setting it to 1 in such a case, does not
make a difference, as the check is done in the wrong place (too late),
and only applies to the profiling code.

On all systems I checked running kernels above 2.6.17, no matter what
the hard and soft CPU time limits were before, a user could escape
them by issuing in the shell (sh/bash/zsh) "ulimit -t 0", and then the
user's process was not ever killed.

Attached is a trivial patch to fix that.  Simply moving the check to a
slightly earlier location (specifically, before the line that actually
assigns the limit - *old_rlim = new_rlim), does the trick.

Do note that at least the zsh (but not ash, dash, or bash) shell has
the problem of "caching" the limits set by the ulimit command, so when
running zsh the fix will not immediately be evident - after entering
"ulimit -t 0", "ulimit -a" will show "-t: cpu time (seconds) 0", even
though the actual limit as returned by getrlimit(...) will be 1.  It
can be verified by opening a subshell (which will not have the values
of the parent shell in cache) and checking in it, or just by running a
CPU intensive command like "echo '65536^1048576' | bc" and verifying
that it dumps core after one second.

Regardless of whether that is a misfeature in the shell, perhaps it
would be better to return -EINVAL from setrlimit in such a case
instead of cheating and setting to 1, as that does not really reflect
the actual state of the process anymore.  I do not however know what
the ground for that decision was in the original 2.6.17 change, and
whether there would be any "backward" compatibility issues, so I
preferred not to touch that right now.

  Cheers,
  -- Tom

-- 
  Tom Alsberg - hacker (being the best description fitting this space)
  Web page:	http://www.cs.huji.ac.il/~alsbergt/
DISCLAIMER:  The above message does not even necessarily represent what
my fingers have typed on the keyboard, save anything further.

[-- Attachment #2.1.2: linux-2.6.20.3-cpulimit.diff --]
[-- Type: text/x-diff, Size: 1186 bytes --]

Follows a trivial patch to check for RLIMIT_CPU to 0 in the right place.

diff -urN linux-2.6.20.3.orig/kernel/sys.c linux-2.6.20.3/kernel/sys.c
--- linux-2.6.20.3.orig/kernel/sys.c	2007-03-13 20:27:08.000000000 +0200
+++ linux-2.6.20.3/kernel/sys.c	2007-04-17 16:38:51.651236000 +0300
@@ -1916,6 +1916,16 @@
 	if (retval)
 		return retval;
 
+	if (resource == RLIMIT_CPU && new_rlim.rlim_cur == 0) {
+		/*
+		 * The caller is asking for an immediate RLIMIT_CPU
+		 * expiry.  But we use the zero value to mean "it was
+		 * never set".  So let's cheat and make it one second
+		 * instead
+		 */
+		new_rlim.rlim_cur = 1;
+	}
+
 	task_lock(current->group_leader);
 	*old_rlim = new_rlim;
 	task_unlock(current->group_leader);
@@ -1937,15 +1947,6 @@
 		unsigned long rlim_cur = new_rlim.rlim_cur;
 		cputime_t cputime;
 
-		if (rlim_cur == 0) {
-			/*
-			 * The caller is asking for an immediate RLIMIT_CPU
-			 * expiry.  But we use the zero value to mean "it was
-			 * never set".  So let's cheat and make it one second
-			 * instead
-			 */
-			rlim_cur = 1;
-		}
 		cputime = secs_to_cputime(rlim_cur);
 		read_lock(&tasklist_lock);
 		spin_lock_irq(&current->sighand->siglock);