aboutsummaryrefslogtreecommitdiff
path: root/.gitmodules
diff options
context:
space:
mode:
authorEric Blake <eblake@redhat.com>2017-10-05 14:02:44 -0500
committerKevin Wolf <kwolf@redhat.com>2017-10-06 16:28:58 +0200
commit9cdcfd9f7afd0274919af95a164178ac6ee847ca (patch)
treeeaec130c5e70163aff362338131a3c7058b2d6e3 /.gitmodules
parent0f40444cc4fc6526a9a544b11475f1086113f9ba (diff)
block: Uniform handling of 0-length bdrv_get_block_status()
Handle a 0-length block status request up front, with a uniform return value claiming the area is not allocated. Most callers don't pass a length of 0 to bdrv_get_block_status() and friends; but it definitely happens with a 0-length read when copy-on-read is enabled. While we could audit all callers to ensure that they never make a 0-length request, and then assert that fact, it was just as easy to fix things to always report success (as long as the callers are careful to not go into an infinite loop). However, we had inconsistent behavior on whether the status is reported as allocated or defers to the backing layer, depending on what callbacks the driver implements, and possibly wasting quite a few CPU cycles to get to that answer. Consistently reporting unallocated up front doesn't really hurt anything, and makes it easier both for callers (0-length requests now have well-defined behavior) and for drivers (drivers don't have to deal with 0-length requests). Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Diffstat (limited to '.gitmodules')
0 files changed, 0 insertions, 0 deletions