Re: [OT] Bug in ulimit ?

[Stephane Chazelas <Stephane_Chazelas@xxxxxxxx>]

On Tue, Apr 17, 2007 at 02:34:16PM +0100, 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....

Not that rubbish though,

the comment about it_prof_expires is valid I think. But what
that means is that the processing of the process CPU timers is
not scheduled.

In:


perl -W -MTime::HiRes -MBSD::Resource -le '
  setrlimit(RLIMIT_CPU,0,RLIM_INFINITY);
  if (fork) {wait} else {
   Time::HiRes::setitimer(2, 0.5); while (1) { ; }}'

The child process gets the SIGXCPU (not a SIGPROF) after half a
second because the check_process_timers has been scheduled
because of the itimer.

So I beleive the statement about

> But we use the zero value to mean "it was never set"

is not accurate. the soft limit is initialised to infinity
 so there should be no reason AFAICT to treat 0 specially, so
 that this "1 second" cheating shouldn't be necessary (and I'd
 bet if there's a itimer due to fire sooner than 1 second from
 now, the SIGXCPU will be delivered earlier).

So scheduling a check_process_timer for the next tick in
sys_setitimer and for the first tick if rlim_cur is 0 in
copy_signal should do it, I beleive.

> 
> > 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?
> 

-- 
Stéphane