Re: [Qemu-devel] [PATCH v2 4/6] s390x/pci: Ignore the unplug call if we already have a release_timer

[Cornelia Huck]

On Tue, 15 Jan 2019 17:53:17 -0500
Collin Walling <address@hidden> wrote:

> On 1/14/19 5:31 AM, David Hildenbrand wrote:
> > ... otherwise two successive calls to qdev_unplug() (e.g. by an impatient
> > user) will effectively overwrite pbdev->release_timer, resulting in a
> > memory leak. We are already processing the unplug.
> >   
> 
> Does QEMU not have a way to detect if a device is already in the process 
> of being unplugged? Seems like not having that kind of protection could 
> cause many problems.

There's also that unplug_request callback, which the next patch will
start to use. That pluggery for s390x pci is really a mess :(

> 
> Perhaps that effort would be arduous.
> 
> > If there is already a release_timer, the unplug will be performed after
> > the timeout.
> > 
> > Can be easily triggered by
> > (hmp) device_add virtio-mouse-pci,id=test
> > (hmp) stop
> > (hmp) device_del test
> > (hmp) device_del test
> > 
> > Signed-off-by: David Hildenbrand <address@hidden>
> > ---
> >   hw/s390x/s390-pci-bus.c | 3 +++
> >   1 file changed, 3 insertions(+)
> > 
> > diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c
> > index 59325cae3b..34a9cb2a80 100644
> > --- a/hw/s390x/s390-pci-bus.c
> > +++ b/hw/s390x/s390-pci-bus.c
> > @@ -972,6 +972,9 @@ static void s390_pcihost_unplug(HotplugHandler 
> > *hotplug_dev, DeviceState *dev,
> >       case ZPCI_FS_STANDBY:
> >           break;
> >       default:
> > +        if (pbdev->release_timer) {
> > +            return;
> > +        }
> >           s390_pci_generate_plug_event(HP_EVENT_DECONFIGURE_REQUEST,
> >                                        pbdev->fh, pbdev->fid);
> >           pbdev->release_timer = timer_new_ns(QEMU_CLOCK_VIRTUAL,
> >   
> 
> Looks good to me.
> 
> Reviewed-by: Collin Walling <address@hidden>
>