On Tue, Aug 26, 2025 at 9:58 PM André Almeida <andrealmeid@xxxxxxxxxx> wrote:
>
>
>
> Em 26/08/2025 12:02, Gabriel Krisman Bertazi escreveu:
> > Amir Goldstein <amir73il@xxxxxxxxx> writes:
> >
> >> On Tue, Aug 26, 2025 at 3:34 AM Gabriel Krisman Bertazi <krisman@xxxxxxx> 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;
> }
>
Yap, I've put it into ovl_set_encoding() to warn more accurately
on upper fs:
/*
* Set the ovl sb encoding as the same one used by the first layer
*/
static int ovl_set_encoding(struct super_block *sb, struct super_block *fs_sb)
{
if (!sb_has_encoding(fs_sb))
return 0;
#if IS_ENABLED(CONFIG_UNICODE)
if (sb_has_strict_encoding(fs_sb)) {
pr_err("strict encoding not supported\n");
return -EINVAL;
}
sb->s_encoding = fs_sb->s_encoding;
sb->s_encoding_flags = fs_sb->s_encoding_flags;
#endif
return 0;
}
Thanks,
Amir.
