[Devel] [PATCH hci-8.1 0/2] dm-zero-rq: fix a crash on a flush after ploop release

[Devel] [PATCH hci-8.1 0/2] dm-zero-rq: fix a crash on a flush after ploop release

[Denis V. Lunev]

ploop releases a device by reloading it to the error target, and
ploop_dmreload_zero() (VSTOR-146886) later reloads it to zero-rq while
the file system on top is still mounted. A request queued against the previous table waits out
the suspend and is dispatched to zero-rq on resume.

For a flush this is a host panic: the flush request has no bio and
zero_clone_and_map_rq() reads the operation from rq->bio. QA hit it in
the vzctl release-disks test on hci-8.1 (VSTOR-152097): sgdisk run by
"vzctl release-disks" called sync() just before the reload. The vmcore
shows the queue's own flush_rq (REQ_OP_FLUSH, bio NULL, end_io
flush_end_io) in zero-rq, and the original empty PREFLUSH bio from
ext4_sync_fs() still waiting on the flush queue.

Patch 1 fixes the crash: the operation is taken from the request, and a
flush is killed like any other request zero-rq does not handle. Patch 2
completes flushes, discards and write zeroes instead of failing them,
which is what the zero-rq reload is there for. It is split out because
it changes what the target returns, not only whether it crashes.

The error and multipath request-based targets do not look at rq->bio,
so mainline is not affected; dm-zero-rq is ours.

Tested on 6.12.0-211.52.1.22.10.vz10 with the module built out of tree,
by suspending a released device, starting a sync or a blkdiscard on it,
then running ploop_dmreload_zero():
- stock: the node panics with the oops QA got, every time;
- patch 1: no panic, the sync and the discard fail with EIO;
- patches 1+2: both complete, nothing in the log;
- the ploop release tests, ploop and qcow2 formats, pass. The new
  tests for ploop_dmreload_zero() and the reproducer above go to ploop
  separately.

Denis V. Lunev (2):
  dm-zero-rq: fix a NULL dereference mapping a flush request
  dm-zero-rq: drop flushes, discards and write zeroes instead of failing
    them

 drivers/md/dm-zero-rq.c | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)


base-commit: b499efa17aa9fb8f20512d1831d1cb61b22e60d3
-- 
2.53.0

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

[Devel] [PATCH hci-8.1 1/2] dm-zero-rq: fix a NULL dereference mapping a flush request

[Denis V. Lunev]

From: Denis V. Lunev <den@openvz.org>

zero_clone_and_map_rq() reads the operation from rq->bio. The flush
request the block layer issues for a preflush carries no bio, so the
target oopses in the kblockd worker:

  BUG: kernel NULL pointer dereference, address: 0000000000000010
  RIP: 0010:zero_clone_and_map_rq+0x12/0x70 [dm_zero_rq]
   map_request+0x57/0x230 [dm_mod]
   dm_mq_queue_rq+0xe0/0x240 [dm_mod]

zero-rq advertises no write cache, but a flush reaches it anyway after
a table swap. ploop releases a device by reloading it to the error
target, which keeps the write cache on, and later to zero-rq while the
file system on top is still mounted. A flush queued against the
previous table waits out the suspend and is dispatched to zero-rq on
resume. A sync during "vzctl release-disks" is enough to hit it.

Take the operation from the request. The flush is now killed like any
other request zero-rq does not handle.

Fixes: caf9c61aeb93 ("dm-zero-req: Introduce zero request based target")
https://virtuozzo.atlassian.net/browse/VSTOR-152097
Feature: cbt: changed block tracking (for backup)
Signed-off-by: Denis V. Lunev <den@openvz.org>
---
 drivers/md/dm-zero-rq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/md/dm-zero-rq.c b/drivers/md/dm-zero-rq.c
