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@xxxxxxxxxxx http://www.aurel32.net
Attachment:
signature.asc
Description: Digital signature
