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;
}
