any reason for CONFIG_FUSE_FS=y

[Dimitri John Ledkov]

On Tue, 9 Aug 2022 at 16:24, Bernd Schubert <bs_lists at aakef.fastmail.fm> wrote:
>
> Hi Dimitri,
>
> On 8/9/22 15:54, Dimitri John Ledkov wrote:
> > Hi,
> >
> > On Tue, 9 Aug 2022 at 14:22, Bernd Schubert <bs_lists at aakef.fastmail.fm> wrote:
> >>
> >> Hello,
> >>
> >> I would like to ask if there is a good reason Ubuntu builds fuse as
> >> statically into the kernel instead of using a module?
> >>
> >> Reason I'm asking is that we are currently working on a couple of fuse
> >> improvements and
> >>
> >> a) A static module makes development a bit harder, I cannot take any
> >> quickly installed ubuntu system and just load an updated module, but
> >> always need to install a non custom kernel package.
> >>
> >> b) Makes it impossible to provide the updated module as preview to our
> >> customers, without extra work like renaming all exported symbols and
> >> adding another /dev/something char device to replace /dev/fuse
> >>
> >> c) Makes it hard for us to support customer issues if a fuse issue
> >> should come up (rare case).
> >>
> >
> > Historically this is due to many bugs with dynamically loaded fuse. It
> > is an autoloadable module, thus userspace requesting fuse would
> > autoload it. then later one has to mount /sys/fs/fuse/connections
> > which is all racy. And in practice fuse is often always in use as
> > well..... on my system it is common to mount things in nautilus with
> > fuse; lxd/lxc uses fuse; and keybase as well. Also my windows
> > partition is mounted with fuse (not sure why it's not using kernel's
> > module here).
> >
> > you can change ACL methods to not make /dev/fuse accesible; or change
> > udev rules not not even create it; then make your loaded module
> > provide /dev/fuse possibly under a different character device number.
> > You can use linux-backports infrastructure to create a
> > non-symbol-clashing fuse module (see how we build and vendor
> > backports-iwlwifi module). Or something similar.
>
> hmm ok, I would have added "modprobe fuse" in a initramfs script and so
> only users who manually unloaded the module would get issues?
>

The fast majority of Ubuntu installations boot without initramfs at
all. And doing modprobe during early boot would be racy.
Also there becomes a non-trivial upgrade issue, where we have to roll
out a change to modprobe fuse everywhere first, before being able to
change kernel config from y to m.
For no apparent benefit to fast majority of users - just introducing
race / requirement to modprobe fuse.

I will check if static nodes for fuse are pre-created even with the
module not loaded, in which case it might be relatively safish to make
it a module. But given that it is almost always used on both desktops
and servers, I find it counterintuitive to make it a module, and thus
have a tiny module penalty (in terms of bootspeed, loading it from
disk, and having it a module vs builtin).

In general, I do wonder if there are any better kernel mechanisms for
overriding built-in modules.

> >
> > But furthermore.... If you have an improved fuse module, can we not
> > make it available as part of stock Ubuntu or Ubuntu Pro? If it is
> > useful, and your customers are on Ubuntu, let's make it the best out
> > of the box experience.
> >
>
> We are in the process to upstream out changes. We got disrupted by other
> work for our main product but will continue to send new patches soon.
> However, as expected getting the patches upstream takes time, which is
> replacing the module might be helpful.
>

You can open a bug report in launchpad and attempt to submit pull
requests to Ubuntu directly. We do carry many features and backports
of features that are in progress of making it into mainline, or are
being pulled from maintainer trees. See for example how many SAUCE
patches we carry for apparmor, intel cpu features, ibm power cpu
features and so on. Depending on how clean and maintained your fuse
tree is it might be suitable for inclusion in Ubuntu kernels ahead of
vanilla mainline.

-- 
okurrr,

Dimitri