From: Miklos Szeredi <mszeredi@redhat.com>
To: linux-unionfs@vger.kernel.org
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH 3/7] mm: ovl: copy-up on MAP_SHARED
Date: Thu, 24 Nov 2016 11:55:40 +0100 [thread overview]
Message-ID: <1479984944-1017-5-git-send-email-mszeredi@redhat.com> (raw)
In-Reply-To: <1479984944-1017-1-git-send-email-mszeredi@redhat.com>
A corner case of a corner case is when
- file opened for O_RDONLY
- which is then memory mapped SHARED
- file opened for O_WRONLY
- contents modified
- contents read back though the shared mapping
Unfortunately it looks very difficult to do anything about the established
shared map after the file is copied up. Instead when a read-only file is
mapped shared overlayfs copies up the file before actually doing the map.
This may result in unnecessary copy-ups (but so may copy-up on open(O_RDWR)
for exampe).
We can revisit this later if it turns out to be a performance problem in
real life.
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
---
mm/util.c | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/mm/util.c b/mm/util.c
index 1a41553db866..09a179f92d18 100644
--- a/mm/util.c
+++ b/mm/util.c
@@ -300,6 +300,28 @@ unsigned long vm_mmap_pgoff(struct file *file, unsigned long addr,
ret = security_mmap_file(file, prot, flag);
if (!ret) {
+ /*
+ * Special treatment for overlayfs:
+ *
+ * Take MAP_SHARED/PROT_READ as hint about future writes to the
+ * file (through another file descriptor). Caller might not
+ * have had such an intent, but we hope MAP_PRIVATE will be used
+ * in most such cases.
+ *
+ * If we don't copy up now and the file is modified, it becomes
+ * really difficult to change the mapping to match that of the
+ * file's content later.
+ *
+ * Copy up needs to be done without mmap_sem since it takes vfs
+ * locks which would potentially deadlock under mmap_sem.
+ */
+ if ((flag & MAP_SHARED) && !(prot & PROT_WRITE)) {
+ void *p = d_real(file->f_path.dentry, NULL, O_WRONLY);
+
+ if (IS_ERR(p))
+ return PTR_ERR(p);
+ }
+
if (down_write_killable(&mm->mmap_sem))
return -EINTR;
ret = do_mmap_pgoff(file, addr, len, prot, flag, pgoff,
--
2.5.5
next prev parent reply other threads:[~2016-11-24 10:56 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-24 10:55 [PATCH 0/7] overlayfs: fix ro/rw fd data inconsistecies Miklos Szeredi
2016-11-24 10:55 ` Miklos Szeredi
2016-11-24 14:14 ` Miklos Szeredi
2016-11-24 20:50 ` Amir Goldstein
2016-11-24 10:55 ` [PATCH 1/7] vfs: allow overlayfs to intercept file ops Miklos Szeredi
2016-11-24 10:55 ` [PATCH 2/7] vfs: export filp_clone_open() Miklos Szeredi
2016-11-24 10:55 ` Miklos Szeredi [this message]
2016-11-25 21:20 ` [mm] 68ab21008a: BUG:unable_to_handle_kernel kernel test robot
2016-11-24 10:55 ` [PATCH 4/7] ovl: add infrastructure for intercepting file ops Miklos Szeredi
2016-11-24 11:52 ` Amir Goldstein
2016-11-24 12:03 ` Miklos Szeredi
2016-11-24 13:12 ` Amir Goldstein
2016-11-24 13:51 ` Miklos Szeredi
2016-11-24 14:08 ` Amir Goldstein
2016-11-25 5:22 ` Amir Goldstein
2016-11-24 10:55 ` [PATCH 5/7] ovl: intercept read_iter Miklos Szeredi
2016-11-24 10:55 ` [PATCH 6/7] ovl: intercept mmap Miklos Szeredi
2016-11-24 13:25 ` Amir Goldstein
2016-11-24 18:03 ` Amir Goldstein
2016-11-24 19:06 ` Amir Goldstein
2016-11-24 10:55 ` [PATCH 7/7] ovl: intercept fsync Miklos Szeredi
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=1479984944-1017-5-git-send-email-mszeredi@redhat.com \
--to=mszeredi@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
/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
Powered by JetHome