Re: prlimit64: inconsistencies between kernel and userland

[David Daney <ddaney.cavm@gmail.com>]

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@aerifal.cx) [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@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...
>>
>> 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