[PATCH 1/2] staging: exfat: clean up d_entry rebuilding.

Valdis Kl=?utf-8?Q?=c4=93?=tnieks valdis.kletnieks at vt.edu
Tue Mar 3 03:39:19 UTC 2020


On Tue, 03 Mar 2020 03:07:51 +0000, "Kohada.Tetsuhiro at dc.MitsubishiElectric.co.jp" said:

> > Are you sure this is OK to do? exfat_get_entry_type() does a lot of
> > mapping between values, using a file_dentry_t->type, while
> > fid->type is a file_id_t->type.

> The value that vfs sets to the old_dentry of exfat_rename() is the dentry value returned by exfat_lookup(), exfat_create(), and create_dir().
> In each function, the value of dentry->fid is initialized to fid->type at create_file(), ffsLookupFile(), and create_dir().
>
>  * create_file() <- ffsCreateFile() <-exfat_create()
>  * ffsLookupFile() <- exfat_find() <-exfat_lookup()
>  * exfat_mkdir() <- ffsCreateDir() <-create_dir()
>
> > and at first read it's not obvious to
> > me whether type is guaranteed to have the correct value already.
>
> A valid value is set in fid->type for all paths.
> What do you think?

OK, that's the part I was worried about, but I hadn't had enough caffeine
to do that analysis.  Thanks.

Acked-by: Valdis Kletnieks <valdis.kletnieks at vt.edu>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/attachments/20200302/0eff0d31/attachment-0001.asc>


More information about the devel mailing list