search for: do_cio_interrupt

...1 [3e00035fb50] ccw_io_helper at 9130ea #2 [3e00035fbd0] virtio_ccw_get_config at 914a28 #3 [3e00035fc30] virtballoon_changed at 76e776 #4 [3e00035fc70] virtio_config_changed at 76aabc #5 [3e00035fca8] virtio_ccw_int_handler at 914ede #6 [3e00035fd18] ccw_device_irq at 8941d4 #7 [3e00035fd48] do_cio_interrupt at 885906 #8 [3e00035fd80] __handle_irq_event_percpu at 1b3c22 #9 [3e00035fdf0] handle_irq_event_percpu at 1b3e1e #10 [3e00035fe28] handle_percpu_irq at 1b87d8 #11 [3e00035fe58] generic_handle_irq at 1b2ce6 #12 [3e00035fe70] do_IRQ at 10c3b2 #13 [3e00035fea8] io_int_handler at a86b3c PSW: 0404c...

...forward to hearing a solid reason why reading config inside the handler is forbidden (if that's true). > About what happens. The apidoc of ccw_device_start() says it needs to be > called with the ccw device lock held, so ccw_io_helper() tries to take it (since > forever I guess). OTOH do_cio_interrupt() takes the subchannel lock and > io_subchannel_initialize_dev() makes the ccw device lock be the subchannel > lock. That means when one tries to get virtio config form within a cio > interrupt context we deadlock, because we try to take a lock we already have. > > That said, I don&...

Some vqs don't need to be allocated when the related feature bits are disabled. Callers notice the vq allocation layer by setting the related names[i] to be NULL. This patch series fixes the find_vqs implementations to handle this case. Wei Wang (2): virtio_pci: use queue idx instead of array idx to set up the vq virtio: don't allocate vqs when names[i] = NULL

Some vqs don't need to be allocated when the related feature bits are disabled. Callers notice the vq allocation layer by setting the related names[i] to be NULL. This patch series fixes the find_vqs implementations to handle this case. Wei Wang (2): virtio_pci: use queue idx instead of array idx to set up the vq virtio: don't allocate vqs when names[i] = NULL

...this is all a bit ugly :( More verbose explanation below. > > > > > > About what happens. The apidoc of ccw_device_start() says it needs to be > > > called with the ccw device lock held, so ccw_io_helper() tries to take it (since > > > forever I guess). OTOH do_cio_interrupt() takes the subchannel lock and > > > io_subchannel_initialize_dev() makes the ccw device lock be the subchannel > > > lock. That means when one tries to get virtio config form within a cio > > > interrupt context we deadlock, because we try to take a lock we already have...