From: Amir Goldstein <amir73il@gmail.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: linux-unionfs@vger.kernel.org, "# v4 . 13" <stable@vger.kernel.org>
Subject: [PATCH 02/11] ovl: verify whiteout index entries on mount
Date: Tue, 17 Oct 2017 19:00:13 +0300 [thread overview]
Message-ID: <1508256022-10267-3-git-send-email-amir73il@gmail.com> (raw)
In-Reply-To: <1508256022-10267-1-git-send-email-amir73il@gmail.com>
Whiteout index entries are used as an indication that
an exported overlay file handle should be treated as stale
(i.e. after unlink/rmdir of the overlay inode).
These entries contain no xattr.
Currently we only verify that whiteout index have a sane name,
but we do not try to decode the index name as file handle to
verify it is not stale.
This allows mounting overlayfs that has whiteout index entries
generated by newer kernel.
Fixes: 61b674710cd9 ("ovl: do not cleanup directory and whiteout index")
Cc: <stable@vger.kernel.org> # v4.13
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
---
fs/overlayfs/namei.c | 24 ++++++++++++++++--------
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/fs/overlayfs/namei.c b/fs/overlayfs/namei.c
index 6a8e0156d40d..c73f490695c6 100644
--- a/fs/overlayfs/namei.c
+++ b/fs/overlayfs/namei.c
@@ -412,16 +412,13 @@ int ovl_verify_index(struct dentry *index, struct path *lowerstack,
/*
* Directory index entries are going to be used for looking up
* redirected upper dirs by lower dir fh when decoding an overlay
- * file handle of a merge dir. Whiteout index entries are going to be
- * used as an indication that an exported overlay file handle should
- * be treated as stale (i.e. after unlink of the overlay inode).
- * We don't know the verification rules for directory and whiteout
- * index entries, because they have not been implemented yet, so return
- * EROFS if those entries are found to avoid corrupting an index that
- * was created by a newer kernel.
+ * file handle of a merge dir. We don't know the verification rules
+ * for directory index entries, because they have not been implemented
+ * yet, so return EROFS if those entries are found to avoid corrupting
+ * an index that was created by a newer kernel.
*/
err = -EROFS;
- if (d_is_dir(index) || ovl_is_whiteout(index))
+ if (d_is_dir(index))
goto fail;
err = -EINVAL;
@@ -438,6 +435,17 @@ int ovl_verify_index(struct dentry *index, struct path *lowerstack,
if (hex2bin((u8 *)fh, index->d_name.name, len) || len != fh->len)
goto fail;
+ /*
+ * Whiteout index entries are used as an indication that
+ * an exported overlay file handle should be treated as stale
+ * (i.e. after unlink/rmdir of the overlay inode).
+ * These entries contain no xattr.
+ * TODO: cleanup stale whiteout index (try to decode index name).
+ */
+ err = 0;
+ if (ovl_is_whiteout(index))
+ goto out;
+
err = ovl_verify_origin_fh(index, fh);
if (err)
goto fail;
--
2.7.4
next prev parent reply other threads:[~2017-10-17 15:59 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-17 16:00 [PATCH 00/11] Implement overlayfs index=all mount option Amir Goldstein
2017-10-17 16:00 ` [PATCH 01/11] ovl: fix EIO from lookup of non-indexed upper Amir Goldstein
2017-10-17 16:00 ` Amir Goldstein [this message]
2017-10-17 16:00 ` [PATCH 03/11] ovl: create ovl_need_index() helper Amir Goldstein
2017-10-17 16:00 ` [PATCH 04/11] ovl: add support for mount option index=all Amir Goldstein
2017-10-17 16:00 ` [PATCH 05/11] ovl: lookup index for directories Amir Goldstein
2017-10-17 16:00 ` [PATCH 06/11] ovl: verify directory index entries on mount Amir Goldstein
2017-10-19 10:35 ` Amir Goldstein
2017-10-17 16:00 ` [PATCH 07/11] ovl: index directories on copy up Amir Goldstein
2017-10-17 16:00 ` [PATCH 08/11] ovl: cleanup dir index when dir nlink drops to zero Amir Goldstein
2017-10-17 16:00 ` [PATCH 09/11] ovl: whiteout index when union " Amir Goldstein
2017-10-17 16:00 ` [PATCH 10/11] ovl: whiteout orphan index entries on mount Amir Goldstein
2017-10-17 16:00 ` [PATCH 11/11] ovl: cleanup stale whiteout " 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=1508256022-10267-3-git-send-email-amir73il@gmail.com \
--to=amir73il@gmail.com \
--cc=linux-unionfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=stable@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;
as well as URLs for NNTP newsgroup(s).