(Off-Topic) Re: Bug in ulimit ?

[Tom Alsberg <alsbergt@xxxxxxxxxxxxx>]

(Repost top zsh-workers in case it may be of interest, original
 address was misspelled)

On Tue, Apr 17, 2007 at 04:15:01PM +0100, Stephane Chazelas wrote:
> 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.