Date: Sun, 26 Apr 2026 08:15:01 +0100
From: Al Viro <viro@zeniv.linux.org.uk>
To: sashiko@lists.linux.dev
Cc: tytso@mit.edu
Subject: Re: why does ext4_sync_parent() bother with d_find_any_alias() at
 all?
Message-ID: <20260426071501.GR3518998@ZenIV>
References: <20260426061009.GQ3518998@ZenIV>
 <20260426064847.49E5AC2BCAF@smtp.kernel.org>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20260426064847.49E5AC2BCAF@smtp.kernel.org>
Sender: Al Viro <viro@ftp.linux.org.uk>

On Sun, Apr 26, 2026 at 06:48:46AM +0000, sashiko-bot@kernel.org 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...