This is the mail archive of the
mailing list for the glibc project.
Re: prlimit64: inconsistencies between kernel and userland
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Rich Felker <dalias at aerifal dot cx>
- Cc: David Daney <ddaney dot cavm at gmail dot com>, "Pinski, Andrew" <Andrew dot Pinski at caviumnetworks dot com>, Andreas Barth <aba at ayous dot org>, David Miller <davem at davemloft dot net>, <aurelien at aurel32 dot net>, <linux-mips at linux-mips dot org>, <libc-alpha at sourceware dot org>
- Date: Tue, 5 Nov 2013 23:25:11 +0000
- Subject: Re: prlimit64: inconsistencies between kernel and userland
- Authentication-results: sourceware.org; auth=none
- References: <20130628133835 dot GA21839 at hall dot aurel32 dot net> <20131104213756 dot GD18700 at hall dot aurel32 dot net> <20131104 dot 194519 dot 1657797548878784116 dot davem at davemloft dot net> <Pine dot LNX dot 4 dot 64 dot 1311050058580 dot 9883 at digraph dot polyomino dot org dot uk> <20131105012203 dot GA24286 at brightrain dot aerifal dot cx> <20131105085859 dot GE28240 at mails dot so dot argh dot org> <20131105183732 dot GB24286 at brightrain dot aerifal dot cx> <52793C50 dot 9030300 at gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1311052234420 dot 30260 at digraph dot polyomino dot org dot uk> <20131105223953 dot GG24286 at brightrain dot aerifal dot cx>
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