On Thu, Nov 23, 2023 at 07:53:27PM +0000, Al Viro wrote: > Huh? If it really depends only upon the superblock, just set it in ->s_d_op > when you set the superblock up. > > Again, whatever setup you do for dentry in ->lookup(), you either > * have a filesystem that never picks an existing directory alias > (e.g. doesn't allow open-by-fhandle or has a very unusual implementation > of related methods, like e.g. shmem), or > * have that setup misplaced, in part that applies to all dentries out > there (->s_d_op for universal ->d_op value, ->d_init() for uniform allocation > of objects hanging from ->d_fsdata and other things like that), or > * need to figure out how to transfer the result to alias (manually > after d_splice_alias(), if races do not matter or using a new method explicitly > for that), or > * lose that state for aliases. Note, BTW, that fscrypt tries to be very special in its handling of that stuff - see fscrypt_handle_d_move() thing and comments in front of its definition. Then take a look at the place where it's called. BTW, it looks like it's broken, since it discounts the possibility of splice caused by lookup on no-key name. You get DCACHE_NOKEY_NAME removed unconditionally there, no-key or not. It's not impossible that the boilerplate around the fscrypt_has_permitted_context() calls in fscrypt-enabled ->lookup() instances somehow prevents those, but if so, it's not obvious from the causual look.
