On Mon, Sep 29, 2025 at 05:02:40PM +0200, Philippe Mathieu-Daudé wrote: > Cc'ing Salil for previous discussions on > https://lore.kernel.org/qemu-devel/[email protected]/
Thanks. While waiting for more comments, I pre-queued this series. Regarding to patch 1: I still think it's almost impossible to use it correctly on address_space_destroy(), even with the doc.. but I agree that's the best we can have right now. The problem is, afaiu we don't even have a way to know when a rcu callback is processed, unlike the grace period (which corresponds to synchronize_rcu()). I think it means there's almost no existing way for the user to properly release the AddressSpace memory if it is e.g. embeded inside a Device object. Here, we will need to rcu-free the Device object too (which I don't think we do at all..), making sure it's called after ASes' rcu callback. Even if we'll do so, we'll have yet another problem of having the Device free() rcu callback to happen after the AddressSpace's destroy rcu callback, we could rely on what Paolo mentioned on FIFO behavior of rcu queues, but it looks unwanted. For the long term, IMHO we may need to convert all embeded AddressSpaces into using dynamically allocated AddressSpaces (for CPUs, we can stick with cpu's address space API, but we have other places using ASes too that may also need to be converted to heap allocations). Then after all users switching to that we may be able to drop address_space_destroy(). Thanks, -- Peter Xu
