On Fri, 17 Jul 2026 02:17:24 -0400 "Michael S. Tsirkin" <[email protected]> wrote: > > reclaiming free pages under memory pressure can trigger page reporting > > which might access the deleted reporting virtqueue if it is not yet > > frozen, or interact with other parts of the driver in a teardown state. > > i feel this is the thing to fix then? not the freeing itself. > > ... > > this is remove, taking locks seems futile - if something will acquire > the lock here, we will be in trouble.
On Fri, 17 Jul 2026 11:30:44 +0200 David Hildenbrand <[email protected]> wrote: > Why not set the boolean immediately after this, and call it > "shrinker_disabled" > instead of "suspended"? > > Then you can keep calling "return_free_pages_to_mm(vb, ULONG_MAX);" here. Hi Michael, David, Michael, your intuition here is exactly right: the freeing itself is perfectly safe, and taking locks in the teardown path is an anti-pattern we should absolutely avoid. After re-tracing the execution paths based on your feedback, I realized that Patch 2/2 is completely unnecessary. The FPH shrinker doesn't touch virtqueues itself. It simply returns pages to the buddy allocator. While this can trigger Free Page Reporting, Patch 1/2 migrates the reporting worker to system_freezable_wq, meaning the PM core natively guarantees that worker is frozen before virtballoon_freeze() ever runs. Furthermore, any asynchronous FPH hinting work happens on vb->balloon_wq (triggered via config changes). Because vb->balloon_wq is natively allocated with WQ_FREEZABLE, the PM core successfully freezes this worker prior to virtballoon_freeze() as well. Because all downstream paths are safely frozen by the PM core, a concurrent shrinker call during suspend is entirely harmless. It will merely return 0 (since remove_common() safely drains the free_page_list anyway using ULONG_MAX) or safely execute without interacting with a teardown state. David, thank you for the cleaner `shrinker_disabled` suggestion, but since the asynchronous workers are already natively frozen, we can avoid touching the teardown paths and locking logic altogether. I am going to drop this patch entirely from the series. I will send out a single-patch v3 consisting solely of the page reporting fix (Patch 1/2) shortly. Thank you both for the rigorous review that steered us away from this unnecessary complexity! Best, Link
