All of lore.kernel.org
 help / color / mirror / Atom feed
From: Amir Goldstein <amir73il@gmail.com>
To: Sargun Dhillon <sargun@sargun.me>
Cc: overlayfs <linux-unionfs@vger.kernel.org>,
	Miklos Szeredi <miklos@szeredi.hu>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Giuseppe Scrivano <gscrivan@redhat.com>,
	Vivek Goyal <vgoyal@redhat.com>,
	Daniel J Walsh <dwalsh@redhat.com>,
	David Howells <dhowells@redhat.com>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [RFC PATCH 3/3] overlay: Add the ability to remount volatile directories when safe
Date: Mon, 16 Nov 2020 13:17:53 +0200	[thread overview]
Message-ID: <CAOQ4uxjmKewbdwCQgGb4ERJXX_oA+dyOjc9M-Y0AWdNo73Xz-A@mail.gmail.com> (raw)
In-Reply-To: <20201116103013.GA13259@ircssh-2.c.rugged-nimbus-611.internal>

> > > +       inode_lock_nested(d_dirty->d_inode, I_MUTEX_XATTR);
> >
> > What's this lock for?
> >
> I need to take a lock on this inode to prevent modifications to it, right, or is
> getting the xattr safe?

No. see Documentation/filesystems/locking.rst.

>
> > > +       err = ovl_do_getxattr(d_dirty, OVL_XATTR_VOLATILE, &info, sizeof(info));
> > > +       inode_unlock(d_dirty->d_inode);
> > > +       if (err != sizeof(info))
> > > +               goto out_putdirty;
> > > +
> > > +       if (!uuid_equal(&overlay_boot_id, &info.overlay_boot_id)) {
> > > +               pr_debug("boot id has changed (reboot or module reloaded)\n");
> > > +               goto out_putdirty;
> > > +       }
> > > +
> > > +       if (d_dirty->d_inode->i_sb->s_instance_id != info.s_instance_id) {
> > > +               pr_debug("workdir has been unmounted and remounted\n");
> > > +               goto out_putdirty;
> > > +       }
> > > +
> > > +       err = errseq_check(&d_dirty->d_inode->i_sb->s_wb_err, info.errseq);
> > > +       if (err) {
> > > +               pr_debug("workdir dir has experienced errors: %d\n", err);
> > > +               goto out_putdirty;
> > > +       }
> >
> > Please put all the above including getxattr in helper ovl_verify_volatile_info()
> >
> Is it okay if the helper stays in super.c?
>

Yes.

>
> > > +
> > > +       /* Dirty file is okay, delete it. */
> > > +       ret = ovl_do_unlink(d_volatile->d_inode, d_dirty);
> >
> > That's a problem. By doing this, you have now approved a regular overlay
> > re-mount, but you need only approve a volatile overlay re-mount.
> > Need to pass ofs to ovl_workdir_cleanup{,_recurse}.
> >
> I can add a check to make sure this behaviour is only allowed on remounts back
> into volatile. There's technically a race condition here, where if there
> is an error between this check, and the mounting being finished, the FS
> could be dirty, but that already exists with the impl today.
>

If you follow my suggestion below and never unlink dirty file,
the filesystem will never be not-dirty so it is safer.

