linux-mips
[Top] [All Lists]

Re: prlimit64: inconsistencies between kernel and userland

To: linux-mips@linux-mips.org
Subject: Re: prlimit64: inconsistencies between kernel and userland
From: Aurelien Jarno <aurelien@aurel32.net>
Date: Mon, 4 Nov 2013 22:37:56 +0100
Cc: libc-alpha@sourceware.org
In-reply-to: <20130628133835.GA21839@hall.aurel32.net>
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
References: <20130628133835.GA21839@hall.aurel32.net>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.21 (2010-09-15)
Any news about this issue? It really starts to causes a lot of issues in
Debian. I have added a Cc: to libc people so that we can also hear their
opinion.

Thanks,
Aurelien

On Fri, Jun 28, 2013 at 03:38:35PM +0200, Aurelien Jarno wrote:
> 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



-- 
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>