linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: NeilBrown <neilb@ownmail.net>
To: "Amir Goldstein" <amir73il@gmail.com>
Cc: "Alexander Viro" <viro@zeniv.linux.org.uk>,
	"Christian Brauner" <brauner@kernel.org>,
	"Jeff Layton" <jlayton@kernel.org>, "Jan Kara" <jack@suse.cz>,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 09/11] VFS/ovl/smb: introduce start_renaming_dentry()
Date: Wed, 01 Oct 2025 14:35:58 +1000	[thread overview]
Message-ID: <175929335864.1696783.9943644484099275405@noble.neil.brown.name> (raw)
In-Reply-To: <CAOQ4uxiZ=R16EN+Ha_HxgxAhE1r2vKX4Ck+H9_AfyB4a6=9=Zw@mail.gmail.com>

On Tue, 30 Sep 2025, Amir Goldstein wrote:
> On Fri, Sep 26, 2025 at 4:51 AM NeilBrown <neilb@ownmail.net> wrote:
> > + * On success the found dentry is stored in @rd.new_dentry and
> > + * @rd.old_parent is confirmed to be the parent of @old_dentry.  If it
> > + * was originally %NULL, it is set.  In either case a refernence is taken.
> 
> Typo: %NULL, typo: refernence

%NULL isn't a typo.  As documented in kernel-doc.rst

   %CONST
   should be used to give appropriate formatting to constant.

Thanks for the refernence fix!

NeilBrown


