prlimit64: inconsistencies between kernel and userland
Rich Felker
dalias@aerifal.cx
Tue Nov 5 01:22:00 GMT 2013
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 <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.
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...
Rich
More information about the Libc-alpha
mailing list