From: Michal Hocko <mhocko@kernel.org>
To: Michael Ellerman <mpe@ellerman.id.au>
Cc: Joel Stanley <joel@jms.id.au>,
Stephen Rothwell <sfr@canb.auug.org.au>,
Andrew Morton <akpm@linux-foundation.org>,
Linux-Next Mailing List <linux-next@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Russell King <linux@armlinux.org.uk>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Abdul Haleem <abdhalee@linux.vnet.ibm.com>,
Ralf Baechle <ralf@linux-mips.org>,
"James E.J. Bottomley" <jejb@parisc-linux.org>,
Helge Deller <deller@gmx.de>,
Yoshinori Sato <ysato@users.sourceforge.jp>,
Rich Felker <dalias@libc.org>,
"David S. Miller" <davem@davemloft.net>,
Chris Zankel <chris@zankel.net>,
Max Filippov <jcmvbkbc@gmail.com>,
linux-arm-kernel@lists.infradead.org,
linuxppc-dev@lists.ozlabs.org, linux-mips@linux-mips.org
Subject: Re: linux-next: Tree for Nov 7
Date: Mon, 13 Nov 2017 17:06:37 +0100 [thread overview]
Message-ID: <20171113160637.jhekbdyfpccme3be@dhcp22.suse.cz> (raw)
In-Reply-To: <20171113154939.6ui2fmpokpm7g4oj@dhcp22.suse.cz>
[Sorry for spamming, this one is the last attempt hopefully]
On Mon 13-11-17 16:49:39, Michal Hocko wrote:
> On Mon 13-11-17 16:16:41, Michal Hocko wrote:
> > On Mon 13-11-17 13:00:57, Michal Hocko wrote:
> > [...]
> > > Yes, I have mentioned that in the previous email but the amount of code
> > > would be even larger. Basically every arch which reimplements
> > > arch_get_unmapped_area would have to special case new MAP_FIXED flag to
> > > do vma lookup.
> >
> > It turned out that this might be much more easier than I thought after
> > all. It seems we can really handle that in the common code. This would
> > mean that we are exposing a new functionality to the userspace though.
> > Myabe this would be useful on its own though. Just a quick draft (not
> > even compile tested) whether this makes sense in general. I would be
> > worried about unexpected behavior when somebody set other bit without a
> > good reason and we might fail with ENOMEM for such a call now.
>
> Hmm, the bigger problem would be the backward compatibility actually. We
> would get silent corruptions which is exactly what the flag is trying
> fix. mmap flags handling really sucks. So I guess we would have to make
> the flag internal only :/
OK, so this one should take care of the backward compatibility while
still not touching the arch code
---
commit 39ff9bf8597e79a032da0954aea1f0d77d137765
Author: Michal Hocko <mhocko@suse.com>
Date: Mon Nov 13 17:06:24 2017 +0100
mm: introduce MAP_FIXED_SAFE
MAP_FIXED is used quite often but it is inherently dangerous because it
unmaps an existing mapping covered by the requested range. While this
might be might be really desidered behavior in many cases there are
others which would rather see a failure than a silent memory corruption.
Introduce a new MAP_FIXED_SAFE flag for mmap to achive this behavior.
It is a MAP_FIXED extension with a single exception that it fails with
ENOMEM if the requested address is already covered by an existing
mapping. We still do rely on get_unmaped_area to handle all the arch
specific MAP_FIXED treatment and check for a conflicting vma after it
returns.
Signed-off-by: Michal Hocko <mhocko@suse.com>
diff --git a/arch/alpha/include/uapi/asm/mman.h b/arch/alpha/include/uapi/asm/mman.h
index 3b26cc62dadb..767bcb8a4c28 100644
--- a/arch/alpha/include/uapi/asm/mman.h
+++ b/arch/alpha/include/uapi/asm/mman.h
@@ -31,6 +31,8 @@
#define MAP_STACK 0x80000 /* give out an address that is best suited for process/thread stacks */
#define MAP_HUGETLB 0x100000 /* create a huge page mapping */
+#define MAP_FIXED_SAFE 0x2000000 /* MAP_FIXED which doesn't unmap underlying mapping */
+
#define MS_ASYNC 1 /* sync memory asynchronously */
#define MS_SYNC 2 /* synchronous memory sync */
#define MS_INVALIDATE 4 /* invalidate the caches */
diff --git a/arch/mips/include/uapi/asm/mman.h b/arch/mips/include/uapi/asm/mman.h
index da3216007fe0..c2311eb7219b 100644
--- a/arch/mips/include/uapi/asm/mman.h
+++ b/arch/mips/include/uapi/asm/mman.h
@@ -49,6 +49,8 @@
#define MAP_STACK 0x40000 /* give out an address that is best suited for process/thread stacks */
#define MAP_HUGETLB 0x80000 /* create a huge page mapping */
+#define MAP_FIXED_SAFE 0x2000000 /* MAP_FIXED which doesn't unmap underlying mapping */
+
/*
* Flags for msync
*/
diff --git a/arch/parisc/include/uapi/asm/mman.h b/arch/parisc/include/uapi/asm/mman.h
index cc9ba1d34779..b06fd830bc6f 100644
--- a/arch/parisc/include/uapi/asm/mman.h
+++ b/arch/parisc/include/uapi/asm/mman.h
@@ -25,6 +25,8 @@
#define MAP_STACK 0x40000 /* give out an address that is best suited for process/thread stacks */
#define MAP_HUGETLB 0x80000 /* create a huge page mapping */
+#define MAP_FIXED_SAFE 0x2000000 /* MAP_FIXED which doesn't unmap underlying mapping */
+
#define MS_SYNC 1 /* synchronous memory sync */
#define MS_ASYNC 2 /* sync memory asynchronously */
#define MS_INVALIDATE 4 /* invalidate the caches */
diff --git a/arch/xtensa/include/uapi/asm/mman.h b/arch/xtensa/include/uapi/asm/mman.h
index b15b278aa314..f4b291bca764 100644
--- a/arch/xtensa/include/uapi/asm/mman.h
+++ b/arch/xtensa/include/uapi/asm/mman.h
@@ -62,6 +62,8 @@
# define MAP_UNINITIALIZED 0x0 /* Don't support this flag */
#endif
+#define MAP_FIXED_SAFE 0x2000000 /* MAP_FIXED which doesn't unmap underlying mapping */
+
/*
* Flags for msync
*/
diff --git a/include/uapi/asm-generic/mman-common.h b/include/uapi/asm-generic/mman-common.h
index 203268f9231e..03c518777f83 100644
--- a/include/uapi/asm-generic/mman-common.h
+++ b/include/uapi/asm-generic/mman-common.h
@@ -25,6 +25,8 @@
# define MAP_UNINITIALIZED 0x0 /* Don't support this flag */
#endif
+#define MAP_FIXED_SAFE 0x2000000 /* MAP_FIXED which doesn't unmap underlying mapping */
+
/*
* Flags for mlock
*/
diff --git a/mm/mmap.c b/mm/mmap.c
index 680506faceae..aad8d37f0205 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1358,6 +1358,10 @@ unsigned long do_mmap(struct file *file, unsigned long addr,
if (mm->map_count > sysctl_max_map_count)
return -ENOMEM;
+ /* force arch specific MAP_FIXED handling in get_unmapped_area */
+ if (flags & MAP_FIXED_SAFE)
+ flags |= MAP_FIXED;
+
/* Obtain the address to map to. we verify (or select) it and ensure
* that it represents a valid section of the address space.
*/
@@ -1365,6 +1369,13 @@ unsigned long do_mmap(struct file *file, unsigned long addr,
if (offset_in_page(addr))
return addr;
+ if (flags & MAP_FIXED_SAFE) {
+ struct vm_area_struct *vma = find_vma(mm, addr);
+
+ if (vma && vma->vm_start <= addr)
+ return -ENOMEM;
+ }
+
if (prot == PROT_EXEC) {
pkey = execute_only_pkey(mm);
if (pkey < 0)
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2017-11-13 16:06 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-07 5:22 linux-next: Tree for Nov 7 Stephen Rothwell
2017-11-07 22:22 ` Joel Stanley
2017-11-08 14:20 ` Michal Hocko
2017-11-10 12:30 ` Michal Hocko
2017-11-12 1:08 ` Joel Stanley
2017-11-13 9:20 ` Michal Hocko
2017-11-13 9:34 ` Russell King - ARM Linux
2017-11-13 9:42 ` Michal Hocko
2017-11-13 11:34 ` Michael Ellerman
2017-11-13 12:00 ` Michal Hocko
2017-11-13 15:16 ` Michal Hocko
2017-11-13 15:48 ` Russell King - ARM Linux
2017-11-13 15:59 ` Michal Hocko
2017-11-13 15:49 ` Michal Hocko
2017-11-13 16:06 ` Michal Hocko [this message]
2017-11-13 16:35 ` Khalid Aziz
2017-11-14 7:07 ` Michal Hocko
2017-11-14 9:18 ` Michael Ellerman
2017-11-14 9:29 ` Michal Hocko
2017-11-14 9:02 ` Michael Ellerman
2017-11-14 8:54 ` Michael Ellerman
2017-11-14 9:04 ` Michal Hocko
2017-11-14 14:52 ` Khalid Aziz
2017-11-13 14:11 ` Michal Hocko
2017-11-13 15:09 ` Russell King - ARM Linux
2017-11-13 15:31 ` Michal Hocko
2017-11-14 0:03 ` Andrew Morton
2017-11-14 0:36 ` Stephen Rothwell
-- strict thread matches above, loose matches on Subject: below --
2023-11-07 1:17 Stephen Rothwell
2022-11-07 3:44 Stephen Rothwell
2019-11-07 8:07 Stephen Rothwell
2018-11-07 3:16 Stephen Rothwell
2013-11-07 7:31 Stephen Rothwell
2012-11-07 5:15 Stephen Rothwell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171113160637.jhekbdyfpccme3be@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=abdhalee@linux.vnet.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=benh@kernel.crashing.org \
--cc=chris@zankel.net \
--cc=dalias@libc.org \
--cc=davem@davemloft.net \
--cc=deller@gmx.de \
--cc=jcmvbkbc@gmail.com \
--cc=jejb@parisc-linux.org \
--cc=joel@jms.id.au \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=linux-next@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=ralf@linux-mips.org \
--cc=sfr@canb.auug.org.au \
--cc=ysato@users.sourceforge.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).