public inbox for linux-unionfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Amir Goldstein <amir73il@gmail.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: Vivek Goyal <vgoyal@redhat.com>, cgxu519 <cgxu519@gmx.com>,
	linux-unionfs@vger.kernel.org
Subject: [RFC][PATCH v2 4/5] ovl: lazy copy up data on page fault
Date: Tue, 22 Jan 2019 14:34:56 +0200	[thread overview]
Message-ID: <20190122123457.10600-5-amir73il@gmail.com> (raw)
In-Reply-To: <20190122123457.10600-1-amir73il@gmail.com>

When overlay filemap operations are supported, all maps, including
private and non writable maps that are created from file that was
opened after copy up, map overlay inode pages. If the file was opened
O_RDWR with lazy copy up of data, the first page fault, read or write,
will trigger data copy up.

NOTE: SHARED maps that are created from file opened O_RDONLY before
data copy up will stay mapped to lower real file also after copy up.
This long standing inconsistency will need to be resolved by future
patches.

Signed-off-by: Amir Goldstein <amir73il@gmail.com>
---
 fs/overlayfs/file.c | 59 +++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 57 insertions(+), 2 deletions(-)

diff --git a/fs/overlayfs/file.c b/fs/overlayfs/file.c
index e02b61af9488..35c75e9d8111 100644
--- a/fs/overlayfs/file.c
+++ b/fs/overlayfs/file.c
@@ -397,6 +397,49 @@ const struct address_space_operations ovl_aops = {
 	.direct_IO		= noop_direct_IO,
 };
 
+static vm_fault_t ovl_fault(struct vm_fault *vmf)
+{
+	struct file *file = vmf->vma->vm_file;
+	struct inode *inode = file_inode(file);
+	bool blocking = (vmf->flags & FAULT_FLAG_KILLABLE) ||
+			((vmf->flags & FAULT_FLAG_ALLOW_RETRY) &&
+			 !(vmf->flags & FAULT_FLAG_RETRY_NOWAIT));
+	int err = 0;
+
+	/*
+	 * Handle fault of pages in maps that were created from file that was
+	 * opened O_RDWR and before data copy up.
+	 */
+	if (!ovl_has_upperdata(inode)) {
+		/* TODO: async copy up data? */
+		if (!blocking)
+			goto out_err;
+
+		up_read(&vmf->vma->vm_mm->mmap_sem);
+		err = ovl_maybe_copy_up(file_dentry(file), O_WRONLY);
+		if (err)
+			goto out_err;
+
+		return VM_FAULT_RETRY;
+	}
+
+	return filemap_fault(vmf);
+
+out_err:
+	pr_warn_ratelimited("overlayfs: %s copy up data on page fault (%pd2, err=%i)\n",
+			    blocking ? "failed to" : "no wait for",
+			    file_dentry(file), err);
+
+	/* We must return VM_FAULT_RETRY if we released mmap_sem */
+	return blocking ? VM_FAULT_NOPAGE : VM_FAULT_RETRY;
+}
+
+static const struct vm_operations_struct ovl_file_vm_ops = {
+	.fault		= ovl_fault,
+	.map_pages	= filemap_map_pages,
+	.page_mkwrite   = filemap_page_mkwrite,
+};
+
 static int ovl_real_mmap(struct file *file, struct vm_area_struct *vma)
 {
 	struct file *realfile = file->private_data;
@@ -430,8 +473,20 @@ static int ovl_real_mmap(struct file *file, struct vm_area_struct *vma)
 
 static int ovl_mmap(struct file *file, struct vm_area_struct *vma)
 {
-	if (ovl_should_use_filemap_meta(file, true))
-		generic_file_mmap(file, vma);
+	/*
+	 * All maps (also private and non writable) that are created from file
+	 * that was opened after copy up, map overlay inode pages. If the file
+	 * was opened O_RDWR with lazy copy up of data, the first page fault
+	 * will trigger data copy up.
+	 *
+	 * FIXME: SHARED maps that are created from file opened O_RDONLY before
+	 * data copy up will stay mapped to lower real file also after copy up.
+	 */
+	if (ovl_should_use_filemap_meta(file, true)) {
+		vma->vm_ops = &ovl_file_vm_ops;
+		file_accessed(file);
+		return 0;
+	}
 
 	return ovl_real_mmap(file, vma);
 }
-- 
2.17.1

  parent reply	other threads:[~2019-01-22 12:34 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-22 12:34 [RFC][PATCH v2 0/5] Experiments with overlayfs filemap Amir Goldstein
2019-01-22 12:34 ` [RFC][PATCH v2 1/5] ovl: reorder tests in ovl_open_need_copy_up() Amir Goldstein
2019-01-22 12:34 ` [RFC][PATCH v2 2/5] ovl: prepare for generic filemap file operations Amir Goldstein
2019-01-22 12:34 ` [RFC][PATCH v2 3/5] ovl: lazy copy up of data on first data access Amir Goldstein
2019-01-22 12:34 ` Amir Goldstein [this message]
2019-01-22 12:34 ` [RFC][PATCH v2 5/5] ovl: noop aops to test filemap operations and lazy copy up Amir Goldstein
2019-01-24 17:18 ` [RFC][PATCH v2 0/5] Experiments with overlayfs filemap Amir Goldstein
2019-01-24 22:35   ` Amir Goldstein
2019-01-25  9:54     ` Miklos Szeredi
2019-01-25 11:24       ` Amir Goldstein
2019-01-25 12:21         ` Miklos Szeredi
2019-01-25 13:04           ` Amir Goldstein
2019-01-25 13:31             ` Miklos Szeredi
2019-01-25 15:56               ` Miklos Szeredi
2019-01-25 21:18                 ` Amir Goldstein
2019-01-27 18:22                   ` Amir Goldstein
2019-01-28 19:22                     ` Vivek Goyal
2019-01-28 20:57                       ` Amir Goldstein
2019-01-28 21:17                         ` Miklos Szeredi
2019-01-28 21:22                           ` Miklos Szeredi
2019-01-28 22:14                             ` Amir Goldstein
2019-01-29  7:17                               ` Miklos Szeredi
2019-01-29  8:54                                 ` Amir Goldstein
2019-01-29  8:58                                   ` Miklos Szeredi
2019-01-29  9:12                                     ` Amir Goldstein
2019-01-29 12:44                                       ` Miklos Szeredi
2019-01-29 16:47                                         ` Amir Goldstein
2019-01-31 16:23                                           ` Miklos Szeredi
2019-01-31 21:54                                             ` Amir Goldstein
2019-02-01  9:14                                               ` Miklos Szeredi
2019-02-01 13:22                                                 ` Amir Goldstein
2019-02-01 16:29                                                   ` Vivek Goyal
2019-02-01 13:25                                                 ` Amir Goldstein
2019-02-01 16:24                                                   ` Miklos Szeredi
2019-02-01 16:47                                                     ` Vivek Goyal
2019-02-02 16:51                                                     ` Amir Goldstein
2019-02-05  7:42                                                       ` Amir Goldstein
2019-02-05  7:50                                                         ` Miklos Szeredi
2019-02-05 13:03                                                         ` Amir Goldstein
2019-02-06 15:36                                                           ` Miklos Szeredi
2019-02-12  7:43                                                             ` Amir Goldstein
2019-02-12  8:11                                                               ` 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=20190122123457.10600-5-amir73il@gmail.com \
    --to=amir73il@gmail.com \
    --cc=cgxu519@gmx.com \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=vgoyal@redhat.com \
    /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