This is the mail archive of the
mailing list for the glibc project.
Re: prlimit64: inconsistencies between kernel and userland
- From: David Daney <ddaney dot cavm at gmail dot com>
- To: Rich Felker <dalias at aerifal dot cx>, "Pinski, Andrew" <Andrew dot Pinski at caviumnetworks dot com>
- Cc: Andreas Barth <aba at ayous dot org>, "Joseph S. Myers" <joseph at codesourcery dot com>, David Miller <davem at davemloft dot net>, aurelien at aurel32 dot net, linux-mips at linux-mips dot org, libc-alpha at sourceware dot org
- Date: Tue, 05 Nov 2013 10:43:28 -0800
- Subject: Re: prlimit64: inconsistencies between kernel and userland
- Authentication-results: sourceware.org; auth=none
- References: <20130628133835 dot GA21839 at hall dot aurel32 dot net> <20131104213756 dot GD18700 at hall dot aurel32 dot net> <20131104 dot 194519 dot 1657797548878784116 dot davem at davemloft dot net> <Pine dot LNX dot 4 dot 64 dot 1311050058580 dot 9883 at digraph dot polyomino dot org dot uk> <20131105012203 dot GA24286 at brightrain dot aerifal dot cx> <20131105085859 dot GE28240 at mails dot so dot argh dot org> <20131105183732 dot GB24286 at brightrain dot aerifal dot cx>
On 11/05/2013 10:37 AM, Rich Felker wrote:
On Tue, Nov 05, 2013 at 09:58:59AM +0100, Andreas Barth wrote:
* Rich Felker (email@example.com) [131105 02:22]:
On Tue, Nov 05, 2013 at 01:04:45AM +0000, Joseph S. Myers wrote:
On Mon, 4 Nov 2013, David Miller wrote:
From: Aurelien Jarno <firstname.lastname@example.org>
Date: Mon, 4 Nov 2013 22:37:56 +0100
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
I had the same exact problem on sparc several years ago, I simply fixed
the glibc header value, it's the only way to fix this.
Yes, that means you then have to recompile applications and libraries
that reference this value.
Surely you can create new symbol versions for getrlimit64 and setrlimit64,
with the old versions just using the 32-bit syscalls (or otherwise
translating between conventions, but using the 32-bit syscalls is the
simplest approach)? I see no need to break compatibility with existing
As I noted in
<https://sourceware.org/ml/libc-ports/2006-05/msg00020.html>, at that time
the value of RLIM64_INFINITY for o32/n32 was purely a glibc convention the
kernel didn't see at all. It's only with the use of newer syscalls that
this glibc convention is any sort of problem.
Why not just make them convert any value >= 0x7fffffffffffffff to
infinity before making the syscall? There's certainly no meaningful
use for finite values in that range...
Or just replace 0x7fffffffffffffff by kernels infinity - and still
fixing glibc, because the same value as the kernel should be the right
answer long term.
Oh, I agree that change should be made too. I just suggested an
additional fix that could be made to avoid the need for recompiling
and replacing old binaries.
Why can't the default version of the functions in question be fixed so
that they do the right thing? That way you wouldn't have to rebuild old
Do we really need new function versions at all?
And FWIW: I think Pinski might be looking at fixing this.