On Mon, Dec 08, 2025 at 11:51:55AM -0800, Ariadne Conill wrote: > We need to do this so that we can signal to the other end that the > device is being removed, so that it will release its claim on the > underlying memory allocation. Otherwise releasing the grant-table > entries is deferred resulting in a kernel oops since the pages have > already been freed. > > Cc: Juergen Gross <[email protected]> > Cc: Stefano Stabellini <[email protected]> > Fixes: 71ebd71921e45 ("xen/9pfs: connect to the backend") > Signed-off-by: Ariadne Conill <[email protected]> > Signed-off-by: Alex Zenla <[email protected]> > --- > net/9p/trans_xen.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c > index b9ff69c7522a..cde283c42dc6 100644 > --- a/net/9p/trans_xen.c > +++ b/net/9p/trans_xen.c > @@ -312,6 +312,7 @@ static void xen_9pfs_front_remove(struct xenbus_device > *dev) > { > struct xen_9pfs_front_priv *priv = dev_get_drvdata(&dev->dev); > > + xenbus_switch_state(dev, XenbusStateClosing);
I think you need to wait for the backend to acknowledge it by switching its state, before continuing. See for example xennet_remove()->xennet_bus_close() in drivers/net/xen-netfront.c. > dev_set_drvdata(&dev->dev, NULL); > xen_9pfs_front_free(priv); > } > -- > 2.52.0 > > -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab
signature.asc
Description: PGP signature
