Re: [PATCH 04/28] fuse: adapt FUSE_DEV_IOC_BACKING_{OPEN,CLOSE} to add new iomap devices

Amir Goldstein
2025-09-19T09:54:52Z

On Fri, Sep 19, 2025 at 9:14 AM Miklos Szeredi <miklos@szeredi.hu> wrote:
>
> On Thu, 18 Sept 2025 at 20:42, Amir Goldstein <amir73il@gmail.com> wrote:
> >
> > On Thu, Sep 18, 2025 at 8:17 PM Darrick J. Wong <djwong@kernel.org> wrote:
>
> > > How about restricting the backing ids to RLIMIT_NOFILE? The @end param
> > > to idr_alloc_cyclic constrains them in exactly that way.
> >
> > IDK. My impression was that Miklos didn't like having a large number
> > of unaccounted files, but it's up to him.
>
> There's no 1:1 mapping between a fuse instance and a "fuse server
> process", so the question is whose RLIMIT_NOFILE? Accounting to the
> process that registered the fd would be good, but implementing it
> looks exceedingly complex. Just taking RLIMIT_NOFILE value from the
> process that is doing the fd registering should work, I guess.
>
> There's still the question of unhiding these files. Latest discussion
> ended with lets create a proper directory tree for open files in proc.
> I.e. /proc/PID/fdtree/FD/hidden/...
>

Yes, well, fuse_backing_open() says:
/* TODO: relax CAP_SYS_ADMIN once backing files are visible to lsof */
So that's the reason I was saying there is no justification to
relax this for FUSE_IOMAP as long as this issue is not resolved.

As Darrick writes, fuse4fs needs only 1 backing blockdev
and other iomap fuse fs are unlikely to need more than a few
backing blockdevs.

So maybe, similar to max_stack_depth, we require the server to
negotiate the max_backing_id at FUSE_INIT time.

We could allow any "reasonable" number without any capabilities
and regardless of RLIMIT_NOFILE or we can account max_backing_id
in advance for the user setting up the connection.

For backward compat (or for privileged servers) zero max_backing_id
means unlimited (within the int32 range) and that requires
CAP_SYS_ADMIN for fuse_backing_open() regardless of which
type of backing file it is.

WDYT?

Thanks,
Amir.