[PULL] pull request for writable limits for 2.6.33-rc1

[PULL] pull request for writable limits for 2.6.33-rc1

[Jiri Slaby]

Hi Linus,

please pull from writable limits git. It contains naming fixes suggested
by Ingo, so that we have task_rlimit() and similar helpers for rlimits now.

--
The following changes since commit 6ec22f9b037fc0c2e00ddb7023fad279c365324d:
  Linus Torvalds (1):
        Merge branch 'x86-debug-for-linus' of
git://git.kernel.org/.../tip/linux-2.6-tip

are available in the git repository at:

  git://decibel.fi.muni.cz/~xslaby/linux writable_limits

Jiri Slaby (25):
      SECURITY: selinux, fix update_rlimit_cpu parameter
      SECURITY: add task_struct to setrlimit
      core: add task_struct to update_rlimit_cpu
      core: split sys_setrlimit
      core: allow setrlimit to non-current tasks
      core: optimize setrlimit for current task
      FS: proc, switch limits reading to fops
      FS: proc, make limits writable
      core: do security check under task_lock
      core: rename setrlimit to do_setrlimit
      resource: move kernel functions inside __KERNEL__
      core: posix-cpu-timers, cleanup rlimits usage
      resource: add helpers for fetching rlimits
      IA64: use helpers for rlimits
      PPC: use helpers for rlimits
      S390: use helpers for rlimits
      SPARC: use helpers for rlimits
      X86: use helpers for rlimits
      FS: use helpers for rlimits
      MM: use helpers for rlimits
      core: use helpers for rlimits
      misc: use helpers for rlimits
      core: implement getprlimit and setprlimit syscalls
      COMPAT: add get/put_compat_rlimit
      x86: add ia32 compat prlimit syscalls

Neil Horman (1):
      unistd: add __NR_[get|set]prlimit syscall numbers

Oleg Nesterov (1):
      sys_setrlimit: make sure ->rlim_max never grows

 arch/ia64/kernel/perfmon.c                     |    2 +-
 arch/ia64/kernel/sys_ia64.c                    |    2 +-
 arch/ia64/mm/init.c                            |    2 +-
 arch/powerpc/mm/mmap_64.c                      |    4 +-
 arch/powerpc/platforms/cell/spufs/coredump.c   |    2 +-
 arch/s390/mm/mmap.c                            |    4 +-
 arch/sparc/kernel/sys_sparc_64.c               |    6 +-
 arch/x86/ia32/ia32_aout.c                      |    2 +-
 arch/x86/ia32/ia32entry.S                      |    2 +
 arch/x86/include/asm/unistd_32.h               |    4 +-
 arch/x86/include/asm/unistd_64.h               |    4 +
 arch/x86/kernel/syscall_table_32.S             |    2 +
 arch/x86/mm/mmap.c                             |    4 +-
 drivers/infiniband/core/umem.c                 |    2 +-
 drivers/infiniband/hw/ipath/ipath_user_pages.c |    3 +-
 fs/attr.c                                      |    2 +-
 fs/binfmt_aout.c                               |    2 +-
 fs/binfmt_flat.c                               |    2 +-
 fs/exec.c                                      |    8 +-
 fs/fcntl.c                                     |    2 +-
 fs/file.c                                      |    2 +-
 fs/proc/array.c                                |    4 +-
 fs/proc/base.c                                 |  101 ++++++++++++++--
 fs/select.c                                    |    2 +-
 include/asm-generic/unistd.h                   |    6 +-
 include/linux/Kbuild                           |    2 +-
 include/linux/posix-timers.h                   |    2 +-
 include/linux/resource.h                       |   10 ++-
 include/linux/sched.h                          |   22 ++++
 include/linux/security.h                       |    9 +-
 include/linux/syscalls.h                       |    4 +
 ipc/mqueue.c                                   |    2 +-
 ipc/shm.c                                      |    3 +-
 kernel/compat.c                                |   91 +++++++++++---
 kernel/fork.c                                  |   10 +-
 kernel/perf_event.c                            |    2 +-
 kernel/posix-cpu-timers.c                      |   52 ++++----
 kernel/sched.c                                 |    4 +-
 kernel/sched_rt.c                              |    5 +-
 kernel/signal.c                                |    2 +-
 kernel/sys.c                                   |  161
+++++++++++++++++++----
 mm/filemap.c                                   |    2 +-
 mm/mlock.c                                     |   12 +-
 mm/mmap.c                                      |   13 +-
 mm/mremap.c                                    |    2 +-
 security/capability.c                          |    3 +-
 security/security.c                            |    5 +-
 security/selinux/hooks.c                       |   10 +-
 48 files changed, 451 insertions(+), 153 deletions(-)

thanks,
-- 
js

[PULL] pull request for writable limits for 2.6.33-rc0

[Jiri Slaby]

Hi,

I messed up the subject last time.

Now I rebased the tree to resolve conflicts, please pull.

---
The following changes since commit 2588465badb648a50cd19623f0dd0063c90d4e31:
  Linus Torvalds (1):
        Merge branch 'bkl-arch-for-linus' of
git://git.kernel.org/.../tip/linux-2.6-tip

are available in the git repository at:

  git://decibel.fi.muni.cz/~xslaby/linux writable_limits

Jiri Slaby (25):
      SECURITY: selinux, fix update_rlimit_cpu parameter
      SECURITY: add task_struct to setrlimit
      core: add task_struct to update_rlimit_cpu
      core: split sys_setrlimit
      core: allow setrlimit to non-current tasks
      core: optimize setrlimit for current task
      FS: proc, switch limits reading to fops
      FS: proc, make limits writable
      core: do security check under task_lock
      core: rename setrlimit to do_setrlimit
      resource: move kernel functions inside __KERNEL__
      core: posix-cpu-timers, cleanup rlimits usage
      resource: add helpers for fetching rlimits
      IA64: use helpers for rlimits
      PPC: use helpers for rlimits
      S390: use helpers for rlimits
      SPARC: use helpers for rlimits
      X86: use helpers for rlimits
      FS: use helpers for rlimits
      MM: use helpers for rlimits
      core: use helpers for rlimits
      misc: use helpers for rlimits
      core: implement getprlimit and setprlimit syscalls
      COMPAT: add get/put_compat_rlimit
      x86: add ia32 compat prlimit syscalls

Neil Horman (1):
      unistd: add __NR_[get|set]prlimit syscall numbers

Oleg Nesterov (1):
      sys_setrlimit: make sure ->rlim_max never grows

 arch/ia64/kernel/perfmon.c                     |    2 +-
 arch/ia64/kernel/sys_ia64.c                    |    2 +-
 arch/ia64/mm/init.c                            |    2 +-
 arch/powerpc/mm/mmap_64.c                      |    4 +-
 arch/powerpc/platforms/cell/spufs/coredump.c   |    2 +-
 arch/s390/mm/mmap.c                            |    4 +-
 arch/sparc/kernel/sys_sparc_64.c               |    6 +-
 arch/x86/ia32/ia32_aout.c                      |    2 +-
 arch/x86/ia32/ia32entry.S                      |    2 +
 arch/x86/include/asm/unistd_32.h               |    4 +-
 arch/x86/include/asm/unistd_64.h               |    4 +
 arch/x86/kernel/syscall_table_32.S             |    2 +
 arch/x86/mm/mmap.c                             |    4 +-
 drivers/infiniband/core/umem.c                 |    2 +-
 drivers/infiniband/hw/ipath/ipath_user_pages.c |    3 +-
 fs/attr.c                                      |    2 +-
 fs/binfmt_aout.c                               |    2 +-
 fs/binfmt_flat.c                               |    2 +-
 fs/exec.c                                      |    8 +-
 fs/fcntl.c                                     |    2 +-
 fs/file.c                                      |    2 +-
 fs/proc/array.c                                |    4 +-
 fs/proc/base.c                                 |  101 ++++++++++++++--
 fs/select.c                                    |    2 +-
 include/asm-generic/unistd.h                   |    6 +-
 include/linux/Kbuild                           |    2 +-
 include/linux/posix-timers.h                   |    2 +-
 include/linux/resource.h                       |   10 ++-
 include/linux/sched.h                          |   22 ++++
 include/linux/security.h                       |    9 +-
 include/linux/syscalls.h                       |    4 +
 ipc/mqueue.c                                   |    2 +-
 ipc/shm.c                                      |    3 +-
 kernel/compat.c                                |   91 +++++++++++---
 kernel/fork.c                                  |   10 +-
 kernel/perf_event.c                            |    2 +-
 kernel/posix-cpu-timers.c                      |   52 ++++----
 kernel/sched.c                                 |    4 +-
 kernel/sched_rt.c                              |    5 +-
 kernel/signal.c                                |    2 +-
 kernel/sys.c                                   |  161
+++++++++++++++++++----
 mm/filemap.c                                   |    2 +-
 mm/mlock.c                                     |   12 +-
 mm/mmap.c                                      |   13 +-
 mm/mremap.c                                    |    2 +-
 security/capability.c                          |    3 +-
 security/security.c                            |    5 +-
 security/selinux/hooks.c                       |   10 +-
 48 files changed, 451 insertions(+), 153 deletions(-)

[git pull -resend] pull request for writable limits for 2.6.33-rc0

[Jiri Slaby]

Hi,

is there something wrong with the patchset? Did the email make it into
your inbox at all?

On 12/09/2009 08:25 PM, Jiri Slaby wrote:
> Hi,
> 
> I messed up the subject last time.
> 
> Now I rebased the tree to resolve conflicts, please pull.
> 
> ---
> The following changes since commit 2588465badb648a50cd19623f0dd0063c90d4e31:
>   Linus Torvalds (1):
>         Merge branch 'bkl-arch-for-linus' of
> git://git.kernel.org/.../tip/linux-2.6-tip
> 
> are available in the git repository at:
> 
>   git://decibel.fi.muni.cz/~xslaby/linux writable_limits
> 
> Jiri Slaby (25):
>       SECURITY: selinux, fix update_rlimit_cpu parameter
>       SECURITY: add task_struct to setrlimit
>       core: add task_struct to update_rlimit_cpu
>       core: split sys_setrlimit
>       core: allow setrlimit to non-current tasks
>       core: optimize setrlimit for current task
>       FS: proc, switch limits reading to fops
>       FS: proc, make limits writable
>       core: do security check under task_lock
>       core: rename setrlimit to do_setrlimit
>       resource: move kernel functions inside __KERNEL__
>       core: posix-cpu-timers, cleanup rlimits usage
>       resource: add helpers for fetching rlimits
>       IA64: use helpers for rlimits
>       PPC: use helpers for rlimits
>       S390: use helpers for rlimits
>       SPARC: use helpers for rlimits
>       X86: use helpers for rlimits
>       FS: use helpers for rlimits
>       MM: use helpers for rlimits
>       core: use helpers for rlimits
>       misc: use helpers for rlimits
>       core: implement getprlimit and setprlimit syscalls
>       COMPAT: add get/put_compat_rlimit
>       x86: add ia32 compat prlimit syscalls
> 
> Neil Horman (1):
>       unistd: add __NR_[get|set]prlimit syscall numbers
> 
> Oleg Nesterov (1):
>       sys_setrlimit: make sure ->rlim_max never grows
> 
>  arch/ia64/kernel/perfmon.c                     |    2 +-
>  arch/ia64/kernel/sys_ia64.c                    |    2 +-
>  arch/ia64/mm/init.c                            |    2 +-
>  arch/powerpc/mm/mmap_64.c                      |    4 +-
>  arch/powerpc/platforms/cell/spufs/coredump.c   |    2 +-
>  arch/s390/mm/mmap.c                            |    4 +-
>  arch/sparc/kernel/sys_sparc_64.c               |    6 +-
>  arch/x86/ia32/ia32_aout.c                      |    2 +-
>  arch/x86/ia32/ia32entry.S                      |    2 +
>  arch/x86/include/asm/unistd_32.h               |    4 +-
>  arch/x86/include/asm/unistd_64.h               |    4 +
>  arch/x86/kernel/syscall_table_32.S             |    2 +
>  arch/x86/mm/mmap.c                             |    4 +-
>  drivers/infiniband/core/umem.c                 |    2 +-
>  drivers/infiniband/hw/ipath/ipath_user_pages.c |    3 +-
>  fs/attr.c                                      |    2 +-
>  fs/binfmt_aout.c                               |    2 +-
>  fs/binfmt_flat.c                               |    2 +-
>  fs/exec.c                                      |    8 +-
>  fs/fcntl.c                                     |    2 +-
>  fs/file.c                                      |    2 +-
>  fs/proc/array.c                                |    4 +-
>  fs/proc/base.c                                 |  101 ++++++++++++++--
>  fs/select.c                                    |    2 +-
>  include/asm-generic/unistd.h                   |    6 +-
>  include/linux/Kbuild                           |    2 +-
>  include/linux/posix-timers.h                   |    2 +-
>  include/linux/resource.h                       |   10 ++-
>  include/linux/sched.h                          |   22 ++++
>  include/linux/security.h                       |    9 +-
>  include/linux/syscalls.h                       |    4 +
>  ipc/mqueue.c                                   |    2 +-
>  ipc/shm.c                                      |    3 +-
>  kernel/compat.c                                |   91 +++++++++++---
>  kernel/fork.c                                  |   10 +-
>  kernel/perf_event.c                            |    2 +-
>  kernel/posix-cpu-timers.c                      |   52 ++++----
>  kernel/sched.c                                 |    4 +-
>  kernel/sched_rt.c                              |    5 +-
>  kernel/signal.c                                |    2 +-
>  kernel/sys.c                                   |  161
> +++++++++++++++++++----
>  mm/filemap.c                                   |    2 +-
>  mm/mlock.c                                     |   12 +-
>  mm/mmap.c                                      |   13 +-
>  mm/mremap.c                                    |    2 +-
>  security/capability.c                          |    3 +-
>  security/security.c                            |    5 +-
>  security/selinux/hooks.c                       |   10 +-
>  48 files changed, 451 insertions(+), 153 deletions(-)


