On Thu, Aug 03, 2023 at 01:37:45PM -0400, Gabriel Krisman Bertazi wrote: > Eric Biggers <ebiggers@xxxxxxxxxx> writes: > > > On Thu, Jul 27, 2023 at 01:28:39PM -0400, Gabriel Krisman Bertazi wrote: > >> - In __lookup_slow, either the parent inode is read locked by the > >> caller (lookup_slow), or it is called with no flags (lookup_one*). > >> The read lock suffices to prevent ->d_name modifications, with the > >> exception of one case: __d_unalias, will call __d_move to fix a > >> directory accessible from multiple dentries, which effectively swaps > >> ->d_name while holding only the shared read lock. This happens > >> through this flow: > >> > >> lookup_slow() //LOOKUP_CREATE > >> d_lookup() > >> ->d_lookup() > >> d_splice_alias() > >> __d_unalias() > >> __d_move() > >> > >> Nevertheless, this case is not a problem because negative dentries > >> are not allowed to be moved with __d_move. > > > > Isn't it possible for a negative dentry to become a positive one concurrently? > > Do you mean d_splice_alias racing with a dentry instantiation and > __d_move being called on a negative dentry that is turning positive? > > It is not possible for __d_move to be called with a negative dentry for > d_splice_alias, since the inode->i_lock is locked during __d_find_alias, > so it can't race with __d_instantiate or d_add. Then, __d_find_alias > can't find negative dentries in the first place, so we either have a > positive dentry, in which case __d_move is fine with regard to > d_revalidate_name, or we don't have any aliases and don't call > __d_move. > > Can you clarify what problem you see here? > I agree that negative dentries can't be moved --- I pointed this out earlier (https://lore.kernel.org/linux-fsdevel/20230720060657.GB2607@sol.localdomain). The question is whether if ->d_revalidate sees a negative dentry, when can it assume that it remains a negative dentry for the remainder of ->d_revalidate. I'm not sure there is a problem, I just don't understand your explanation. - Eric
