Re: [PATCH v3 10/11] rlimits: implement prlimit64 syscall

[Jiri Slaby <jirislaby@gmail.com>]

On 05/14/2010 12:56 AM, Andrew Morton wrote:
> On Mon, 10 May 2010 20:00:50 +0200
> Jiri Slaby <jslaby@suse.cz> wrote:
> 
>> This patch adds the code to support the sys_prlimit64 syscall which
>> modifies-and-returns the rlim values of a selected process
>> atomically. The first parameter, pid, being 0 means current process.
>>
>> Unlike the current implementation, it is a generic interface,
>> architecture indepentent so that we needn't handle compat stuff
>> anymore. In the future, after glibc start to use this we can deprecate
>> sys_setrlimit and sys_getrlimit in favor to clean up the code finally.
>>
>> It also adds a possibility of changing limits of other processes. We
>> check the user's permissions to do that and if it succeeds, the new
>> limits are propagated online. This is good for large scale
>> applications such as SAP or databases where administrators need to
>> change limits time by time (e.g. on crashes increase core size). And
>> it is unacceptable to restart the service.
>>
>> For safety, all rlim users now either use accessors or doesn't need
>> them due to
>> - locking
>> - the fact a process was just forked and nobody else knows about it
>>   yet (and nobody can't thus read/write limits)
>> hence it is safe to modify limits now.
>>
>> The limitation is that we currently stay at ulong internal
>> representation. So we use the rlim64_is_infinity check where we
>> compare to ULONG_MAX on 32-bit which is the maximum value there.
>>
>> And since internally we hold limits in struct rlimit, we introduce
>> converters used before and after do_prlimit call in sys_prlimit64.
>>
> 
> Is this worth all the new code and the increase in locking dependencies
> which I think is there?

Sorry, for the late reply, I was busy with other things.

Both
tasklist_lock -> (task_struct->sighand->siglock)
tasklist_lock -> (task_struct->alloc_lock)
are OK, since both dependencies already exist in the kernel.

This should have been in the changelogs, yes!

> This could all be done in userspace, couldn't it?  Write a little library
> which clones a thread then waits for someone to send it a
> change-your-rlimits message.  Write a little tool to send those
> messages and voila.

Sorry, I'm not sure I understand this. Could you shed some light on what
will run in the new thread?

A code such as:
main()
{
  if (!clone())
    exec("something");

  while (wait_for_message(&m)) {
     setrlimit(m);
     sleep();
  }
}
won't obviously work. Could you change it so it reflects your idea or
explain what I'm missing?

thanks,
-- 
js