prlimit64: inconsistencies between kernel and userland

prlimit64: inconsistencies between kernel and userland

[Aurelien Jarno]

[-- Attachment #1: Type: text/plain, Size: 1847 bytes --]

Hi,

There is an inconsistency in the definition of RLIM64_INFINITY between
kernel and userland for the O32 and N32 ABI:

On the kernel side, the value is defined for all architectures as
include/uapi/linux/resource.h:

| #define RLIM64_INFINITY           (~0ULL)

On the GNU libc side, the value is defined in
ports/sysdeps/unix/sysv/linux/mips/bits/resource.h:

For the O32 and N32 ABI:

| #  define RLIM64_INFINITY 0x7fffffffffffffffULL

and for the N64 ABI:

| #  define RLIM64_INFINITY 0xffffffffffffffffUL

This was not a problem until the prlimit64 syscall was wired in the
2.6.36 kernel. Since then, on a 64-bit kernel and an O32 or N32
userland, but not on a 32-bit kernel, this causes some issues for
example it's not possible to set "ulimit -c unlimited" using dash as a
non-priviledged user.

This is due to the fact that when available the glibc uses the prlimit64
syscall to implement setrlimit64, which is called from called from
pam_limits.so. Instead of setting the limit to infinity (according to
the userland), it is set to a very big value but still lower than
infinity (according to the kernel). When later the setrlimit syscall is
used to set the value to infinity, it gets an EPERM value as the kernel
consider that as an increase of the limit (from a big value to
infinity).

I don't know where the issue should be fixed. The GNU libc has this
value for more than 7 years, and as it is defined in a header file, it
means a lot of binaries are broken when used with a 2.6.36+ kernel.
Fixing that on the kernel side means that MIPS would have a different
value than other architectures.

How do you think the issue should be fixed?

Regards,
Aurelien

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: prlimit64: inconsistencies between kernel and userland

[Aurelien Jarno]

[-- Attachment #1: Type: text/plain, Size: 2325 bytes --]

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.

Thanks,
Aurelien

On Fri, Jun 28, 2013 at 03:38:35PM +0200, Aurelien Jarno wrote:
> Hi,
> 
> There is an inconsistency in the definition of RLIM64_INFINITY between
> kernel and userland for the O32 and N32 ABI:
> 
> On the kernel side, the value is defined for all architectures as
> include/uapi/linux/resource.h:
> 
> | #define RLIM64_INFINITY           (~0ULL)
> 
> On the GNU libc side, the value is defined in
> ports/sysdeps/unix/sysv/linux/mips/bits/resource.h:
> 
> For the O32 and N32 ABI:
> 
> | #  define RLIM64_INFINITY 0x7fffffffffffffffULL
> 
> and for the N64 ABI:
> 
> | #  define RLIM64_INFINITY 0xffffffffffffffffUL
> 
> This was not a problem until the prlimit64 syscall was wired in the
> 2.6.36 kernel. Since then, on a 64-bit kernel and an O32 or N32
> userland, but not on a 32-bit kernel, this causes some issues for
> example it's not possible to set "ulimit -c unlimited" using dash as a
> non-priviledged user.
> 
> This is due to the fact that when available the glibc uses the prlimit64
> syscall to implement setrlimit64, which is called from called from
> pam_limits.so. Instead of setting the limit to infinity (according to
> the userland), it is set to a very big value but still lower than
> infinity (according to the kernel). When later the setrlimit syscall is
> used to set the value to infinity, it gets an EPERM value as the kernel
> consider that as an increase of the limit (from a big value to
> infinity).
> 
> I don't know where the issue should be fixed. The GNU libc has this
> value for more than 7 years, and as it is defined in a header file, it
> means a lot of binaries are broken when used with a 2.6.36+ kernel.
> Fixing that on the kernel side means that MIPS would have a different
> value than other architectures.
> 
> How do you think the issue should be fixed?
> 
> Regards,
> Aurelien
> 
> -- 
> Aurelien Jarno	                        GPG: 1024D/F1BCDB73
> aurelien@aurel32.net                 http://www.aurel32.net



-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: prlimit64: inconsistencies between kernel and userland

[David Miller]

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.

Re: prlimit64: inconsistencies between kernel and userland

[Joseph S. Myers]

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.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: prlimit64: inconsistencies between kernel and userland

[Joseph S. Myers]

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.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: prlimit64: inconsistencies between kernel and userland

[Rich Felker]

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

Re: prlimit64: inconsistencies between kernel and userland

[Andreas Barth]

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


Andi

Re: prlimit64: inconsistencies between kernel and userland

[Rich Felker]

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.

Rich

Re: prlimit64: inconsistencies between kernel and userland

[David Daney]

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

Re: prlimit64: inconsistencies between kernel and userland

[Joseph S. Myers]

On Tue, 5 Nov 2013, David Daney wrote:

> 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?

If we change RLIM64_INFINITY to match the kernel, then the right thing for 
at least getrlimit64 depends on whether it's an old or new binary (for old 
binaries it should return the old value of RLIM64_INFINITY and for new 
ones it should return the new value).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: prlimit64: inconsistencies between kernel and userland

[Joseph S. Myers]

On Tue, 5 Nov 2013, David Daney wrote:

> 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?

If we change RLIM64_INFINITY to match the kernel, then the right thing for 
at least getrlimit64 depends on whether it's an old or new binary (for old 
binaries it should return the old value of RLIM64_INFINITY and for new 
ones it should return the new value).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: prlimit64: inconsistencies between kernel and userland

