Re: [PATCH 1/1] virtio/s390: fix vritio-ccw device teardown

[Vineeth Vijayan <vneethv@linux.ibm.com>]

On Mon, 2021-09-20 at 00:39 +0200, Halil Pasic wrote:
> On Fri, 17 Sep 2021 10:40:20 +0200
> Cornelia Huck <cohuck@redhat.com> wrote:
> 
...snip...
> > > 
> > > Thanks, if I find time for it, I will try to understand this
> > > better and
> > > come back with my findings.
> > >  
> > > > > * Can virtio_ccw_remove() get called while !cdev->online and 
> > > > >   virtio_ccw_online() is running on a different cpu? If yes,
> > > > > what would
> > > > >   happen then?    
> > > > 
> > > > All of the remove/online/... etc. callbacks are invoked via the
> > > > ccw bus
> > > > code. We have to trust that it gets it correct :) (Or have the
> > > > common
> > > > I/O layer maintainers double-check it.)
> > > >   
> > > 
> > > Vineeth, what is your take on this? Are the struct ccw_driver
> > > virtio_ccw_remove and the virtio_ccw_online callbacks mutually
> > > exclusive. Please notice that we may initiate the onlining by
> > > calling ccw_device_set_online() from a workqueue.
> > > 
> > > @Conny: I'm not sure what is your definition of 'it gets it
> > > correct'...
> > > I doubt CIO can make things 100% foolproof in this area.  
> > 
> > Not 100% foolproof, but "don't online a device that is in the
> > progress
> > of going away" seems pretty basic to me.
> > 
> 
> I hope Vineeth will chime in on this.
Considering the online/offline processing, 
The ccw_device_set_offline function or the online/offline is handled
inside device_lock. Also, the online_store function takes care of
avoiding multiple online/offline processing. 

Now, when we consider the unconditional remove of the device,
I am not familiar with the virtio_ccw driver. My assumptions are based
on how CIO/dasd drivers works. If i understand correctly, the dasd
driver sets different flags to make sure that a device_open is getting
prevented while the the device is in progress of offline-ing. 

> 
> > >  
> > > > >  
> > > > > The main addresse of these questions is Conny ;).  
> > > 

...snip...