On Mon, Jul 13, 2026 at 6:17 AM David Hildenbrand wrote: > I assume that workqueue is not frozen yet because ... it's not freezable :) > So could we queue to system_freezable_wq instead, or define our own freezable > workqueue there? Then a driver doesn't have to worry about that.
Exactly. As noted in the RFC, the root cause is indeed that system_wq lacks the WQ_FREEZABLE flag, leaving it active during suspend. Switching the worker over to system_freezable_wq is a brilliant idea. It's a much cleaner abstraction that solves the problem at the core, saving individual drivers from having to micromanage this lifecycle and handle failure unwinding during freeze/restore. On Mon, Jul 13, 2026 at 6:26 AM Michael S. Tsirkin wrote: > +1. Just system_freezable_wq will do the trick. Thanks, David and Michael. I will drop the virtio-balloon specific unregister logic and adopt this approach. Per the earlier feedback to keep these fixes independent, I'll format v2 as a 3-part patch series: [PATCH v2 1/3] mm/page_reporting: use system_freezable_wq [PATCH v2 2/3] virtio_balloon: fix shrinker UAF during PM freeze [PATCH v2 3/3] virtio_balloon: fix OOM notifier UAF during PM freeze I'll send that out shortly. Thanks, Link
