[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFwQM7X+khpZB=8zKLH4ejavZc2LMH659f8tT-DxnQ3vEA@mail.gmail.com>
Date: Wed, 11 Jan 2017 11:39:01 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: "Kirill A. Shutemov" <kirill@...temov.name>
Cc: Andy Lutomirski <luto@...capital.net>,
Dave Hansen <dave.hansen@...el.com>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
Andrew Morton <akpm@...ux-foundation.org>,
X86 ML <x86@...nel.org>, Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Arnd Bergmann <arnd@...db.de>,
"H. Peter Anvin" <hpa@...or.com>, Andi Kleen <ak@...ux.intel.com>,
linux-arch <linux-arch@...r.kernel.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Linux API <linux-api@...r.kernel.org>
Subject: Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR
On Wed, Jan 11, 2017 at 11:32 AM, Kirill A. Shutemov
<kirill@...temov.name> wrote:
>
> Running legacy binary with full address space is valuable option.
I disagree.
It's simply not valuable enough to worry about. Especially when there
is a fairly trivial wrapper approach: just make a full-address-space
wrapper than acts as a binary loader (think "specialized ld.so").
Sure, the wrapper may be "fairly trivial" but not necessarily
pleasant: you have to parse ELF sections etc and basically load the
binary by hand. But there are libraries for that, and loading an ELF
executable isn't rocket surgery, it's just possibly tedious.
Linus
Powered by blists - more mailing lists