linux-kernel - Re: Re: [PATCH RFC v2 1/2] fuse: add compound command to combine multiple requests

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aV5l5OxMuyYs8mzQ@fedora.fritz.box>
Date: Wed, 7 Jan 2026 15:03:45 +0100
From: Horst Birthelmer <horst@...thelmer.de>
To: Joanne Koong <joannelkoong@...il.com>
Cc: Horst Birthelmer <hbirthelmer@...glemail.com>, 
	Miklos Szeredi <miklos@...redi.hu>, Bernd Schubert <bschubert@....com>, linux-kernel@...r.kernel.org, 
	linux-fsdevel@...r.kernel.org, Horst Birthelmer <hbirthelmer@....com>, 
	syzbot@...kaller.appspotmail.com
Subject: Re: Re: [PATCH RFC v2 1/2] fuse: add compound command to combine
 multiple requests

On Tue, Jan 06, 2026 at 05:40:52PM -0800, Joanne Koong wrote:
> On Tue, Dec 23, 2025 at 2:13 PM Horst Birthelmer
> <hbirthelmer@...glemail.com> wrote:
> >
> > For a FUSE_COMPOUND we add a header that contains information
> > about how many commands there are in the compound and about the
> > size of the expected result. This will make the interpretation
> > in libfuse easier, since we can preallocate the whole result.
> > Then we append the requests that belong to this compound.
> >
> > The API for the compound command has:
> >   fuse_compound_alloc()
> >   fuse_compound_add()
> >   fuse_compound_request()
> >   fuse_compound_free()
> >
...
> > +
> > +       if (compound->buffer_pos + needed_size > compound->buffer_size) {
> > +               size_t new_size = max(compound->buffer_size * 2,
> > +                                     compound->buffer_pos + needed_size);
> > +               char *new_buffer;
> > +
> > +               new_size = round_up(new_size, PAGE_SIZE);
> > +               new_buffer = kvrealloc(compound->buffer, new_size,
> > +                                      GFP_KERNEL);
> > +               if (!new_buffer)
> > +                       return -ENOMEM;
> > +               compound->buffer = new_buffer;
> > +               compound->buffer_size = new_size;
> 
> Hmm... when we're setting up a compound request, we already know the
> size that will be needed to hold all the requests, right? Do you think
> it makes sense to allocate that from the get-go in
> fuse_compound_alloc() and then not have to do any buffer reallocation?
> I think that also gets rid of fuse_compound_req->total_size, as that
> would just be the same as fuse_compound_req->buffer_size.
> 
After looking at this again, I realized it would be more efficient to not do any allocation
in fuse_compound_alloc() at all except for the fuse_compound_req, of course, and then
do all the work in fuse_compound_send().
We keep pointers to the fuse_args given to the compound command anyway since we need
to fill out the result, so why not keep just the fuse args and don't copy anything
except when actually sending it out?

I will test this version a bit and make a simplified v3.

...
> 
> Thanks,
> Joanne

Thanks, 
Horst