Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Gabriel Krisman Bertazi <krisman@suse.de>
To:     Eric Biggers <ebiggers@kernel.org>
Cc:     viro@zeniv.linux.org.uk, brauner@kernel.org, tytso@mit.edu,
        jaegeuk@kernel.org, linux-fsdevel@vger.kernel.org,
        linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [PATCH v2 4/7] libfs: Support revalidation of encrypted
 case-insensitive dentries
Organization: SUSE
References: <20230422000310.1802-1-krisman@suse.de>
        <20230422000310.1802-5-krisman@suse.de>
        <20230714053135.GD913@sol.localdomain> <87h6q1580a.fsf@suse.de>
        <20230718221040.GA1005@sol.localdomain>
Date:   Wed, 19 Jul 2023 14:27:05 -0400
In-Reply-To: <20230718221040.GA1005@sol.localdomain> (Eric Biggers's message
        of "Tue, 18 Jul 2023 15:10:40 -0700")
Message-ID: <874jlz69l2.fsf@suse.de>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

Eric Biggers <ebiggers@kernel.org> writes:

> Why would order matter?  If either "feature" wants the dentry to be invalidated,
> then the dentry gets invalidated.

For instance, I was wondering makes sense for instance to memcmp d_name for
!DCACHE_NOKEY_NAME or if we wanted fscrypt_d_revalidate to come first.

>> Note we will start creating negative dentries in casefold directories after
>> patch 6/7, so unless we disable it here, we will start calling
>> fscrypt_d_revalidate for negative+casefold.
>
> fscrypt_d_revalidate() only cares about the DCACHE_NOKEY_NAME flag, so that's
> not a problem.

..I see now it is the first thing checked in fscrypt_d_revalidate.

>> Should I just drop this hunk?  Unless you are confident it works as is, I
>> prefer to add this support in stages and keep negative dentries of
>> encrypted+casefold directories disabled for now.
>
> Unless I'm missing something, I think you're overcomplicating it.

Not overcomplicating. I'm just not familiar with fscrypt details enough to be
sure I could enable it.  But yes, it seems safe.

> It should
> just work if you don't go out of your way to prohibit this case.  I.e., just
> don't add the IS_ENCRYPTED(dir) check to generic_ci_d_revalidate().

I'll drop the check. And resend.

Thanks,

-- 
Gabriel Krisman Bertazi