linux-unionfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Christian Kohlschütter" <christian@kohlschutter.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: overlayfs <linux-unionfs@vger.kernel.org>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] ovl: Handle ENOSYS when fileattr support is missing in lower/upper fs
Date: Mon, 18 Jul 2022 12:56:19 +0200	[thread overview]
Message-ID: <FFA26FD1-60EF-457E-B914-E1978CCC7B57@kohlschutter.com> (raw)
In-Reply-To: <CAJfpegv5W0CycWCc2-kcn4=UVqk1hP7KrvBpzXHwW-Nmkjx8zA@mail.gmail.com>


-- 
Dr. Christian Kohlschütter



> Am 18.07.2022 um 12:31 schrieb Miklos Szeredi <miklos@szeredi.hu>:
> 
> On Mon, 18 Jul 2022 at 12:10, Christian Kohlschütter
> <christian@kohlschutter.com> wrote:
>> 
>>> Am 18.07.2022 um 11:14 schrieb Miklos Szeredi <miklos@szeredi.hu>:
>>> 
>>> On Mon, 4 Jul 2022 at 20:36, Christian Kohlschütter
>>> <christian@kohlschutter.com> wrote:
>>>> 
>>>> overlayfs may fail to complete updates when a filesystem lacks
>>>> fileattr/xattr syscall support and responds with an ENOSYS error code,
>>>> resulting in an unexpected "Function not implemented" error.
>>> 
>>> Issue seems to be with fuse: nothing should be returning ENOSYS to
>>> userspace except the syscall lookup code itself.  ENOSYS means that
>>> the syscall does not exist.
>>> 
>>> Fuse uses ENOSYS in the protocol to indicate that the filesystem does
>>> not support that operation, but that's not the value that the
>>> filesystem should be returning to userspace.
>>> 
>>> The getxattr/setxattr implementations already translate ENOSYS to
>>> EOPNOTSUPP, but ioctl doesn't.
>>> 
>>> The attached patch (untested) should do this.   Can you please give it a try?
>>> 
>>> Thanks,
>>> Miklos
>>> <fuse-ioctl-translate-enosys.patch>
>> 
>> Yes, that change basically has the same effect for the demo use case,.
>> 
>> However: it will change (and potentially) break assumptions in user space. We should never break user space.
>> 
>> Example: lsattr /test/lower
>> Currently, fuse returns ENOSYS, e.g.
>>> lsattr: reading ./lost+found: Function not implemented
>> With your change, it would return ENOTTY
>>> lsattr: reading ./lost+found: Not a tty
> 
> No, it would return success.

I'm referring to /test/lower (powered by fuse davfs2), not /test/mnt (overlayfs).

> 
>> I also tried the setup (without patches) on a very old 4.4.176 system, and everything works fine. ovl introduced the regression, so it should also be fixed there.
>> It may affect other filing systems as well (I see some other fs also return ENOSYS on occasion).
>> 
>> It's safe to say that adding the ENOSYS to the ovl code is probably the best move. Besides, you already have a workaround for ntfs-3g there as well.
> 
> Flawed arguments.  The change in overlayfs just made the preexisting
> bug in fuse visible.  The bug should still be fixed in fuse.

I understand your point from ovl's perspective, however you are proposing a fix in fuse, and so we have to see it from fuse's perspective (and its users).

From ovl's point of view, your patch fixes it because the behavior in ovl will now become how it was before the regression was introduced.
However, users of fuse that have no business with overlayfs suddenly see their ioctl return ENOTTY instead of ENOSYS.


  reply	other threads:[~2022-07-18 10:56 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-04 18:36 [PATCH] ovl: Handle ENOSYS when fileattr support is missing in lower/upper fs Christian Kohlschütter
2022-07-18  9:14 ` Miklos Szeredi
2022-07-18 10:10   ` Christian Kohlschütter
2022-07-18 10:31     ` Miklos Szeredi
2022-07-18 10:56       ` Christian Kohlschütter [this message]
2022-07-18 12:21         ` Miklos Szeredi
2022-07-18 13:03           ` [PATCH] [REGRESSION] " Christian Kohlschütter
2022-07-18 13:13             ` Miklos Szeredi
2022-07-18 14:25               ` Christian Kohlschütter
2022-07-18 15:02                 ` Antonio SJ Musumeci
2022-07-18 17:23                 ` Miklos Szeredi
2022-07-18 18:29               ` Linus Torvalds
2022-07-18 19:04                 ` Christian Kohlschütter
2022-07-18 19:17                   ` Linus Torvalds
2022-07-18 19:27                     ` Miklos Szeredi
2022-07-18 20:12                       ` Linus Torvalds
2022-07-18 20:33                         ` Christian Kohlschütter
2023-01-18  3:41                           ` Jonathan Katz
2023-01-26 13:26                             ` Miklos Szeredi
2023-01-30 19:27                               ` Jonathan Katz
2023-02-23 23:11                                 ` Jonathan Katz
2023-03-07  1:12                                   ` Jonathan Katz
2023-03-07  8:38                                     ` Miklos Szeredi
2023-03-07 17:14                                       ` Jonathan Katz
2023-03-09 15:31                                         ` Miklos Szeredi
2023-03-15  2:43                                           ` Jonathan Katz
2023-03-22 18:42                                             ` Jonathan Katz
2023-04-21 14:26                                               ` Miklos Szeredi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=FFA26FD1-60EF-457E-B914-E1978CCC7B57@kohlschutter.com \
    --to=christian@kohlschutter.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).