On Thu, 25 Sept 2025 at 21:06, Peter Xu <pet...@redhat.com> wrote: > > On Thu, Sep 25, 2025 at 10:03:45AM +0100, Peter Maydell wrote: > > On Wed, 24 Sept 2025 at 22:14, Peter Xu <pet...@redhat.com> wrote: > > > Side note: when I was trying to test hotplugs with i386/q35, unfortunately > > > I didn't really see when the address space was destroyed, maybe there's a > > > bug somewhere; I put that info into appendix at the end. > > > > This is https://gitlab.com/qemu-project/qemu/-/issues/2517 > > > > I got blocked on that because I ran into a weird "I have some > > memory that needs to be freed by the RCU callback, but only > > after the callback has freed some other RCU stuff". I see > > Paolo made a reply on that bug -- I would need to get back > > to it and reproduce whatever it was I was doing. > > Thanks for the link, right that looks exactly like what I hit. > > I am curious if FIFO is guaranteed for RCU in general, or it is an impl > detail only specific to QEMU. > > The other thing is I feel like it should be OK to reorder callbacks, if all > the call_rcu() users can make sure the rcu-freed object is completely > detached from the rest world, e.g. resetting all relevant pointers to NULL. > With that, it seems the order won't matter too, because nobody will be able > to reference the internal object anyway, so the two objects (after reseting > all referers to NULL pointer of the inner object) are completely standalone.
The specific ordering problem for cpu_address_space is that there's a g_new allocated array of memory which contains the AddressSpace objects (not pointers to them). The ASes need to be RCU-deallocated first so they can clean up their internal data structures; only once that has happened can we free the memory that holds the AddressSpace structs themselves. -- PMM
