Re: [PATCH v3 6/7] fuse: alloc pqueue before installing fc

["Darrick J. Wong" <djwong@kernel.org>]

On Mon, Mar 23, 2026 at 07:33:10PM +0100, Bernd Schubert wrote:
> 
> 
> On 3/23/26 19:22, Darrick J. Wong wrote:
> > On Mon, Mar 16, 2026 at 05:53:17PM +0100, Miklos Szeredi wrote:
> >> Prior to this patchset, fuse_dev (containing fuse_pqueue) was allocated on
> >> mount.  But now fuse_dev is allocated when opening /dev/fuse, even though
> >> the queues are not needed at that time.
> >>
> >> Delay allocation of the pqueue (4k worth of list_head) just before mounting
> >> or cloning a device.
> >>
> >> Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
> > 
> > I wonder if this is worth the extra complexity to defer a memory
> > allocation?  If the fuse server actually mount()s then we need the
> > pqueues, right?  How common is it for a fuse server to open the
> > /dev/fuse when the kernel is so low on memory that the open() would fail
> > with ENOMEM on account of the pqueue allocation?  And is it likely that
> > a lot of memory would be freed up by the time we get to mount/clone?
> > 
> > I suppose if you had a very slow mounting fuse server this could happen,
> > but now everyone has to understand that fud->pq.processing can be NULL.
> 
> I guess the issue is that people might abuse it and open /dev/fuse for fun?

Ah, right, I forget that /dev/fuse is world-writable now.  Yeah, we
shouldn't let any idiot pin a bunch of kernel memory. :)

I think the commit message should include that:

"Prior to this patchset, fuse_dev (containing fuse_pqueue) was allocated
on mount.  But now fuse_dev is allocated when opening /dev/fuse, even
though the queues are not needed at that time.

"Delay allocation of the pqueue (4k worth of list_head) just before
mounting or cloning a device.

"Various distributions (e.g. Debian/Fedora) configure /dev/fuse as world
writable, so the pqueue allocation should be deferred to a privileged
operation (mount) to prevent unprivileged userspace from consuming
pinned kernel memory."

With that justification,
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>

--D