From: Vivek Goyal <vgoyal@redhat.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
linux-unionfs@vger.kernel.org, syzkaller-bugs@googlegroups.com
Subject: Re: [PATCH] ovl: detect overlapping layers
Date: Wed, 3 Apr 2019 16:46:12 -0400 [thread overview]
Message-ID: <20190403204612.GC19929@redhat.com> (raw)
In-Reply-To: <20190402193155.27555-1-amir73il@gmail.com>
On Tue, Apr 02, 2019 at 10:31:55PM +0300, Amir Goldstein wrote:
[..]
> /*
> * Does overlay inode need to be hashed by lower inode?
> */
> diff --git a/fs/overlayfs/namei.c b/fs/overlayfs/namei.c
> index efd372312ef1..badf039267a2 100644
> --- a/fs/overlayfs/namei.c
> +++ b/fs/overlayfs/namei.c
> @@ -18,6 +18,7 @@
> #include "overlayfs.h"
>
> struct ovl_lookup_data {
> + struct super_block *sb;
> struct qstr name;
> bool is_dir;
> bool opaque;
> @@ -244,6 +245,12 @@ static int ovl_lookup_single(struct dentry *base, struct ovl_lookup_data *d,
> if (!d->metacopy || d->last)
> goto out;
> } else {
> + if (ovl_lookup_trap_inode(d->sb, this)) {
> + /* Caught in a trap of overlapping layers */
> + err = -ELOOP;
> + goto out_err;
> + }
> +
Hi Amir,
This idea of putting dummy inodes in overlay inode cache hashed by inode
pointer of root inode of underlying layers seems very clever. Cost
of checking overlapping layer also seems to be O(N) and that's good.
So if we want to detect this case of overlapping layers after the mount,
then we have to pay the cost of this trap inode lookup for every dentry
found in upper/lower layer
[..]
> +static int ovl_setup_trap(struct super_block *sb, struct dentry *dir,
> + struct inode **ptrap, const char *name)
> +{
> + struct inode *trap;
> + int err;
> +
> + trap = ovl_get_trap_inode(sb, dir);
> + err = PTR_ERR(trap);
> + if (IS_ERR(trap)) {
> + pr_err("overlayfs: conflicting %s path (%i)\n", name, err);
> + return err;
> + }
> +
ovl_get_trap_inode() can fail for other reasons like -ENOMEM. Should we
warn about conflicting path only on -EEXIST.
[..]
> static int ovl_fill_super(struct super_block *sb, void *data, int silent)
> {
> struct path upperpath = { };
> @@ -1457,17 +1552,20 @@ static int ovl_fill_super(struct super_block *sb, void *data, int silent)
> if (ofs->config.xino != OVL_XINO_OFF)
> ofs->xino_bits = BITS_PER_LONG - 32;
>
> + /* alloc/destroy_inode needed for setting up traps in inode cache */
> + sb->s_op = &ovl_super_operations;
> +
Passing super block pointer to routines outside overlay before sb
initializaiton is complete, is it safe?
Thanks
Vivek
next prev parent reply other threads:[~2019-04-03 20:46 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-02 19:31 [PATCH] ovl: detect overlapping layers Amir Goldstein
2019-04-03 20:46 ` Vivek Goyal [this message]
2019-04-04 4:41 ` Amir Goldstein
2019-04-04 13:10 ` Vivek Goyal
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=20190403204612.GC19929@redhat.com \
--to=vgoyal@redhat.com \
--cc=amir73il@gmail.com \
--cc=linux-unionfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=syzkaller-bugs@googlegroups.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;
as well as URLs for NNTP newsgroup(s).