On Thu, Apr 19, 2018 at 4:09 PM, Simon Gaiser <si...@invisiblethingslab.com> wrote: > Jason Andryuk: >> On Thu, Apr 19, 2018 at 2:10 PM, Simon Gaiser >> <si...@invisiblethingslab.com> wrote: >>> Jason Andryuk: >>>> A toolstack may delete the vif frontend and backend xenstore entries >>>> while xen-netfront is in the removal code path. In that case, the >>>> checks for xenbus_read_driver_state would return XenbusStateUnknown, and >>>> xennet_remove would hang indefinitely. This hang prevents system >>>> shutdown. >>>> >>>> xennet_remove must be able to handle XenbusStateUnknown, and >>>> netback_changed must also wake up the wake_queue for that state as well. >>>> >>>> Fixes: 5b5971df3bc2 ("xen-netfront: remove warning when unloading module") >>> >>> I think this should go into stable since AFAIK the hanging network >>> device can only be fixed by rebooting the guest. AFAICS this affects all >>> 4.* branches since 5b5971df3bc2 got backported to them. >>> >>> Upstream commit c2d2e6738a209f0f9dffa2dc8e7292fc45360d61. >> >> Simon, >> >> Yes, I agree. I actually submitted the request to stable earlier >> today, so hopefully it gets added soon. > > Ok, great. (I checked the stable patch queue, but didn't check the > mailing list archive). > >> Have you experienced this hang? > > Yes, it's affecting the kernel shipped by Qubes OS (see [1]).
Ok, interesting. I tracked down this bug with older xenvm tools, and I didn't know if libxl tools were also affected. Greg KH added the patch to the stable queue, so it's in the process. Regards, Jason _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel