xen/blkfront: Fix crash if backend doesn't follow the right states.
authorKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Fri, 18 Dec 2015 21:28:53 +0000 (16:28 -0500)
committerKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Mon, 4 Jan 2016 17:21:26 +0000 (12:21 -0500)
commitc31ecf6c126dbc7f30234eaf6c4a079649a38de7
tree8d51cdb3d3c3ea4ee8a801b6d44c88e35518ab35
parent93bb277f97a6d319361766bde228717faf4abdeb
xen/blkfront: Fix crash if backend doesn't follow the right states.

We have split the setting up of all the resources in two steps:
1) talk_to_blkback  - which figures out the num_ring_pages (from
   the default value of zero), sets up shadow and so
2) blkfront_connect - does the real part of filling out the
   internal structures.

The problem is if we bypass the 1) step and go straight to 2)
and call blkfront_setup_indirect where we use the macro
BLK_RING_SIZE - which returns an negative value (because
sz is zero  - since num_ring_pages is zero - since it has never
been set).

We can fix this by making sure that we always have called
talk_to_blkback before going to blkfront_connect.

Or we could set in blkfront_probe info->nr_ring_pages = 1
to have a default value. But that looks odd - as we haven't
actually negotiated any ring size.

This patch changes XenbusStateConnected state to detect if
we haven't done the initial handshake - and if so continue
on as if were in XenbusStateInitWait state.

We also roll the error recovery (freeing the structure) into
talk_to_blkback error path - which is safe since that function
is only called from blkback_changed.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
drivers/block/xen-blkfront.c