[Top] [All Lists]

Re: prlimit64: inconsistencies between kernel and userland

To: Rich Felker <>
Subject: Re: prlimit64: inconsistencies between kernel and userland
From: "Joseph S. Myers" <>
Date: Tue, 5 Nov 2013 15:13:23 +0000
Cc: David Miller <>, <>, <>, <>
In-reply-to: <>
List-archive: <>
List-help: <>
List-id: linux-mips <>
List-owner: <>
List-post: <>
List-software: Ecartis version 1.0.0
List-subscribe: <>
List-unsubscribe: <>
Original-recipient: rfc822;
References: <> <> <> <> <>
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 
> > <>, 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

<Prev in Thread] Current Thread [Next in Thread>