Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 9 Jun 2021 09:46:38 +0200
From:   Greg Kurz <groug@kaod.org>
To:     Max Reitz <mreitz@redhat.com>
Cc:     Miklos Szeredi <miklos@szeredi.hu>, linux-kernel@vger.kernel.org,
        linux-fsdevel@vger.kernel.org, virtio-fs@redhat.com,
        Vivek Goyal <vgoyal@redhat.com>
Subject: Re: [PATCH v2 0/7] fuse: Some fixes for submounts
Message-ID: <20210609094638.197ca7fc@bahia.lan>
In-Reply-To: <c3d49438-6ee1-32b1-1be4-41be78cec2ce@redhat.com>
References: <20210604161156.408496-1-groug@kaod.org>
        <c3d49438-6ee1-32b1-1be4-41be78cec2ce@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT
Precedence: bulk

On Tue, 8 Jun 2021 17:52:13 +0200
Max Reitz <mreitz@redhat.com> wrote:

> On 04.06.21 18:11, Greg Kurz wrote:
> > v2:
> >
> > - add an extra fix (patch 2) : mount is now added to the list before
> >    unlocking sb->s_umount
> > - set SB_BORN just before unlocking sb->s_umount, just like it would
> >    happen when using fc_mount() (Max)
> > - don't allocate a FUSE context for the submounts (Max)
> > - introduce a dedicated context ops for submounts
> > - add a extra cleanup : simplify the code even more with fc_mount()
> >
> > v1:
> >
> > While working on adding syncfs() support in FUSE, I've hit some severe
> > bugs with submounts (a crash and an infinite loop). The fix for the
> > crash is straightforward (patch 1), but the fix for the infinite loop
> > is more invasive : as suggested by Miklos, a simple bug fix is applied
> > first (patch 2) and the final fix (patch 3) is applied on top.
> 
> Thanks a lot for these patches. I’ve had a style nit on patch 6, but 
> other than that, looks nice to me.
> 

Thanks a lot for the review !

Cheers,

--
Greg

> Max
>