Re: [PATCH v6 4/9] ovl: Create ovl_casefold() to support casefolded strncmp()

["André Almeida" <andrealmeid@igalia.com>]

Em 26/08/2025 12:02, Gabriel Krisman Bertazi escreveu:
> Amir Goldstein <amir73il@gmail.com> writes:
> 
>> On Tue, Aug 26, 2025 at 3:34 AM Gabriel Krisman Bertazi <krisman@suse.de> wrote:
>>
>>>
>>> I was thinking again about this and I suspect I misunderstood your
>>> question.  let me try to answer it again:
>>>
>>> Ext4, f2fs and tmpfs all allow invalid utf8-encoded strings in a
>>> casefolded directory when running on non-strict-mode.  They are treated
>>> as non-encoded byte-sequences, as if they were seen on a case-Sensitive
>>> directory.  They can't collide with other filenames because they
>>> basically "fold" to themselves.
>>>
>>> Now I suspect there is another problem with this series: I don't see how
>>> it implements the semantics of strict mode.  What happens if upper and
>>> lower are in strict mode (which is valid, same encoding_flags) but there
>>> is an invalid name in the lower?  overlayfs should reject the dentry,
>>> because any attempt to create it to the upper will fail.
>>
>> Ok, so IIUC, one issue is that return value from ovl_casefold() should be
>> conditional to the sb encoding_flags, which was inherited from the
>> layers.
> 
> yes, unless you reject mounting strict_mode filesystems, which the best
> course of action, in my opinion.
> 
>>
>> Again, *IF* I understand correctly, then strict mode ext4 will not allow
>> creating an invalid-encoded name, but will strict mode ext4 allow
>> it as a valid lookup result?
> 
> strict mode ext4 will not allow creating an invalid-encoded name. And
> even lookups will fail.  Because the kernel can't casefold it, it will
> assume the dirent is broken and ignore it during lookup.
> 
> (I just noticed the dirent is ignored and the error is not propagated in
> ext4_match.  That needs improvement.).
> 
>>>
>>> André, did you consider this scenario?
>>
>> In general, as I have told Andre from v1, please stick to the most common
>> configs that people actually need.
>>
>> We do NOT need to support every possible combination of layers configurations.
>>
>> This is why we went with supporting all-or-nothing configs for casefolder dirs.
>> Because it is simpler for overlayfs semantics and good enough for what
>> users need.
>>
>> So my question is to you both: do users actually use strict mode for
>> wine and such?
>> Because if they don't I would rather support the default mode only
>> (enforced on mount)
>> and add support for strict mode later per actual users demand.
> 
> I doubt we care.  strict mode is a restricted version of casefolding
> support with minor advantages.  Basically, with it, you can trust that
> if you update the unicode version, there won't be any behavior change in
> casefolding due to newly assigned code-points.  For Wine, that is
> irrelevant.
> 
> You can very well reject strict mode and be done with it.
> 

Amir,

I think this can be done at ovl_get_layers(), something like:

if (sb_has_strict_encoding(sb)) {
	pr_err("strict encoding not supported\n");
	return -EINVAL;
}