On Fri, Jun 13, 2014 at 5:26 AM, Josh Durgin <[email protected]> wrote:
> On 06/11/2014 09:40 AM, Ilya Dryomov wrote:
>>
>> 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.
>>
>> Signed-off-by: Ilya Dryomov <[email protected]>
>> ---
>
>
> Good catch! This should be included in any stable kernels 3.10 or later
> too.
>
> Reviewed-by: Josh Durgin <[email protected]>
This commit in ceph-client already has the 3.10+ stable tag.
Thanks,
Ilya
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html