On Thu, Sep 25, 2025 at 10:03:45AM +0100, Peter Maydell wrote: > On Wed, 24 Sept 2025 at 22:14, Peter Xu <[email protected]> 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. -- Peter Xu
