Re: Bug in ulimit ?

[David Peer <davidpeer@cs.huji.ac.il>]

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