On 11/05/2013 10:37 AM, Rich Felker wrote:
On Tue, Nov 05, 2013 at 09:58:59AM +0100, Andreas Barth wrote:
* Rich Felker (dalias@xxxxxxxxxx) [131105 02:22]:
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@xxxxxxxxxxx>
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...
Or just replace 0x7fffffffffffffff by kernels infinity - and still
fixing glibc, because the same value as the kernel should be the right
answer long term.
Oh, I agree that change should be made too. I just suggested an
additional fix that could be made to avoid the need for recompiling
and replacing old binaries.
Why can't the default version of the functions in question be fixed so
that they do the right thing? That way you wouldn't have to rebuild old
binaries.
Do we really need new function versions at all?
And FWIW: I think Pinski might be looking at fixing this.
David Daney
