MIPS: Add wrappers to get/setrlimit64 to fix RLIM64_INFINITY constant

RLIM64_INFINITY was supposed to be a glibc convention rather than
anything seen by the kernel, but it ended being passed to the kernel
through the prlimit64 syscall.  On O32 and N32 ABIs, we therefore
end-up with different values on the userland and kernel side:

* On the kernel side, the value is defined for all architectures as
  include/uapi/linux/resource.h:

  #define RLIM64_INFINITY           (~0ULL)

* On the GNU libc side, the value is defined in
  ports/sysdeps/unix/sysv/linux/mips/bits/resource.h:

  For the O32 and N32 ABI:
  #  define RLIM64_INFINITY 0x7fffffffffffffffULL

  and for the N64 ABI:
  #  define RLIM64_INFINITY 0xffffffffffffffffUL

This was not a problem until the prlimit64 syscall was wired in the
2.6.36 kernel. Given the GLIBC uses the prlimit64 syscall to implement
getrlimit64 and setrlimit64, pam_limits.so is setting the limits to
a very big value instead of infinity. As a normal user process can
later only decrease the value and not increase it, it will later get
and EPERM error when trying to set the value to infinity with setrlimit.

The GLIBC has this constant for more than 7 years, and as it is defined
in a header file, it means a lot of binaries are in the wild. This patch
fixes that by adding a wrapper to fix the value passed to or received
from the kernel, before or after calling the prlimit64 syscall.

0 files changed, 0 insertions, 0 deletions