On Mon, 30 Jan 2017, Dmitry Safonov 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. I really have a hard time to understand what is fixed and how that is related to the $subject. Again. Please explain the problem first properly so one can understand the issue immediately. > As a little bonus it'll make thread flag a little less used. I really do not understand the bonus part here. You replace the thread flag check with a different one and AFAICT this looks like oart of the 'fix'. Thanks, tglx > @@ -101,7 +101,7 @@ SYSCALL_DEFINE6(mmap, unsigned long, addr, unsigned long, len, > static void find_start_end(unsigned long flags, unsigned long *begin, > unsigned long *end) > { > - if (!test_thread_flag(TIF_ADDR32) && (flags & MAP_32BIT)) { > + if (!in_compat_syscall() && (flags & MAP_32BIT)) { > /* This is usually used needed to map code in small > model, so it needs to be in the first 31bit. Limit > it to that. This means we need to move the > @@ -195,7 +195,7 @@ arch_get_unmapped_area_topdown(struct file *filp, const unsigned long addr0, > return addr; > > /* for MAP_32BIT mappings we force the legacy mmap base */ > - if (!test_thread_flag(TIF_ADDR32) && (flags & MAP_32BIT)) > + if (!in_compat_syscall() && (flags & MAP_32BIT)) > goto bottomup; > > /* requesting a specific address */ > -- > 2.11.0 > > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx"> email@xxxxxxxxx </a>