On Tue, Aug 27, 2024 at 03:45:11PM -0300, Fabiano Rosas wrote: > Peter Xu <pet...@redhat.com> writes: > > > On Tue, Aug 27, 2024 at 02:46:05PM -0300, Fabiano Rosas wrote: > >> @@ -254,12 +250,10 @@ int multifd_ram_unfill_packet(MultiFDRecvParams *p, > >> Error **errp) > >> return 0; > >> } > >> > >> - /* make sure that ramblock is 0 terminated */ > >> - packet->ramblock[255] = 0; > >> - p->block = qemu_ram_block_by_name(packet->ramblock); > >> + ramblock_name = g_strndup(packet->ramblock, 255); > > > > I understand we want to move to a const*, however this introduces a 256B > > allocation per multifd packet, which we definitely want to avoid.. I wonder > > whether that's worthwhile just to make it const. :-( > > > > I don't worry too much on the const* and vars pointed being abused / > > updated when without it - the packet struct is pretty much limited only to > > be referenced in this unfill function, and then we will do the load based > > on MultiFDRecvParams* later anyway. So personally I'd rather lose the > > const* v.s. one allocation. > > > > Or we could also sanity check byte 255 to be '\0' (which, AFAIU, should > > always be the case..), then we can get both benefits. > > We can't because it breaks compat. Previous QEMUs didn't zero the > packet.
Ouch! Then.. shall we still try to avoid the allocation? -- Peter Xu