-- 
js
suse labs

Re: [git pull -resend] pull request for writable limits for 2.6.33-rc0

[Jiri Slaby]

On 12/11/2009 12:05 PM, Jiri Slaby wrote:
> Hi,
> 
> is there something wrong with the patchset? Did the email make it into
> your inbox at all?

May I ask again, why this wasn't pulled, so that I can fix it?

> On 12/09/2009 08:25 PM, Jiri Slaby wrote:
>> Hi,
>>
>> I messed up the subject last time.
>>
>> Now I rebased the tree to resolve conflicts, please pull.
>>
>> ---
>> The following changes since commit 2588465badb648a50cd19623f0dd0063c90d4e31:
>>   Linus Torvalds (1):
>>         Merge branch 'bkl-arch-for-linus' of
>> git://git.kernel.org/.../tip/linux-2.6-tip
>>
>> are available in the git repository at:
>>
>>   git://decibel.fi.muni.cz/~xslaby/linux writable_limits
>>
>> Jiri Slaby (25):
>>       SECURITY: selinux, fix update_rlimit_cpu parameter
>>       SECURITY: add task_struct to setrlimit
>>       core: add task_struct to update_rlimit_cpu
>>       core: split sys_setrlimit
>>       core: allow setrlimit to non-current tasks
>>       core: optimize setrlimit for current task
>>       FS: proc, switch limits reading to fops
>>       FS: proc, make limits writable
>>       core: do security check under task_lock
>>       core: rename setrlimit to do_setrlimit
>>       resource: move kernel functions inside __KERNEL__
>>       core: posix-cpu-timers, cleanup rlimits usage
>>       resource: add helpers for fetching rlimits
>>       IA64: use helpers for rlimits
>>       PPC: use helpers for rlimits
>>       S390: use helpers for rlimits
>>       SPARC: use helpers for rlimits
>>       X86: use helpers for rlimits
>>       FS: use helpers for rlimits
>>       MM: use helpers for rlimits
>>       core: use helpers for rlimits
>>       misc: use helpers for rlimits
>>       core: implement getprlimit and setprlimit syscalls
>>       COMPAT: add get/put_compat_rlimit
>>       x86: add ia32 compat prlimit syscalls
>>
>> Neil Horman (1):
>>       unistd: add __NR_[get|set]prlimit syscall numbers
>>
>> Oleg Nesterov (1):
>>       sys_setrlimit: make sure ->rlim_max never grows
>>
>>  arch/ia64/kernel/perfmon.c                     |    2 +-
>>  arch/ia64/kernel/sys_ia64.c                    |    2 +-
>>  arch/ia64/mm/init.c                            |    2 +-
>>  arch/powerpc/mm/mmap_64.c                      |    4 +-
>>  arch/powerpc/platforms/cell/spufs/coredump.c   |    2 +-
>>  arch/s390/mm/mmap.c                            |    4 +-
>>  arch/sparc/kernel/sys_sparc_64.c               |    6 +-
>>  arch/x86/ia32/ia32_aout.c                      |    2 +-
>>  arch/x86/ia32/ia32entry.S                      |    2 +
>>  arch/x86/include/asm/unistd_32.h               |    4 +-
>>  arch/x86/include/asm/unistd_64.h               |    4 +
>>  arch/x86/kernel/syscall_table_32.S             |    2 +
>>  arch/x86/mm/mmap.c                             |    4 +-
>>  drivers/infiniband/core/umem.c                 |    2 +-
>>  drivers/infiniband/hw/ipath/ipath_user_pages.c |    3 +-
>>  fs/attr.c                                      |    2 +-
>>  fs/binfmt_aout.c                               |    2 +-
>>  fs/binfmt_flat.c                               |    2 +-
>>  fs/exec.c                                      |    8 +-
>>  fs/fcntl.c                                     |    2 +-
>>  fs/file.c                                      |    2 +-
>>  fs/proc/array.c                                |    4 +-
>>  fs/proc/base.c                                 |  101 ++++++++++++++--
>>  fs/select.c                                    |    2 +-
>>  include/asm-generic/unistd.h                   |    6 +-
>>  include/linux/Kbuild                           |    2 +-
>>  include/linux/posix-timers.h                   |    2 +-
>>  include/linux/resource.h                       |   10 ++-
>>  include/linux/sched.h                          |   22 ++++
>>  include/linux/security.h                       |    9 +-
>>  include/linux/syscalls.h                       |    4 +
>>  ipc/mqueue.c                                   |    2 +-
>>  ipc/shm.c                                      |    3 +-
>>  kernel/compat.c                                |   91 +++++++++++---
>>  kernel/fork.c                                  |   10 +-
>>  kernel/perf_event.c                            |    2 +-
>>  kernel/posix-cpu-timers.c                      |   52 ++++----
>>  kernel/sched.c                                 |    4 +-
>>  kernel/sched_rt.c                              |    5 +-
>>  kernel/signal.c                                |    2 +-
>>  kernel/sys.c                                   |  161
>> +++++++++++++++++++----
>>  mm/filemap.c                                   |    2 +-
>>  mm/mlock.c                                     |   12 +-
>>  mm/mmap.c                                      |   13 +-
>>  mm/mremap.c                                    |    2 +-
>>  security/capability.c                          |    3 +-
>>  security/security.c                            |    5 +-
>>  security/selinux/hooks.c                       |   10 +-
>>  48 files changed, 451 insertions(+), 153 deletions(-)

thanks,
-- 
js

Re: [PULL] pull request for writable limits for 2.6.33-rc0

[Jiri Kosina]

On Wed, 9 Dec 2009, Jiri Slaby wrote:

> ---
> The following changes since commit 2588465badb648a50cd19623f0dd0063c90d4e31:
>   Linus Torvalds (1):
>         Merge branch 'bkl-arch-for-linus' of
> git://git.kernel.org/.../tip/linux-2.6-tip
> 
> are available in the git repository at:
> 
>   git://decibel.fi.muni.cz/~xslaby/linux writable_limits
> 
> Jiri Slaby (25):
>       SECURITY: selinux, fix update_rlimit_cpu parameter
>       SECURITY: add task_struct to setrlimit
>       core: add task_struct to update_rlimit_cpu
>       core: split sys_setrlimit
>       core: allow setrlimit to non-current tasks
>       core: optimize setrlimit for current task
>       FS: proc, switch limits reading to fops
>       FS: proc, make limits writable
>       core: do security check under task_lock
>       core: rename setrlimit to do_setrlimit
>       resource: move kernel functions inside __KERNEL__
>       core: posix-cpu-timers, cleanup rlimits usage
>       resource: add helpers for fetching rlimits
>       IA64: use helpers for rlimits
>       PPC: use helpers for rlimits
>       S390: use helpers for rlimits
>       SPARC: use helpers for rlimits
>       X86: use helpers for rlimits
>       FS: use helpers for rlimits
>       MM: use helpers for rlimits
>       core: use helpers for rlimits
>       misc: use helpers for rlimits
>       core: implement getprlimit and setprlimit syscalls
>       COMPAT: add get/put_compat_rlimit
>       x86: add ia32 compat prlimit syscalls
> 
> Neil Horman (1):
>       unistd: add __NR_[get|set]prlimit syscall numbers
> 
> Oleg Nesterov (1):
>       sys_setrlimit: make sure ->rlim_max never grows

Hmm, so this seems to have missed thw 2.6.33 merge window, being dropped 
in a silent way.

Linus, is there any reason you have not pulled this for .33 (I can't see 
any objections from previous reviews), or was this just forgotten?

Thanks,

-- 
Jiri Kosina
SUSE Labs, Novell Inc.

Re: [PULL] pull request for writable limits for 2.6.33-rc0

[Ingo Molnar]

* Jiri Kosina <jkosina@suse.cz> wrote:

> Hmm, so this seems to have missed thw 2.6.33 merge window, being dropped in 
> a silent way.
> 
> Linus, is there any reason you have not pulled this for .33 (I can't see any 
> objections from previous reviews), or was this just forgotten?

I think a "why do we want this badly" blurb would be helpful for next time 
around, to justify the impact to the core kernel:

  48 files changed, 451 insertions(+), 153 deletions(-)

And, maybe, if you know about pros/cons of the approach, list them as well. 
The patches looked reasonably clean when i last saw them, and i havent seen 
anyone comment pro or contra - and that's both good and bad: good because 
there's no 'contra' opinion - bad because there's no 'pro' opinion either.

	Ingo

Re: [PULL] pull request for writable limits for 2.6.33-rc0

[Jiri Kosina]

On Sat, 2 Jan 2010, Ingo Molnar wrote:

> > Hmm, so this seems to have missed thw 2.6.33 merge window, being dropped in 
> > a silent way.
> > 
> > Linus, is there any reason you have not pulled this for .33 (I can't see any 
> > objections from previous reviews), or was this just forgotten?
> 
> I think a "why do we want this badly" blurb would be helpful for next time 
> around, to justify the impact to the core kernel:
> 
>   48 files changed, 451 insertions(+), 153 deletions(-)
> 
> And, maybe, if you know about pros/cons of the approach, list them as well. 
> The patches looked reasonably clean when i last saw them, and i havent seen 
> anyone comment pro or contra - and that's both good and bad: good because 
> there's no 'contra' opinion - bad because there's no 'pro' opinion either.

Well, I am myself aware of users asking for this functionality, and 
thinking about it, it "just makes sense" to have the possibility to 
change the limits on the fly.

... but you are right that such justification should probably be clearly 
expressed in the pull request itself.

-- 
Jiri Kosina
SUSE Labs, Novell Inc.

[PULL] pull request for limits FIXES for 2.6.33-rc

[Jiri Slaby]

On 12/09/2009 08:25 PM, Jiri Slaby wrote:
> The following changes since commit 2588465badb648a50cd19623f0dd0063c90d4e31:
>   Linus Torvalds (1):
>         Merge branch 'bkl-arch-for-linus' of
> git://git.kernel.org/.../tip/linux-2.6-tip
> 
> are available in the git repository at:
> 
>   git://decibel.fi.muni.cz/~xslaby/linux writable_limits

So this seems not to not be in 2.6.33 at all, could you pull at least fixes?

The following changes since commit 45d28b097280a78893ce25a5d0db41e6a2717853:
  Linus Torvalds (1):
        Merge branch 'reiserfs/kill-bkl' of
