Re: [PATCH RFC] fuse: add generic file store

From: Alessio Balsini <balsini@android.com>
To: Peng Tao <tao.peng@linux.alibaba.com>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Miklos Szeredi <miklos@szeredi.hu>,
	Alessio Balsini <balsini@android.com>,
	Amir Goldstein <amir73il@gmail.com>
Subject: Re: [PATCH RFC] fuse: add generic file store
Date: Wed, 2 Jun 2021 16:50:17 +0100	[thread overview]
Message-ID: <YLeoucLiMOSPwn4U@google.com> (raw)
In-Reply-To: <1622537906-54361-1-git-send-email-tao.peng@linux.alibaba.com>

On Tue, Jun 01, 2021 at 04:58:26PM +0800, Peng Tao wrote:
> Add a generic file store that userspace can save/restore any open file
> descriptor. These file descriptors can be managed by different
> applications not just the same user space application.
> 
> A possible use case is fuse fd passthrough being developed
> by Alessio Balsini [1] where underlying file system fd can be saved in
> this file store.
> 
> Another possible use case is user space application live upgrade and
> failover (upon panic etc.). Currently during userspace live upgrade and
> failover, open file descriptors usually have to be saved seprately in
> a different management process with AF_UNIX sendmsg.
> 
> But it causes chicken and egg problem and such management process needs
> to support live upgrade and failover as well. With a generic file store
> in the kernel, application live upgrade and failover no longer require such
> management process to hold reference for their open file descriptors.
> 
> This is an RFC to see if the approach makes sense to upstream and it can be
> tested with the following C programe.
> 
> Why FUSE?
> - Because we are trying to solve FUSE fd passthrough and FUSE daemon
>   live upgrade.
> 
> Why global IDR rather than per fuse connnection one?
> - Because for live upgrade new process, we don't have a valid fuse connection
>   in the first place.
> 
> Missing cleanup method in case user space messes up?
> - We can limit the number of saved FDs and hey it is RFC ;).
> 
> [1] https://lore.kernel.org/lkml/20210125153057.3623715-1-balsini@android.com/
> --------
> 
> [...]
> 

Hi Peng,

This is a cool feature indeed.

I guess we also want to ensure that restoring an FD can only be
performed by a trusted FUSE daemon, and not any other process attached
to /dev/fuse. Maybe adding some permission checks?

I also see that multiple restores can be done on the same FD, is that
intended? Shouldn't the IDR entry be removed once restored?

As far as I understand, the main use case is to be able to replace a
FUSE daemon with another, preserving the opened lower file system files.
How would user space handle the unmounting of the old FUSE file system
and mounting of the new one?
I wonder if something can be done with a pair of ioctls similar to
FUSE_DEV_IOC_CLONE to transfer the FUSE connection from the old to the
new FUSE daemon.  Maybe either the IDR or some other container to store
the files that are intended to be preserved can be put in fuse_conn
instead of keeping it global.

Does it make sense?

Thanks,
Alessio