On Mon, Jul 18, 2022 at 12:04 PM Christian Kohlschütter
<christian@xxxxxxxxxxxxxxxx> wrote:
>
> The regression in question caused overlayfs to erroneously return ENOSYS when one lower filesystem (e.g., davfs2) returned this upon checking extended attributes (there were two relevant submissions triggering this somewhere around 5.15, 5.16)
Well, if that's the case, isn't the proper fix to just fix davfs2?
If ENOSYS isn't a valid error, and has broken apps that want to just
ignore "no fattr support", then it's a davfs2 bug, and fixing it there
will presumably magically just fix the ovl case too?
Yes, yes, you point to that commit to util-linux to also accept
ENOSYS, but that's from 2021.
So it's presumably triggered by the same issue - a rare (or new) and
broken filesystem returned the wrong error code.
Let's just fix that.
I do not object to *also* doing the ovlfs "accept ENOSYS too", since
it seems harmless and understandable, but at the same time this all
does make me go "the actual *fundamental* cause of this was davfs2
being confused, it should be fixed there too.
And yes, yes, I realize that davfs2 is out-of-tree fuse filesystem,
and is not in the kernel. But have people made the bug-report to the
maintainers there?
I don't think we should *only* have a kernel-side fix for a broken
FUSE filesystem. Particularly not one to some random bystander like
ovlfs.
In fact if we do a kernel patch for this dodgy filesystem, it would
seem to me to make more sense to have FUSE notice that "ok, ENOSYS is
broken for this situation, let's translate it to the right ENOTTY",
and that would have fixed both the ovlfs case and the util-linux one.
Hmm?
Linus
