From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-23294-mason-zsh=primenet.com.au@sunsite.dk>
Received: (qmail 28449 invoked from network); 17 Apr 2007 14:42:26 -0000
X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on f.primenet.com.au
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO
	autolearn=ham version=3.1.8
Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88)
  by ns1.primenet.com.au with SMTP; 17 Apr 2007 14:42:26 -0000
Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts)
Received: (qmail 6959 invoked from network); 17 Apr 2007 14:42:20 -0000
Received: from sunsite.dk (130.225.247.90)
  by a.mx.sunsite.dk with SMTP; 17 Apr 2007 14:42:20 -0000
Received: (qmail 13056 invoked by alias); 17 Apr 2007 14:42:16 -0000
Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm
Precedence: bulk
X-No-Archive: yes
X-Seq: 23294
Received: (qmail 9854 invoked from network); 17 Apr 2007 14:15:32 -0000
Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88)
  by sunsite.dk with SMTP; 17 Apr 2007 14:15:32 -0000
Received: (qmail 76548 invoked from network); 17 Apr 2007 14:15:32 -0000
Received: from cs1.cs.huji.ac.il (132.65.16.10)
  by a.mx.sunsite.dk with SMTP; 17 Apr 2007 14:15:27 -0000
Received: from serin.cs.huji.ac.il ([132.65.80.149])
	by cs1.cs.huji.ac.il with esmtp
	id 1HdoSt-0009rs-0h; Tue, 17 Apr 2007 17:15:27 +0300
Received: from alsbergt by serin.cs.huji.ac.il with local (Exim 4.60 (FreeBSD))
	(envelope-from <alsbergt@cs.huji.ac.il>)
	id 1HdoSt-000Eer-0J; Tue, 17 Apr 2007 17:15:27 +0300
Date: Tue, 17 Apr 2007 17:15:26 +0300
From: Tom Alsberg <alsbergt@cs.huji.ac.il>
To: Micah Cowan <micah@cowan.name>
Cc: David Peer <davidpeer@cs.huji.ac.il>,
	Zsh Workers List <zsh-workers@sunsite.dk>
Subject: Re: Bug in ulimit ?
Message-ID: <20070417141526.GA56078@cs.huji.ac.il>
References: <462493C0.20700@cowan.name>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="KsGdsel6WgEHnImy"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <462493C0.20700@cowan.name>
X-Face: "5"j@Y1Peoz1;ftTv>\|['ox-csmV+:_RDNdi/2lSe2x?0:HVAeVW~ajwQ7RfDlcb^18eJ;t,O,s5-aNdU/DJ2E8h1s,..4}N9$27u`pWmH|;s!zlqqVwr9R^_ji=1\3}Z6gQBYyQ]{gd5-V8s^fYf{$V2*_&S>eA|SH@Y\hOVUjd[5eah{EO@gCr.ydSpJHJIU[QsH~bC?$C@O:SzF=CaUxp80-iknM(]q(W<UR
User-Agent: mutt-ng/devel-r804 (FreeBSD)


--KsGdsel6WgEHnImy
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

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.

--KsGdsel6WgEHnImy
Content-Type: message/rfc822
Content-Disposition: attachment; filename="lkml-cpulimit.mail"

>>From alsbergt@cs.huji.ac.il Tue Apr 17 16:57:55 2007
Date: Tue, 17 Apr 2007 16:57:55 +0300
From: Tom Alsberg <alsbergt@cs.huji.ac.il>
To: Linux-Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: CPU time limit patch / setrlimit(RLIMIT_CPU, 0) cheat fix
Message-ID: <20070417135755.GA55049@cs.huji.ac.il>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="XsQoSWH+UP9D9v3l"
Content-Disposition: inline
X-Face: "5"j@Y1Peoz1;ftTv>\|['ox-csmV+:_RDNdi/2lSe2x?0:HVAeVW~ajwQ7RfDlcb^18eJ;t,O,s5-aNdU/DJ2E8h1s,..4}N9$27u`pWmH|;s!zlqqVwr9R^_ji=1\3}Z6gQBYyQ]{gd5-V8s^fYf{$V2*_&S>eA|SH@Y\hOVUjd[5eah{EO@gCr.ydSpJHJIU[QsH~bC?$C@O:SzF=CaUxp80-iknM(]q(W<UR
User-Agent: mutt-ng/devel-r804 (FreeBSD)
Status: RO
Content-Length: 3530


--XsQoSWH+UP9D9v3l
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

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.

--XsQoSWH+UP9D9v3l
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment; filename="linux-2.6.20.3-cpulimit.diff"

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);

--XsQoSWH+UP9D9v3l--


--KsGdsel6WgEHnImy--