[PATCH v4 0/5] Improve robustness of migration

[David Gibson <david@gibson.dropbear.id.au>]

From Red Hat internal testing we've had some reports that if
attempting to migrate without passt-repair, the failure mode is uglier
than we'd like.  The migration fails, which is somewhat expected, but
we don't correctly roll things back on the source, so it breaks
network there as well.

Address this and several other fragilities in the migration.

Everything tested with the basic test suite, plus some additional
testing for the specific functionality of the patches:

For patches 1..2:
 * I get a clean migration if there are now active flows
 * Migration completes, although connections are broken if
   passt-repair isn't connected

For patches 3..5:
 * Migration completes ok if the source and destination hosts have
   different IPs
 * Target correctly sees the bind() failure and abandons the flow
 * Unfortunately, target-side client doesn't get a reset, it just sits
   there not working.  This is because a) the RST we try to send is
   lost because the queue is still inactive over the migration and b)
   we don't send RSTs or ICMPs for packets from the guest which no
   longer match a flow (I hope to tackle this soon)
 * After manually quitting the stuck client on the target, other
   connectivity works

There are more fragile cases that I'm looking to fix, particularly the
die()s in flow_migrate_source_rollback() and elsewhere.

David Gibson (5):
  migrate, flow: Trivially succeed if migrating with no flows
  migrate, flow: Don't attempt to migrate TCP flows without passt-repair
  tcp: Correct error code handling from tcp_flow_repair_socket()
  tcp: Unconditionally move to CLOSED state on tcp_rst()
  migrate, tcp: Don't flow_alloc_cancel() during incoming migration

 flow.c | 17 +++++++++++++++--
 tcp.c  | 28 +++++++++++++++++++++-------
 2 files changed, 36 insertions(+), 9 deletions(-)

-- 
2.48.1