rbd: handle parent_overlap on writes correctly
authorIlya Dryomov <ilya.dryomov@inktank.com>
Tue, 10 Jun 2014 09:53:29 +0000 (13:53 +0400)
committerIlya Dryomov <ilya.dryomov@inktank.com>
Mon, 23 Jun 2014 08:55:37 +0000 (12:55 +0400)
commit9638556a276125553549fdfe349c464481ec2f39
treead8df9f63ce194d773efaa362b08d4e1177cb690
parenta497c3ba1d97fc69c1e78e7b96435ba8c2cb42ee
rbd: handle parent_overlap on writes correctly

The following check in rbd_img_obj_request_submit()

    rbd_dev->parent_overlap <= obj_request->img_offset

allows the fall through to the non-layered write case even if both
parent_overlap and obj_request->img_offset belong to the same RADOS
object.  This leads to data corruption, because the area to the left of
parent_overlap ends up unconditionally zero-filled instead of being
populated with parent data.  Suppose we want to write 1M to offset 6M
of image bar, which is a clone of foo@snap; object_size is 4M,
parent_overlap is 5M:

    rbd_data.<id>.0000000000000001
     ---------------------|----------------------|------------
    | should be copyup'ed | should be zeroed out | write ...
     ---------------------|----------------------|------------
   4M                    5M                     6M
                    parent_overlap    obj_request->img_offset

4..5M should be copyup'ed from foo, yet it is zero-filled, just like
5..6M is.

Given that the only striping mode kernel client currently supports is
chunking (i.e. stripe_unit == object_size, stripe_count == 1), round
parent_overlap up to the next object boundary for the purposes of the
overlap check.

Cc: stable@vger.kernel.org # 3.10+
Signed-off-by: Ilya Dryomov <ilya.dryomov@inktank.com>
Reviewed-by: Josh Durgin <josh.durgin@inktank.com>
drivers/block/rbd.c