OpenVZ / Virtuozzo kernel development (devel@openvz.org)
 help / color / mirror / Atom feed
From: "Denis V. Lunev" <den@openvz.org>
To: andrey.zhadchenko@virtuozzo.com
Cc: devel@openvz.org
Subject: [Devel] [PATCH hci-8.1 v3 0/5] dm-qcow2: fix merges not stopping the users of the images they change
Date: Wed,  4 Nov 2026 19:01:00 +0100	[thread overview]
Message-ID: <20261104180105.1807820-1-den@openvz.org> (raw)

Checking dm-qcow2 for the same problem showed that a merge does not
stop everything using the images it changes (VSTOR-153049,
VSTOR-153050):

- a backward merge of an inner image starts without pausing anything,
  while reads enter through the top image. A read reaching the inner
  image as the merge starts oopses on a NULL qio->ext (patch 2);

- SEEK_HOLE/SEEK_DATA walks the images with nothing keeping them
  alive, so merge_backward complete frees an image under the walk
  (patch 3). Patch 4 (VSTOR-153422) fixes a seek that sleeps forever
  after a failed metadata read, which with patch 3 would also hold off
  the next merge_backward complete and every target message.

Patches 1 and 5 fix the refcount table relocation. Patch 1
(VSTOR-153051) is the counterpart of dm-ploop patch 4, an error path
leaving state behind: after a failed relocation, allocating writes past
the old refcount coverage fail with EIO until the device is suspended
and resumed. Patch 5 (VSTOR-153421) fixes a relocation failing on a
valid image once the new reftable fills a refcount group by itself,
with 4K clusters and refcount_bits=64 at about 511G.

The series does not depend on the dm-ploop one.

Tested on dev-cl04, stock 6.12.0-211.52.1.22.11.vz10, dm-qcow2 built
out of tree:
- with a test-only kprobe module widening the windows, on the stock
  module: with 4K clusters and refcount_bits=64 so the reftable
  relocates at 1G, a failed md page insert left every later write past
  1G failing with EIO; a seek went on with an image qcow2_destroy() had
  freed; an intermediate merge oopsed in submit_read_sliced_clu(). None
  of them reproduce with the series;
- SEEK_DATA over an image whose backing device starts failing reads
  returns EIO with patch 4;
- an image with a 511-cluster reftable covering 511G and every cluster
  in use: without patch 5 the first allocating write fails with EIO
  after a WARN, and qemu-img check then reports 513 errors; with it the
  writes go through and the check finds no errors;
- the ploop pytest suite, qcow2 format, passes.

Changes in v3, after Konstantin's review:
- 1/5: once the header write has succeeded, the error paths only return
  -EIO and leave the new md pages alone, as they may already be dirty
  and queued for writeback. The commit message says so in place of the
  note;
- 2/5: "no guest writes" in the comment, and the message says that
  starting or stopping a merge of an inner image now pauses guest I/O
  to the top image for the inflight ref switch;
- 3/5: the message says that merge_backward complete now waits for a
  running seek while it holds ctl_mutex;
- 4/5, 5/5: new, the two older bugs found in the review;
- rebased on rh10-6.12.0-211.52.1.22.17.vz10, Reviewed-by tags added
  to 2/5 and 3/5; Andrey's on 1/5 is dropped, as its code changed.

v2: http://lore.virtuozzo.com/kernel/20261103090813.166986-1-den@openvz.org/
v1: http://lore.virtuozzo.com/kernel/20261103083708.131379-1-den@openvz.org/

Denis V. Lunev (5):
  dm-qcow2: fix a failed refcount table relocation leaking md pages
  dm-qcow2: fix backward merge of an inner image racing its reads
  dm-qcow2: fix SEEK_HOLE/SEEK_DATA using an image freed by a merge
  dm-qcow2: fix SEEK_HOLE/SEEK_DATA hanging after a failed metadata read
  dm-qcow2: fix a refcount table relocation failing on a valid image

 drivers/md/dm-qcow2-cmd.c    | 28 ++++++++-----------
 drivers/md/dm-qcow2-map.c    | 53 ++++++++++++++++++++++++++----------
 drivers/md/dm-qcow2-target.c |  1 +
 drivers/md/dm-qcow2.h        |  2 ++
 4 files changed, 54 insertions(+), 30 deletions(-)


base-commit: 95ab11e2c57e8468412ca586d4be8cd75b6bfbf0
-- 
2.53.0

_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel

             reply	other threads:[~2026-11-04 18:43 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-04 18:01 Denis V. Lunev [this message]
2026-11-04 18:01 ` [Devel] [PATCH hci-8.1 v3 1/5] dm-qcow2: fix a failed refcount table relocation leaking md pages Denis V. Lunev
2026-11-04 18:52   ` no-reply
2026-11-04 18:01 ` [Devel] [PATCH hci-8.1 v3 2/5] dm-qcow2: fix backward merge of an inner image racing its reads Denis V. Lunev
2026-11-04 18:52   ` no-reply
2026-11-04 18:01 ` [Devel] [PATCH hci-8.1 v3 3/5] dm-qcow2: fix SEEK_HOLE/SEEK_DATA using an image freed by a merge Denis V. Lunev
2026-11-04 18:54   ` no-reply
2026-11-04 18:01 ` [Devel] [PATCH hci-8.1 v3 4/5] dm-qcow2: fix SEEK_HOLE/SEEK_DATA hanging after a failed metadata read Denis V. Lunev
2026-11-04 18:55   ` no-reply
2026-11-04 18:01 ` [Devel] [PATCH hci-8.1 v3 5/5] dm-qcow2: fix a refcount table relocation failing on a valid image Denis V. Lunev
2026-11-04 18:55   ` no-reply
2026-11-04 18:30 ` [Devel] [PATCH hci-8.1 v3 0/5] dm-qcow2: fix merges not stopping the users of the images they change Konstantin Khorenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261104180105.1807820-1-den@openvz.org \
    --to=den@openvz.org \
    --cc=andrey.zhadchenko@virtuozzo.com \
    --cc=devel@openvz.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox