On Thu, Mar 28, 2024 at 11:45 PM Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > My plan was to start from passthrough ioctl with O_PATH fd on lookup > and deal with performance improvements later when there are actual > workloads that report a problem and that depends where the overhead is. > > Is it with the opening of O_PATH fds? > Is it with the passthtough ioctls? > If latter, then when fuse uring is merged, I think we could get loose > the ioctls anyway. > I'm not terribly sure. Ideally I would have cc'ed them on this email, but I didn't take down contact info with my notes. I was under the impression that it was triggering all of the opens before an actual open was needed, for example, during ls -l, but I don't know if that was with O_PATH fds. I was a bit concerned that a performance fix there might end up needing a different interface, and managing multiple of those could get pretty cluttered. But I agree that it doesn't make sense to do anything there without a concrete use-case and issue. > > The original reason was to mitigate an attack vector of fooling a > privileged process into writing the fd (number) to /dev/fuse to > gain access to a backing file this way. > > The fuse-bpf way of doing all responds with ioctls seems fine for > this purpose, but note that the explicit setup also provides feedback > to the server in case the passthrough cannot be accomplished > for a specific inode (e.g. because of stacking depths overflow) > and that is a big benefit IMO. > That certainly informs the daemon of the error earlier. So long as we can still run the complete passthrough mode serverless that's fine by me. I've found that mode helpful for running filesystem tests on pure backing mode, plus I imagine some simple Fuse filesystems could get away with only the bpf programs. > > Using a global cred should be fine, just as overlayfs does. > The specific inode passthrough setup could mention if the global > cred should be used. > > However, note that overlayfs needs to handle some special cases > when using mounter creds (e.g.: ovl_create_or_link() and dropping > of CAP_SYS_RESOURCE). > > If you are going to mimic all this, better have that in the stacking fs > common code. > Sure. The less duplicate code the better :) > > That sounds like a good plan, but also, please remember Miklos' request - > please split the patch sets for review to: > 1. FUSE-passthrough-all-mode > 2. Attach BPF program > > We FUSE developers must be able to review the FUSE/passthough changes > without any BPF code at all (which we have little understanding thereof) > > As a merge strategy, I think we need to aim for merging all the FUSE > passthrough infrastructure needed for passthrough of inode operations > strictly before merging any FUSE-BPF specific code. > > In parallel you may get BPF infrastructure merged, but integrating FUSE+BPF, > should be done only after all infrastructure is already merged IMO. > Ok. I'll probably mess around with the module stuff at least, in order to work out if everything I need is present on the bpf side. Do you know if anyone is actively working on extending the file-backing work to something like inode-backing? I don't want to duplicate work there, but I'd be happy to start looking at it. Otherwise I'd focus on the bpf end for now. I expect we'll want to be able to optionally set the bpf program at the same place where we set the backing file/inode. Hence the spit into a file and inode program set. I'm still thinking over what the best way to address the programs is... > > So I don't think there is any point in anyone actually reviewing the > v4 patch set that you just posted? > Correct. The only reason I included it was as a reference for the sort of stuff fuse-bpf is currently doing. > > Please explain what you mean by that. > How are fuse-bpf file operations expected to be used and specifically, > How are they expected to extend the current FUSE passthrough functionality? > > Do you mean that an passthrough setup will include a reference to a bpf > program that will be used to decide per read/write/splice operation > whether it should be passed through to backing file or sent to server > direct_io style? > So in the current fuse-bpf setup, the bpf program does two things. It can edit certain parameters, and it can indicate what the next action should be. That action could be queuing up the post filter after the backing operation, deferring to a userspace pre/post filter, or going back to normal fuse operations. The latter one isn't currently very well fleshed out. Unless you do some specific tracking, under existing fuse-bpf you'd have a node id of 0, and userspace can't make much out of that. With that aside, there's all sorts of caching nightmares to deal with there. We're only using the parameter changing currently in our use cases. I wouldn't be opposed to leaving the falling back to fuse for specific operations out of v1 of the bpf enhancements, especially if we have the userspace pre/post filters available. So you'd optionally specify a bpf program to use with the backing file. That would allow you to manipulate some data in the files like you might in Fuse itself. For instance, data redaction. You could null out location metadata in images, provided a map or something with the offsets that should be nulled. You could also prepend some data at the beginning of a file by adjusting offsets and attrs and whatnot. I could imagine having multiple backing files, and the bpf program splitting a read into multiple parts to handle parts of it using different backing files, although that's not in the current design. > > I just wanted to make sure that you are aware of the fact that direct io > to server is the only mode of io that is allowed on an inode with an attached > backing file. > > Thanks, > Amir. > Can you not read/write without interacting with the server? Or do you mean FOPEN_DIRECT_IO sends some file ops to the server even in passthrough mode? At the moment I'm tempted to follow the same mechanics passthrough is using. The only exception would be possibly tossing back to the server, which I mentioned above. That'd only happen for, say, read, if we're not under FOPEN_DIRECT_IO. I've not looked too closely at FOPEN_DIRECT_IO. In Fuse bpf we currently have bpf mode taking priority. Are there any email threads I should look at for more background there? -Daniel
