From: Christian Brauner <brauner@kernel.org>
To: Gao Xiang <hsiangkao@linux.alibaba.com>
Cc: Jingbo Xu <jefflexu@linux.alibaba.com>,
Miklos Szeredi <miklos@szeredi.hu>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
winters.zc@antgroup.com
Subject: Re: [RFC 0/2] fuse: introduce fuse server recovery mechanism
Date: Tue, 28 May 2024 11:32:35 +0200 [thread overview]
Message-ID: <20240528-umstritten-liedchen-30e6ca6632b2@brauner> (raw)
In-Reply-To: <36c14658-2c38-4515-92e1-839553971477@linux.alibaba.com>
On Tue, May 28, 2024 at 05:13:04PM +0800, Gao Xiang wrote:
> Hi Christian,
>
> On 2024/5/28 16:43, Christian Brauner wrote:
> > On Tue, May 28, 2024 at 12:02:46PM +0800, Gao Xiang wrote:
> > >
> > >
> > > On 2024/5/28 11:08, Jingbo Xu wrote:
> > > >
> > > >
> > > > On 5/28/24 10:45 AM, Jingbo Xu wrote:
> > > > >
> > > > >
> > > > > On 5/27/24 11:16 PM, Miklos Szeredi wrote:
> > > > > > On Fri, 24 May 2024 at 08:40, Jingbo Xu <jefflexu@linux.alibaba.com> wrote:
> > > > > >
> > > > > > > 3. I don't know if a kernel based recovery mechanism is welcome on the
> > > > > > > community side. Any comment is welcome. Thanks!
> > > > > >
> > > > > > I'd prefer something external to fuse.
> > > > >
> > > > > Okay, understood.
> > > > >
> > > > > >
> > > > > > Maybe a kernel based fdstore (lifetime connected to that of the
> > > > > > container) would a useful service more generally?
> > > > >
> > > > > Yeah I indeed had considered this, but I'm afraid VFS guys would be
> > > > > concerned about why we do this on kernel side rather than in user space.
> > >
> > > Just from my own perspective, even if it's in FUSE, the concern is
> > > almost the same.
> > >
> > > I wonder if on-demand cachefiles can keep fds too in the future
> > > (thus e.g. daemonless feature could even be implemented entirely
> > > with kernel fdstore) but it still has the same concern or it's
> > > a source of duplication.
> > >
> > > Thanks,
> > > Gao Xiang
> > >
> > > > >
> > > > > I'm not sure what the VFS guys think about this and if the kernel side
> > > > > shall care about this.
> >
> > Fwiw, I'm not convinced and I think that's a big can of worms security
> > wise and semantics wise. I have discussed whether a kernel-side fdstore
> > would be something that systemd would use if available multiple times
> > and they wouldn't use it because it provides them with no benefits over
> > having it in userspace.
>
> As far as I know, currently there are approximately two ways to do
> failover mechanisms in kernel.
>
> The first model much like a fuse-like model: in this mode, we should
> keep and pass fd to maintain the active state. And currently,
> userspace should be responsible for the permission/security issues
> when doing something like passing fds.
>
> The second model is like one device-one instance model, for example
> ublk (If I understand correctly): each active instance (/dev/ublkbX)
> has their own unique control device (/dev/ublkcX). Users could
> assign/change DAC/MAC for each control device. And failover
> recovery just needs to reopen the control device with proper
> permission and do recovery.
>
> So just my own thought, kernel-side fdstore pseudo filesystem may
> provide a DAC/MAC mechanism for the first model. That is a much
> cleaner way than doing some similar thing independently in each
> subsystem which may need DAC/MAC-like mechanism. But that is
> just my own thought.
The failover mechanism for /dev/ublkcX could easily be implemented using
the fdstore. The fact that they rolled their own thing is orthogonal to
this imho. Implementing retrieval policies like this in the kernel is
slowly advancing into /proc/$pid/fd/ levels of complexity. That's all
better handled with appropriate policies in userspace. And cachefilesd
can similarly just stash their fds in the fdstore.
next prev parent reply other threads:[~2024-05-28 9:32 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-24 6:40 [RFC 0/2] fuse: introduce fuse server recovery mechanism Jingbo Xu
2024-05-24 6:40 ` [RFC 1/2] fuse: introduce recovery mechanism for fuse server Jingbo Xu
2024-05-24 6:40 ` [RFC 2/2] fuse: uid-based security enhancement for the recovery mechanism Jingbo Xu
2024-05-27 15:16 ` [RFC 0/2] fuse: introduce fuse server " Miklos Szeredi
2024-05-28 2:45 ` Jingbo Xu
2024-05-28 3:08 ` Jingbo Xu
2024-05-28 4:02 ` Gao Xiang
2024-05-28 8:43 ` Christian Brauner
2024-05-28 9:13 ` Gao Xiang
2024-05-28 9:32 ` Christian Brauner [this message]
2024-05-28 9:58 ` Gao Xiang
2024-05-28 7:46 ` Miklos Szeredi
2024-05-28 7:45 ` Miklos Szeredi
2024-05-28 8:38 ` Christian Brauner
2024-05-28 9:45 ` Jingbo Xu
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=20240528-umstritten-liedchen-30e6ca6632b2@brauner \
--to=brauner@kernel.org \
--cc=hsiangkao@linux.alibaba.com \
--cc=jefflexu@linux.alibaba.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=winters.zc@antgroup.com \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).