git://git.kernel.org/.../frederic/random-tracing

are available in the git repository at:

  git://decibel.fi.muni.cz/~xslaby/linux limits_fixes

Jiri Slaby (2):
      SECURITY: selinux, fix update_rlimit_cpu parameter
      resource: move kernel function inside __KERNEL__

 include/linux/resource.h |    8 ++++++--
 security/selinux/hooks.c |    2 +-
 2 files changed, 7 insertions(+), 3 deletions(-)




Or better even with rlimit helpers added so that people may start using
those:

The following changes since commit 45d28b097280a78893ce25a5d0db41e6a2717853:
  Linus Torvalds (1):
        Merge branch 'reiserfs/kill-bkl' of
git://git.kernel.org/.../frederic/random-tracing

are available in the git repository at:

  git://decibel.fi.muni.cz/~xslaby/linux limits_cleanup

Jiri Slaby (3):
      SECURITY: selinux, fix update_rlimit_cpu parameter
      resource: move kernel function inside __KERNEL__
      resource: add helpers for fetching rlimits

 include/linux/resource.h |    8 ++++++--
 include/linux/sched.h    |   22 ++++++++++++++++++++++
 security/selinux/hooks.c |    2 +-
 3 files changed, 29 insertions(+), 3 deletions(-)




I'll reply to this message with the 3 patches.

thanks,
-- 
js

[PATCH 1/3] SECURITY: selinux, fix update_rlimit_cpu parameter

[Jiri Slaby]

From: Jiri Slaby <jirislaby@gmail.com>

Don't pass current RLIMIT_RTTIME to update_rlimit_cpu() in
selinux_bprm_committing_creds, since update_rlimit_cpu expects
RLIMIT_CPU limit.

Use proper rlim[RLIMIT_CPU].rlim_cur instead to fix that.

Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Acked-by: James Morris <jmorris@namei.org>
Cc: Stephen Smalley <sds@tycho.nsa.gov>
Cc: Eric Paris <eparis@parisplace.org>
Cc: David Howells <dhowells@redhat.com>
---
 security/selinux/hooks.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 7a374c2..9a2ee84 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -2365,7 +2365,7 @@ static void selinux_bprm_committing_creds(struct linux_binprm *bprm)
 			initrlim = init_task.signal->rlim + i;
 			rlim->rlim_cur = min(rlim->rlim_max, initrlim->rlim_cur);
 		}
-		update_rlimit_cpu(rlim->rlim_cur);
+		update_rlimit_cpu(current->signal->rlim[RLIMIT_CPU].rlim_cur);
 	}
 }
 
-- 
1.6.5.7

Re: [PATCH 1/3] SECURITY: selinux, fix update_rlimit_cpu parameter

[David Howells]

Jiri Slaby <jslaby@suse.cz> wrote:

> From: Jiri Slaby <jirislaby@gmail.com>
> 
> Don't pass current RLIMIT_RTTIME to update_rlimit_cpu() in
> selinux_bprm_committing_creds, since update_rlimit_cpu expects
> RLIMIT_CPU limit.
> 
> Use proper rlim[RLIMIT_CPU].rlim_cur instead to fix that.
> 
> Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
> Acked-by: James Morris <jmorris@namei.org>
> Cc: Stephen Smalley <sds@tycho.nsa.gov>
> Cc: Eric Paris <eparis@parisplace.org>

Acked-by: David Howells <dhowells@redhat.com>

[PATCH 2/3] resource: move kernel function inside __KERNEL__

[Jiri Slaby]

It is an internal function. Move it inside __KERNEL__ ifdef, along
with task_struct declaration.

Then we get:
--- /usr/include/linux/resource.h       2009-09-14 15:09:29.000000000 +0200
+++ usr/include/linux/resource.h       2010-01-04 11:30:54.000000000 +0100
@@ -3,8 +3,6 @@

 #include <linux/time.h>

-struct task_struct;
-
 /*
  * Resource control/accounting header file for linux
  */
@@ -70,6 +68,5 @@
  */
 #include <asm/resource.h>

-int getrusage(struct task_struct *p, int who, struct rusage *ru);

 #endif

***********

include/linux/Kbuild is untouched, since unifdef is run even on
headers-y nowadays.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 include/linux/resource.h |    8 ++++++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/include/linux/resource.h b/include/linux/resource.h
index 40fc7e6..f1e914e 100644
--- a/include/linux/resource.h
+++ b/include/linux/resource.h
@@ -3,8 +3,6 @@
 
 #include <linux/time.h>
 
-struct task_struct;
-
 /*
  * Resource control/accounting header file for linux
  */
@@ -70,6 +68,12 @@ struct rlimit {
  */
 #include <asm/resource.h>
 
+#ifdef __KERNEL__
+
+struct task_struct;
+
 int getrusage(struct task_struct *p, int who, struct rusage __user *ru);
 
+#endif /* __KERNEL__ */
+
 #endif
-- 
1.6.5.7

[PATCH 3/3] resource: add helpers for fetching rlimits

[Jiri Slaby]

We want to be sure that compiler fetches the limit variable only
once, so add helpers for fetching current and maximal resource
limits which do that.

Add them to sched.h (instead of resource.h) due to circular dependency
 sched.h->resource.h->task_struct
Alternative would be to create a separate res_access.h or similar.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: James Morris <jmorris@namei.org>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Ingo Molnar <mingo@elte.hu>
---
 include/linux/sched.h |   22 ++++++++++++++++++++++
 1 files changed, 22 insertions(+), 0 deletions(-)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index f2f842d..8d4991b 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -2601,6 +2601,28 @@ static inline void mm_init_owner(struct mm_struct *mm, struct task_struct *p)
 }
 #endif /* CONFIG_MM_OWNER */
 
+static inline unsigned long task_rlimit(const struct task_struct *tsk,
+		unsigned int limit)
+{
+	return ACCESS_ONCE(tsk->signal->rlim[limit].rlim_cur);
+}
+
+static inline unsigned long task_rlimit_max(const struct task_struct *tsk,
+		unsigned int limit)
+{
+	return ACCESS_ONCE(tsk->signal->rlim[limit].rlim_max);
+}
+
+static inline unsigned long rlimit(unsigned int limit)
+{
+	return task_rlimit(current, limit);
+}
+
+static inline unsigned long rlimit_max(unsigned int limit)
+{
+	return task_rlimit_max(current, limit);
+}
+
 #endif /* __KERNEL__ */
 
 #endif
-- 
1.6.5.7

[git pull] pull request for writable limits for 2.6.34-rc0

[Jiri Slaby]

Hi,

please pull the writable limits tree below.

I'm not sure why you didn't pull it in the .33 window. I just guess
there was no reasoning about why you would do so. So, what are the
writable limits good for and why we are about to ship it in the next
Suse enterprise?

Conceivably, there are companies out there (such as SAP) running their
large-scale products on Linux and eventually they need to change a limit
without restarting the service. It is because restarting is not an
option most of the time. The limits are needed to be changed usually
because (a) it is not known in advance that some limits will need to
have a different value; (b) some processes start to crash occasionally.
In both cases the only necessity is just to change the particular limit
(core size in case of (b)) in runtime.

Hence we provide the functionality in the tree below. Opposing to the
last merge, most of the cleanup stuff was already merged by respective
maintainers into their trees rather than being here and are on the way
to you. They are independent of this merge and just ensure that future
compiler releases won't do weird things with the code.

---
The following changes since commit 64ba9926759792cf7b95f823402e2781edd1b5d4:
  Linus Torvalds (1):
        Merge branch 'for-linus' of git://git.open-osd.org/linux-open-osd

are available in the git repository at:

  git://decibel.fi.muni.cz/~xslaby/linux writable_limits

Jiri Slaby (13):
      SECURITY: add task_struct to setrlimit
      core: add task_struct to update_rlimit_cpu
      core: split sys_setrlimit
      core: allow setrlimit to non-current tasks
      core: optimize setrlimit for current task
      FS: proc, switch limits reading to fops
      FS: proc, make limits writable
      core: do security check under task_lock
      core: implement getprlimit and setprlimit syscalls
      compat: use do_setrlimit in compat_sys_setrlimit
      COMPAT: add get/put_compat_rlimit
      x86: add ia32 compat prlimit syscalls
      Documentation: fs/proc, add limits documentation

Neil Horman (1):
      unistd: add __NR_[get|set]prlimit syscall numbers

Oleg Nesterov (1):
      sys_setrlimit: make sure ->rlim_max never grows

 Documentation/filesystems/proc.txt |   11 +++
 arch/x86/ia32/ia32entry.S          |    2 +
 arch/x86/include/asm/unistd_32.h   |    4 +-
 arch/x86/include/asm/unistd_64.h   |    4 +
 arch/x86/kernel/syscall_table_32.S |    2 +
 fs/proc/base.c                     |  101 ++++++++++++++++++++++--
 include/asm-generic/unistd.h       |    6 +-
 include/linux/posix-timers.h       |    2 +-
 include/linux/resource.h           |    2 +
 include/linux/security.h           |    9 ++-
 include/linux/syscalls.h           |    4 +
 kernel/compat.c                    |   98 +++++++++++++++++-------
 kernel/posix-cpu-timers.c          |   10 +-
 kernel/sys.c                       |  151
++++++++++++++++++++++++++++++------
 security/capability.c              |    3 +-
 security/security.c                |    5 +-
 security/selinux/hooks.c           |   10 ++-
 17 files changed, 346 insertions(+), 78 deletions(-)

thanks,
-- 
js

Re: [git pull] pull request for writable limits for 2.6.34-rc0

[Linus Torvalds]

On Fri, 5 Mar 2010, Jiri Slaby wrote:
> 
> please pull the writable limits tree below.

Ok, sorry for the long delay - I spent 5 days at two separate intel events 
over the last two weeks, which ended up sucking up a lot of my spare time 
that I normally use to try to judge the merge window stuff. As a result, I 
pulled mainly code that wasn't new (ie existing models), or that was 
"obviously independent" (liek the new ceph filesystem) and didn't have any 
contentious issues.

As a result, I ended up looking at the writable limits only today.

And I'm not entirely happy. For example, I absolutely _detest_ seeing new 
compat code for a feature that was just added. My immediate reaction is 
"WTF? What kind of moron doesn't make things 64-bit safe to begin with?". 
It's really annoying.

Why doesn't the new set/getprlimit things just take a pointer to a 
well-defined pair of 64-bit values? Why is there any compat cruft at all 
there? That is beyond insane. Just make the user level interface work 
right in the first place, instead of adding crazy compat crap. This is 
_not_ a legacy interface.

I'd also like to hear more about actual uses. Does _any_ other Unix-like 
system actually implement this writable limits thing? Who is asking for 
it? 

			Linus

Re: [git pull] pull request for writable limits for 2.6.34-rc0

[Neil Horman]

On Sat, Mar 20, 2010 at 12:20:58PM -0700, Linus Torvalds wrote:
> 
> 
> On Fri, 5 Mar 2010, Jiri Slaby wrote:
> > 
> > please pull the writable limits tree below.
> 
> Ok, sorry for the long delay - I spent 5 days at two separate intel events 
> over the last two weeks, which ended up sucking up a lot of my spare time 
> that I normally use to try to judge the merge window stuff. As a result, I 
> pulled mainly code that wasn't new (ie existing models), or that was 
> "obviously independent" (liek the new ceph filesystem) and didn't have any 
> contentious issues.
> 
> As a result, I ended up looking at the writable limits only today.
> 
> And I'm not entirely happy. For example, I absolutely _detest_ seeing new 
> compat code for a feature that was just added. My immediate reaction is 
> "WTF? What kind of moron doesn't make things 64-bit safe to begin with?". 
> It's really annoying.
> 
> Why doesn't the new set/getprlimit things just take a pointer to a 
> well-defined pair of 64-bit values? Why is there any compat cruft at all 
> there? That is beyond insane. Just make the user level interface work 
> right in the first place, instead of adding crazy compat crap. This is 
> _not_ a legacy interface.
> 
I won't speak to this yet, its been awhile since I looked at it, but I don't
recall there being any compat code in place (although it went through several
revisions, so I may be thinking of the wrong version).

