On Wed, May 11, 2022 at 4:17 PM Cornelia Huck <cohuck at redhat.com> wrote:> > On Wed, May 11 2022, Jason Wang <jasowang at redhat.com> wrote: > > > On Tue, May 10, 2022 at 7:28 PM Michael S. Tsirkin <mst at redhat.com> wrote: > >> > >> On Sat, May 07, 2022 at 03:19:51PM +0800, Jason Wang wrote: > >> > @@ -1106,6 +1130,7 @@ static void virtio_ccw_int_handler(struct ccw_device *cdev, > >> > vcdev->err = -EIO; > >> > } > >> > virtio_ccw_check_activity(vcdev, activity); > >> > + read_lock_irqsave(&vcdev->irq_lock, flags); > >> > for_each_set_bit(i, indicators(vcdev), > >> > sizeof(*indicators(vcdev)) * BITS_PER_BYTE) { > >> > /* The bit clear must happen before the vring kick. */ > >> > >> Cornelia sent a lockdep trace on this. > >> > >> Basically I think this gets the irqsave/restore logic wrong. > >> It attempts to disable irqs in the handler (which is an interrupt > >> anyway). > > > > The reason I use irqsave/restore is that it can be called from process > > context (if I was not wrong), e.g from io_subchannel_quiesce(). > > io_subchannel_quiesce() should disable interrupts, though? Otherwise, it > would be a bug.Right, it was protected by a spin_lock_irq(), but I can see other cdev->handler() in e.g device_fsm.c, the irq status is not obvious, do they have the same assumption which IRQ is disabled? Thanks>
Cornelia Huck
2022-May-11 09:13 UTC
[PATCH V4 6/9] virtio-ccw: implement synchronize_cbs()
On Wed, May 11 2022, Jason Wang <jasowang at redhat.com> wrote:> On Wed, May 11, 2022 at 4:17 PM Cornelia Huck <cohuck at redhat.com> wrote: >> >> On Wed, May 11 2022, Jason Wang <jasowang at redhat.com> wrote: >> >> > On Tue, May 10, 2022 at 7:28 PM Michael S. Tsirkin <mst at redhat.com> wrote: >> >> >> >> On Sat, May 07, 2022 at 03:19:51PM +0800, Jason Wang wrote: >> >> > @@ -1106,6 +1130,7 @@ static void virtio_ccw_int_handler(struct ccw_device *cdev, >> >> > vcdev->err = -EIO; >> >> > } >> >> > virtio_ccw_check_activity(vcdev, activity); >> >> > + read_lock_irqsave(&vcdev->irq_lock, flags); >> >> > for_each_set_bit(i, indicators(vcdev), >> >> > sizeof(*indicators(vcdev)) * BITS_PER_BYTE) { >> >> > /* The bit clear must happen before the vring kick. */ >> >> >> >> Cornelia sent a lockdep trace on this. >> >> >> >> Basically I think this gets the irqsave/restore logic wrong. >> >> It attempts to disable irqs in the handler (which is an interrupt >> >> anyway). >> > >> > The reason I use irqsave/restore is that it can be called from process >> > context (if I was not wrong), e.g from io_subchannel_quiesce(). >> >> io_subchannel_quiesce() should disable interrupts, though? Otherwise, it >> would be a bug. > > Right, it was protected by a spin_lock_irq(), but I can see other > cdev->handler() in e.g device_fsm.c, the irq status is not obvious, do > they have the same assumption which IRQ is disabled?Yes, that should be the case for any invocations via the fsm as well. It's been some time since I've worked on that part of the code, though, so let's cc: the s390 cio maintainers so that they can speak up if I'm wrong.