[Top] [All Lists]

Re: prlimit64: inconsistencies between kernel and userland

To: David Miller <>
Subject: Re: prlimit64: inconsistencies between kernel and userland
From: "Joseph S. Myers" <>
Date: Tue, 5 Nov 2013 01:04:45 +0000
Cc: <>, <>, <>
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, David Miller wrote:

> From: Aurelien Jarno <>
> 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 

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.

Joseph S. Myers

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