[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

xen-netback hotplug-status regression bug



Commit https://github.com/torvalds/linux/commit/1f25657 ("xen-netback: remove 'hotplug-status' once it has served its purpose") seems to have introduced a regression that prevents a vif frontend from transitioning more than once into Connected state.

As far as I can tell:

- The defined vif script (e.g. /etc/xen/scripts/vif-bridge) executes only once, at domU startup, and sets backend/vif/<domU>/0/hotplug-status="connected"

- When the frontend first enters Connected state, drivers/net/xen-netback/xenbus.c's connect() sets up a watch on "hotplug-status" with the callback function hotplug_status_changed()

- When hotplug_status_changed() is triggered by the watch, it transitions the backend to Connected state and calls xenbus_rm() to delete the "hotplug-status" attribute.

If the frontend subsequently disconnects and reconnects (e.g. transitions through Closed->Initialising->Connected) then:

- Nothing recreates "hotplug-status"

- When the frontend re-enters Connected state, connect() sets up a watch on "hotplug-status" again

- The callback hotplug_status_changed() is never triggered, and so the backend device never transitions to Connected state.


Reverting the commit would fix this bug, but would obviously also reintroduce the race condition that the commit was designed to avoid.

I'm happy to put together a patch, if one of the maintainers could suggest a sensible design approach.

I'm not a list member, so please CC me directly on replies.

Thanks,

Michael



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.