From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28488 invoked from network); 17 Apr 2007 13:58:01 -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 13:58:01 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 49021 invoked from network); 17 Apr 2007 13:57:56 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 17 Apr 2007 13:57:56 -0000 Received: (qmail 4344 invoked by alias); 17 Apr 2007 13:57:51 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 23293 Received: (qmail 4332 invoked from network); 17 Apr 2007 13:57:49 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 17 Apr 2007 13:57:49 -0000 Received: (qmail 48614 invoked from network); 17 Apr 2007 13:57:49 -0000 Received: from cs1.cs.huji.ac.il (132.65.16.10) by a.mx.sunsite.dk with SMTP; 17 Apr 2007 13:57:46 -0000 Received: from wrath.cs.huji.ac.il ([132.65.80.62]) by cs1.cs.huji.ac.il with esmtp id 1HdoBl-0008r1-OD for zsh-workers@sunsite.dk; Tue, 17 Apr 2007 16:57:45 +0300 Message-ID: <4624D259.1070300@cs.huji.ac.il> Date: Tue, 17 Apr 2007 16:57:45 +0300 From: David Peer Reply-To: davidpeer@cs.huji.ac.il Organization: Hebrew University - Computer User-Agent: Icedove 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: zsh-workers@sunsite.dk Subject: Re: Bug in ulimit ? References: <46248CC2.4010901@cs.huji.ac.il> <462493C0.20700@cowan.name> <20070417094244.GA4955@sc.homeunix.net> <46249BC7.8070200@cowan.name> <20070417104303.GB4955@sc.homeunix.net> <4624A79F.1020107@cowan.name> <20070417125355.GC4955@sc.homeunix.net> <20070417130316.GD4955@sc.homeunix.net> <20070417132446.GE4955@sc.homeunix.net> <20070417133416.GF4955@sc.homeunix.net> <4624D1AA.4030902@cs.huji.ac.il> In-Reply-To: <4624D1AA.4030902@cs.huji.ac.il> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit I forgot: The file that needs to be changed, of-course is: kernel/sys.c It was check on kernel 2.6.20.3 David David Peer wrote: > I hope kernel people will add it to the next kernel release, > > but here is one rapid fix that solves the problem. > > (you will not see the new limit of 1 sec but you'll still see it set > to 0, but its 1 sec - believe me && try, > > if you want to see it, fork another any shell and you'll see it....bug > or feature?!) > > > Before the line: *old_rlim = new_rlim; > > > add: > > > 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; > } > > > You can remove the dumb if statement that does nothing cause the > assignment occurs(*old_rlim = new_rlim) before > > so it has no meaning! : if (rlim_cur == 0) {....} > > > David > > > > Stephane Chazelas wrote: > >> On Tue, Apr 17, 2007 at 02:24:46PM +0100, Stephane Chazelas wrote: >> >>> On Tue, Apr 17, 2007 at 02:03:16PM +0100, Stephane Chazelas wrote: >>> [...] >>> >>>> So it would seem that the limit is inherited but not applied in >>>> the child (and I couldn't see any signal being blocked or >>>> ignored). So that's probably not a libc issue, rather a Linux >>>> issue. >>>> >>> [...] >>> >> >> Please ignore this email, I was talking rubbish again, I should >> probably get back to sleep.... >> >> >>> The Linux code for setrlimit gives a hint: >>> >>> if (it_prof_secs == 0 || new_rlim.rlim_cur <= it_prof_secs) { >>> 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; >>> } >>> >>> It's stored as being "0" and armed with a 1 second delay. And on a >>> fork, >>> obviously, for the new process, there's no way to distinguish >>> between a 0 that means "not set" and a 0 that means exit >>> immediately. >>> >>> And one can verify that it_prof_expires will be set to 0 in >>> copy_signal during the fork and that 0 means not armed in >>> check_process_timers. >>> >>> But what's the point of setting a cputime of 0 anyway? >>> >> >> > > -- David Peer davidpeer@cs.huji.ac.il CS System Group | Phone: 02 - 6586942 School of Computer Science and Engineering Hebrew University of Jerusalem - Israel Edmund Safra Campus - Givat Ram