> I'd also like to hear more about actual uses. Does _any_ other Unix-like 
> system actually implement this writable limits thing? Who is asking for 
> it? 
> 
The main request that I've gotten in regards to this feature request is for
admins who want to make limits adjustments to processes without the need to
restart them.  The specific example I've been given is the desire to increase
the number of open files a database process can hold without needing to restart
the database.

Neil

> 			Linus
> 

Re: [git pull] pull request for writable limits for 2.6.34-rc0

[Alexey Dobriyan]

On Sat, Mar 20, 2010 at 12:20:58PM -0700, Linus Torvalds wrote:
> On Fri, 5 Mar 2010, Jiri Slaby wrote:
> > 
> > please pull the writable limits tree below.

> As a result, I ended up looking at the writable limits only today.
> 
> And I'm not entirely happy. For example, I absolutely _detest_ seeing new 
> compat code for a feature that was just added. My immediate reaction is 
> "WTF? What kind of moron doesn't make things 64-bit safe to begin with?". 
> It's really annoying.
> 
> Why doesn't the new set/getprlimit things just take a pointer to a 
> well-defined pair of 64-bit values? Why is there any compat cruft at all 
> there? That is beyond insane. Just make the user level interface work 
> right in the first place, instead of adding crazy compat crap. This is 
> _not_ a legacy interface.

It's a perfect opportunity to introduce getrlimit64(2), setrlimit64(2)
_without_ involving /proc, without all bugs in setrlimit(2), without
compat code, with all resources equal across arches, and, optionally,
with infinity setting clearly separate from value (useful for C/R).

Pity, we will have config option for 64-bit internal rlimits.

	Alexey, who detests /proc/self/limits format

Re: [git pull] pull request for writable limits for 2.6.34-rc0

[Linus Torvalds]

On Sun, 21 Mar 2010, Alexey Dobriyan wrote:
> 
> It's a perfect opportunity to introduce getrlimit64(2), setrlimit64(2)
> _without_ involving /proc, without all bugs in setrlimit(2), without
> compat code, with all resources equal across arches, and, optionally,
> with infinity setting clearly separate from value (useful for C/R).

Yeah, the infinity setting should be cleaned up. I also wonder if we 
should clean up the odd file limit rules, and make them all be about 
bytes. Correct me if I'm wrong, but don't we do that whole file size thing 
in kilobytes right now?

I do also agree that maybe we could/should skip the whole "writable /proc" 
thing.

So introducing it as just two system calls:

	int getprlimit64(pid, limit, struct rlimit64 *);
	int setprlimit64(pid, limit, const struct rlimit64 *);

and having perhaps something like 'pid=0 means current' would look a lot 
prettier to me.

Or even just _one_ system call that takes two pointers, and can do an 
atomic replace-and-return-the-old-value, like 'sigaction()' does, ie 
something like

	int prlimit64(pid, limit, const struct rlimit64 *new, struct rlimit64 *old);

wouldn't that be a nice generic interface?

(Somebody should really check me on the whole "limit in kilobytes" thing - 
I may be _totally_ off there. I am too lazy to check the actual source 
code)

			Linus

Re: [git pull] pull request for writable limits for 2.6.34-rc0

[Jiri Slaby]

Hi.

On 03/21/2010 07:38 PM, Linus Torvalds wrote:
> Yeah, the infinity setting should be cleaned up. I also wonder if we 
> should clean up the odd file limit rules, and make them all be about 
> bytes. Correct me if I'm wrong, but don't we do that whole file size thing 
> in kilobytes right now?

Nope, it's just ulimit in bash who takes "blocks" and calls setrlimit
with 1024*value for core and file size limits.

> I do also agree that maybe we could/should skip the whole "writable /proc" 
> thing.

I agree too, why I had to implement is that we cannot assign syscall
numbers before merging upstream (for obvious reasons of not destroying
userspace interface where programs won't work on our distro) and we
needed the writable-limits feature.

> Or even just _one_ system call that takes two pointers, and can do an 
> atomic replace-and-return-the-old-value, like 'sigaction()' does, ie 
> something like
> 
> 	int prlimit64(pid, limit, const struct rlimit64 *new, struct rlimit64 *old);
> 
> wouldn't that be a nice generic interface?

Seconded. But should the limits be by default 64-bit even on 32-bit? I
mean: switch 'struct limit' in signal_struct to 'struct rlimit64'? This
would make the limits non-atomic on 32-bit. Oh, they are not already if
reader wants both cur and max without any locks, but I'm not sure now
what implications this will have (I haven't checked compilers, but I
think a store of 00000001 0000000 in place of 00000000 ffffffff may
result in a read of 00000001 ffffffff or alike). Or did I misunderstand you?

thanks,
-- 
js

Re: [git pull] pull request for writable limits for 2.6.34-rc0

[Jiri Slaby]

On 03/24/2010 06:02 PM, Jiri Slaby wrote:
> On 03/21/2010 07:38 PM, Linus Torvalds wrote:
>> Or even just _one_ system call that takes two pointers, and can do an 
>> atomic replace-and-return-the-old-value, like 'sigaction()' does, ie 
>> something like
>>
>> 	int prlimit64(pid, limit, const struct rlimit64 *new, struct rlimit64 *old);
>>
>> wouldn't that be a nice generic interface?
> 
> Seconded. But should the limits be by default 64-bit even on 32-bit? I
> mean: switch 'struct limit' in signal_struct to 'struct rlimit64'? This
> would make the limits non-atomic on 32-bit. Oh, they are not already if
> reader wants both cur and max without any locks, but I'm not sure now
> what implications this will have (I haven't checked compilers, but I
> think a store of 00000001 0000000 in place of 00000000 ffffffff may
> result in a read of 00000001 ffffffff or alike). Or did I misunderstand you?

Maybe it is a silly question or you was just busy at that time?

thanks,
-- 
js

Resource limits interface proposal [was: pull request for writable limits]

[Jiri Slaby]

Hi.

On 03/21/2010 07:38 PM, Linus Torvalds wrote:
> Or even just _one_ system call that takes two pointers, and can do an 
> atomic replace-and-return-the-old-value, like 'sigaction()' does, ie 
> something like
> 
> 	int prlimit64(pid, limit, const struct rlimit64 *new, struct rlimit64 *old);
> 
> wouldn't that be a nice generic interface?

So I ended up with thinking about these possibilities:

1) internal representation of limits will stay as is in signal_struct,
i.e. long limits with infinity being ~0ul. This is the least intrusive
solution. The new prlimit64 will convert rlimit64 to rlimit and pass
down to do_prlimit. With setrlimit and getrilimit just as wrappers it
will look like:
prlimit64(pid, resource, new64, old64) ->
    new = convert_to_rlim(new64)
    tsk = find_task(pid)
    do_prlimit(tsk, resource, new, old)
    old64 = convert_to_rlim64(old)
setrlimit(resource, rlim) ->
    do_prlimit(current, resource, rlim, NULL)
getrlimit(resource, rlim) ->
    do_prlimit(current, resource, NULL, rlim)
with appropriate copy_{from,to}_user. (And setrlimit+getrlimit will be
scheduled for removal with all the compat crap around them.)

It may also be that rlimit64 will contain flags like:
#define RLIM64_CUR_INFINITY     0x00000001
#define RLIM64_MAX_INFINITY     0x00000002
struct rlimit64 {
        __u64 rlim_cur;
        __u64 rlim_max;
        __u32 flags;
};
if I understood Alexey correctly to separate limits values from
infinity? flags then will be converted to ~0ul when converting from
rlimit64 to rlimit above too.

The drawback is when a 32-bit user passes down a value >= (1 << 32),
EINVAL shall occur.

The pros are, no locking, no magic, longs are naturally atomic. Still
with arch-independent parameter for sys_prlimit64.


2) Introduce an rlimit lock and move every user to the rlimit helpers
which appropriately lock the accesses. And making locking a nop when
BITS_PER_LONG == 64. Then we can have rlimit64 in signal_struct and
everything will happen on 64-bit limit values.

If we decide to separate infinity from value with the flags above, we
should also reconsider what infinity will be. Much code just counts with
rlimit.rlim_{cur,max} being the highest possible value and doesn't count
with something like rlimit64.flags. This will result in locks not-being
a nop on 64-bit, because we want fresh rlim_cur+flags and rlim_max+flags
pairs. We could also have the flags solely in the syscall interface and
~0ULL count as infty internally.

In this case the situation will be
prlimit64(pid, resource, new64, old64) ->
    tsk = find_task(pid)
    do_prlimit(tsk, resource, new64, old64)
setrlimit(resource, rlim) ->
    rlim64 = convert_to_rlim64(rlim)
    do_prlimit(current, resource, rlim64, NULL)
getrlimit(resource, rlim) ->
    do_prlimit(current, resource, NULL, rlim64)
    rlim = convert_to_rlim(rlim64)

We cannot fail in prlimit64 due to limited space in longs on 32-bit,
however we added locking which may slow things down. I have no idea how
contended the lock will be, but as rlimits are used in the scheduler and
filesystem core, it might affect performance. I might measure if this is
of interest.


3) [inspired by Jan Kara's idea who knows how inode handling works] It's
some kind of similar to 2), we just avoid locks similarly to
inode->i_size accessors.

It doesn't solve the case of separate flags though.



Just a side note, we cannot use the rlimit64 name which is already
reserved in glibc headers for limits handling.

I will appreciate any comments.

thanks,
-- 
js

-- 
js
suse labs

-- 
js

Re: Resource limits interface proposal [was: pull request for writable limits]

[Linus Torvalds]

On Wed, 5 May 2010, Jiri Slaby wrote:
> 
> So I ended up with thinking about these possibilities:
> 
> 1) internal representation of limits will stay as is in signal_struct,
> i.e. long limits with infinity being ~0ul. This is the least intrusive
> solution. The new prlimit64 will convert rlimit64 to rlimit and pass
> down to do_prlimit. With setrlimit and getrilimit just as wrappers it
> will look like:
> prlimit64(pid, resource, new64, old64) ->
>     new = convert_to_rlim(new64)
>     tsk = find_task(pid)
>     do_prlimit(tsk, resource, new, old)
>     old64 = convert_to_rlim64(old)
> setrlimit(resource, rlim) ->
>     do_prlimit(current, resource, rlim, NULL)
> getrlimit(resource, rlim) ->
>     do_prlimit(current, resource, NULL, rlim)
> with appropriate copy_{from,to}_user. (And setrlimit+getrlimit will be
> scheduled for removal with all the compat crap around them.)

Yes, this sounds much better to me.

> It may also be that rlimit64 will contain flags like:
> #define RLIM64_CUR_INFINITY     0x00000001
> #define RLIM64_MAX_INFINITY     0x00000002
> struct rlimit64 {
>         __u64 rlim_cur;
>         __u64 rlim_max;
>         __u32 flags;
> };
> if I understood Alexey correctly to separate limits values from
> infinity? flags then will be converted to ~0ul when converting from
> rlimit64 to rlimit above too.

Ok, I'm not entirely sure we need to care specially about INFINITY, 
_especially_ since INF is really rather big in 64 bits. So to some degree, 
making things 64-bit is _less_ likely to make INFINITIES a problem.

It's also impossible to convert back and forth reliably unless you were to 
add this bit to the internal rlimit structure too. It sounds like a bad 
design to have

	prlimit64(-1, limit, &new, NULL);
	prlimit64(-1, limit, NULL, &old);

result in "old" containing something different than "new".

Of course, if there are 32-bit/64-bit issues, the above can _never_ give 
the same results for >= (1<<32) values, but that's a somewhat separate 
issue, and is directly tied to the word-size, not some new internal flag.

> The drawback is when a 32-bit user passes down a value >= (1 << 32),
> EINVAL shall occur.

I'd almost prefer to just turn them into RLIMIT_MAX. If somebody asks for 
a really huge limit that is bigger than the max we already have, doesn't 
RLIMIT_MAX sound like the right thing?

> 2) Introduce an rlimit lock and move every user to the rlimit helpers
> which appropriately lock the accesses. And making locking a nop when
> BITS_PER_LONG == 64. Then we can have rlimit64 in signal_struct and
> everything will happen on 64-bit limit values.

