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. Rich
