This is the mail archive of the
mailing list for the glibc project.
Re: prlimit64: inconsistencies between kernel and userland
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Rich Felker <dalias at aerifal dot cx>
- Cc: 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, 5 Nov 2013 15:13:23 +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> <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>
On Mon, 4 Nov 2013, Rich Felker wrote:
> > 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.
> 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...
It might be possible to do such a conversion in setrlimit64 - I'm not sure
offhand if such a conversion for large finite values is valid, and a new
symbol version is certainly the more conservative option - but getrlimit64
in existing binaries should return results using the existing
RLIM64_INFINITY, in case binaries compare against that, so if you change
the header value to match the kernel I don't think you can avoid the new
symbol version for getrlimit64, and versioning both together seems safer.
Joseph S. Myers