On Wed, Sep 28, 2022 at 5:31 AM Brian Foster <bfoster@xxxxxxxxxx> wrote: > > I had a similar thought when poking through this. A related question I > had is how much of a functional dependency does the core passthrough > mechanism have on bpf? If bpf is optional for filtering purposes and > isn't absolutely necessary to set up a basic form of passthrough, I > think review would be made easier by splitting off those core bits from > the bpf components so each part is easier to review by people who know > them best. For example, introduce all the fuse enhancements, hooks and > cleanups to set up a passthrough to start the series, then plumb in the > bpf filtering magic on top. Hm? > The passthrough code has no dependency on the bpf functionality. I can reorder these patches to not have any bpf changes until patch 24. I'll probably change the order like I described in my previous email. The patches do become a lot more useful once the pre/post filters enter the mix though. > BTW if the bpf bits are optional, how might one mount a fuse/no > daemon/passthrough filesystem from userspace? Is that possible with this > series as is? > This is provided by patch 23. You can mount with the "no_daemon" option. Anywhere FUSE attempts to call the daemon will end up with an error, since the daemon is not connected. If you pair this with "root_dir=[fd]" and optionally "root_bpf=[fd]", you can run in a daemon-less passthrough mode. It's a bit less exciting though, since at that point you're kind of doing a bind mount with extra steps. Useful for testing though, and in theory you may be able to implement most of a daemon in bpf. > Something more on the fuse side.. it looks like we introduce a pattern > where bits of generic request completion processing can end up > duplicated between the shortcut (i.e. _backing()/_finalize()) handlers > and the traditional post request code, because the shortcuts basically > bypass the entire rest of the codepath. For example, something like > create_new_entry() is currently reused for several inode creation > operations. With passthrough mode, it looks like some of that code (i.e. > vfs dentry fixups) is split off from create_new_entry() into each > individual backing mode handler. > > It looks like much of the lower level request processing code was > refactored into the fuse_iqueue to support things like virtiofs. Have > you looked into whether that abstraction can be reused or enhanced to > support bpf filtering, direct passthrough calls, etc.? Or perhaps > whether more of the higher level code could be refactored in a similar > way to encourage more reuse and avoid branching off every fs operation > into a special passthrough codepath? > > Brian > The largest opportunity for reducing duplicate code would probably be trying to unify the backing calls between overlayfs and our work here. In places where you need to do more work than directly calling the relevant vfs calls we probably could factor out some common helpers. I haven't looked too much into that yet since I want to see where the fuse-bpf code ends up before I try to commit to that. I've thought about unifying some of the code around node creation in the backing implementations, but haven't gotten around to it yet. We definitely need to branch off for every operation though, since fuse otherwise has no concept of the backing filesystem. We do have some more work to do to ensure there is a clean handoff between regular fuse and fuse-bpf. The goal is to be able to handle just the parts you need to in the daemon, while the rest can be passed through if you're acting as a stacked filesystem. There are some oddities around things fuse does for efficiency that fuse-bpf doesn't need to do. For instance, if you're using passthrough for getattr, you don't really need to do a readdir_plus, since you don't have to worry about all the extra daemon requests. -Daniel
