[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <176186746483.1793333.1130347070516464496@noble.neil.brown.name>
Date: Fri, 31 Oct 2025 10:37:44 +1100
From: NeilBrown <neilb@...mail.net>
To: "Al Viro" <viro@...iv.linux.org.uk>
Cc: "Christian Brauner" <brauner@...nel.org>,
"Amir Goldstein" <amir73il@...il.com>, "Jan Kara" <jack@...e.cz>,
linux-fsdevel@...r.kernel.org, "Jeff Layton" <jlayton@...nel.org>,
"Chris Mason" <clm@...com>, "David Sterba" <dsterba@...e.com>,
"David Howells" <dhowells@...hat.com>,
"Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
"Rafael J. Wysocki" <rafael@...nel.org>,
"Danilo Krummrich" <dakr@...nel.org>, "Tyler Hicks" <code@...icks.com>,
"Miklos Szeredi" <miklos@...redi.hu>,
"Chuck Lever" <chuck.lever@...cle.com>,
"Olga Kornievskaia" <okorniev@...hat.com>,
"Dai Ngo" <Dai.Ngo@...cle.com>, "Namjae Jeon" <linkinjeon@...nel.org>,
"Steve French" <smfrench@...il.com>,
"Sergey Senozhatsky" <senozhatsky@...omium.org>,
"Carlos Maiolino" <cem@...nel.org>,
"John Johansen" <john.johansen@...onical.com>,
"Paul Moore" <paul@...l-moore.com>, "James Morris" <jmorris@...ei.org>,
"Serge E. Hallyn" <serge@...lyn.com>,
"Stephen Smalley" <stephen.smalley.work@...il.com>,
"Ondrej Mosnacek" <omosnace@...hat.com>,
"Mateusz Guzik" <mjguzik@...il.com>,
"Lorenzo Stoakes" <lorenzo.stoakes@...cle.com>,
"Stefan Berger" <stefanb@...ux.ibm.com>,
"Darrick J. Wong" <djwong@...nel.org>, linux-kernel@...r.kernel.org,
netfs@...ts.linux.dev, ecryptfs@...r.kernel.org,
linux-nfs@...r.kernel.org, linux-unionfs@...r.kernel.org,
linux-cifs@...r.kernel.org, linux-xfs@...r.kernel.org,
apparmor@...ts.ubuntu.com, linux-security-module@...r.kernel.org,
selinux@...r.kernel.org
Subject: Re: [PATCH v4 11/14] Add start_renaming_two_dentries()
On Thu, 30 Oct 2025, Al Viro wrote:
> On Thu, Oct 30, 2025 at 10:31:11AM +1100, NeilBrown wrote:
>
> > +++ b/fs/debugfs/inode.c
>
> Why does debugfs_change_name() need any of that horror? Seriously, WTF?
> This is strictly a name change on a filesystem that never, ever moves
> anything from one directory to another.
"horror" is clearly in the eye of the beholder, and not a helpful
description...
Is there anything in this use of start_renaming_two_dentries() which is
harmful? I agree that not all of the functionality is needed in this
case, but some of it is.
Would you prefer we also add
start_renaming_two_dentries_with_same_parent()
or similar?
>
> IMO struct renamedata is a fucking eyesore, but that aside, this:
>
> > @@ -539,22 +540,30 @@ static int sel_make_policy_nodes(struct selinux_fs_info *fsi,
> > if (ret)
> > goto out;
> >
> > - lock_rename(tmp_parent, fsi->sb->s_root);
> > + rd.old_parent = tmp_parent;
> > + rd.new_parent = fsi->sb->s_root;
> >
> > /* booleans */
> > - d_exchange(tmp_bool_dir, fsi->bool_dir);
> > + ret = start_renaming_two_dentries(&rd, tmp_bool_dir, fsi->bool_dir);
> > + if (!ret) {
> > + d_exchange(tmp_bool_dir, fsi->bool_dir);
> >
> > - swap(fsi->bool_num, bool_num);
> > - swap(fsi->bool_pending_names, bool_names);
> > - swap(fsi->bool_pending_values, bool_values);
> > + swap(fsi->bool_num, bool_num);
> > + swap(fsi->bool_pending_names, bool_names);
> > + swap(fsi->bool_pending_values, bool_values);
> >
> > - fsi->bool_dir = tmp_bool_dir;
> > + fsi->bool_dir = tmp_bool_dir;
> > + end_renaming(&rd);
> > + }
> >
> > /* classes */
> > - d_exchange(tmp_class_dir, fsi->class_dir);
> > - fsi->class_dir = tmp_class_dir;
> > + ret = start_renaming_two_dentries(&rd, tmp_class_dir, fsi->class_dir);
> > + if (ret == 0) {
> > + d_exchange(tmp_class_dir, fsi->class_dir);
> > + fsi->class_dir = tmp_class_dir;
> >
> > - unlock_rename(tmp_parent, fsi->sb->s_root);
> > + end_renaming(&rd);
> > + }
> >
> > out:
> > sel_remove_old_bool_data(bool_num, bool_names, bool_values);
>
> is very interesting - suddenly you get two non-overlapping scopes instead of one.
> Why is that OK?
>
>From the perspective of code performing lookup of these names, two
consecutive lookups would not be locked so they could see
inconsistencies anyway.
>From the perspective of code changing these names, that is protected by
selinux_state.policy_mutex which is held across the combined operation.
A readdir could possibly see the old inum for one name and the new inum
for the other name. I don't imagine this would be a problem.
I have added a comment to the commit message to highlight this.
Thanks,
NeilBrown
Powered by blists - more mailing lists