From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15349 invoked from network); 18 Apr 2007 07:47:20 -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=AWL,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; 18 Apr 2007 07:47:20 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 27110 invoked from network); 18 Apr 2007 07:47:14 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 18 Apr 2007 07:47:14 -0000 Received: (qmail 27451 invoked by alias); 18 Apr 2007 07:47:10 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 23297 Received: (qmail 27442 invoked from network); 18 Apr 2007 07:47:09 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 18 Apr 2007 07:47:09 -0000 Received: (qmail 26779 invoked from network); 18 Apr 2007 07:47:09 -0000 Received: from cs1.cs.huji.ac.il (132.65.16.10) by a.mx.sunsite.dk with SMTP; 18 Apr 2007 07:47:06 -0000 Received: from serin.cs.huji.ac.il ([132.65.80.149]) by cs1.cs.huji.ac.il with esmtp id 1He4sS-0008MT-V9; Wed, 18 Apr 2007 10:46:57 +0300 Received: from alsbergt by serin.cs.huji.ac.il with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1He4sS-000NaN-Ul; Wed, 18 Apr 2007 10:46:56 +0300 Date: Wed, 18 Apr 2007 10:46:56 +0300 From: Tom Alsberg To: Stephane Chazelas Cc: Zsh Workers List Subject: (Off-Topic) Re: Bug in ulimit ? Message-ID: <20070418074656.GA90534@cs.huji.ac.il> References: <462493C0.20700@cowan.name> <20070417141526.GA56078@cs.huji.ac.il> <20070417151501.GH4955@sc.homeunix.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20070417151501.GH4955@sc.homeunix.net> 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 Hi Tom, > > I couldn't find the attachment, That is weird - I checked and did attach it, and it even appears in the zsh-workers archives at: http://www.zsh.org/mla/workers/2007/msg00215.html > but I could find your message to linux kernel mailing list on google > groups. > Your fix will solve the problem but change the value of the > current of the soft limit and make it different from what the > user requested. Indeed - as I mentioned in my message to LKML. This is not really due to my "fix", however. This code was there already since Linux 2.6.17, and was inserted as a "cheat" with the (apparently unsuccessful) intention of inhibiting users from overrunning the CPU time limit. I just moved it to where it will have the (presumably) intended effect. > I guess you'll find that this is breaking some standard. May be - I am not sure right now whether the standards specify any specific meaning to a RLIMIT_CPU of 0 and how strict the behaviour of setrlimit(...) is defined. On the other hand, considering it is not impossible or inconceivable that the limits of a process might at some point change externally without the process calling setrlimit(...) by itself (for example, if some interface is provided for users or administrators to change those limits from a central control; or in case of some flexible/dynamic economy-resource based multi-user systems - I know several groups of people working on such projects). In such a case, caching the limits for the ulimit command may be undesirable as the cache may be inconsistent of the actual limits. > I beleive this "cheat" is not necessary at all. I am not quite sure about this either. As I noted, what looks to be the obvious thing to do is simply fail with -EINVAL in such a case. However, it was not my idea to change it to 1 second - there might have been some reason of backward compatibility for whoever conceived this "cheat". > I don't have time to try it, but I think an easy fix would be to > change the sys_setrlimit() code to still keep the value of the > cpu-limit timer as 0 as before, but to schedule the processing of > CPU timers for the next tick instead of for the next second (which > was wrong as it would delay an itimer), Since the scheduling is done somewhere else in the code, that may require saving some other piece of information to differentiate between a zero value meaning "limit not set" and a zero value meaning "break immediately". Thinking of it now, I am not quite sure why a value of zero is necessary at all to denote the limit was never set (where is that information necessary?), and whether the initial value could not be set to infinity or the hard limit. But again, this logic was there already, and is beyond the scope of this small fix. > and at the time of the fork, make sure the it_prof_expirer in > copy_signal is not set to zero (for instance, schedule it for the > first tick, as in the code in copy_process). I have very little with the profiling code in Linux, so I am not sure whether this alone will do. > Cheers, > Stéphane Regards, -- 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.