This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: prlimit64: inconsistencies between kernel and userland
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: David Miller <davem at davemloft dot net>
- Cc: <aurelien at aurel32 dot net>, <linux-mips at linux-mips dot org>, <libc-alpha at sourceware dot org>
- Date: Tue, 5 Nov 2013 01:04:45 +0000
- 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>
On Mon, 4 Nov 2013, David Miller wrote:
> From: Aurelien Jarno <aurelien@aurel32.net>
> 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
> > opinion.
>
> 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
binaries.
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.
--
Joseph S. Myers
joseph@codesourcery.com