index 9e44de15dcd6..4f09266ff5ed 100644
--- a/drivers/md/dm-zero-rq.c
+++ b/drivers/md/dm-zero-rq.c
@@ -38,7 +38,7 @@ static int zero_clone_and_map_rq(struct dm_target *ti, struct request *rq,
 {
 	struct bio *bio = rq->bio;
 
-	switch (bio_op(bio)) {
+	switch (req_op(rq)) {
 	case REQ_OP_READ:
 		while (bio) {
 			zero_fill_bio(bio);
-- 
2.53.0

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

Re: [Devel] [PATCH hci-8.1 1/2] dm-zero-rq: fix a NULL dereference mapping a flush request

[no-reply]

> From: Denis V. Lunev <den@openvz.org>
> 
> zero_clone_and_map_rq() reads the operation from rq->bio. The flush
> request the block layer issues for a preflush carries no bio, so the
> target oopses in the kblockd worker:
> 
>   BUG: kernel NULL pointer dereference, address: 0000000000000010
>   RIP: 0010:zero_clone_and_map_rq+0x12/0x70 [dm_zero_rq]
>    map_request+0x57/0x230 [dm_mod]
>    dm_mq_queue_rq+0xe0/0x240 [dm_mod]
> 
> zero-rq advertises no write cache, but a flush reaches it anyway after
> a table swap. ploop releases a device by reloading it to the error
> target, which keeps the write cache on, and later to zero-rq while the
> file system on top is still mounted. A flush queued against the
> previous table waits out the suspend and is dispatched to zero-rq on
> resume. A sync during "vzctl release-disks" is enough to hit it.
> 
> Take the operation from the request. The flush is now killed like any
> other request zero-rq does not handle.
> 
> Fixes: caf9c61aeb93 ("dm-zero-req: Introduce zero request based target")
> https://virtuozzo.atlassian.net/browse/VSTOR-152097
> Feature: cbt: changed block tracking (for backup)
> Signed-off-by: Denis V. Lunev <den@openvz.org>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.vzint.dev/#/patchset/20261028123130.2828357-1-den@openvz.org?part=1


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

[Devel] [PATCH hci-8.1 2/2] dm-zero-rq: drop flushes, discards and write zeroes instead of failing them

[Denis V. Lunev]

From: Denis V. Lunev <den@openvz.org>

zero-rq kills every request that is not a read or a write. Requests
queued against the previous table and dispatched to zero-rq after a
table swap therefore fail, a flush with an error returned to the
syncing task and a discard with an I/O error in the log:

  I/O error, dev dm-0, sector 0 op 0x3:(DISCARD) flags 0x4800

ploop reloads a released device to zero-rq precisely to keep the file
system on it from seeing such errors.

Complete flushes, discards and write zeroes as writes are completed.
Reads already return zeros, so all of them are honoured. Drop
num_discard_bios from the constructor: it only matters to bio-based
targets and to targets that pass discards through to a device, and
zero-rq is neither, so "silently drop discards" above it never held.

https://virtuozzo.atlassian.net/browse/VSTOR-152097
Feature: cbt: changed block tracking (for backup)
Signed-off-by: Denis V. Lunev <den@openvz.org>
---
 drivers/md/dm-zero-rq.c | 10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/md/dm-zero-rq.c b/drivers/md/dm-zero-rq.c
index 4f09266ff5ed..315ef8c930b3 100644
--- a/drivers/md/dm-zero-rq.c
+++ b/drivers/md/dm-zero-rq.c
@@ -24,11 +24,6 @@ static int zero_ctr(struct dm_target *ti, unsigned int argc, char **argv)
 		return -EINVAL;
 	}
 
-	/*
-	 * Silently drop discards, avoiding -EOPNOTSUPP.
-	 */
-	ti->num_discard_bios = 1;
-
 	return 0;
 }
 
@@ -47,7 +42,10 @@ static int zero_clone_and_map_rq(struct dm_target *ti, struct request *rq,
 
 		break;
 	case REQ_OP_WRITE:
-		/* writes get silently dropped */
+	case REQ_OP_FLUSH:
+	case REQ_OP_DISCARD:
+	case REQ_OP_WRITE_ZEROES:
+		/* writes of any kind get silently dropped */
 		break;
 	default:
 		return DM_MAPIO_KILL;
-- 
2.53.0

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

Re: [Devel] [PATCH hci-8.1 2/2] dm-zero-rq: drop flushes, discards and write zeroes instead of failing them

[no-reply]

> From: Denis V. Lunev <den@openvz.org>
> 
> zero-rq kills every request that is not a read or a write. Requests
> queued against the previous table and dispatched to zero-rq after a
> table swap therefore fail, a flush with an error returned to the
> syncing task and a discard with an I/O error in the log:
> 
>   I/O error, dev dm-0, sector 0 op 0x3:(DISCARD) flags 0x4800
> 
> ploop reloads a released device to zero-rq precisely to keep the file
> system on it from seeing such errors.
> 
> Complete flushes, discards and write zeroes as writes are completed.
> Reads already return zeros, so all of them are honoured. Drop
> num_discard_bios from the constructor: it only matters to bio-based
> targets and to targets that pass discards through to a device, and
> zero-rq is neither, so "silently drop discards" above it never held.
> 
> https://virtuozzo.atlassian.net/browse/VSTOR-152097
> Feature: cbt: changed block tracking (for backup)
> Signed-off-by: Denis V. Lunev <den@openvz.org>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.vzint.dev/#/patchset/20261028123130.2828357-1-den@openvz.org?part=2


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

Re: [Devel] [PATCH hci-8.1 2/2] dm-zero-rq: drop flushes, discards and write zeroes instead of failing them

[Konstantin Khorenko]

On 10/28/26 13:31, Denis V. Lunev wrote:
> dm-zero-rq: drop flushes, discards and write zeroes instead of failing them

Will commit, with three edits to the message only, the code is fine.

1. Subject: "write zeroes" dropped, so

   dm-zero-rq: complete flushes and discards instead of failing them

   No table in our tree sets num_write_zeroes_bios (ploop, qcow2, error,
   zero-rq), so max_write_zeroes_sectors is 0 everywhere and
   submit_bio_noacct() rejects such a bio before a request exists. The
   case label is harmless, but no write zeroes request can be queued
   against a previous table. The old subject was also 75 characters.

> table swap therefore fail, a flush with an error returned to the
> syncing task and a discard with an I/O error in the log:

2. sync(2) returns void, the error reaches fsync()/syncfs() and the jbd2
   commit, which aborts the journal. And a killed flush leaves an I/O
   error line in the log too, for the PREFLUSH request that waited on it
   (blk_flush_complete_seq() -> blk_mq_end_request()). So: "a flush with
   an error returned to fsync and to the journal commit, and both with
   an I/O error in the log".

> num_discard_bios from the constructor: it only matters to bio-based
> targets and to targets that pass discards through to a device, and
> zero-rq is neither, so "silently drop discards" above it never held.

3. dm_table_supports_discards() also honours a target that sets
   discards_supported without any device, which is what error, ploop,
   qcow2 and mainline dm-zero do. The assignment was dead because zero-rq
   never set discards_supported, not because it is request-based. I will
   say that instead.

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

Re: [Devel] [PATCH hci-8.1 0/2] dm-zero-rq: fix a crash on a flush after ploop release

[Andrey Zhadchenko]

Reviewed-by: Andrey Zhadchenko <andrey.zhadchenko@virtuozzo.com>

On 10/28/26 13:31, Denis V. Lunev wrote:
> ploop releases a device by reloading it to the error target, and
> ploop_dmreload_zero() (VSTOR-146886) later reloads it to zero-rq while
> the file system on top is still mounted. A request queued against the previous table waits out
> the suspend and is dispatched to zero-rq on resume.
> 
> For a flush this is a host panic: the flush request has no bio and
> zero_clone_and_map_rq() reads the operation from rq->bio. QA hit it in
> the vzctl release-disks test on hci-8.1 (VSTOR-152097): sgdisk run by
> "vzctl release-disks" called sync() just before the reload. The vmcore
> shows the queue's own flush_rq (REQ_OP_FLUSH, bio NULL, end_io
> flush_end_io) in zero-rq, and the original empty PREFLUSH bio from
> ext4_sync_fs() still waiting on the flush queue.
> 
> Patch 1 fixes the crash: the operation is taken from the request, and a
> flush is killed like any other request zero-rq does not handle. Patch 2
> completes flushes, discards and write zeroes instead of failing them,
> which is what the zero-rq reload is there for. It is split out because
> it changes what the target returns, not only whether it crashes.
> 
> The error and multipath request-based targets do not look at rq->bio,
> so mainline is not affected; dm-zero-rq is ours.
> 
> Tested on 6.12.0-211.52.1.22.10.vz10 with the module built out of tree,
> by suspending a released device, starting a sync or a blkdiscard on it,
> then running ploop_dmreload_zero():
> - stock: the node panics with the oops QA got, every time;
> - patch 1: no panic, the sync and the discard fail with EIO;
> - patches 1+2: both complete, nothing in the log;
> - the ploop release tests, ploop and qcow2 formats, pass. The new
>    tests for ploop_dmreload_zero() and the reproducer above go to ploop
>    separately.
> 
> Denis V. Lunev (2):
>    dm-zero-rq: fix a NULL dereference mapping a flush request
>    dm-zero-rq: drop flushes, discards and write zeroes instead of failing
>      them
> 
>   drivers/md/dm-zero-rq.c | 12 +++++-------
>   1 file changed, 5 insertions(+), 7 deletions(-)
> 
> 
> base-commit: b499efa17aa9fb8f20512d1831d1cb61b22e60d3

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

Re: [Devel] [PATCH hci-8.1 0/2] dm-zero-rq: fix a crash on a flush after ploop release

[Konstantin Khorenko]

On Wed, 28 Oct 2026 13:31:27 +0100, Denis V. Lunev <den@openvz.org> wrote:
> dm-zero-rq: fix a crash on a flush after ploop release
> 
> ploop releases a device by reloading it to the error target, and
> ploop_dmreload_zero() (VSTOR-146886) later reloads it to zero-rq while
> the file system on top is still mounted. A request queued against the previous table waits out
> the suspend and is dispatched to zero-rq on resume.
> 
> [...]

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

Re: [Devel] [PATCH hci-8.1 0/2] dm-zero-rq: fix a crash on a flush after ploop release

[Konstantin Khorenko]

On Wed, 28 Oct 2026 13:31:27 +0100, Denis V. Lunev wrote:
> dm-zero-rq: fix a crash on a flush after ploop release
> 
> ploop releases a device by reloading it to the error target, and
> ploop_dmreload_zero() (VSTOR-146886) later reloads it to zero-rq while
> the file system on top is still mounted. A request queued against the previous table waits out
> the suspend and is dispatched to zero-rq on resume.
> 
> [...]

Applied to branch-rh10-6.12.0-211.52.1.22.x.vz10-ovz, will be released in rh10-6.12.0-211.52.1.22.12.vz10, thanks!

[1/2] dm-zero-rq: fix a NULL dereference mapping a flush request
      https://bitbucket.org/virtuozzocore/vzkernel.vzs/commits/715454eaf102
[2/2] dm-zero-rq: drop flushes, discards and write zeroes instead of failing them
      https://bitbucket.org/virtuozzocore/vzkernel.vzs/commits/7196ed314486

-- 
Konstantin Khorenko,
Virtuozzo Linux Kernel Team


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