[Rich Felker]

On Tue, Nov 05, 2013 at 10:36:24PM +0000, Joseph S. Myers wrote:
> On Tue, 5 Nov 2013, David Daney wrote:
> 
> > 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?
> 
> If we change RLIM64_INFINITY to match the kernel, then the right thing for 
> at least getrlimit64 depends on whether it's an old or new binary (for old 
> binaries it should return the old value of RLIM64_INFINITY and for new 
> ones it should return the new value).

BTW, what happens on a distro where -dev packages are separate and the
user compiles with old headers (not having upgraded the dev package)
but new libc.so? :-)

Rich

Re: prlimit64: inconsistencies between kernel and userland

[Joseph S. Myers]

On Tue, 5 Nov 2013, Rich Felker wrote:

> On Tue, Nov 05, 2013 at 10:36:24PM +0000, Joseph S. Myers wrote:
> > On Tue, 5 Nov 2013, David Daney wrote:
> > 
> > > 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?
> > 
> > If we change RLIM64_INFINITY to match the kernel, then the right thing for 
> > at least getrlimit64 depends on whether it's an old or new binary (for old 
> > binaries it should return the old value of RLIM64_INFINITY and for new 
> > ones it should return the new value).
> 
> BTW, what happens on a distro where -dev packages are separate and the
> user compiles with old headers (not having upgraded the dev package)
> but new libc.so? :-)

That's a bug in the distribution packaging that it allows such 
inconsistent versions.  glibc only supports the case when the static-link 
stage happens against the same glibc version as the headers that were used 
(static libraries built with old headers are expected to break whenever 
there's some ABI change made through symbol versioning).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: prlimit64: inconsistencies between kernel and userland

[Joseph S. Myers]

On Tue, 5 Nov 2013, Rich Felker wrote:

> On Tue, Nov 05, 2013 at 10:36:24PM +0000, Joseph S. Myers wrote:
> > On Tue, 5 Nov 2013, David Daney wrote:
> > 
> > > 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?
> > 
> > If we change RLIM64_INFINITY to match the kernel, then the right thing for 
> > at least getrlimit64 depends on whether it's an old or new binary (for old 
> > binaries it should return the old value of RLIM64_INFINITY and for new 
> > ones it should return the new value).
> 
> BTW, what happens on a distro where -dev packages are separate and the
> user compiles with old headers (not having upgraded the dev package)
> but new libc.so? :-)