I think long-term we might want to do this, but not as a first stage. And 
if the 'infinity' flag makes sense, _and_ we decide that long-term we want 
to do this, then I'm not objecting to adding it now.

> Just a side note, we cannot use the rlimit64 name which is already
> reserved in glibc headers for limits handling.

What does the glibc 'struct rlimit64' look like? It's the structure name 
that matters, since the system call name would presumably be 'prlimit64()' 
due to the pid thing.

And if the glibc rlimit64 matches what we would use, I think we can decide 
to just re-use it.

		Linus

Re: Resource limits interface proposal [was: pull request for writable limits]

[Alexey Dobriyan]

On Wed, May 5, 2010 at 6:08 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>> It may also be that rlimit64 will contain flags like:
>> #define RLIM64_CUR_INFINITY     0x00000001
>> #define RLIM64_MAX_INFINITY     0x00000002
>> struct rlimit64 {
>>         __u64 rlim_cur;
>>         __u64 rlim_max;
>>         __u32 flags;
>> };
>> if I understood Alexey correctly to separate limits values from
>> infinity? flags then will be converted to ~0ul when converting from
>> rlimit64 to rlimit above too.
>
> Ok, I'm not entirely sure we need to care specially about INFINITY,
> _especially_ since INF is really rather big in 64 bits. So to some degree,
> making things 64-bit is _less_ likely to make INFINITIES a problem.

I'm _sure_, someone will mention bloat and performance degradation
on 32-bit, so there will be config option for 32-bit in-kernel limits.
And if there will be config option, infinities are better be separated.

Re: Resource limits interface proposal [was: pull request for writable limits]

[Linus Torvalds]

On Thu, 6 May 2010, Alexey Dobriyan wrote:

> On Wed, May 5, 2010 at 6:08 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > Ok, I'm not entirely sure we need to care specially about INFINITY,
> > _especially_ since INF is really rather big in 64 bits. So to some degree,
> > making things 64-bit is _less_ likely to make INFINITIES a problem.
> 
> I'm _sure_, someone will mention bloat and performance degradation
> on 32-bit, so there will be config option for 32-bit in-kernel limits.
> And if there will be config option, infinities are better be separated.

Umm. Why?

Adding an INF field will make it essentially impossible to use that thing 
as a compatibility function, and/or together with the legacy rlimit() 
system call. And that is going to be 99.999% of all uses.

I don't think you understand how system calls work. People don't use 
Linux-only features. It's been shown over and over and over again. People 
use the standard interfaces, and they don't _have_ that INF field. We can 
extend ranges by just updating structures (see "stat()" and friends) and a 
recompile will make it use higher limits, but we can't make programs use 
new features.

So there is _no_ upside. There would be _no_ programs ever using it. 

Whether the internal limits for the kernel are 32-bit or not makes 
absolutely zero difference. And my argument is that _if_ they are 64-bit, 
that makes the INF field even _less_ interesting. So they go from "zero 
practical difference" in 32-bit to "f*ck it, nobody can _possibly_ care 
even in theory" in 64-bit.

If the internal limits are 32-bit, then you just turn any 64-bit value 
larger than the (32-bit) RLIM_INFINITY into a RLIM_INFINITY. And that's as 
good as you can get with mixing with the legacy interface anyway.

		Linus

[PATCH 01/11] rlimits: security, add task_struct to setrlimit

[Jiri Slaby]

From: Jiri Slaby <jirislaby@gmail.com>

Add task_struct to task_setrlimit of security_operations to be able to set
rlimit of different task than current.

Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Acked-by: Eric Paris <eparis@redhat.com>
Acked-by: James Morris <jmorris@namei.org>
---
 include/linux/security.h |    9 ++++++---
 kernel/sys.c             |    2 +-
 security/capability.c    |    3 ++-
 security/security.c      |    5 +++--
 security/selinux/hooks.c |    7 ++++---
 5 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/include/linux/security.h b/include/linux/security.h
index 24fc295..2c6a756 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -1502,7 +1502,8 @@ struct security_operations {
 	int (*task_setnice) (struct task_struct *p, int nice);
 	int (*task_setioprio) (struct task_struct *p, int ioprio);
 	int (*task_getioprio) (struct task_struct *p);
-	int (*task_setrlimit) (unsigned int resource, struct rlimit *new_rlim);
+	int (*task_setrlimit) (struct task_struct *p, unsigned int resource,
+			struct rlimit *new_rlim);
 	int (*task_setscheduler) (struct task_struct *p, int policy,
 				  struct sched_param *lp);
 	int (*task_getscheduler) (struct task_struct *p);
@@ -1752,7 +1753,8 @@ void security_task_getsecid(struct task_struct *p, u32 *secid);
 int security_task_setnice(struct task_struct *p, int nice);
 int security_task_setioprio(struct task_struct *p, int ioprio);
 int security_task_getioprio(struct task_struct *p);
-int security_task_setrlimit(unsigned int resource, struct rlimit *new_rlim);
+int security_task_setrlimit(struct task_struct *p, unsigned int resource,
+		struct rlimit *new_rlim);
 int security_task_setscheduler(struct task_struct *p,
 				int policy, struct sched_param *lp);
 int security_task_getscheduler(struct task_struct *p);
@@ -2314,7 +2316,8 @@ static inline int security_task_getioprio(struct task_struct *p)
 	return 0;
 }
 
-static inline int security_task_setrlimit(unsigned int resource,
+static inline int security_task_setrlimit(struct task_struct *p,
+					  unsigned int resource,
 					  struct rlimit *new_rlim)
 {
 	return 0;
diff --git a/kernel/sys.c b/kernel/sys.c
index e83ddbb..1ba4522 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -1290,7 +1290,7 @@ SYSCALL_DEFINE2(setrlimit, unsigned int, resource, struct rlimit __user *, rlim)
 	if (resource == RLIMIT_NOFILE && new_rlim.rlim_max > sysctl_nr_open)
 		return -EPERM;
 
-	retval = security_task_setrlimit(resource, &new_rlim);
+	retval = security_task_setrlimit(current, resource, &new_rlim);
 	if (retval)
 		return retval;
 
diff --git a/security/capability.c b/security/capability.c
index 7f093d5..33a16d6 100644
--- a/security/capability.c
+++ b/security/capability.c
@@ -412,7 +412,8 @@ static int cap_task_getioprio(struct task_struct *p)
 	return 0;
 }
 
-static int cap_task_setrlimit(unsigned int resource, struct rlimit *new_rlim)
+static int cap_task_setrlimit(struct task_struct *p, unsigned int resource,
+		struct rlimit *new_rlim)
 {
 	return 0;
 }
diff --git a/security/security.c b/security/security.c
index a525e01..3ed1719 100644
--- a/security/security.c
+++ b/security/security.c
@@ -781,9 +781,10 @@ int security_task_getioprio(struct task_struct *p)
 	return security_ops->task_getioprio(p);
 }
 
-int security_task_setrlimit(unsigned int resource, struct rlimit *new_rlim)
+int security_task_setrlimit(struct task_struct *p, unsigned int resource,
+		struct rlimit *new_rlim)
 {
-	return security_ops->task_setrlimit(resource, new_rlim);
+	return security_ops->task_setrlimit(p, resource, new_rlim);
 }
 
 int security_task_setscheduler(struct task_struct *p,
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index ebee467..674992f 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -3393,16 +3393,17 @@ static int selinux_task_getioprio(struct task_struct *p)
 	return current_has_perm(p, PROCESS__GETSCHED);
 }
 
-static int selinux_task_setrlimit(unsigned int resource, struct rlimit *new_rlim)
+static int selinux_task_setrlimit(struct task_struct *p, unsigned int resource,
+		struct rlimit *new_rlim)
 {
-	struct rlimit *old_rlim = current->signal->rlim + resource;
+	struct rlimit *old_rlim = p->signal->rlim + resource;
 
 	/* Control the ability to change the hard limit (whether
 	   lowering or raising it), so that the hard limit can
 	   later be used as a safe reset point for the soft limit
 	   upon context transitions.  See selinux_bprm_committing_creds. */
 	if (old_rlim->rlim_max != new_rlim->rlim_max)
-		return current_has_perm(current, PROCESS__SETRLIMIT);
+		return current_has_perm(p, PROCESS__SETRLIMIT);
 
 	return 0;
 }
-- 
1.7.1

[PATCH 02/11] rlimits: add task_struct to update_rlimit_cpu

[Jiri Slaby]

From: Jiri Slaby <jirislaby@gmail.com>

Add task_struct as a parameter to update_rlimit_cpu to be able to set
rlimit_cpu of different task than current.

Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Acked-by: James Morris <jmorris@namei.org>
---
 include/linux/posix-timers.h |    2 +-
 kernel/posix-cpu-timers.c    |    8 ++++----
 kernel/sys.c                 |    2 +-
 security/selinux/hooks.c     |    3 ++-
 4 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/include/linux/posix-timers.h b/include/linux/posix-timers.h
index 4f71bf4..3e23844 100644
--- a/include/linux/posix-timers.h
+++ b/include/linux/posix-timers.h
@@ -117,6 +117,6 @@ void set_process_cpu_timer(struct task_struct *task, unsigned int clock_idx,
 
 long clock_nanosleep_restart(struct restart_block *restart_block);
 
-void update_rlimit_cpu(unsigned long rlim_new);
+void update_rlimit_cpu(struct task_struct *task, unsigned long rlim_new);
 
 #endif
diff --git a/kernel/posix-cpu-timers.c b/kernel/posix-cpu-timers.c
index 9829646..0513900 100644
--- a/kernel/posix-cpu-timers.c
+++ b/kernel/posix-cpu-timers.c
@@ -16,13 +16,13 @@
  * siglock protection since other code may update expiration cache as
  * well.
  */
-void update_rlimit_cpu(unsigned long rlim_new)
+void update_rlimit_cpu(struct task_struct *task, unsigned long rlim_new)
 {
 	cputime_t cputime = secs_to_cputime(rlim_new);
 
-	spin_lock_irq(&current->sighand->siglock);
-	set_process_cpu_timer(current, CPUCLOCK_PROF, &cputime, NULL);
-	spin_unlock_irq(&current->sighand->siglock);
+	spin_lock_irq(&task->sighand->siglock);
+	set_process_cpu_timer(task, CPUCLOCK_PROF, &cputime, NULL);
+	spin_unlock_irq(&task->sighand->siglock);
 }
 
 static int check_clock(const clockid_t which_clock)
diff --git a/kernel/sys.c b/kernel/sys.c
index 1ba4522..f5183b0 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -1320,7 +1320,7 @@ SYSCALL_DEFINE2(setrlimit, unsigned int, resource, struct rlimit __user *, rlim)
 	if (new_rlim.rlim_cur == RLIM_INFINITY)
 		goto out;
 
-	update_rlimit_cpu(new_rlim.rlim_cur);
+	update_rlimit_cpu(current, new_rlim.rlim_cur);
 out:
 	return 0;
 }
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 674992f..740a71f 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -2360,7 +2360,8 @@ static void selinux_bprm_committing_creds(struct linux_binprm *bprm)
 			initrlim = init_task.signal->rlim + i;
 			rlim->rlim_cur = min(rlim->rlim_max, initrlim->rlim_cur);
 		}
-		update_rlimit_cpu(current->signal->rlim[RLIMIT_CPU].rlim_cur);
+		update_rlimit_cpu(current,
+				current->signal->rlim[RLIMIT_CPU].rlim_cur);
 	}
 }
 
-- 
1.7.1

[PATCH 03/11] rlimits: make sure ->rlim_max never grows in sys_setrlimit

[Jiri Slaby]

From: Oleg Nesterov <oleg@redhat.com>

Mostly preparation for Jiri's changes, but probably makes sense anyway.

sys_setrlimit() checks new_rlim.rlim_max <= old_rlim->rlim_max, but when
it takes task_lock() old_rlim->rlim_max can be already lowered. Move this
check under task_lock().

