[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrWXCr_nYMb41JSgVSAmMYkkkkDfWtLfQhh7S5Enz8YJCA@mail.gmail.com>
Date: Tue, 17 Jan 2017 12:30:47 -0800
From: Andy Lutomirski <luto@...capital.net>
To: Dmitry Safonov <dsafonov@...tuozzo.com>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Dmitry Safonov <0x7f454c46@...il.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>,
Andy Lutomirski <luto@...nel.org>,
Borislav Petkov <bp@...e.de>, X86 ML <x86@...nel.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>
Subject: Re: [PATCHv2 4/5] x86/mm: for MAP_32BIT check in_compat_syscall()
instead TIF_ADDR32
On Mon, Jan 16, 2017 at 4:33 AM, Dmitry Safonov <dsafonov@...tuozzo.com> wrote:
> At this momet, logic in arch_get_unmapped_area{,_topdown} for mmaps with
> MAP_32BIT flag checks TIF_ADDR32 which means:
> o if 32-bit ELF changes mode to 64-bit on x86_64 and then tries to
> mmap() with MAP_32BIT it'll result in addr over 4Gb (as default is
> top-down allocation)
> o if 64-bit ELF changes mode to 32-bit and tries mmap() with MAP_32BIT,
> it'll allocate only memory in 1GB space: [0x40000000, 0x80000000).
>
> Fix it by handeling MAP_32BIT in 64-bit syscalls only.
> As a little bonus it'll make thread flag a little less used.
Seems like an improvement. Also, jeez, the mmap code is complicated.
Powered by blists - more mailing lists