Patches one and two here are a 2.10 bandaid that avoids a crash.
Patches three and four are a more comprehensive fix as written by
Kevin in another discussion and are being posted here for the sake
of a discussion.
Patch three as written causes hangs in iotests 20, 39, 97, 98, 129,
153, 176, and 185. 124 actually segfaults.
For the purposes of 2.10, we'll likely just want patches 1 and 2
The problem in a nutshell: incrementing the in-flight counter of the
BDS from the BB layer assumes that every BB always has a BDS. That's
not true; and some devices like IDE have not in the past checked to
see if a given blk_ operation WOULD fail.
This culminates in a new regression where issuing a cache flush to a
CDROM (which is, for some reason, specification valid) will crash QEMU
due to a null dereference when attempting to atomically increment that
backend's in-flight counter.
John Snow (1):
IDE: Do not flush empty CDROM drives
Kevin Wolf (3):
IDE: test flush on empty CDROM
block-backend: shift in-flight counter to BB from BDS
block-backend: test flush op on empty backend
block.c | 2 +-
block/block-backend.c | 40 +++++++++++++++++++++++++-----
hw/ide/core.c | 11 +++++---
tests/Makefile.include | 2 ++
tests/ide-test.c | 19 ++++++++++++++
tests/test-block-backend.c | 62 ++++++++++++++++++++++++++++++++++++++++++++++
6 files changed, 125 insertions(+), 11 deletions(-)
create mode 100644 tests/test-block-backend.c