]> git-server-git.apps.pok.os.sepia.ceph.com Git - ceph.git/commit
librbd: make diff-iterate in fast-diff mode aware of encryption 58201/head
authorIlya Dryomov <idryomov@gmail.com>
Thu, 20 Jun 2024 19:13:56 +0000 (21:13 +0200)
committerIlya Dryomov <idryomov@gmail.com>
Sat, 22 Jun 2024 18:48:41 +0000 (20:48 +0200)
commitcdeb0efce3f9f857ad6d5b7ff3965f3292cb571a
tree6ea1df0e15da273c2c084659a3548c8afa5c0d4c
parentda69d1fdbf69cf37ba8b75ea9a230634bb25ae76
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>
src/librbd/api/DiffIterate.cc
src/test/librbd/test_librbd.cc