Max Reitz d470ad42ac block: Guard against NULL bs->drv
We currently do not guard everywhere against a NULL bs->drv where we
should be doing so.  Most of the places fixed here just do not care
about that case at all.

Some care implicitly, e.g. through a prior function call to
bdrv_getlength() which would always fail for an ejected BDS.  Add an
assert there to make it more obvious.

Other places seem to care, but do so insufficiently: Freeing clusters in
a qcow2 image is an error-free operation, but it may leave the image in
an unusable state anyway.  Giving qcow2_free_clusters() an error code is
not really viable, it is much easier to note that bs->drv may be NULL
even after a successful driver call.  This concerns bdrv_co_flush(), and
the way the check is added to bdrv_co_pdiscard() (in every iteration
instead of only once).

Finally, some places employ at least an assert(bs->drv); somewhere, that
may be reasonable (such as in the reopen code), but in
bdrv_has_zero_init(), it is definitely not.  Returning 0 there in case
of an ejected BDS saves us much headache instead.

Reported-by: R. Nageswara Sastry <nasastry@in.ibm.com>
Buglink: https://bugs.launchpad.net/qemu/+bug/1728660
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-id: 20171110203111.7666-4-mreitz@redhat.com
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-11-17 18:21:31 +01:00
..
2017-09-22 10:46:25 +08:00
2017-10-11 15:15:17 -03:00
2017-11-17 18:21:30 +01:00
2017-06-20 14:31:31 +02:00
2017-03-01 11:51:28 +04:00
2017-03-01 11:51:28 +04:00
2017-03-01 11:51:05 +04:00
2017-03-01 11:51:04 +04:00
2017-03-01 11:51:28 +04:00
2017-08-10 14:33:43 +01:00
2017-10-20 13:32:10 +02:00
2017-03-01 11:51:05 +04:00
2017-10-20 13:32:10 +02:00
2017-10-20 13:32:10 +02:00
2017-10-20 13:32:10 +02:00
2017-09-15 09:05:19 +02:00
2017-03-01 00:09:28 +04:00
2017-03-01 00:09:28 +04:00
2017-10-20 13:32:10 +02:00
2017-07-14 11:04:34 +02:00
2017-09-05 22:34:40 +02:00
2017-03-01 11:51:29 +04:00