On Tue, Jul 14, 2026 at 11:21:33AM -0700, David Rientjes wrote:
> On Tue, 14 Jul 2026, Michael S. Tsirkin wrote:
>
> > > > diff --git a/drivers/virtio/virtio_balloon.c
> > > > b/drivers/virtio/virtio_balloon.c
> > > > index a1b2c3d4e5f6..45a90fb3abf8 100640
> > > > --- a/drivers/virtio/virtio_balloon.c
> > > > +++ b/drivers/virtio/virtio_balloon.c
> > > > @@ -1055,6 +1055,9 @@ static int virtballoon_freeze(struct
> > > > virtio_device *vdev)
> > > > * The workqueue is already frozen by the PM core before this
> > > > * function is called.
> > > > */
> > > > + if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_REPORTING))
> > > > + page_reporting_unregister(&vb->pr_dev_info);
> > > > +
> > > > remove_common(vb);
> > > > return 0;
> > > > }
> > > >
> > > > static int virtballoon_restore(struct virtio_device *vdev)
> > > > {
> > > > struct virtio_balloon *vb = vdev->priv;
> > > > int ret;
> > > >
> > > > ret = init_vqs(vdev->priv);
> > > > if (ret)
> > > > return ret;
> > > >
> > > > virtio_device_ready(vdev);
> > > >
> > > > + if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_REPORTING)) {
> > > > + ret = page_reporting_register(&vb->pr_dev_info);
> > > > + if (ret)
> > > > + goto out_remove_vqs;
> > > > + }
> > >
> > > Hm, that failure handling is rather nasty.
> > >
> > >
> > > In virtballoon_freeze() we document:
> > >
> > > "The workqueue is already frozen by the PM core before this function is
> > > called"
> > >
> > > Your report states:
> > >
> > > "Workqueue: events page_reporting_process"
> > >
> > >
> > > 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.
> > >
> > > --
> > > Cheers,
> > >
> > > David
> >
> > +1. Just system_freezable_wq will do the trick.
> >
>
> This makes sense.
>
> I'm curious why this bug hasn't popped up earlier, presumably any VM that
> has gone through suspend while reporting free pages through FPR is
> vulnerable to it and could have panicked as a result. Which would suggest
> maybe >99% of FPR is done by guests that never suspend?
Quite possible.
> While under
> pressure this issue seems reproducible.
