(request for -mm inclusion) Re: [PATCH v3] arm64, ia64, ppc, s390, sh, tile, um, x86, mm: Remove default gate area
luto at amacapital.net
Fri Jul 25 04:48:00 EST 2014
One more try before I spam the world with a new thread. Is this patch
okay for -mm?
So far, it's accumulated:
Acked-by: Nathan Lynch <nathan_lynch at mentor.com>
Acked-by: H. Peter Anvin <hpa at linux.intel.com>
Acked-by: Benjamin Herrenschmidt <benh at kernel.crashing.org> [in principle]
Acked-by: Richard Weinberger <richard at nod.at> [for um]
Acked-by: Will Deacon <will.deacon at arm.com> [for arm64]
For convenience, I've attached the patch w/ the acked-by's folded in
and with no other changes.
On Fri, Jul 18, 2014 at 9:53 AM, Andy Lutomirski <luto at amacapital.net> wrote:
> On Jul 18, 2014 3:20 AM, "Richard Weinberger" <richard at nod.at> wrote:
>> Am 18.07.2014 12:14, schrieb Will Deacon:
>> > On Tue, Jul 15, 2014 at 03:47:26PM +0100, Andy Lutomirski wrote:
>> >> On Sun, Jul 13, 2014 at 1:01 PM, Andy Lutomirski <luto at amacapital.net>
>> >> wrote:
>> >>> The core mm code will provide a default gate area based on
>> >>> FIXADDR_USER_START and FIXADDR_USER_END if
>> >>> !defined(__HAVE_ARCH_GATE_AREA) && defined(AT_SYSINFO_EHDR).
>> >>> This default is only useful for ia64. arm64, ppc, s390, sh, tile,
>> >>> 64-bit UML, and x86_32 have their own code just to disable it. arm,
>> >>> 32-bit UML, and x86_64 have gate areas, but they have their own
>> >>> implementations.
>> >>> This gets rid of the default and moves the code into ia64.
>> >>> This should save some code on architectures without a gate area: it's
>> >>> now possible to inline the gate_area functions in the default case.
>> >> Can one of you pull this somewhere? Otherwise I can put it somewhere
>> >> stable and ask for -next inclusion, but that seems like overkill for a
>> >> single patch.
>> For the um bits:
>> Acked-by: Richard Weinberger <richard at nod.at>
>> > I'd be happy to take the arm64 part, but it doesn't feel right for mm/*
>> > changes (or changes to other archs) to go via our tree.
>> > I'm not sure what the best approach is if you want to send this via a
>> > single
>> > tree. Maybe you could ask akpm nicely?
>> Going though Andrew's tree sounds sane to me.
> Splitting this will be annoying: I'd probably have to add a flag asking for
> the new behavior, update all the arches, then remove the flag. The chance
> of screwing up bisectability in the process seems pretty high. This seems
> like overkill for a patch that mostly deletes code.
> Akpm, can you take this?
AMA Capital Management, LLC
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 14779 bytes
Desc: not available
More information about the Linuxppc-dev