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] [day] [month] [year] [list]

Message-ID: <CAJnrk1ZanYaUymGnU83imfAu-FQ-qQHRX_ys5B=5daoWvbp-gw@mail.gmail.com>
Date: Wed, 7 Jan 2026 17:42:42 -0800
From: Joanne Koong <joannelkoong@...il.com>
To: Horst Birthelmer <horst@...thelmer.de>
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 Wed, Jan 7, 2026 at 6:03 AM Horst Birthelmer <horst@...thelmer.de> wrote:
>
> 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.

Awesome, looking forward to seeing v3.

Thanks,
Joanne
>
> ...
> >
> > Thanks,
> > Joanne
>
> Thanks,
> Horst