Re: [PATCH 00/31] Skip automatic zero-init of large arrays / structs in I/O paths

["Daniel P. Berrangé" <berrange@redhat.com>]

On Tue, Jun 10, 2025 at 05:00:43PM +0200, Philippe Mathieu-Daudé wrote:
> On 10/6/25 14:56, Daniel P. Berrangé wrote:
> > On Tue, Jun 10, 2025 at 02:49:02PM +0200, Philippe Mathieu-Daudé wrote:
> > > On 10/6/25 14:36, Daniel P. Berrangé wrote:
> > > > This series is an extension of Stefan's proposal:
> > > > 
> > > >     https://lists.nongnu.org/archive/html/qemu-devel/2025-06/msg00736.html
> > > > 
> > > > It used '-Wframe-larger-than=4096' to identify all code locations
> > > > with more than 4k on the stack. Any locations in the I/O paths
> > > > were chosen to avoid automatic zero-init, to eliminate the performance
> > > > overhead of the automatic initialization.
> > > 
> > > Should we eventually add it to our default CFLAGS?
> > 
> > You mean as a way to impose a hard limit on stack frame size ?
> 
> Yes, we could use -Wframe-larger-than=50000 for this release, then
> aim to reduce by 5/10k every release until some reasonable limit...

I guess the key thing is to define approximately what our target
should be ?

There are some large stack frames in QEMU device I/O paths that are
not unreasonable to have, because they avoid need to malloc in the
I/O path. A greater many devices have 4/8k buffers for copying
data around, and some bigger ones are fairly valid to have too.

On the flip side there's still way too much use of PATH_MAX that
is gratuitous and should be removed, but its hard to enforce the
latter without negatively impacting the former.


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|