All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Cc: Wesley Hershberger <wesley.hershberger@canonical.com>,
	qemu-devel@nongnu.org, Hanna Reitz <hreitz@redhat.com>,
	qemu-block@nongnu.org, jsnow@redhat.com
Subject: Re: [PATCH] block: Add missing null checks during query-named-block-nodes
Date: Tue, 28 Oct 2025 11:29:17 +0100	[thread overview]
Message-ID: <aQCa_dDWxGWlQa_N@redhat.com> (raw)
In-Reply-To: <a6a09fdf-e5a6-4c8e-b232-223bbbd53509@yandex-team.ru>

Am 27.10.2025 um 20:44 hat Vladimir Sementsov-Ogievskiy geschrieben:
> Anyway, starting from 3860c0201924d, permission restrictions become less aggressive, let's
> check, staying at 3860c0201924d, and with same hack to bdrv_drop_filter:
> 
> check -qcow2 028 055 056 124 129 141 185 219 222 256 257 264 281 283 294 304
> 
> - only 257 fails. (why?)
> 
> Double check with 3860c0201924d^: again, almost all fails:
> 
> Failures: 028 055 056 124 129 185 222 256 257 264 281 304
> 
> 
> 
> And same with current master: 257 fails, if hack bdrv_drop_filter() to
> pass detach_subchain=false to bdrv_replace_node_common().

I'm trying to understand the 257, but that seems to be a fairly
complicated test case.

Looking at the first failing part, this uses error injection with a
blkdebug configuration where one single I/O error is injected on the
second read after the first flush. This feels very specific, like it's
targeting a specific operation to fail, but it doesn't really document
what it is.

John, I'm sure that after six years, you remember the details! :-)

Anyway, the difference that we're seeing after changing
bdrv_drop_filter() to pass detach_subchain=false is that now the error
seems to be triggered earlier. The same error that we get in the bad
output happens in the reference output, too, but only during "Test
Backup #1" rather than "Reference Backup #1".

So taking a shot in the dark, I tried failing the second read after the
_second_ flush (patch see below), and that fixes the test apart from the
changed blockdev-add commands. So not detaching the cor node causes an
additional flush on the image. I suspect this might be the flush in
bdrv_close() when the cor node is deleted?

Anyway, an additional flush is harmless, so I think we should be good if
we just change the test case.

Kevin


diff --git a/block.c b/block.c
index cf08e64add..982371e735 100644
--- a/block.c
+++ b/block.c
@@ -5478,7 +5478,7 @@ int bdrv_drop_filter(BlockDriverState *bs, Error **errp)

     bdrv_drained_begin(child_bs);
     bdrv_graph_wrlock();
-    ret = bdrv_replace_node_common(bs, child_bs, true, true, errp);
+    ret = bdrv_replace_node_common(bs, child_bs, true, false, errp);
     bdrv_graph_wrunlock();
     bdrv_drained_end(child_bs);

diff --git a/tests/qemu-iotests/257 b/tests/qemu-iotests/257
index 7d3720b8e5..dffc3ba0a4 100755
--- a/tests/qemu-iotests/257
+++ b/tests/qemu-iotests/257
@@ -310,14 +310,18 @@ def test_bitmap_sync(bsync_mode, msync_mode='bitmap', failure=None):
                     'state': 1,
                     'new_state': 2
                 }, {
-                    'event': 'read_aio',
+                    'event': 'flush_to_disk',
                     'state': 2,
                     'new_state': 3
+                }, {
+                    'event': 'read_aio',
+                    'state': 3,
+                    'new_state': 4
                 }],
                 'inject-error': [{
                     'event': 'read_aio',
                     'errno': 5,
-                    'state': 3,
+                    'state': 4,
                     'immediately': False,
                     'once': True
                 }]



      reply	other threads:[~2025-10-28 10:30 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-24 18:07 [PATCH] block: Add missing null checks during query-named-block-nodes Wesley Hershberger
2025-10-25  8:27 ` Vladimir Sementsov-Ogievskiy
2025-10-27  9:55 ` Kevin Wolf
2025-10-27 16:04   ` Wesley Hershberger
2025-10-27 18:45     ` Kevin Wolf
2025-10-27 20:42       ` Vladimir Sementsov-Ogievskiy
2025-10-27 20:55     ` Vladimir Sementsov-Ogievskiy
2025-10-27 19:44   ` Vladimir Sementsov-Ogievskiy
2025-10-28 10:29     ` Kevin Wolf [this message]

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=aQCa_dDWxGWlQa_N@redhat.com \
    --to=kwolf@redhat.com \
    --cc=hreitz@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=vsementsov@yandex-team.ru \
    --cc=wesley.hershberger@canonical.com \
    /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.