linux-mips
[Top] [All Lists]

Re: prlimit64: inconsistencies between kernel and userland

To: Rich Felker <dalias@aerifal.cx>, "Pinski, Andrew" <Andrew.Pinski@caviumnetworks.com>
Subject: Re: prlimit64: inconsistencies between kernel and userland
From: David Daney <ddaney.cavm@gmail.com>
Date: Tue, 05 Nov 2013 10:43:28 -0800
Cc: Andreas Barth <aba@ayous.org>, "Joseph S. Myers" <joseph@codesourcery.com>, David Miller <davem@davemloft.net>, aurelien@aurel32.net, linux-mips@linux-mips.org, libc-alpha@sourceware.org
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=7cL/uis/Wda8Ut5U9vSTGOQ6aPertW7ZbrXo52D+ZR0=; b=j8ElsvS4m2JQnQ+G+hpv8hn2KMh0ZGBVmdCEnGITyR3GHj0AFtQWTNMvCbloMPuGcB 5L4a3kxwZD8OExoR4eItwgFTY3pm7Nd1iMynoqmgerNVBbrc/4raac/qLKMoRtyGbc1u gB6x9tuk6IJy3jzJLxCRdipZyKt92zshDh11eC1aoUmN2D94iOw2DwX4sy6ySpt6alnn Br3BkCT5mujbfISsY/LDlB6kGJvIwaa24geQLZlkVTy6gPuUcW3n8xcIKGJYe0wsFSK1 bBNQlnU0v/KBXMRlFUmSbvA2BgAgtNlqrqkkm93ZfHwy/bCP8r7TgN+v2e7nJoabHiWI ZCnQ==
In-reply-to: <20131105183732.GB24286@brightrain.aerifal.cx>
List-archive: <http://www.linux-mips.org/archives/linux-mips/>
List-help: <mailto:ecartis@linux-mips.org?Subject=help>
List-id: linux-mips <linux-mips.eddie.linux-mips.org>
List-owner: <mailto:ralf@linux-mips.org>
List-post: <mailto:linux-mips@linux-mips.org>
List-software: Ecartis version 1.0.0
List-subscribe: <mailto:ecartis@linux-mips.org?subject=subscribe%20linux-mips>
List-unsubscribe: <mailto:ecartis@linux-mips.org?subject=unsubscribe%20linux-mips>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20130628133835.GA21839@hall.aurel32.net> <20131104213756.GD18700@hall.aurel32.net> <20131104.194519.1657797548878784116.davem@davemloft.net> <Pine.LNX.4.64.1311050058580.9883@digraph.polyomino.org.uk> <20131105012203.GA24286@brightrain.aerifal.cx> <20131105085859.GE28240@mails.so.argh.org> <20131105183732.GB24286@brightrain.aerifal.cx>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
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


<Prev in Thread] Current Thread [Next in Thread>