public inbox for linux-unionfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: linux-unionfs@vger.kernel.org
Cc: miklos@szeredi.hu, amir73il@gmail.com, vgoyal@redhat.com
Subject: [PATCH v11 17/18] ovl: Do not expose metacopy only upper dentry from d_real()
Date: Wed, 31 Jan 2018 16:13:28 -0500	[thread overview]
Message-ID: <20180131211329.16328-18-vgoyal@redhat.com> (raw)
In-Reply-To: <20180131211329.16328-1-vgoyal@redhat.com>

d_real() can make a upper metacopy dentry/inode visible to the vfs layer.
This is something new and vfs layer does not know that this inode contains
only metadata and not data. And this could break things.

So to be safe, do not expose metacopy only dentry/inode to vfs using
d_real().

IOW, d_real() will not reuturn metacopy dentry. Instead, it will return
dentry corresponding lower dentry/inode which has file data.

For regular d_real() call (inode == NULL, D_REAL_UPPER not set), if upper
dentry inode is metacopy only and does not have data, return lower dentry.

If d_real() is called with flag D_REAL_UPPER, return upper dentry only if
it has data (flag OVL_UPPERDATA is set).

Similiarly, if d_real(inode=X) is called, a warning is emitted if returned
dentry/inode does not have OVL_UPPERDATA set. This should not happen as
we never made this metacopy inode visible to vfs so nobody should be
calling overlayfs back with inode=metacopy_inode.

I scanned the code and I don't think it breaks any of the existing code.
There are two users of D_REAL_UPPER. may_write_real() and
update_ovl_inode_times().

may_write_real(), will get an NULL dentry if upper inode is metacopy only
and it will return -EPERM. Effectively, we are disallowing modifications
to metacopy only inode from this interface. Though there is opportunity
to improve it. (Allow chattr on metacopy inodes).

update_ovl_inode_times() gets inode mtime and ctime from real inode. It
should not be broken for metacopy inode as well for following reasons.

- For any metadata operations (setattr, acl etc), overlay always calls
  ovl_copyattr() and updates ovl inode mtime and ctime. So there is no
  need to update mtime and ctime in this case. Its already updated, hence
  even if d_real(D_REAL_UPPER) returns nil, it should be fine.