Currently this is not important, we can only race with our sub-thread,
this means the application is stupid. But when we change the code to allow
the update of !current task's limits, it becomes important to make sure
->rlim_max can be lowered "reliably" even if we race with the application
doing sys_setrlimit().

Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
---
 kernel/sys.c |   15 ++++++++-------
 1 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/kernel/sys.c b/kernel/sys.c
index f5183b0..d527c46 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -1283,10 +1283,6 @@ SYSCALL_DEFINE2(setrlimit, unsigned int, resource, struct rlimit __user *, rlim)
 		return -EFAULT;
 	if (new_rlim.rlim_cur > new_rlim.rlim_max)
 		return -EINVAL;
-	old_rlim = current->signal->rlim + resource;
-	if ((new_rlim.rlim_max > old_rlim->rlim_max) &&
-	    !capable(CAP_SYS_RESOURCE))
-		return -EPERM;
 	if (resource == RLIMIT_NOFILE && new_rlim.rlim_max > sysctl_nr_open)
 		return -EPERM;
 
@@ -1304,11 +1300,16 @@ SYSCALL_DEFINE2(setrlimit, unsigned int, resource, struct rlimit __user *, rlim)
 		new_rlim.rlim_cur = 1;
 	}
 
+	old_rlim = current->signal->rlim + resource;
 	task_lock(current->group_leader);
-	*old_rlim = new_rlim;
+	if ((new_rlim.rlim_max <= old_rlim->rlim_max) ||
+				capable(CAP_SYS_RESOURCE))
+		*old_rlim = new_rlim;
+	else
+		retval = -EPERM;
 	task_unlock(current->group_leader);
 
-	if (resource != RLIMIT_CPU)
+	if (retval || resource != RLIMIT_CPU)
 		goto out;
 
 	/*
@@ -1322,7 +1323,7 @@ SYSCALL_DEFINE2(setrlimit, unsigned int, resource, struct rlimit __user *, rlim)
 
 	update_rlimit_cpu(current, new_rlim.rlim_cur);
 out:
-	return 0;
+	return retval;
 }
 
 /*
-- 
1.7.1

[PATCH 04/11] rlimits: split sys_setrlimit

[Jiri Slaby]

From: Jiri Slaby <jirislaby@gmail.com>

Create do_setrlimit from sys_setrlimit and declare do_setrlimit
in the resource header. This is the firts phase to have generic
do_prlimit which allows to be called from read, write and compat
rlimits code.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 include/linux/resource.h |    2 ++
 kernel/sys.c             |   40 ++++++++++++++++++++++++----------------
 2 files changed, 26 insertions(+), 16 deletions(-)

diff --git a/include/linux/resource.h b/include/linux/resource.h
index f1e914e..cf8dc96 100644
--- a/include/linux/resource.h
+++ b/include/linux/resource.h
@@ -73,6 +73,8 @@ struct rlimit {
 struct task_struct;
 
 int getrusage(struct task_struct *p, int who, struct rusage __user *ru);
+int do_setrlimit(struct task_struct *tsk, unsigned int resource,
+		struct rlimit *new_rlim);
 
 #endif /* __KERNEL__ */
 
