Are there any more concerns? So far the biggest one was the name. The other which suggests a flag as a modifier has been sorted out hopefully. Is there anymore more before we can consider this for merging? Well except for man page update which I will prepare of course. Can we target this to 4.16? On Thu 16-11-17 13:14:38, Michal Hocko wrote: > [Ups, managed to screw the subject - fix it] > > On Thu 16-11-17 11:18:58, Michal Hocko wrote: > > Hi, > > this has started as a follow up discussion [1][2] resulting in the > > runtime failure caused by hardening patch [3] which removes MAP_FIXED > > from the elf loader because MAP_FIXED is inherently dangerous as it > > might silently clobber and existing underlying mapping (e.g. stack). The > > reason for the failure is that some architectures enforce an alignment > > for the given address hint without MAP_FIXED used (e.g. for shared or > > file backed mappings). > > > > One way around this would be excluding those archs which do alignment > > tricks from the hardening [4]. The patch is really trivial but it has > > been objected, rightfully so, that this screams for a more generic > > solution. We basically want a non-destructive MAP_FIXED. > > > > The first patch introduced MAP_FIXED_SAFE which enforces the given > > address but unlike MAP_FIXED it fails with ENOMEM if the given range > > conflicts with an existing one. The flag is introduced as a completely > > new flag rather than a MAP_FIXED extension because of the backward > > compatibility. We really want a never-clobber semantic even on older > > kernels which do not recognize the flag. Unfortunately mmap sucks wrt. > > flags evaluation because we do not EINVAL on unknown flags. On those > > kernels we would simply use the traditional hint based semantic so the > > caller can still get a different address (which sucks) but at least not > > silently corrupt an existing mapping. I do not see a good way around > > that. Except we won't export expose the new semantic to the userspace at > > all. It seems there are users who would like to have something like that > > [5], though. Atomic address range probing in the multithreaded programs > > sounds like an interesting thing to me as well, although I do not have > > any specific usecase in mind. > > > > The second patch simply replaces MAP_FIXED use in elf loader by > > MAP_FIXED_SAFE. I believe other places which rely on MAP_FIXED should > > follow. Actually real MAP_FIXED usages should be docummented properly > > and they should be more of an exception. > > > > Does anybody see any fundamental reasons why this is a wrong approach? > > > > Diffstat says > > arch/alpha/include/uapi/asm/mman.h | 2 ++ > > arch/metag/kernel/process.c | 6 +++++- > > arch/mips/include/uapi/asm/mman.h | 2 ++ > > arch/parisc/include/uapi/asm/mman.h | 2 ++ > > arch/powerpc/include/uapi/asm/mman.h | 1 + > > arch/sparc/include/uapi/asm/mman.h | 1 + > > arch/tile/include/uapi/asm/mman.h | 1 + > > arch/xtensa/include/uapi/asm/mman.h | 2 ++ > > fs/binfmt_elf.c | 12 ++++++++---- > > include/uapi/asm-generic/mman.h | 1 + > > mm/mmap.c | 11 +++++++++++ > > 11 files changed, 36 insertions(+), 5 deletions(-) > > > > [1] http://lkml.kernel.org/r/20171107162217.382cd754@xxxxxxxxxxxxxxxx > > [2] http://lkml.kernel.org/r/1510048229.12079.7.camel@xxxxxxxxxxxxxxxx > > [3] http://lkml.kernel.org/r/20171023082608.6167-1-mhocko@xxxxxxxxxx > > [4] http://lkml.kernel.org/r/20171113094203.aofz2e7kueitk55y@xxxxxxxxxxxxxx > > [5] http://lkml.kernel.org/r/87efp1w7vy.fsf@xxxxxxxxxxxxxxxxxxxxxxxx > > > > > > -- > > 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> > > -- > Michal Hocko > SUSE Labs -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
