On Thu, Aug 28 2025, Parav Pandit <pa...@nvidia.com> wrote: >> From: Cornelia Huck <coh...@redhat.com> >> Sent: 27 August 2025 05:04 PM >> >> On Wed, Aug 27 2025, "Michael S. Tsirkin" <m...@redhat.com> wrote: >> >> > On Tue, Aug 26, 2025 at 06:52:03PM +0000, Parav Pandit wrote: >> >> > What I do not understand, is what good does the revert do. Sorry. >> >> > >> >> Let me explain. >> >> It prevents the issue of vblk requests being stuck due to broken VQ. >> >> It prevents the vnet driver start_xmit() to be not stuck on skb >> >> completions. >> > >> > This is the part I don't get. In what scenario, before 43bb40c5b9265 >> > start_xmit is not stuck, but after 43bb40c5b9265 it is stuck? >> > >> > Once the device is gone, it is not using any buffers at all. >> >> What I also don't understand: virtio-ccw does exactly the same thing >> (virtio_break_device(), added in 2014), and it supports surprise removal >> _only_, yet I don't remember seeing bug reports? > > I suspect that stress testing may not have happened for ccw with active vblk > Ios and outstanding transmit pkt and cvq commands. > Hard to say as we don't have ccw hw or systems.
cc:ing linux-s390 list. I'd be surprised if nobody ever tested surprise removal on a loaded system in the last 11 years.
