On Mon, Sep 20 2021, Vineeth Vijayan <vneethv@xxxxxxxxxxxxx> wrote: > On Mon, 2021-09-20 at 00:39 +0200, Halil Pasic wrote: >> On Fri, 17 Sep 2021 10:40:20 +0200 >> Cornelia Huck <cohuck@xxxxxxxxxx> 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. Hm, if we are invoking the online/offline callbacks under the device lock already, how would that affect the remove callback? Shouldn't they be serialized under the device lock already? I think we are fine. For dasd, I think they also need to deal with the block device lifetimes. For virtio-ccw, we are basically a transport that does not know about devices further down the chain (that are associated with the virtio device, whose lifetime is tied to online/offline processing.) I'd presume that the serialization above would be enough.
