Al Viro <viro@xxxxxxxxxxxxxxxxxx> writes:
> On Thu, Nov 23, 2023 at 02:06:39PM -0500, Gabriel Krisman Bertazi wrote:
>
>> > A paragraph above you've said that it's not constant over the entire
>> > filesystem.
>>
>> The same ->d_op is used by every dentry in the filesystem if the superblock
>> has the casefold bit enabled, regardless of whether a specific inode is
>> casefolded or not. See generic_set_encrypted_ci_d_ops in my tree. It is
>> called unconditionally by ext4_lookup and only checks the superblock:
>>
>> void generic_set_encrypted_ci_d_ops(struct dentry *dentry)
>> {
>> if (dentry->d_sb->s_encoding) {
>> d_set_d_op(dentry, &generic_encrypted_ci_dentry_ops);
>> return;
>> }
>> ...
>>
>> What I meant was that this used to be set once at sb->s_d_op, and
>> propagated during dentry allocation. Therefore, the propagation to the
>> alias would happen inside __d_alloc. Once we enabled fscrypt and
>> casefold to work together, sb->s_d_op is NULL
>
> Why? That's what I don't understand - if you really want it for
> all dentries on that filesystem, that's what ->s_d_op is for.
> If it is not, you have that problem, no matter which way you flip ->d_op
> value.
I'm not sure why it changed. I'm guessing that, since it doesn't make
sense to set fscrypt_d_revalidate for every dentry in the
!case-insensitive case, they just kept the same behavior for
case-insensitive+fscrypt. This is what I get from looking at the git
history.
I will get a new series reverting to use ->s_d_op, folding the
dentry_cmp behavior you mentioned, and based on what you merge in your
branch.
>> and we always set the same
>> handler for every dentry during lookup.
>
> Not every dentry goes through lookup - see upthread for details.
Yes, I got that already. This should be "we always set the same handler
for every dentry that goes through lookup and bork whatever doesn't come
through lookup."
--
Gabriel Krisman Bertazi
