From: Konstantin Khorenko <khorenko@virtuozzo.com>
To: "Denis V. Lunev" <den@openvz.org>
Cc: devel@openvz.org
Subject: Re: [Devel] [PATCH hci-8.1 v2 2/3] dm-ploop: refuse flip_upper_deltas onto a lower delta smaller than the device
Date: Thu, 05 Nov 2026 19:19:02 +0100 [thread overview]
Message-ID: <179390274229.2948524.12095886078781139789.b4-review@b4> (raw)
In-Reply-To: <20261105145749.2643035-3-den@openvz.org>
Applying with these fixes on my side:
- paragraphs 1 and 2 of the commit message replaced with:
A flip_upper_deltas after a grow of the device, with the lower delta
left at its old size, makes a top delta whose header covers fewer
entries than the delta below it. Unless a write rewrites BAT page 0
first, the stack no longer loads. When the grow added BAT clusters, a
write past the old size can also put a BAT page onto a data cluster of
that file.
Today ploop_check_delta_before_flip() oopses on such a flip only when
the grow added BAT pages, as its walk runs past the end of the BAT of
the lower delta. A grow within the same BAT pages already gets
through, and fixing the walk alone would let every such flip through.
- paragraph 3: "Read the header of the lower delta on every flip, not
only under PLOOP_DEBUG" became "Check the size of the lower delta
outside PLOOP_DEBUG", and "a stack that ploop_add_delta() refuses on
the next load" became "a top delta whose header covers fewer entries
than the delta below it".
On Thu, 05 Nov 2026 15:57:48 +0100, Denis V. Lunev wrote:
> A flip_upper_deltas after a grow of the device, with the lower delta
> left at its old size, makes a top delta whose header and BAT cover fewer
> entries than the device. After resume the BAT writeback puts the grown
> header into page 0 of that file and the BAT pages past its old size onto
> its data clusters, and the image no longer opens.
Only dirty BAT pages are written back, and page 0 gets dirty only from
a write to its own clusters. BAT pages land on data only when the grow
added BAT clusters. In your 1G -> 2G test the new top kept its old
m_Size, and that is the EPROTO you saw. My v1 reply described it
wrongly.
> Today ploop_check_delta_before_flip() oopses on such a flip before it
> gets that far, as its walk runs past the end of the BAT of the lower
> delta. Fixing the walk alone would let the flip through.
The old walk oopses only when the grow added BAT pages; a grow within
the same pages returns 0 and the flip goes through today.
> Read the header of the lower delta on every flip, not only under
> PLOOP_DEBUG, and refuse with -EBADSLT when it has fewer BAT entries than
The call reads and converts the whole BAT, as Sashiko said, and it
already ran on every flip since PLOOP_DEBUG is always defined. Whether
the flipped stack fails with EPROTO or EBADSLT depends on how the table
length is set, so the new text names no errno.
With that fixed:
Reviewed-by: Konstantin Khorenko <khorenko@virtuozzo.com>
--
Konstantin Khorenko,
Virtuozzo Linux Kernel Team
_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel
next prev parent reply other threads:[~2026-11-05 18:20 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-05 14:57 [Devel] [PATCH hci-8.1 v2 0/3] dm-ploop: fix flip_upper_deltas panicking the host in its pre-flip check Denis V. Lunev
2026-11-05 14:57 ` [Devel] [PATCH hci-8.1 v2 1/3] dm-ploop: fix flip_upper_deltas returning with two md_locks held Denis V. Lunev
2026-11-05 15:01 ` no-reply
2026-11-05 14:57 ` [Devel] [PATCH hci-8.1 v2 2/3] dm-ploop: refuse flip_upper_deltas onto a lower delta smaller than the device Denis V. Lunev
2026-11-05 15:02 ` no-reply
2026-11-05 18:19 ` Konstantin Khorenko [this message]
2026-11-05 14:57 ` [Devel] [PATCH hci-8.1 v2 3/3] dm-ploop: fix the flip_upper_deltas check skipping the last BAT entry Denis V. Lunev
2026-11-05 15:02 ` no-reply
2026-11-05 18:19 ` Konstantin Khorenko
2026-11-05 18:19 ` [Devel] [PATCH hci-8.1 v2 0/3] dm-ploop: fix flip_upper_deltas panicking the host in its pre-flip check Konstantin Khorenko
2026-11-05 18:19 ` 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=179390274229.2948524.12095886078781139789.b4-review@b4 \
--to=khorenko@virtuozzo.com \
--cc=den@openvz.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.