Re: why does ext4_sync_parent() bother with d_find_any_alias() at all?

On Sun, Apr 26, 2026 at 06:48:46AM +0000, [email protected] wrote:

> Prior to this patch, d_find_any_alias(inode) would reliably fetch the newest
> dentry (the new hard link) from the head of the list, successfully traversing
> and syncing the new parent directory.

FSVO "reliably"; apply memory pressure and all promises are gone.  As the matter
of fact, have another thread link() into a different directory and unlink() the
result before your fsync(), and you'll end up syncing a directory that has no
links to the file in question.

> By using file->f_path.dentry, won't ext4_sync_parent() now target the older
> dentry used to open the file descriptor? It appears it will traverse the old
> parent directory, clear the EXT4_STATE_NEWENTRY flag, and miss syncing the
> newly created link's parent directory, potentially losing the new link in the
> event of a crash.
> 
> Additionally, if the file is opened via open_by_handle_at(),
> file->f_path.dentry is a disconnected root.

Quite possibly returned by d_find_any_alias().

What warranties is the entire thing trying to provide?  Anything that relies upon
the order of dentries in the alias list is going to be quite brittle...