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? While under
pressure this issue seems reproducible.