That's a bug in the distribution packaging that it allows such 
inconsistent versions.  glibc only supports the case when the static-link 
stage happens against the same glibc version as the headers that were used 
(static libraries built with old headers are expected to break whenever 
there's some ABI change made through symbol versioning).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: prlimit64: inconsistencies between kernel and userland

[Andreas Schwab]

Rich Felker <dalias@aerifal.cx> writes:

> BTW, what happens on a distro where -dev packages are separate and the
> user compiles with old headers (not having upgraded the dev package)
> but new libc.so? :-)

The devel package must either be self-contained or require the matching
non-devel package.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: prlimit64: inconsistencies between kernel and userland

[Andreas Schwab]

Rich Felker <dalias@aerifal.cx> writes:

> BTW, what happens on a distro where -dev packages are separate and the
> user compiles with old headers (not having upgraded the dev package)
> but new libc.so? :-)

The devel package must either be self-contained or require the matching
non-devel package.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: prlimit64: inconsistencies between kernel and userland

[Rich Felker]

On Wed, Nov 06, 2013 at 12:52:14AM +0100, Andreas Schwab wrote:
> Rich Felker <dalias@aerifal.cx> writes:
> 
> > BTW, what happens on a distro where -dev packages are separate and the
> > user compiles with old headers (not having upgraded the dev package)
> > but new libc.so? :-)
> 
> The devel package must either be self-contained or require the matching
> non-devel package.

That doesn't help. The problem is that the non-devel package gets
upgraded and ldconfig re-links the .so to the .so.X.Y.Z for the new
version. Really, the problem is ldconfig. If the .so link were
correctly created by the devel package, rather than by ldconfig, then
the headers and link-time library version would always match.

So, in short, ldconfig considered harmful.

Rich

Re: prlimit64: inconsistencies between kernel and userland

[Russ Allbery]

Rich Felker <dalias@aerifal.cx> writes:

> That doesn't help. The problem is that the non-devel package gets
> upgraded and ldconfig re-links the .so to the .so.X.Y.Z for the new
> version.

Require the upgrades happen in lockstep.

Package: libc6-dev
Version: 2.17-93
Depends: libc6 (= 2.17-93), libc-dev-bin (= 2.17-93), linux-libc-dev

-- 
Russ Allbery (eagle@eyrie.org)              <http://www.eyrie.org/~eagle/>

Re: prlimit64: inconsistencies between kernel and userland

[Russ Allbery]

Rich Felker <dalias@aerifal.cx> writes:

> That doesn't help. The problem is that the non-devel package gets
> upgraded and ldconfig re-links the .so to the .so.X.Y.Z for the new
> version.

Require the upgrades happen in lockstep.

Package: libc6-dev
Version: 2.17-93
Depends: libc6 (= 2.17-93), libc-dev-bin (= 2.17-93), linux-libc-dev

-- 
Russ Allbery (eagle@eyrie.org)              <http://www.eyrie.org/~eagle/>

Re: prlimit64: inconsistencies between kernel and userland

[Joseph S. Myers]

On Mon, 4 Nov 2013, Rich Felker wrote:

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

It might be possible to do such a conversion in setrlimit64 - I'm not sure 
offhand if such a conversion for large finite values is valid, and a new 
symbol version is certainly the more conservative option - but getrlimit64 
in existing binaries should return results using the existing 
RLIM64_INFINITY, in case binaries compare against that, so if you change 
the header value to match the kernel I don't think you can avoid the new 
symbol version for getrlimit64, and versioning both together seems safer.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: prlimit64: inconsistencies between kernel and userland

[Joseph S. Myers]

On Mon, 4 Nov 2013, Rich Felker wrote:

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

It might be possible to do such a conversion in setrlimit64 - I'm not sure 
offhand if such a conversion for large finite values is valid, and a new 
symbol version is certainly the more conservative option - but getrlimit64 
in existing binaries should return results using the existing 
RLIM64_INFINITY, in case binaries compare against that, so if you change 
the header value to match the kernel I don't think you can avoid the new 
symbol version for getrlimit64, and versioning both together seems safer.

-- 
Joseph S. Myers
joseph@codesourcery.com