On Wed, May 11 2022, Jason Wang <jasowang@xxxxxxxxxx> wrote:
> On Wed, May 11, 2022 at 4:17 PM Cornelia Huck <cohuck@xxxxxxxxxx> wrote:
>>
>> On Wed, May 11 2022, Jason Wang <jasowang@xxxxxxxxxx> wrote:
>>
>> > On Tue, May 10, 2022 at 7:28 PM Michael S. Tsirkin <mst@xxxxxxxxxx> 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.
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