> 
> > + *
> > + * References and the lock can be dropped with end_renaming()
> > + *
> > + * The passed in qstr need not have the hash calculated, and basic
> > + * eXecute permission checking is performed against @rd.mnt_idmap.
> > + *
> > + * Returns: zero or an error.
> > + */
> > +int start_renaming_dentry(struct renamedata *rd, int lookup_flags,
> > +                         struct dentry *old_dentry, struct qstr *new_last)
> > +{
> > +       int err;
> > +
> > +       err = lookup_one_common(rd->mnt_idmap, new_last, rd->new_parent);
> > +       if (err)
> > +               return err;
> > +       return __start_renaming_dentry(rd, lookup_flags, old_dentry, new_last);
> > +}
> > +
> >  void end_renaming(struct renamedata *rd)
> >  {
> >         unlock_rename(rd->old_parent, rd->new_parent);
> >         dput(rd->old_dentry);
> >         dput(rd->new_dentry);
> > +       dput(rd->old_parent);
> >  }
> >  EXPORT_SYMBOL(end_renaming);
> >
> > diff --git a/fs/overlayfs/copy_up.c b/fs/overlayfs/copy_up.c
> > index 6a31ea34ff80..3f19548b5d48 100644
> > --- a/fs/overlayfs/copy_up.c
> > +++ b/fs/overlayfs/copy_up.c
> > @@ -523,8 +523,8 @@ static int ovl_create_index(struct dentry *dentry, const struct ovl_fh *fh,
> >  {
> >         struct ovl_fs *ofs = OVL_FS(dentry->d_sb);
> >         struct dentry *indexdir = ovl_indexdir(dentry->d_sb);
> > -       struct dentry *index = NULL;
> >         struct dentry *temp = NULL;
> > +       struct renamedata rd = {};
> >         struct qstr name = { };
> >         int err;
> >
> > @@ -556,17 +556,15 @@ static int ovl_create_index(struct dentry *dentry, const struct ovl_fh *fh,
> >         if (err)
> >                 goto out;
> >
> > -       err = ovl_parent_lock(indexdir, temp);
> > +       rd.mnt_idmap = ovl_upper_mnt_idmap(ofs);
> > +       rd.old_parent = indexdir;
> > +       rd.new_parent = indexdir;
> > +       err = start_renaming_dentry(&rd, 0, temp, &name);
> >         if (err)
> >                 goto out;
> > -       index = ovl_lookup_upper(ofs, name.name, indexdir, name.len);
> > -       if (IS_ERR(index)) {
> > -               err = PTR_ERR(index);
> > -       } else {
> > -               err = ovl_do_rename(ofs, indexdir, temp, indexdir, index, 0);
> > -               dput(index);
> > -       }
> > -       ovl_parent_unlock(indexdir);
> > +
> > +       err = ovl_do_rename_rd(&rd);
> > +       end_renaming(&rd);
> >  out:
> >         if (err)
> >                 ovl_cleanup(ofs, indexdir, temp);
> > @@ -763,7 +761,8 @@ static int ovl_copy_up_workdir(struct ovl_copy_up_ctx *c)
> >         struct ovl_fs *ofs = OVL_FS(c->dentry->d_sb);
> >         struct inode *inode;
> >         struct path path = { .mnt = ovl_upper_mnt(ofs) };
> > -       struct dentry *temp, *upper, *trap;
> > +       struct renamedata rd = {};
> > +       struct dentry *temp;
> >         struct ovl_cu_creds cc;
> >         int err;
> >         struct ovl_cattr cattr = {
> > @@ -807,29 +806,27 @@ static int ovl_copy_up_workdir(struct ovl_copy_up_ctx *c)
> >          * ovl_copy_up_data(), so lock workdir and destdir and make sure that
> >          * temp wasn't moved before copy up completion or cleanup.
> >          */
> > -       trap = lock_rename(c->workdir, c->destdir);
> > -       if (trap || temp->d_parent != c->workdir) {
> > +       rd.mnt_idmap = ovl_upper_mnt_idmap(ofs);
> > +       rd.old_parent = c->workdir;
> > +       rd.new_parent = c->destdir;
> > +       rd.flags = 0;
> > +       err = start_renaming_dentry(&rd, 0, temp,
> > +                                   &QSTR_LEN(c->destname.name, c->destname.len));
> > +       if (err == -EINVAL || err == -EXDEV) {
> 
> This error code whitelist is not needed and is too fragile anyway.
> After your commit
> 9d23967b18c64 ("ovl: simplify an error path in ovl_copy_up_workdir()")
> any locking error is treated the same - it does not matter what the
> reason for lock_rename() or start_renaming_dentry() is.
> 
> >                 /* temp or workdir moved underneath us? abort without cleanup */
> >                 dput(temp);
> >                 err = -EIO;
> > -               if (!IS_ERR(trap))
> > -                       unlock_rename(c->workdir, c->destdir);
> >                 goto out;
> >         }
> 
> Frankly, we could get rid of the "abort without cleanup"
> comment and instead: err = -EIO; goto cleanup_unlocked;
> because before cleanup_unlocked, cleanup was relying on the
> lock_rename() to take the lock for the cleanup, but we don't need
> that anymore.
> 
> To be clear, I don't think is it important to goto cleanup_unlocked,
> leaving goto out is fine because we are not very sympathetic
> to changes to underlying layers while ovl is mounted, so we should
> not really care about this cleanup, but for the sake of simpler code
> I wouldn't mind the goto cleanup_unlocked.
> 
> > -
> > -       err = ovl_copy_up_metadata(c, temp);
> >         if (err)
> >                 goto cleanup;
> 
> Is this right? should we be calling end_renaming() on error?
> 
> Thanks,
> Amir.
> 


  parent reply	other threads:[~2025-10-01  4:36 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-26  2:49 [PATCH 00/11] Create APIs to centralise locking for directory ops NeilBrown
2025-09-26  2:49 ` [PATCH 01/11] debugfs: rename end_creating() to debugfs_end_creating() NeilBrown
2025-09-27  9:13   ` Amir Goldstein
2025-09-27 11:29   ` Jeff Layton
2025-09-26  2:49 ` [PATCH 02/11] VFS: introduce start_dirop() and end_dirop() NeilBrown
2025-09-26 16:41   ` Amir Goldstein
2025-09-27 11:32     ` NeilBrown
2025-09-26  2:49 ` [PATCH 03/11] VFS/nfsd/cachefiles/ovl: add start_creating() and end_creating() NeilBrown
2025-09-29 12:37   ` Jeff Layton
2025-09-30  5:37     ` NeilBrown
2025-09-30 10:19       ` Jeff Layton
2025-09-30  8:54   ` Amir Goldstein
2025-10-01  3:15     ` NeilBrown
2025-10-02 10:52       ` Amir Goldstein
2025-09-26  2:49 ` [PATCH 04/11] VFS/nfsd/cachefiles/ovl: introduce start_removing() and end_removing() NeilBrown
2025-09-27  9:12   ` Amir Goldstein
2025-10-02 17:02   ` Jeff Layton
2025-09-26  2:49 ` [PATCH 05/11] VFS: introduce start_creating_noperm() and start_removing_noperm() NeilBrown
2025-09-28 12:26   ` Amir Goldstein
2025-10-02 17:13   ` Jeff Layton
2025-09-26  2:49 ` [PATCH 06/11] VFS: introduce start_removing_dentry() NeilBrown
2025-09-27  9:32   ` Amir Goldstein
2025-09-27 11:55     ` NeilBrown
2025-10-02 17:19   ` Jeff Layton
2025-09-26  2:49 ` [PATCH 07/11] VFS: add start_creating_killable() and start_removing_killable() NeilBrown
2025-09-28 12:05   ` Amir Goldstein
2025-09-29  1:44     ` NeilBrown
2025-09-26  2:49 ` [PATCH 08/11] VFS/nfsd/ovl: introduce start_renaming() and end_renaming() NeilBrown
2025-09-29 11:23   ` Amir Goldstein
2025-09-26  2:49 ` [PATCH 09/11] VFS/ovl/smb: introduce start_renaming_dentry() NeilBrown
2025-09-26 15:43   ` kernel test robot
2025-09-26 17:17   ` kernel test robot
2025-09-30  7:08   ` Amir Goldstein
2025-10-01  1:45     ` NeilBrown
2025-10-02 10:56       ` Amir Goldstein
2025-10-01  4:35     ` NeilBrown [this message]
2025-09-26  2:49 ` [PATCH 10/11] Add start_renaming_two_dentrys() NeilBrown
2025-09-30  7:46   ` Amir Goldstein
2025-10-01  4:14     ` NeilBrown
2025-09-26  2:49 ` [PATCH 11/11] ecryptfs: use new start_creaing/start_removing APIs NeilBrown
2025-09-26 16:03   ` kernel test robot
2025-09-28 12:50   ` Amir Goldstein
2025-09-29  5:26     ` NeilBrown
2025-09-29  7:53       ` Amir Goldstein
2025-10-01  1:31         ` NeilBrown
2025-10-02 10:25           ` Amir Goldstein
2025-09-26 15:47 ` [PATCH 00/11] Create APIs to centralise locking for directory ops Amir Goldstein
2025-09-27 11:20   ` NeilBrown
2025-10-01  5:04     ` NeilBrown

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=175929335864.1696783.9943644484099275405@noble.neil.brown.name \
    --to=neilb@ownmail.net \
    --cc=amir73il@gmail.com \
    --cc=brauner@kernel.org \
    --cc=jack@suse.cz \
    --cc=jlayton@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=neil@brown.name \
    --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 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).