drivers: xen frontend devices should handle missed backend CLOSING
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest5 patches 16 repliesIn review
Patches in v1 No applies recorded yet
Reviews trailers per patch
All 10 patches have a Reviewed-by or Acked-by.
| Patch | Konrad Rzeszutek Wilk | Dmitry Torokhov | Florian Tobias Schandinat |
|---|---|---|---|
| 1/5 | A-b A-b | ||
| 1/5 | A-b A-b | ||
| 2/5 | A-b A-b | ||
| 2/5 | A-b A-b | ||
| 3/5 | A-b A-b | ||
| 3/5 | A-b A-b | ||
| 4/5 | A-b A-b | A-b A-b | |
| 4/5 | A-b A-b | A-b A-b | |
| 5/5 | A-b A-b | A-b A-b | |
| 5/5 | A-b A-b | A-b A-b |
Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes. Scroll the table sideways for all 3 reviewers.
Cover letter [PATCH 0/5] drivers: xen frontend devices should handle missed backend CLOSING
Subsystem maintainers, you can either pick up the relevant driver patch or ack it to go via Konrad's Xen tree.
The series makes all the Xen frontend drivers handle the backend transitioning to CLOSED without the frontend having previously seen the backend in the CLOSING state.
Backends shouldn't do this but some do. e.g., if the host is XenServer and the toolstack decides to do a forced shutdown of a VBD, then the blkfront may miss the CLOSING transition and the /dev/xvdX device will not be destroyed which prevents it being reused.
I have seen systems that ended up in this state but it's not clear if this was the actual cause. However, I think in general it's a good thing to thing to improve the handling of unexpected state transitions.
David