[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87plzzgou0.fsf@>
Date: Fri, 24 Nov 2023 10:20:39 -0500
From: Gabriel Krisman Bertazi <gabriel@...sman.be>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: Gabriel Krisman Bertazi <gabriel@...sman.be>, Linus Torvalds
<torvalds@...ux-foundation.org>, Christian Brauner <brauner@...nel.org>,
tytso@....edu, linux-f2fs-devel@...ts.sourceforge.net,
ebiggers@...nel.org, linux-fsdevel@...r.kernel.org, jaegeuk@...nel.org,
linux-ext4@...r.kernel.org
Subject: Re: [f2fs-dev] [PATCH v6 0/9] Support negative dentries on
case-insensitive ext4 and f2fs
Al Viro <viro@...iv.linux.org.uk> 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
Powered by blists - more mailing lists