Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220511013057.245827-1-dlunev@chromium.org> <CAJfpegsmyY+D4kK3ov51FLGA=RkyGDKMcYiMo2zBqYuFNs78JQ@mail.gmail.com>
In-Reply-To: <CAJfpegsmyY+D4kK3ov51FLGA=RkyGDKMcYiMo2zBqYuFNs78JQ@mail.gmail.com>
From:   Daniil Lunev <dlunev@chromium.org>
Date:   Wed, 11 May 2022 17:36:37 +1000
Message-ID: <CAONX=-dqY64VkqF6cNYvm8t-ad8XRqDhELP9icfPTPD2iLobLA@mail.gmail.com>
Subject: Re: [PATCH 0/2] Prevent re-use of FUSE superblock after force unmount
To:     Miklos Szeredi <miklos@szeredi.hu>
Cc:     linux-fsdevel@vger.kernel.org,
        fuse-devel <fuse-devel@lists.sourceforge.net>,
        linux-kernel@vger.kernel.org,
        Alexander Viro <viro@zeniv.linux.org.uk>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Wed, May 11, 2022 at 5:07 PM Miklos Szeredi <miklos@szeredi.hu> wrote:
>
> On Wed, 11 May 2022 at 03:31, Daniil Lunev <dlunev@chromium.org> wrote:
> >
> > Force unmount of fuse severes the connection between FUSE driver and its
> > userspace counterpart.
>
> Why is forced umount being used in the first place?

To correctly suspend-resume. We have been using this force unmount historically
to circumvent the suspend-resume issues which periodically occur with fuse.
We observe FUSE rejecting to remount the device because of the issue this
patchset attempts to address after the resume if there are still open
file handles
holding old super blocks. I am not sure if fuse's interaction with suspend is
something that has been resolved systematically (we are also trying to
figure that
out). Regardless of that, doing force unmount of a mount point is a legitimate
operation, and with FUSE it may leave the system in a state that is returning
errors for other legitimate operations.

Thanks,
Daniil