[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEivzxdjjJmwPaxe5miWPxun_ZCRt-wjuCCA2nzOWWyzZZUuOg@mail.gmail.com>
Date: Mon, 3 Apr 2023 16:51:34 +0200
From: Aleksandr Mikhalitsyn <aleksandr.mikhalitsyn@...onical.com>
To: Bernd Schubert <bernd.schubert@...tmail.fm>
Cc: mszeredi@...hat.com, Al Viro <viro@...iv.linux.org.uk>,
Amir Goldstein <amir73il@...il.com>,
Stéphane Graber <stgraber@...ntu.com>,
Seth Forshee <sforshee@...nel.org>,
Christian Brauner <brauner@...nel.org>,
Andrei Vagin <avagin@...il.com>,
Pavel Tikhomirov <ptikhomirov@...tuozzo.com>,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
criu@...nvz.org
Subject: Re: [RFC PATCH 7/9] fuse: add fuse device ioctl(FUSE_DEV_IOC_REINIT)
On Mon, Mar 6, 2023 at 3:09 PM Aleksandr Mikhalitsyn
<aleksandr.mikhalitsyn@...onical.com> wrote:
>
> On Fri, Mar 3, 2023 at 8:26 PM Bernd Schubert
> <bernd.schubert@...tmail.fm> wrote:
> >
> >
> >
> > On 2/20/23 20:37, Alexander Mikhalitsyn wrote:
> > > This ioctl aborts fuse connection and then reinitializes it,
> > > sends FUSE_INIT request to allow a new userspace daemon
> > > to pick up the fuse connection.
> > >
> > > Cc: Miklos Szeredi <mszeredi@...hat.com>
> > > Cc: Al Viro <viro@...iv.linux.org.uk>
> > > Cc: Amir Goldstein <amir73il@...il.com>
> > > Cc: Stéphane Graber <stgraber@...ntu.com>
> > > Cc: Seth Forshee <sforshee@...nel.org>
> > > Cc: Christian Brauner <brauner@...nel.org>
> > > Cc: Andrei Vagin <avagin@...il.com>
> > > Cc: Pavel Tikhomirov <ptikhomirov@...tuozzo.com>
> > > Cc: linux-fsdevel@...r.kernel.org
> > > Cc: linux-kernel@...r.kernel.org
> > > Cc: criu@...nvz.org
> > > Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@...onical.com>
> > > ---
> > > fs/fuse/dev.c | 132 ++++++++++++++++++++++++++++++++++++++
> > > include/uapi/linux/fuse.h | 1 +
> > > 2 files changed, 133 insertions(+)
> > >
> > > diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
> > > index 737764c2295e..0f53ffd63957 100644
> > > --- a/fs/fuse/dev.c
> > > +++ b/fs/fuse/dev.c
> > > @@ -2187,6 +2187,112 @@ void fuse_abort_conn(struct fuse_conn *fc)
> > > }
> > > EXPORT_SYMBOL_GPL(fuse_abort_conn);
> > >
> > > +static int fuse_reinit_conn(struct fuse_conn *fc)
> > > +{
> > > + struct fuse_iqueue *fiq = &fc->iq;
> > > + struct fuse_dev *fud;
> > > + unsigned int i;
> > > +
> > > + if (fc->conn_gen + 1 < fc->conn_gen)
> > > + return -EOVERFLOW;
> > > +
> > > + fuse_abort_conn(fc);
> > > + fuse_wait_aborted(fc);
> >
> > Shouldn't this also try to flush all data first?
Dear Bernd,
I've reviewed this place 2nd time and I'm not sure that we have to
perform any flushing there, because userspace daemon can be dead or
stuck.
Technically, if userspace knows that daemon is alive then it can call
fsync/sync before doing reinit.
What do you think about it?
Kind regards,
Alex
>
> I think we should. Thanks for pointing to that!
>
> I've read all your comments and I'll prepare -v2 series soon.
>
> Thanks a lot, Bernd!
>
> >
Powered by blists - more mailing lists