Faked requests during frontend resets causing broken ring state

[Tu Dinh <ngoc-tu.dinh@xxxxxxxxxx>]

Currently, when transitioning from Enabled to Connected, XenVbd and 
XenVif will fake pending requests without resetting the ring. If the 
backend comes back later (e.g. after a long pause, such as one caused by 
an in-memory snapshot), it will continue talking to a corrupted ring 
state. This leads to reading/writing of corrupt data.

Here's how to reproduce:
- Create and attach a VBD, add a large zip file (several GBs) to it,
   then use Sync [1] to flush the zip file to disk.
- Before testing, empty the standby list with RAMMap [2].
- Start to test the zip file using 7-Zip or equivalent.
- While the test is running, immediately run
   `tap-ctl pause -p <pid> -m <minor>` to pause the backend while keeping
   the ring alive.
- Wait for TargetReset to be issued.
- Run `tap-ctl unpause ...` to unpause tapdisk while reusing the same
   ring.
- Observe the data corruption as a ZIP data error.

Patches in reply. I've gone with a more complicated fix which involves 
keeping track of each ring's poisoned state, but we can also consider 
reverting acd08c9dc962 ("Dont close ring during FrontendReset"). I don't 
know if this is the only case where we can transition from Enabled - 
Connected - Enabled, however. We can also remove the Enabled->Connected 
transition and always consider the ring tainted after a ring disable, 
which may be cleaner.

[1] https://learn.microsoft.com/en-us/sysinternals/downloads/sync
[2] https://learn.microsoft.com/en-us/sysinternals/downloads/rammap


--
Ngoc Tu Dinh | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech