]> 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, 8 Jul 2024 14:59:03 +0000 (16:59 +0200)
commit8f7381a58e06d6366f1fa3b68cb4d116f559c218
treefa64bf540fc3827a6cc773094c417833872fa385
parenta3bb22092e8ee5f6c5ad59c64b9a758156b85972
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