On Mon, Sep 12, 2022 at 8:29 AM Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > On Mon, Sep 12, 2022 at 12:29 PM Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > > > On Sat, 10 Sept 2022 at 10:52, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > > > > I think we should accept the fact that just as any current FUSE > > > passthrough (in userspace) implementation is limited to max number of > > > open files as the server's process limitation, kernel passthrough implementation > > > will be limited by inheriting the mounter's process limitation. > > > > > > There is no reason that the server should need to keep more > > > passthrough fd's open than client open fds. > > > > Maybe you're right. > > > > > If we only support FOPEN_PASSTHROUGH_AUTOCLOSE as v12 > > > patches implicitly do, then the memory overhead is not much different > > > than the extra overlayfs pseudo realfiles. > > > > How exactly would this work? > > > > ioctl(F_D_I_P_OPEN) - create passthrough fd with ref 1 > > open/FOPEN_PASSTHOUGH - inc refcount in passthrough fd > > release - put refcount in passthrough fd > > ioctl(F_D_I_P_CLOSE) - put ref in passthrough fd > > > > Due to being refcounted the F_D_I_P_CLOSE can come at any point past > > the finished open request. > > > > Or did you have something else in mind? > > > > What I had in mind is that FOPEN_PASSTHROUGH_AUTOCLOSE > "transfers" the server's refcount to the kernel and server does > not need to call explicit F_D_I_P_CLOSE. > > This is useful for servers that don't care about reusing mappings. > Hi Daniel, I was waiting for LSFMM to see if and how FUSE-BPF intends to address the highest value use case of read/write passthrough. >From what I've seen, you are still taking a very broad approach of all-or-nothing which still has a lot of core design issues to address, while these old patches already address the most important use case of read/write passthrough of fd without any of the core issues (credentials, hidden fds). As far as I can tell, this old implementation is mostly independent of your lookup based approach - they share the low level read/write passthrough functions but not much more than that, so merging them should not be a blocker to your efforts in the longer run. Please correct me if I am wrong. As things stand, I intend to re-post these old patches with mandatory FOPEN_PASSTHROUGH_AUTOCLOSE to eliminate the open questions about managing mappings. Miklos, please stop me if I missed something and if you do not think that these two approaches are independent. Thanks, Amir.
