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.
>
next prev 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).