> > > +
> > > +out_putdirty:
> > > +       dput(d_dirty);
> > > +out_putvolatile:
> > > +       inode_unlock(d_volatile->d_inode);
> > > +       dput(d_volatile);
> > > +       return ret;
> > > +}
> > > +
> > > +/*
> > > + * check_incompat checks this specific incompat entry for incompatibility.
> > > + * If it is found to be incompatible -EINVAL will be returned.
> > > + *
> > > + * Any other -errno indicates an unknown error, and filesystem mounting
> > > + * should be aborted.
> > > + */
> > > +static int ovl_check_incompat(struct ovl_cache_entry *p, struct path *path)
> > > +{
> > > +       int err = -EINVAL;
> > > +
> > > +       if (!strcmp(p->name, OVL_VOLATILEDIR_NAME))
> > > +               err = ovl_check_incompat_volatile(p, path);
> > > +
> > > +       if (err == -EINVAL)
> > > +               pr_err("incompat feature '%s' cannot be mounted\n", p->name);
> > > +       else
> > > +               pr_debug("incompat '%s' handled: %d\n", p->name, err);
> > > +
> > > +       return err;
> > > +}
> > >
> > >  static int ovl_workdir_cleanup_recurse(struct path *path, int level)
> > >  {
> > > @@ -1098,10 +1175,9 @@ static int ovl_workdir_cleanup_recurse(struct path *path, int level)
> > >                         if (p->len == 2 && p->name[1] == '.')
> > >                                 continue;
> > >                 } else if (incompat) {
> > > -                       pr_err("overlay with incompat feature '%s' cannot be mounted\n",
> > > -                               p->name);
> > > -                       err = -EINVAL;
> > > -                       break;
> > > +                       err = ovl_check_incompat(p, path);
> > > +                       if (err)
> > > +                               break;
> >
> > The call to ovl_check_incompat here is too soon and it makes
> > you need to lookup both the volatile dir and dirty file.
> > What you need to do and let cleanup recurse into the next level
> > while letting it know that we are now traversing the "incompat"
> > subtree.
> >
> Maybe a dumb question but why is it incompat/volatile/dirty, rather than just
> incompat/volatile, where volatile is a file?

Not dumb. It's so old kernels cannot mount with this workdir,
because recursive cleanup never recursed more than 2 levels.
If it were just incompat/volatile old kernels would have cleaned it
and allowed it to mount.

> Are there any caveats with putting the xattr on the directory

Not that I can think of.

> , or alternatively are there any reasons not to make
> the structure incompat/volatile/dirty?
>

Old kernels as I wrote above.
The sole purpose of the dirty file is to cause rmdir on volatile to fail
in old kernels.

Thanks,
Amir.

  reply	other threads:[~2020-11-16 12:37 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-16  4:57 [RFC PATCH 0/3] Make overlayfs volatile mounts reusable Sargun Dhillon
2020-11-16  4:57 ` [RFC PATCH 1/3] fs: Add s_instance_id field to superblock for unique identification Sargun Dhillon
2020-11-16  5:07   ` Sargun Dhillon
2020-11-16  4:57 ` [RFC PATCH 2/3] overlay: Add ovl_do_getxattr helper Sargun Dhillon
2020-11-16 11:00   ` Amir Goldstein
2020-11-16  4:57 ` [RFC PATCH 3/3] overlay: Add the ability to remount volatile directories when safe Sargun Dhillon
2020-11-16  9:31   ` Amir Goldstein
2020-11-16 10:30     ` Sargun Dhillon
2020-11-16 11:17       ` Amir Goldstein [this message]
2020-11-16 12:52         ` Amir Goldstein
2020-11-16 14:42   ` Vivek Goyal
2020-11-16 14:45     ` Vivek Goyal
2020-11-16 15:20     ` Amir Goldstein
2020-11-16 16:36       ` Vivek Goyal
2020-11-16 18:25         ` Sargun Dhillon
2020-11-16 19:27           ` Vivek Goyal
2020-11-16 20:18         ` Amir Goldstein
2020-11-16 21:09           ` Vivek Goyal
2020-11-17  5:33             ` Amir Goldstein
2020-11-17 14:48               ` Vivek Goyal
2020-11-17 15:24                 ` Amir Goldstein
2020-11-17 15:40                   ` Vivek Goyal
2020-11-17 16:46                   ` Vivek Goyal
2020-11-17 18:03                     ` Amir Goldstein
2020-11-17 18:29                       ` Vivek Goyal
2020-11-18  7:24                         ` Amir Goldstein
2020-11-18  8:27                           ` Sargun Dhillon
2020-11-18 10:46                             ` Amir Goldstein
2020-11-18 14:55                           ` Vivek Goyal
2020-11-16 21:26           ` Vivek Goyal
2020-11-16 22:14             ` Sargun Dhillon
2020-11-17  5:41               ` Amir Goldstein
2020-11-17 17:05               ` Vivek Goyal
2020-11-16 17:38     ` Sargun Dhillon

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=CAOQ4uxjmKewbdwCQgGb4ERJXX_oA+dyOjc9M-Y0AWdNo73Xz-A@mail.gmail.com \
    --to=amir73il@gmail.com \
    --cc=dhowells@redhat.com \
    --cc=dwalsh@redhat.com \
    --cc=gscrivan@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=sargun@sargun.me \
    --cc=vgoyal@redhat.com \
    --cc=viro@zeniv.linux.org.uk \
    /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.