Re: [PATCH] [REGRESSION] ovl: Handle ENOSYS when fileattr support is missing in lower/upper fs

[Miklos Szeredi]

On Mon, 18 Jul 2022 at 15:03, Christian Kohlschütter
<christian@xxxxxxxxxxxxxxxx> wrote:
>
> Am 18.07.2022 um 14:21 schrieb Miklos Szeredi <miklos@xxxxxxxxxx>:
> >
> > On Mon, 18 Jul 2022 at 12:56, Christian Kohlschütter
> > <christian@xxxxxxxxxxxxxxxx> wrote:
> >
> >> However, users of fuse that have no business with overlayfs suddenly see their ioctl return ENOTTY instead of ENOSYS.
> >
> > And returning ENOTTY is the correct behavior.  See this comment in
> > <asm-generic/errrno.h>:
> >
> > /*
> > * This error code is special: arch syscall entry code will return
> > * -ENOSYS if users try to call a syscall that doesn't exist.  To keep
> > * failures of syscalls that really do exist distinguishable from
> > * failures due to attempts to use a nonexistent syscall, syscall
> > * implementations should refrain from returning -ENOSYS.
> > */
> > #define ENOSYS 38 /* Invalid system call number */
> >
> > Thanks,
> > Miklos
>
> That ship is sailed since ENOSYS was returned to user-space for the first time.
>
> It reminds me a bit of Linus' "we do not break userspace" email from 2012 [1, 2], where Linus wrote:
> > Applications *do* care about error return values. There's no way in
> > hell you can willy-nilly just change them. And if you do change them,
> > and applications break, there is no way in hell you can then blame the
> > application.

Correct.  The question is whether any application would break in this
case.  I think not, but you are free to prove otherwise.

Thanks,
Miklos