]> git.apps.os.sepia.ceph.com Git - ceph-ci.git/commit
librbd: make diff-iterate in fast-diff mode aware of encryption
authorIlya Dryomov <idryomov@gmail.com>
Thu, 20 Jun 2024 19:13:56 +0000 (21:13 +0200)
committerIlya Dryomov <idryomov@gmail.com>
Mon, 15 Jul 2024 14:27:28 +0000 (16:27 +0200)
commitd64b1af84dbac0de9d8c94203a8b768a72c2b0a5
treec993e02c0ea0215763c4d4a5497101ad4ee5e12c
parent089181eee1b0f1cade03e3561353f38ed36c448d
librbd: make diff-iterate in fast-diff mode aware of encryption

diff-iterate wasn't updated when librbd was being prepared to support
encryption in commit 8d6a47933269 ("librbd: add crypto image dispatch
layer").  This is even noted in [1]:

> The two places I skipped for now are DiffIterate and TrimRequest.

CryptoImageDispatch has since been removed, but diff-iterate in
fast-diff mode is still unaware of encryption and just assumes that all
offsets are raw.  This means that the callback gets invoked with
incorrect image offsets when encryption is loaded.  For example, for
a LUKS1-formatted image with some data at offsets 0 and 20971520,
diff-iterate with encryption loaded reports

  0~4194304
  4194304~4194304
  25165824~4194304

instead of

  0~4194304
  20971520~4194304

as "exists".  For any piece of code that is using diff-iterate to
optimize block-by-block processing (e.g. copy an encrypted source image
to a differently-encrypted destination image), this is fatal: it would
skip processing block 20971520 which has data and instead process block
25165824 which doesn't have any data and was to be skipped, producing
a corrupted destination image.

[1] https://github.com/ceph/ceph/pull/37935#issue-735278403

Fixes: https://tracker.ceph.com/issues/66570
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
(cherry picked from commit cdeb0efce3f9f857ad6d5b7ff3965f3292cb571a)
src/librbd/api/DiffIterate.cc
src/test/librbd/test_librbd.cc