diff --git a/kernel/sys.c b/kernel/sys.c
index d527c46..7c76f84 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -1272,42 +1272,41 @@ SYSCALL_DEFINE2(old_getrlimit, unsigned int, resource,
 
 #endif
 
-SYSCALL_DEFINE2(setrlimit, unsigned int, resource, struct rlimit __user *, rlim)
+int do_setrlimit(struct task_struct *tsk, unsigned int resource,
+		struct rlimit *new_rlim)
 {
-	struct rlimit new_rlim, *old_rlim;
+	struct rlimit *old_rlim;
 	int retval;
 
 	if (resource >= RLIM_NLIMITS)
 		return -EINVAL;
-	if (copy_from_user(&new_rlim, rlim, sizeof(*rlim)))
-		return -EFAULT;
-	if (new_rlim.rlim_cur > new_rlim.rlim_max)
+	if (new_rlim->rlim_cur > new_rlim->rlim_max)
 		return -EINVAL;
-	if (resource == RLIMIT_NOFILE && new_rlim.rlim_max > sysctl_nr_open)
+	if (resource == RLIMIT_NOFILE && new_rlim->rlim_max > sysctl_nr_open)
 		return -EPERM;
 
-	retval = security_task_setrlimit(current, resource, &new_rlim);
+	retval = security_task_setrlimit(tsk, resource, new_rlim);
 	if (retval)
 		return retval;
 
-	if (resource == RLIMIT_CPU && new_rlim.rlim_cur == 0) {
+	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;
+		new_rlim->rlim_cur = 1;
 	}
 
-	old_rlim = current->signal->rlim + resource;
-	task_lock(current->group_leader);
-	if ((new_rlim.rlim_max <= old_rlim->rlim_max) ||
+	old_rlim = tsk->signal->rlim + resource;
+	task_lock(tsk->group_leader);
+	if ((new_rlim->rlim_max <= old_rlim->rlim_max) ||
 				capable(CAP_SYS_RESOURCE))
-		*old_rlim = new_rlim;
+		*old_rlim = *new_rlim;
 	else
 		retval = -EPERM;
-	task_unlock(current->group_leader);
+	task_unlock(tsk->group_leader);
 
 	if (retval || resource != RLIMIT_CPU)
 		goto out;
@@ -1318,14 +1317,23 @@ SYSCALL_DEFINE2(setrlimit, unsigned int, resource, struct rlimit __user *, rlim)
 	 * very long-standing error, and fixing it now risks breakage of
 	 * applications, so we live with it
 	 */
-	if (new_rlim.rlim_cur == RLIM_INFINITY)
+	if (new_rlim->rlim_cur == RLIM_INFINITY)
 		goto out;
 
-	update_rlimit_cpu(current, new_rlim.rlim_cur);
+	update_rlimit_cpu(tsk, new_rlim->rlim_cur);
 out:
 	return retval;
 }
 
+SYSCALL_DEFINE2(setrlimit, unsigned int, resource, struct rlimit __user *, rlim)
+{
+	struct rlimit new_rlim;
+
+	if (copy_from_user(&new_rlim, rlim, sizeof(*rlim)))
+		return -EFAULT;
+	return do_setrlimit(current, resource, &new_rlim);
+}
+
 /*
  * It would make sense to put struct rusage in the task_struct,
  * except that would make the task_struct be *really big*.  After
-- 
1.7.1

[PATCH 05/11] rlimits: allow setrlimit to non-current tasks

[Jiri Slaby]

From: Jiri Slaby <jirislaby@gmail.com>

Add locking to allow setrlimit accept task parameter other than
current.

Namely, lock tasklist_lock for read and check whether the task
structure has sighand non-null. Do all the signal processing under
that lock still held.

Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Cc: Oleg Nesterov <oleg@redhat.com>
---
 kernel/sys.c |   11 ++++++++++-
 1 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/kernel/sys.c b/kernel/sys.c
index 7c76f84..eb21661 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -1272,6 +1272,7 @@ SYSCALL_DEFINE2(old_getrlimit, unsigned int, resource,
 
 #endif
 
+/* make sure you are allowed to change @tsk limits before calling this */
 int do_setrlimit(struct task_struct *tsk, unsigned int resource,
 		struct rlimit *new_rlim)
 {
@@ -1285,9 +1286,16 @@ int do_setrlimit(struct task_struct *tsk, unsigned int resource,
 	if (resource == RLIMIT_NOFILE && new_rlim->rlim_max > sysctl_nr_open)
 		return -EPERM;
 
+	/* protect tsk->signal and tsk->sighand from disappearing */
+	read_lock(&tasklist_lock);
+	if (!tsk->sighand) {
+		retval = -ESRCH;
+		goto out;
+	}
+
 	retval = security_task_setrlimit(tsk, resource, new_rlim);
 	if (retval)
-		return retval;
+		goto out;
 
 	if (resource == RLIMIT_CPU && new_rlim->rlim_cur == 0) {
 		/*
@@ -1322,6 +1330,7 @@ int do_setrlimit(struct task_struct *tsk, unsigned int resource,
 
 	update_rlimit_cpu(tsk, new_rlim->rlim_cur);
 out:
+	read_unlock(&tasklist_lock);
 	return retval;
 }
 
-- 
1.7.1

[PATCH 06/11] rlimits: do security check under task_lock

[Jiri Slaby]

Do security_task_setrlimit under task_lock. Other tasks may
change limits under our hands while we are checking limits
inside the function. From now on, they can't.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Acked-by: James Morris <jmorris@namei.org>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Ingo Molnar <mingo@elte.hu>
---
 kernel/sys.c |   16 +++++++---------
 1 files changed, 7 insertions(+), 9 deletions(-)

diff --git a/kernel/sys.c b/kernel/sys.c
index eb21661..9e9a3a7 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -1277,7 +1277,7 @@ int do_setrlimit(struct task_struct *tsk, unsigned int resource,
 		struct rlimit *new_rlim)
 {
 	struct rlimit *old_rlim;
-	int retval;
+	int retval = 0;
 
 	if (resource >= RLIM_NLIMITS)
 		return -EINVAL;
@@ -1293,10 +1293,6 @@ int do_setrlimit(struct task_struct *tsk, unsigned int resource,
 		goto out;
 	}
 
-	retval = security_task_setrlimit(tsk, resource, new_rlim);
-	if (retval)
-		goto out;
-
 	if (resource == RLIMIT_CPU && new_rlim->rlim_cur == 0) {
 		/*
 		 * The caller is asking for an immediate RLIMIT_CPU
@@ -1309,11 +1305,13 @@ int do_setrlimit(struct task_struct *tsk, unsigned int resource,
 
 	old_rlim = tsk->signal->rlim + resource;
 	task_lock(tsk->group_leader);
-	if ((new_rlim->rlim_max <= old_rlim->rlim_max) ||
-				capable(CAP_SYS_RESOURCE))
-		*old_rlim = *new_rlim;
-	else
+	if ((new_rlim->rlim_max > old_rlim->rlim_max) &&
+				!capable(CAP_SYS_RESOURCE))
 		retval = -EPERM;
+	if (!retval)
+		retval = security_task_setrlimit(tsk, resource, new_rlim);
+	if (!retval)
+		*old_rlim = *new_rlim;
 	task_unlock(tsk->group_leader);
 
 	if (retval || resource != RLIMIT_CPU)
-- 
1.7.1

[PATCH 07/11] rlimits: add rlimit64 structure

[Jiri Slaby]

Add a platform independent structure for resource limits to use with
a new prlimit64 syscall. This structure is the same which uses glibc
for 64-bit limits.

Also add corresponding infinity which is a 64-bit full of ones.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 include/linux/resource.h |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/include/linux/resource.h b/include/linux/resource.h
index cf8dc96..037aa7e 100644
--- a/include/linux/resource.h
+++ b/include/linux/resource.h
@@ -43,6 +43,13 @@ struct rlimit {
 	unsigned long	rlim_max;
 };
 
+#define RLIM64_INFINITY		(~0ULL)
+
+struct rlimit64 {
+	__u64 rlim_cur;
+	__u64 rlim_max;
+};
+
 #define	PRIO_MIN	(-20)
 #define	PRIO_MAX	20
 
-- 
1.7.1

[PATCH 08/11] rlimits: redo do_setrlimit to more generic do_prlimit

[Jiri Slaby]

It now allows also reading of limits. I.e. all read and writes will
later use this function.

It takes two parameters, new and old limits which can be both NULL.
If new is non-NULL, the value in it is set to rlimits.
If old is non-NULL, current rlimits are stored there.
If both are non-NULL, old are stored prior to setting the new ones,
atomically.
(Similar to sigaction.)

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 include/linux/resource.h |    4 +-
 kernel/sys.c             |   63 ++++++++++++++++++++++++++-------------------
 2 files changed, 38 insertions(+), 29 deletions(-)

diff --git a/include/linux/resource.h b/include/linux/resource.h
index 037aa7e..88d36f9 100644
--- a/include/linux/resource.h
+++ b/include/linux/resource.h
@@ -80,8 +80,8 @@ struct rlimit64 {
 struct task_struct;
 
 int getrusage(struct task_struct *p, int who, struct rusage __user *ru);
-int do_setrlimit(struct task_struct *tsk, unsigned int resource,
-		struct rlimit *new_rlim);
+int do_prlimit(struct task_struct *tsk, unsigned int resource,
+		struct rlimit *new_rlim, struct rlimit *old_rlim);
 
 #endif /* __KERNEL__ */
 
diff --git a/kernel/sys.c b/kernel/sys.c
index 9e9a3a7..7a453d2 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -1273,18 +1273,30 @@ SYSCALL_DEFINE2(old_getrlimit, unsigned int, resource,
 #endif
 
 /* make sure you are allowed to change @tsk limits before calling this */
-int do_setrlimit(struct task_struct *tsk, unsigned int resource,
-		struct rlimit *new_rlim)
+int do_prlimit(struct task_struct *tsk, unsigned int resource,
+		struct rlimit *new_rlim, struct rlimit *old_rlim)
 {
-	struct rlimit *old_rlim;
+	struct rlimit *rlim;
 	int retval = 0;
 
 	if (resource >= RLIM_NLIMITS)
 		return -EINVAL;
-	if (new_rlim->rlim_cur > new_rlim->rlim_max)
-		return -EINVAL;
-	if (resource == RLIMIT_NOFILE && new_rlim->rlim_max > sysctl_nr_open)
-		return -EPERM;
+	if (new_rlim) {
+		if (new_rlim->rlim_cur > new_rlim->rlim_max)
+			return -EINVAL;
+		if (resource == RLIMIT_NOFILE &&
+				new_rlim->rlim_max > sysctl_nr_open)
+			return -EPERM;
+		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;
+		}
+	}
 
 	/* protect tsk->signal and tsk->sighand from disappearing */
 	read_lock(&tasklist_lock);
@@ -1293,28 +1305,25 @@ int do_setrlimit(struct task_struct *tsk, unsigned int resource,
 		goto out;
 	}
 
-	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;
-	}
-
-	old_rlim = tsk->signal->rlim + resource;
+	rlim = tsk->signal->rlim + resource;
 	task_lock(tsk->group_leader);
-	if ((new_rlim->rlim_max > old_rlim->rlim_max) &&
-				!capable(CAP_SYS_RESOURCE))
-		retval = -EPERM;
-	if (!retval)
-		retval = security_task_setrlimit(tsk, resource, new_rlim);
-	if (!retval)
-		*old_rlim = *new_rlim;
+	if (new_rlim) {
+		if ((new_rlim->rlim_max > rlim->rlim_max) &&
+					!capable(CAP_SYS_RESOURCE))
+			retval = -EPERM;
+		if (!retval)
+			retval = security_task_setrlimit(tsk, resource,
+					new_rlim);
+	}
+	if (!retval) {
+		if (old_rlim)
+			*old_rlim = *rlim;
+		if (new_rlim)
+			*rlim = *new_rlim;
+	}
 	task_unlock(tsk->group_leader);
 
-	if (retval || resource != RLIMIT_CPU)
+	if (retval || !new_rlim || resource != RLIMIT_CPU)
 		goto out;
 
 	/*
@@ -1338,7 +1347,7 @@ SYSCALL_DEFINE2(setrlimit, unsigned int, resource, struct rlimit __user *, rlim)
 
 	if (copy_from_user(&new_rlim, rlim, sizeof(*rlim)))
 		return -EFAULT;
-	return do_setrlimit(current, resource, &new_rlim);
+	return do_prlimit(current, resource, &new_rlim, NULL);
 }
 
 /*
-- 
1.7.1

[PATCH 09/11] rlimits: switch getrlimit to do_prlimit

[Jiri Slaby]

From: Jiri Slaby <jirislaby@gmail.com>

After we added more generic do_prlimit, switch sys_getrlimit to that.
We now have all non-compat rlimit handling at one place.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 kernel/sys.c |   17 ++++++++---------
 1 files changed, 8 insertions(+), 9 deletions(-)

diff --git a/kernel/sys.c b/kernel/sys.c
index 7a453d2..0f8034f 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -1236,15 +1236,14 @@ SYSCALL_DEFINE2(setdomainname, char __user *, name, int, len)
 
 SYSCALL_DEFINE2(getrlimit, unsigned int, resource, struct rlimit __user *, rlim)
 {
-	if (resource >= RLIM_NLIMITS)
-		return -EINVAL;
-	else {
-		struct rlimit value;
-		task_lock(current->group_leader);
-		value = current->signal->rlim[resource];
-		task_unlock(current->group_leader);
-		return copy_to_user(rlim, &value, sizeof(*rlim)) ? -EFAULT : 0;
-	}
+	struct rlimit value;
+	int ret;
+
+	ret = do_prlimit(current, resource, NULL, &value);
+	if (!ret)
+		ret = copy_to_user(rlim, &value, sizeof(*rlim)) ? -EFAULT : 0;
+
+	return ret;
 }
 
 #ifdef __ARCH_WANT_SYS_OLD_GETRLIMIT
-- 
1.7.1

[PATCH v2 09/11] rlimits: switch more rlimit syscalls to do_prlimit

[Jiri Slaby]

From: Jiri Slaby <jirislaby@gmail.com>

This is the correct one, I forgot to re-run format-patch.
--

After we added more generic do_prlimit, switch sys_getrlimit to that.
Also switch compat handling, so we can get rid of ugly __user casts
and avoid setting process' address limit to kernel data and back.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 kernel/compat.c |   16 +++-------------
 kernel/sys.c    |   17 ++++++++---------
 2 files changed, 11 insertions(+), 22 deletions(-)

diff --git a/kernel/compat.c b/kernel/compat.c
index 7f40e92..199b345 100644
--- a/kernel/compat.c
+++ b/kernel/compat.c
@@ -280,10 +280,6 @@ asmlinkage long compat_sys_setrlimit(unsigned int resource,
 {
 	struct rlimit r;
 	int ret;
-	mm_segment_t old_fs = get_fs ();
-
-	if (resource >= RLIM_NLIMITS)
-		return -EINVAL;
 
 	if (!access_ok(VERIFY_READ, rlim, sizeof(*rlim)) ||
 	    __get_user(r.rlim_cur, &rlim->rlim_cur) ||
@@ -294,10 +290,7 @@ asmlinkage long compat_sys_setrlimit(unsigned int resource,
 		r.rlim_cur = RLIM_INFINITY;
 	if (r.rlim_max == COMPAT_RLIM_INFINITY)
 		r.rlim_max = RLIM_INFINITY;
-	set_fs(KERNEL_DS);
-	ret = sys_setrlimit(resource, (struct rlimit __user *) &r);
-	set_fs(old_fs);
-	return ret;
+	return do_prlimit(current, resource, &r, NULL);
 }
 
 #ifdef COMPAT_RLIM_OLD_INFINITY
@@ -329,16 +322,13 @@ asmlinkage long compat_sys_old_getrlimit(unsigned int resource,
 
 #endif
 
-asmlinkage long compat_sys_getrlimit (unsigned int resource,
+asmlinkage long compat_sys_getrlimit(unsigned int resource,
 		struct compat_rlimit __user *rlim)
 {
 	struct rlimit r;
 	int ret;
-	mm_segment_t old_fs = get_fs();
 
-	set_fs(KERNEL_DS);
-	ret = sys_getrlimit(resource, (struct rlimit __user *) &r);
-	set_fs(old_fs);
+	ret = do_prlimit(current, resource, NULL, &r);
 	if (!ret) {
 		if (r.rlim_cur > COMPAT_RLIM_INFINITY)
 			r.rlim_cur = COMPAT_RLIM_INFINITY;
diff --git a/kernel/sys.c b/kernel/sys.c
index 7a453d2..0f8034f 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -1236,15 +1236,14 @@ SYSCALL_DEFINE2(setdomainname, char __user *, name, int, len)
 
 SYSCALL_DEFINE2(getrlimit, unsigned int, resource, struct rlimit __user *, rlim)
 {
-	if (resource >= RLIM_NLIMITS)
-		return -EINVAL;
-	else {
-		struct rlimit value;
-		task_lock(current->group_leader);
-		value = current->signal->rlim[resource];
-		task_unlock(current->group_leader);
-		return copy_to_user(rlim, &value, sizeof(*rlim)) ? -EFAULT : 0;
-	}
+	struct rlimit value;
+	int ret;
+
+	ret = do_prlimit(current, resource, NULL, &value);
+	if (!ret)
+		ret = copy_to_user(rlim, &value, sizeof(*rlim)) ? -EFAULT : 0;
+
+	return ret;
 }
 
 #ifdef __ARCH_WANT_SYS_OLD_GETRLIMIT
-- 
1.7.1

Re: [PATCH v2 09/11] rlimits: switch more rlimit syscalls to do_prlimit

[Jiri Slaby]

On 05/07/2010 11:02 AM, Jiri Slaby wrote:
> From: Jiri Slaby <jirislaby@gmail.com>
> 
> This is the correct one, I forgot to re-run format-patch.

Ah, no I didn't. There are two 09/11 because it generates the latter
with a different name.

So "rlimits: switch getrlimit to do_prlimit" is old and wrong.

-- 
js

[PATCH 09/11] rlimits: switch more rlimit syscalls to do_prlimit

[Jiri Slaby]

From: Jiri Slaby <jirislaby@gmail.com>

After we added more generic do_prlimit, switch sys_getrlimit to that.
Also switch compat handling, so we can get rid of ugly __user casts
and avoid setting process' address limit to kernel data and back.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 kernel/compat.c |   16 +++-------------
 kernel/sys.c    |   17 ++++++++---------
 2 files changed, 11 insertions(+), 22 deletions(-)

diff --git a/kernel/compat.c b/kernel/compat.c
index 7f40e92..199b345 100644
--- a/kernel/compat.c
+++ b/kernel/compat.c
@@ -280,10 +280,6 @@ asmlinkage long compat_sys_setrlimit(unsigned int resource,
 {
 	struct rlimit r;
 	int ret;
-	mm_segment_t old_fs = get_fs ();
-
-	if (resource >= RLIM_NLIMITS)
-		return -EINVAL;
 
 	if (!access_ok(VERIFY_READ, rlim, sizeof(*rlim)) ||
 	    __get_user(r.rlim_cur, &rlim->rlim_cur) ||
@@ -294,10 +290,7 @@ asmlinkage long compat_sys_setrlimit(unsigned int resource,
 		r.rlim_cur = RLIM_INFINITY;
 	if (r.rlim_max == COMPAT_RLIM_INFINITY)
 		r.rlim_max = RLIM_INFINITY;
-	set_fs(KERNEL_DS);
-	ret = sys_setrlimit(resource, (struct rlimit __user *) &r);
-	set_fs(old_fs);
-	return ret;
+	return do_prlimit(current, resource, &r, NULL);
 }
 
 #ifdef COMPAT_RLIM_OLD_INFINITY
@@ -329,16 +322,13 @@ asmlinkage long compat_sys_old_getrlimit(unsigned int resource,
 
 #endif
 
-asmlinkage long compat_sys_getrlimit (unsigned int resource,
+asmlinkage long compat_sys_getrlimit(unsigned int resource,
 		struct compat_rlimit __user *rlim)
 {
 	struct rlimit r;
 	int ret;
-	mm_segment_t old_fs = get_fs();
 
-	set_fs(KERNEL_DS);
-	ret = sys_getrlimit(resource, (struct rlimit __user *) &r);
-	set_fs(old_fs);
+	ret = do_prlimit(current, resource, NULL, &r);
 	if (!ret) {
 		if (r.rlim_cur > COMPAT_RLIM_INFINITY)
 			r.rlim_cur = COMPAT_RLIM_INFINITY;
diff --git a/kernel/sys.c b/kernel/sys.c
index 7a453d2..0f8034f 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -1236,15 +1236,14 @@ SYSCALL_DEFINE2(setdomainname, char __user *, name, int, len)
 
 SYSCALL_DEFINE2(getrlimit, unsigned int, resource, struct rlimit __user *, rlim)
 {
-	if (resource >= RLIM_NLIMITS)
-		return -EINVAL;
-	else {
-		struct rlimit value;
-		task_lock(current->group_leader);
-		value = current->signal->rlim[resource];
-		task_unlock(current->group_leader);
-		return copy_to_user(rlim, &value, sizeof(*rlim)) ? -EFAULT : 0;
-	}
+	struct rlimit value;
+	int ret;
+
+	ret = do_prlimit(current, resource, NULL, &value);
+	if (!ret)
+		ret = copy_to_user(rlim, &value, sizeof(*rlim)) ? -EFAULT : 0;
+
+	return ret;
 }
 
 #ifdef __ARCH_WANT_SYS_OLD_GETRLIMIT
-- 
1.7.1

[PATCH 10/11] rlimits: implement prlimit64 syscall

[Jiri Slaby]

This patch adds the code to support the sys_prlimit64 syscall which
modifies-and-return the rlim values of a selected process. pid 0 means
current process.

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 them now.

The limitation is that we 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 maximal value there.

And since internally we hold limits in struct rlimit, we introduce
converters used before and after do_prlimit call in sys_prlimit64.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 include/linux/syscalls.h |    4 ++
 kernel/sys.c             |   99 ++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 103 insertions(+), 0 deletions(-)

diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
index f93a5c4..3f0e3ab 100644
--- a/include/linux/syscalls.h
+++ b/include/linux/syscalls.h
@@ -35,6 +35,7 @@ struct oldold_utsname;
 struct old_utsname;
 struct pollfd;
 struct rlimit;
+struct rlimit64;
 struct rusage;
 struct sched_param;
 struct sel_arg_struct;
@@ -667,6 +668,9 @@ asmlinkage long sys_old_getrlimit(unsigned int resource, struct rlimit __user *r
 #endif
 asmlinkage long sys_setrlimit(unsigned int resource,
 				struct rlimit __user *rlim);
+asmlinkage long sys_prlimit64(pid_t pid, unsigned int resource,
+				const struct rlimit64 __user *new_rlim,
+				struct rlimit64 __user *old_rlim);
 asmlinkage long sys_getrusage(int who, struct rusage __user *ru);
 asmlinkage long sys_umask(int mask);
 
diff --git a/kernel/sys.c b/kernel/sys.c
index 0f8034f..d7fcd4a 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -1271,6 +1271,39 @@ SYSCALL_DEFINE2(old_getrlimit, unsigned int, resource,
 
 #endif
 
+static inline bool rlim64_is_infinity(__u64 rlim64)
+{
+#if BITS_PER_LONG < 64
+	return rlim64 >= ULONG_MAX;
+#else
+	return rlim64 == RLIM64_INFINITY;
+#endif
+}
+
+static void rlim_to_rlim64(const struct rlimit *rlim, struct rlimit64 *rlim64)
+{
+	if (rlim->rlim_cur == RLIM_INFINITY)
+		rlim64->rlim_cur = RLIM64_INFINITY;
+	else
+		rlim64->rlim_cur = rlim->rlim_cur;
+	if (rlim->rlim_max == RLIM_INFINITY)
+		rlim64->rlim_max = RLIM64_INFINITY;
+	else
+		rlim64->rlim_max = rlim->rlim_max;
+}
+
+static void rlim64_to_rlim(const struct rlimit64 *rlim64, struct rlimit *rlim)
+{
+	if (rlim64_is_infinity(rlim64->rlim_cur))
+		rlim->rlim_cur = RLIM_INFINITY;
+	else
+		rlim->rlim_cur = (unsigned long)rlim64->rlim_cur;
+	if (rlim64_is_infinity(rlim64->rlim_max))
+		rlim->rlim_max = RLIM_INFINITY;
+	else
+		rlim->rlim_max = (unsigned long)rlim64->rlim_max;
+}
+
 /* make sure you are allowed to change @tsk limits before calling this */
 int do_prlimit(struct task_struct *tsk, unsigned int resource,
 		struct rlimit *new_rlim, struct rlimit *old_rlim)
@@ -1340,6 +1373,72 @@ out:
 	return retval;
 }
 
+/* rcu lock must be held */
+static int check_prlimit_permission(struct task_struct *task)
+{
+	const struct cred *cred = current_cred(), *tcred;
+
+	tcred = __task_cred(task);
+	if ((cred->uid != tcred->euid ||
+	     cred->uid != tcred->suid ||
+	     cred->uid != tcred->uid  ||
+	     cred->gid != tcred->egid ||
+	     cred->gid != tcred->sgid ||
+	     cred->gid != tcred->gid) &&
+	     !capable(CAP_SYS_RESOURCE)) {
+		return -EPERM;
+	}
+
+	return 0;
+}
+
+SYSCALL_DEFINE4(prlimit64, pid_t, pid, unsigned int, resource,
+		const struct rlimit64 __user *, new_rlim,
+		struct rlimit64 __user *, old_rlim)
+{
+	struct rlimit64 old64, new64;
+	struct rlimit old, new;
+	struct task_struct *tsk;
+	int ret;
+
+	if (new_rlim) {
+		if (copy_from_user(&new64, new_rlim, sizeof(new64)))
+			return -EFAULT;
+		rlim64_to_rlim(&new64, &new);
+	}
+
+	/* we don't want to fail after do_rlimit */
+	if (old_rlim && !access_ok(VERIFY_WRITE, old_rlim, sizeof(old64)))
+		return -EFAULT;
+
+	rcu_read_lock();
+	tsk = pid ? find_task_by_vpid(pid) : current;
+	if (!tsk) {
+		rcu_read_unlock();
+		return -ESRCH;
+	}
+	ret = check_prlimit_permission(tsk);
+	if (ret) {
+		rcu_read_unlock();
+		return ret;
+	}
+	get_task_struct(tsk);
+	rcu_read_unlock();
+
+	ret = do_prlimit(tsk, resource, new_rlim ? &new : NULL,
+			old_rlim ? &old : NULL);
+
+	if (!ret && old_rlim) {
+		rlim_to_rlim64(&old, &old64);
+		if (WARN_ON_ONCE(__copy_to_user(old_rlim, &old64,
+						sizeof(old64))))
+			ret = -EFAULT;
+	}
+
+	put_task_struct(tsk);
+	return ret;
+}
+
 SYSCALL_DEFINE2(setrlimit, unsigned int, resource, struct rlimit __user *, rlim)
 {
 	struct rlimit new_rlim;
-- 
1.7.1

[PATCH 11/11] unistd: add __NR_prlimit64 syscall numbers

[Jiri Slaby]

Add __NR_prlimit64 syscall numbers to asm-generic. Add them also to
asm-x86, both 32 and 64-bit.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: "H. Peter Anvin" <hpa@zytor.com>
---
 arch/x86/ia32/ia32entry.S          |    1 +
 arch/x86/include/asm/unistd_32.h   |    3 ++-
 arch/x86/include/asm/unistd_64.h   |    2 ++
 arch/x86/kernel/syscall_table_32.S |    1 +
 include/asm-generic/unistd.h       |    4 +++-
 5 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/arch/x86/ia32/ia32entry.S b/arch/x86/ia32/ia32entry.S
index 17cf65c..b9472ec 100644
--- a/arch/x86/ia32/ia32entry.S
+++ b/arch/x86/ia32/ia32entry.S
@@ -844,4 +844,5 @@ ia32_sys_call_table:
 	.quad compat_sys_recvmmsg
 	.quad sys_fanotify_init
 	.quad sys32_fanotify_mark
+	.quad sys_prlimit64			/* 340 */
 ia32_syscall_end:
diff --git a/arch/x86/include/asm/unistd_32.h b/arch/x86/include/asm/unistd_32.h
index 80b799c..b766a5e 100644
--- a/arch/x86/include/asm/unistd_32.h
+++ b/arch/x86/include/asm/unistd_32.h
@@ -345,10 +345,11 @@
 #define __NR_recvmmsg		337
 #define __NR_fanotify_init	338
 #define __NR_fanotify_mark	339
+#define __NR_prlimit64		340
 
 #ifdef __KERNEL__
 
-#define NR_syscalls 340
+#define NR_syscalls 341
 
 #define __ARCH_WANT_IPC_PARSE_VERSION
 #define __ARCH_WANT_OLD_READDIR
diff --git a/arch/x86/include/asm/unistd_64.h b/arch/x86/include/asm/unistd_64.h
index 5b7b1d5..363e9b8 100644
--- a/arch/x86/include/asm/unistd_64.h
+++ b/arch/x86/include/asm/unistd_64.h
@@ -667,6 +667,8 @@ __SYSCALL(__NR_recvmmsg, sys_recvmmsg)
 __SYSCALL(__NR_fanotify_init, sys_fanotify_init)
 #define __NR_fanotify_mark			301
 __SYSCALL(__NR_fanotify_mark, sys_fanotify_mark)
+#define __NR_prlimit64				302
+__SYSCALL(__NR_prlimit64, sys_prlimit64)
 
 #ifndef __NO_STUBS
 #define __ARCH_WANT_OLD_READDIR
diff --git a/arch/x86/kernel/syscall_table_32.S b/arch/x86/kernel/syscall_table_32.S
index 07ad5eb..b35786d 100644
--- a/arch/x86/kernel/syscall_table_32.S
+++ b/arch/x86/kernel/syscall_table_32.S
@@ -339,3 +339,4 @@ ENTRY(sys_call_table)
 	.long sys_recvmmsg
 	.long sys_fanotify_init
 	.long sys_fanotify_mark
+	.long sys_prlimit64		/* 340 */
diff --git a/include/asm-generic/unistd.h b/include/asm-generic/unistd.h
index 6a0b30f..0dfd517 100644
--- a/include/asm-generic/unistd.h
+++ b/include/asm-generic/unistd.h
@@ -626,9 +626,11 @@ __SYSCALL(__NR_perf_event_open, sys_perf_event_open)
 __SYSCALL(__NR_accept4, sys_accept4)
 #define __NR_recvmmsg 243
 __SYSCALL(__NR_recvmmsg, sys_recvmmsg)
+#define __NR_prlimit64 244
+__SYSCALL(__NR_prlimit64, sys_prlimit64)
 
 #undef __NR_syscalls
-#define __NR_syscalls 244
+#define __NR_syscalls 245
 
 /*
  * All syscalls below here should go away really,
-- 
1.7.1

Re: Resource limits interface proposal [was: pull request for writable limits]

[Jiri Slaby]

On 05/05/2010 05:08 PM, Linus Torvalds wrote:
> On Wed, 5 May 2010, Jiri Slaby wrote:
>> The drawback is when a 32-bit user passes down a value >= (1 << 32),
>> EINVAL shall occur.
> 
> I'd almost prefer to just turn them into RLIMIT_MAX. If somebody asks for 
> a really huge limit that is bigger than the max we already have, doesn't 
> RLIMIT_MAX sound like the right thing?

Yes, silently setting the highest possible value (INFINITY) is OK too
(as we cannot do better anyway).

>> Just a side note, we cannot use the rlimit64 name which is already
>> reserved in glibc headers for limits handling.
> 
> What does the glibc 'struct rlimit64' look like? It's the structure name 
> that matters, since the system call name would presumably be 'prlimit64()' 
> due to the pid thing.
> 
> And if the glibc rlimit64 matches what we would use, I think we can decide 
> to just re-use it.

With glibc-2.11.1 which I have includes from:
#ifdef __USE_LARGEFILE64
struct rlimit64
  {
    /* The current (soft) limit.  */
    rlim64_t rlim_cur;
    /* The hard limit.  */
    rlim64_t rlim_max;
 };
#endif

where rlim64_t expands to __u_quad_t which is
#if __WORDSIZE == 64
typedef unsigned long int __u_quad_t;
#elif defined __GLIBC_HAVE_LONG_LONG
__extension__ typedef unsigned long long int __u_quad_t;
#endif

so something like our u64. The structure is the same to what we are
about to use. If nobody objects?

-- 
js

Re: [git pull] pull request for writable limits for 2.6.34-rc0

[Jiri Slaby]

On 03/20/2010 08:20 PM, Linus Torvalds wrote:
> I'd also like to hear more about actual uses. Does _any_ other Unix-like 
> system actually implement this writable limits thing?

I'm currently not aware of any. Will do some research if that matters.

> Who is asking for  it? 

The scenario I described in the pull request is true, SAP requested that.

thanks,
-- 
js