- For metadata inode, mtime should be same as lower and not change. (data
  can't be modified on metadata inode without copyup). IOW, mtime of
  ovl dentry should be same as mtime of underlying metadata inode on upper
  always. So there is no need to update it.

- For file writes, ctime and mtime will be updated. But in that case
  first data will be copied up and this will not be a metadata inode
  anymore. And furthr call to d_real(D_REAL_UPPER) will return upper
  inode and new mtime and ctime will be obtainable.

So atime updates should work just fine for metacopy inodes. I think only
corner case is if somehow underlying filesystem changes ctime of upper
metadata inode without overlay knowing about it. Not sure how that
can happen. If somehow is affected by that, then we probably can implement
another flag which will allow caller to get metacopy inode as well.
Something like d_real(D_REAL_UPPER | D_METACOPY). And that should solve
this issue.

Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
---
 fs/overlayfs/overlayfs.h |  1 +
 fs/overlayfs/super.c     | 21 +++++++++++++++++----
 fs/overlayfs/util.c      |  8 ++++++++
 3 files changed, 26 insertions(+), 4 deletions(-)

diff --git a/fs/overlayfs/overlayfs.h b/fs/overlayfs/overlayfs.h
index b663a65826a7..c712ab7274f9 100644
--- a/fs/overlayfs/overlayfs.h
+++ b/fs/overlayfs/overlayfs.h
@@ -214,6 +214,7 @@ void ovl_path_lowerdata(struct dentry *dentry, struct path *path);
 enum ovl_path_type ovl_path_real(struct dentry *dentry, struct path *path);
 struct dentry *ovl_dentry_upper(struct dentry *dentry);
 struct dentry *ovl_dentry_lower(struct dentry *dentry);
+struct dentry *ovl_dentry_lowerdata(struct dentry *dentry);
 struct dentry *ovl_dentry_real(struct dentry *dentry);
 struct dentry *ovl_i_dentry_upper(struct inode *inode);
 struct inode *ovl_inode_upper(struct inode *inode);
diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c
index a6e3719a599b..f5cacae8269a 100644
--- a/fs/overlayfs/super.c
+++ b/fs/overlayfs/super.c
@@ -91,8 +91,14 @@ static struct dentry *ovl_d_real(struct dentry *dentry,
 	struct dentry *real;
 	int err;
 
-	if (flags & D_REAL_UPPER)
-		return ovl_dentry_upper(dentry);
+	if (flags & D_REAL_UPPER) {
+		real = ovl_dentry_upper(dentry);
+		if (!real)
+			return NULL;
+		if (!ovl_has_upperdata(dentry))
+			return NULL;
+		return real;
+	}
 
 	if (!d_is_reg(dentry)) {
 		if (!inode || inode == d_inode(dentry))
@@ -108,15 +114,22 @@ static struct dentry *ovl_d_real(struct dentry *dentry,
 
 	real = ovl_dentry_upper(dentry);
 	if (real && (!inode || inode == d_inode(real))) {
+		bool metacopy = !ovl_has_upperdata(dentry);
 		if (!inode) {
 			err = ovl_check_append_only(d_inode(real), open_flags);
 			if (err)
 				return ERR_PTR(err);
-		}
+
+			if (unlikely(metacopy))
+				goto lower;
+		} else if (unlikely(metacopy))
+			goto bug;
+
 		return real;
 	}
 
-	real = ovl_dentry_lower(dentry);
+lower:
+	real = ovl_dentry_lowerdata(dentry);
 	if (!real)
 		goto bug;
 
diff --git a/fs/overlayfs/util.c b/fs/overlayfs/util.c
index ee0c46ae34f9..b11bb9f10464 100644
--- a/fs/overlayfs/util.c
+++ b/fs/overlayfs/util.c
@@ -170,6 +170,14 @@ struct dentry *ovl_dentry_lower(struct dentry *dentry)
 	return oe->numlower ? oe->lowerstack[0].dentry : NULL;
 }
 
+struct dentry *ovl_dentry_lowerdata(struct dentry *dentry)
+{
+	struct ovl_entry *oe = dentry->d_fsdata;
+	int idx = oe->numlower - 1;
+
+	return oe->lowerstack[idx].dentry;
+}
+
 struct dentry *ovl_dentry_real(struct dentry *dentry)
 {
 	return ovl_dentry_upper(dentry) ?: ovl_dentry_lower(dentry);
-- 
2.13.6

  parent reply	other threads:[~2018-01-31 21:13 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-31 21:13 [PATCH v11 00/18] overlayfs: Delayed copy up of data Vivek Goyal
2018-01-31 21:13 ` [PATCH v11 01/18] ovl: Do not look for OVL_XATTR_NLINK if index is not there Vivek Goyal
2018-01-31 23:52   ` Amir Goldstein
2018-01-31 21:13 ` [PATCH v11 02/18] ovl: disable redirect_dir and index when no xattr support Vivek Goyal
2018-01-31 21:13 ` [PATCH v11 03/18] ovl: Create origin xattr on copy up for all files Vivek Goyal
2018-01-31 21:13 ` [PATCH v11 04/18] ovl: Provide a mount option metacopy=on/off for metadata copyup Vivek Goyal
2018-01-31 21:13 ` [PATCH v11 05/18] ovl: During copy up, first copy up metadata and then data Vivek Goyal
2018-01-31 21:13 ` [PATCH v11 06/18] ovl: Move the copy up helpers to copy_up.c Vivek Goyal
2018-01-31 21:13 ` [PATCH v11 07/18] ovl: Copy up only metadata during copy up where it makes sense Vivek Goyal
2018-01-31 21:13 ` [PATCH v11 08/18] ovl: Add helper ovl_already_copied_up() Vivek Goyal
2018-01-31 21:13 ` [PATCH v11 09/18] ovl: A new xattr OVL_XATTR_METACOPY for file on upper Vivek Goyal
2018-01-31 21:13 ` [PATCH v11 10/18] ovl: Set OVL_UPPERDATA flag during ovl_lookup() Vivek Goyal
2018-01-31 21:13 ` [PATCH v11 11/18] ovl: Allocate bigger stack for origin Vivek Goyal
2018-02-01  0:07   ` Amir Goldstein
2018-02-01  0:38     ` Vivek Goyal
2018-01-31 21:13 ` [PATCH v11 12/18] ovl: Get and install lower most data dentry in stack Vivek Goyal
2018-02-01  0:05   ` Amir Goldstein
2018-01-31 21:13 ` [PATCH v11 13/18] ovl: Setup origin chain for lower regular files Vivek Goyal
2018-01-31 21:13 ` [PATCH v11 14/18] ovl: Do not mark a non dir as _OVL_PATH_MERGE in ovl_path_type() Vivek Goyal
2018-01-31 23:51   ` Amir Goldstein
2018-01-31 21:13 ` [PATCH v11 15/18] ovl: Copy up meta inode data from lowest data inode Vivek Goyal
2018-01-31 23:48   ` Amir Goldstein
2018-01-31 21:13 ` [PATCH v11 16/18] ovl: Fix ovl_getattr() to get number of blocks from lower Vivek Goyal
2018-01-31 21:13 ` Vivek Goyal [this message]
2018-01-31 21:13 ` [PATCH v11 18/18] ovl: Enable metadata only feature Vivek Goyal
2018-01-31 23:41 ` [PATCH v11 00/18] overlayfs: Delayed copy up of data Amir Goldstein

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=20180131211329.16328-18-vgoyal@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox