From: Cornelia Huck <cohuck@redhat.com>
To: Vineeth Vijayan <vneethv@linux.ibm.com>,
Halil Pasic <pasic@linux.ibm.com>
Cc: Heiko Carstens <hca@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Christian Borntraeger <borntraeger@de.ibm.com>,
Pierre Morel <pmorel@linux.ibm.com>,
Michael Mueller <mimu@linux.ibm.com>,
linux-s390@vger.kernel.org,
virtualization@lists.linux-foundation.org, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, bfu@redhat.com
Subject: Re: [PATCH 1/1] virtio/s390: fix vritio-ccw device teardown
Date: Mon, 20 Sep 2021 12:07:23 +0200 [thread overview]
Message-ID: <878rzrh86c.fsf@redhat.com> (raw)
In-Reply-To: <88b514a4416cf72cda53a31ad2e15c13586350e4.camel@linux.ibm.com>
On Mon, Sep 20 2021, Vineeth Vijayan <vneethv@linux.ibm.com> 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@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.
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.
WARNING: multiple messages have this Message-ID (diff)
From: Cornelia Huck <cohuck@redhat.com>
To: Vineeth Vijayan <vneethv@linux.ibm.com>,
Halil Pasic <pasic@linux.ibm.com>
Cc: linux-s390@vger.kernel.org, Vasily Gorbik <gor@linux.ibm.com>,
Pierre Morel <pmorel@linux.ibm.com>,
Heiko Carstens <hca@linux.ibm.com>,
bfu@redhat.com, linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org,
Christian Borntraeger <borntraeger@de.ibm.com>,
kvm@vger.kernel.org, Michael Mueller <mimu@linux.ibm.com>
Subject: Re: [PATCH 1/1] virtio/s390: fix vritio-ccw device teardown
Date: Mon, 20 Sep 2021 12:07:23 +0200 [thread overview]
Message-ID: <878rzrh86c.fsf@redhat.com> (raw)
In-Reply-To: <88b514a4416cf72cda53a31ad2e15c13586350e4.camel@linux.ibm.com>
On Mon, Sep 20 2021, Vineeth Vijayan <vneethv@linux.ibm.com> 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@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.
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.
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
next prev parent reply other threads:[~2021-09-20 10:07 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-15 21:57 [PATCH 1/1] virtio/s390: fix vritio-ccw device teardown Halil Pasic
2021-09-15 21:57 ` Halil Pasic
2021-09-15 22:00 ` Halil Pasic
2021-09-15 22:00 ` Halil Pasic
2021-09-16 8:59 ` Cornelia Huck
2021-09-16 8:59 ` Cornelia Huck
2021-09-16 13:18 ` Halil Pasic
2021-09-16 13:18 ` Halil Pasic
2021-09-17 8:40 ` Cornelia Huck
2021-09-17 8:40 ` Cornelia Huck
2021-09-19 22:39 ` Halil Pasic
2021-09-19 22:39 ` Halil Pasic
2021-09-20 7:41 ` Vineeth Vijayan
2021-09-20 10:07 ` Cornelia Huck [this message]
2021-09-20 10:07 ` Cornelia Huck
2021-09-21 3:25 ` Halil Pasic
2021-09-21 3:25 ` Halil Pasic
2021-09-21 12:09 ` Cornelia Huck
2021-09-21 12:09 ` Cornelia Huck
2021-09-21 13:31 ` Vineeth Vijayan
2021-09-21 16:52 ` Halil Pasic
2021-09-21 16:52 ` Halil Pasic
2021-09-21 18:25 ` Vineeth Vijayan
2021-09-20 10:30 ` Cornelia Huck
2021-09-20 10:30 ` Cornelia Huck
2021-09-20 13:27 ` Halil Pasic
2021-09-20 13:27 ` Halil Pasic
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878rzrh86c.fsf@redhat.com \
--to=cohuck@redhat.com \
--cc=bfu@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=mimu@linux.ibm.com \
--cc=pasic@linux.ibm.com \
--cc=pmorel@linux.ibm.com \
--cc=virtualization@lists.linux-foundation.org \
--cc=vneethv@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.