From: Kevin Wolf <kwolf@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org, hreitz@redhat.com,
vsementsov@yandex-team.ru
Subject: Re: [PATCH] block: Fix bdrv_activate() not to fail without medium
Date: Thu, 20 Mar 2025 12:30:18 +0100 [thread overview]
Message-ID: <Z9v8SjOHxEm4ouXM@redhat.com> (raw)
In-Reply-To: <87tt7x87um.fsf@pond.sub.org>
Am 13.03.2025 um 12:53 hat Markus Armbruster geschrieben:
> Kevin Wolf <kwolf@redhat.com> writes:
>
> > Am 12.03.2025 um 15:37 hat Markus Armbruster geschrieben:
> >> bdrv_activate() returns failure without setting an error when
> >> !bs->drv. This is suspicious. Turns out it used to succeed then,
> >> until commit 5416645fcf82 changed it to return -ENOMEDIUM.
> >>
> >> Return zero instead.
> >>
> >> Fixes: 5416645fcf82 (block: return error-code from bdrv_invalidate_cache)
> >> Signed-off-by: Markus Armbruster <armbru@redhat.com>
> >
> > The commit message sounds more theoretical. Did you find this only by
> > code inspection? Do we know what the effect on real-world cases is, so
> > we could add a sentence about it to the commit message? Maybe we could
> > even have a qemu-iotests case to show the effect?
> >
> > I absolutely agree that returning -ENOMEDIUM while not setting errp is
> > wrong. But without an example of what is affected, it's not obvious to
> > me which part of it needs to be fixed.
>
> Code inspection.
>
> Here's my somewhat extended rationale for my fix.
> [...]
> Not failing the function on !bs->drv is clearly intentional.
>
> Behavior stayed this way for more than six years. Then commit
> 5416645fcf8 (block: return error-code from bdrv_invalidate_cache)
> changed the function to return zero on success, a negative errno on
> failure. According to the commit message, the patch is mere cleanup,
> and not supposed to change behavior.
>
> Since the first return was a success before the patch (no error set),
> the correct value to return was zero. The patch used -ENOMEDIUM
> instead. This is a clear regression.
>
> My patch restores previous behavior.
I understand your rationale and don't disagree with your patch.
But I would still like the commit message to explain the practical
consequences of the bug and if possible a test case.
If you tried to find the practical consequences and couldn't find any
way to trigger a bug as a user, that is worth documenting, too.
Kevin
prev parent reply other threads:[~2025-03-20 11:31 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-12 14:37 [PATCH] block: Fix bdrv_activate() not to fail without medium Markus Armbruster
2025-03-13 10:17 ` Kevin Wolf
2025-03-13 10:44 ` Markus Armbruster
2025-03-13 10:45 ` Markus Armbruster
2025-03-13 11:53 ` Markus Armbruster
2025-03-20 11:30 ` 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=Z9v8SjOHxEm4ouXM@redhat.com \
--to=kwolf@redhat.com \
--cc=armbru@redhat.com \
--cc=hreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=vsementsov@yandex-team.ru \
/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.