On Wed, 2025-07-23 at 03:32 +0100, Al Viro wrote:
> On Tue, Jul 22, 2025 at 01:13:45AM -0600, Yangtao Li wrote:
>
> > @@ -552,9 +553,13 @@ static int hfsplus_rename(struct mnt_idmap *idmap,
> > res = hfsplus_rename_cat((u32)(unsigned long)old_dentry->d_fsdata,
> > old_dir, &old_dentry->d_name,
> > new_dir, &new_dentry->d_name);
> > - if (!res)
> > - new_dentry->d_fsdata = old_dentry->d_fsdata;
> > - return res;
> > + if (res)
> > + return res;
> > +
> > + new_dentry->d_fsdata = old_dentry->d_fsdata;
>
> Umm... Is that assignment (either before or after that patch)
> actually correct?
>
> Note that new_dentry essentially got unlinked here; old_dentry
> is about to have its parent/name changed by the caller of ->rename(),
> so... that looks very odd.
>
> What is that line about?
So, as far as I can see, the dentry structure [1] has:
void *d_fsdata; /* fs-specific data */
And HFS+ is using this field to store Catalog File's ID (CNID) of
the file or folder, for example [2]:
static inline void hfsplus_instantiate(struct dentry *dentry,
struct inode *inode, u32 cnid)
{
dentry->d_fsdata = (void *)(unsigned long)cnid;
d_instantiate(dentry, inode);
}
So, this line simply copies CNID from old_dentry->d_fsdata to
new_dentry->d_fsdata during the rename operation. I assume that
->fs_data should be untouched by generic logic of dentries processing.
Thanks,
Slava.
[1]
https://elixir.bootlin.com/linux/v6.16-rc6/source/include/linux/dcache.h#L108
[2]
https://elixir.bootlin.com/linux/v6.16-rc7/source/fs/hfsplus/dir.c#L25
