All of lore.kernel.org
 help / color / mirror / Atom feed
From: Amir Goldstein <amir73il@gmail.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: linux-unionfs@vger.kernel.org
Subject: [PATCH 7/7] ovl: prevent copy on read if no upper/work dir
Date: Thu, 30 Mar 2017 14:26:20 +0300	[thread overview]
Message-ID: <1490873180-7433-1-git-send-email-amir73il@gmail.com> (raw)
In-Reply-To: <1490798166-22310-1-git-send-email-amir73il@gmail.com>

On ro mount there are only ro fd's, so all fd's of the same file
are always consistent on a ro overlay mount.  But, if overlay can
be later remounted rw, we need to copy on read anyway, so that
ro fd that was opened during ro mount will be consistent with
rw fd that is opened after remount rw.

Therefore, we need to disable consistent_fd feature only in case
there are no upper/work dirs, so overlay can never be mounted rw.

Signed-off-by: Amir Goldstein <amir73il@gmail.com>
---

Miklos,

Patch 5 should have prevented copy on read for ro mount,
but forgot to do so.

This extra patch relaxes the ro mount constrain and also
enforces the stronger contrain of no copy up if no upper/work.

If you're ok with the patch series, I can either fold this
patch into patch 5 or fix patch 5 and keep this one separate.

Amir.

 fs/overlayfs/super.c | 20 ++++++++++++++++----
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c
index ef159f8..688c0b0 100644
--- a/fs/overlayfs/super.c
+++ b/fs/overlayfs/super.c
@@ -222,6 +222,12 @@ static int ovl_statfs(struct dentry *dentry, struct kstatfs *buf)
 	return err;
 }
 
+/* Will this overlay be forced to mount/remount ro? */
+static bool ovl_force_readonly(struct ovl_fs *ufs)
+{
+	return (!ufs->upper_mnt || !ufs->workdir);
+}
+
 /**
  * ovl_show_options
  *
@@ -243,7 +249,7 @@ static int ovl_show_options(struct seq_file *m, struct dentry *dentry)
 	if (ufs->config.redirect_dir != ovl_redirect_dir_def)
 		seq_printf(m, ",redirect_dir=%s",
 			   ufs->config.redirect_dir ? "on" : "off");
-	if (!(sb->s_flags & MS_RDONLY) &&
+	if (!ovl_force_readonly(ufs) &&
 	    ufs->config.consistent_fd != ovl_consistent_fd_def)
 		seq_printf(m, ",consistent_fd=%s",
 			   ufs->config.consistent_fd ? "on" : "off");
@@ -254,7 +260,7 @@ static int ovl_remount(struct super_block *sb, int *flags, char *data)
 {
 	struct ovl_fs *ufs = sb->s_fs_info;
 
-	if (!(*flags & MS_RDONLY) && (!ufs->upper_mnt || !ufs->workdir))
+	if (!(*flags & MS_RDONLY) && ovl_force_readonly(ufs))
 		return -EROFS;
 
 	return 0;
@@ -942,8 +948,14 @@ static int ovl_fill_super(struct super_block *sb, void *data, int silent)
 	if (!ufs->upper_mnt)
 		sb->s_flags |= MS_RDONLY;
 
-	/* Copy on read for consistent fd depends on clone support */
-	if (!ufs->cloneup)
+	/*
+	 * Copy on read for consistent fd depends on clone support.
+	 * On ro mount fd is always consistent, but if overlay can be
+	 * later remounted rw, we need to copy on read anyway, so that
+	 * ro fd that was opened during ro mount will be consistent with
+	 * rw fd that is opened after remount rw.
+	 */
+	if (!ufs->cloneup || ovl_force_readonly(ufs))
 		ufs->config.consistent_fd = false;
 
 	if (remote)
-- 
2.7.4

  parent reply	other threads:[~2017-03-30 11:26 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-29 14:36 [PATCH 0/6] ovl: consistent_fd feature Amir Goldstein
2017-03-29 14:36 ` [PATCH 1/6] ovl: store path type in dentry Amir Goldstein
2017-03-29 14:36 ` [PATCH 2/6] ovl: cram opaque boolean into type flags Amir Goldstein
2017-03-29 14:36 ` [PATCH 3/6] ovl: check if all layers are on the same fs Amir Goldstein
2017-03-29 14:36 ` [PATCH 4/6] ovl: check if clone from lower to upper is supported Amir Goldstein
2017-03-29 14:36 ` [PATCH 5/6] ovl: copy on read with consistent_fd feature Amir Goldstein
2017-03-30 11:28   ` Amir Goldstein
2017-03-31 17:58   ` Vivek Goyal
2017-04-01  9:27     ` Amir Goldstein
2017-04-05 13:20       ` Amir Goldstein
2017-03-29 14:36 ` [PATCH 6/6] ovl: link upper tempfile on open for write Amir Goldstein
2017-03-30 11:26 ` Amir Goldstein [this message]
2017-03-30 11:34 ` [PATCH 0/6] ovl: consistent_fd feature Amir Goldstein
2017-04-06 15:20   ` Miklos Szeredi
2017-04-06 15:37     ` Miklos Szeredi
2017-04-06 16:25       ` Amir Goldstein
2017-04-07  9:32         ` Miklos Szeredi
2017-04-07  9:56           ` Miklos Szeredi
2017-04-07 10:47             ` Amir Goldstein
2017-04-07 13:03               ` Miklos Szeredi
2017-04-07 15:07                 ` Amir Goldstein
2017-04-06 16:46     ` Amir Goldstein
2017-04-07  9:43       ` Miklos Szeredi
2017-04-07 11:04         ` Amir Goldstein
2017-04-08  3:03     ` J. R. Okajima

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=1490873180-7433-1-git-send-email-amir73il@gmail.com \
    --to=amir73il@gmail.com \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.