linux-mips
[Top] [All Lists]

prlimit64: inconsistencies between kernel and userland

To: linux-mips@linux-mips.org
Subject: prlimit64: inconsistencies between kernel and userland
From: Aurelien Jarno <aurelien@aurel32.net>
Date: Fri, 28 Jun 2013 15:38:35 +0200
List-archive: <http://www.linux-mips.org/archives/linux-mips/>
List-help: <mailto:ecartis@linux-mips.org?Subject=help>
List-id: linux-mips <linux-mips.eddie.linux-mips.org>
List-owner: <mailto:ralf@linux-mips.org>
List-post: <mailto:linux-mips@linux-mips.org>
List-software: Ecartis version 1.0.0
List-subscribe: <mailto:ecartis@linux-mips.org?subject=subscribe%20linux-mips>
List-unsubscribe: <mailto:ecartis@linux-mips.org?subject=unsubscribe%20linux-mips>
Original-recipient: rfc822;linux-mips@linux-mips.org
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.21 (2010-09-15)
Hi,

There is an inconsistency in the definition of RLIM64_INFINITY between
kernel and userland for the O32 and N32 ABI:

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. Since then, on a 64-bit kernel and an O32 or N32
userland, but not on a 32-bit kernel, this causes some issues for
example it's not possible to set "ulimit -c unlimited" using dash as a
non-priviledged user.

This is due to the fact that when available the glibc uses the prlimit64
syscall to implement setrlimit64, which is called from called from
pam_limits.so. Instead of setting the limit to infinity (according to
the userland), it is set to a very big value but still lower than
infinity (according to the kernel). When later the setrlimit syscall is
used to set the value to infinity, it gets an EPERM value as the kernel
consider that as an increase of the limit (from a big value to
infinity).

I don't know where the issue should be fixed. The GNU libc has this
value for more than 7 years, and as it is defined in a header file, it
means a lot of binaries are broken when used with a 2.6.36+ kernel.
Fixing that on the kernel side means that MIPS would have a different
value than other architectures.

How do you think the issue should be fixed?

Regards,
Aurelien

-- 
Aurelien Jarno                          GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net

Attachment: signature.asc
Description: Digital signature

<Prev in Thread] Current Thread [Next in Thread>
  • prlimit64: inconsistencies between kernel and userland, Aurelien Jarno <=