From: Kevin Wolf <kwolf@redhat.com>
To: Max Reitz <mreitz@redhat.com>
Cc: qemu-block@nongnu.org, qemu-devel@nongnu.org,
Alberto Garcia <berto@igalia.com>, Fam Zheng <famz@redhat.com>
Subject: Re: [Qemu-devel] [PATCH for-3.1? v2 0/3] block: Fix two minor reopen issues
Date: Mon, 19 Nov 2018 14:37:48 +0100 [thread overview]
Message-ID: <20181119133748.GF8066@localhost.localdomain> (raw)
In-Reply-To: <20181116164526.31487-1-mreitz@redhat.com>
Am 16.11.2018 um 17:45 hat Max Reitz geschrieben:
> These are fixes for issues I found when looking after something Berto
> has reported. The second patch fixes that issue Berto found, the first
> one is only kind of related.
>
> For the first patch: bdrv_reopen_abort() or bdrv_reopen_commit() are
> called only if the respective bdrv_reopen_prepare() has succeeded.
> However, bdrv_reopen_prepare() can fail even if the block driver’s
> .bdrv_reopen_prepare() succeeded. In that case, the block driver is
> expecting a .bdrv_reopen_abort() or .bdrv_reopen_commit(), but will
> never get it.
>
> This is fixed by making bdrv_reopen_prepare() call .bdrv_reopen_abort()
> if an error occurs after .bdrv_reopen_prepare() has already succeeded.
>
> In practice this just prevents resource leaks, so nothing too dramatic
> (fine for qemu-next). It also means I’ve been incapable of writing a
> test, sorry.
>
>
> The second issue is more severe: file-posix applies the inverse share
> locks when reopening. Now the user can only directly do reopens from
> the monitor for now, so that wouldn’t be so bad. But of course there
> are other places in qemu that implicitly reopen nodes, like dropping
> R/W to RO or gaining R/W from RO. Most of these places are symmetrical
> at least (they’ll get R/W on an RO image for a short period of time and
> then drop back to RO), so you’ll see the wrong shared permission locks
> only for a short duration. But at least blockdev-snapshot and
> blockdev-snapshot-sync are one way; they drop R/W to RO and stay there.
> So if you do a blockdev-snapshot*, the shared permission bits will be
> flipped. This is therefore very much user-visible.
>
> It’s not catastrophic, though, so I’m not sure whether we need it in
> 3.1. It’s definitely a bugfix, and I think we have patches queued for
> the next RC already, so I think it makes sense to include at least
> patches 2 and 3 as well.
Thanks, applied to the block branch.
Kevin
prev parent reply other threads:[~2018-11-19 13:38 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-16 16:45 [Qemu-devel] [PATCH for-3.1? v2 0/3] block: Fix two minor reopen issues Max Reitz
2018-11-16 16:45 ` [Qemu-devel] [PATCH for-3.1? v2 1/3] block: Always abort reopen after prepare succeeded Max Reitz
2018-11-19 8:35 ` Alberto Garcia
2018-11-16 16:45 ` [Qemu-devel] [PATCH for-3.1? v2 2/3] file-posix: Fix shared locks on reopen commit Max Reitz
2018-11-19 10:10 ` Alberto Garcia
2018-11-16 16:45 ` [Qemu-devel] [PATCH for-3.1? v2 3/3] iotests: Test file-posix locking and reopen Max Reitz
2018-11-19 9:53 ` Alberto Garcia
2018-11-19 13:37 ` 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=20181119133748.GF8066@localhost.localdomain \
--to=kwolf@redhat.com \
--cc=berto@igalia.com \
--cc=famz@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.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.