From: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
To: Max Reitz <mreitz@redhat.com>,
"qemu-block@nongnu.org" <qemu-block@nongnu.org>
Cc: Kevin Wolf <kwolf@redhat.com>, John Snow <jsnow@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Markus Armbruster <armbru@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 0/4] mirror: Do not dereference invalid pointers
Date: Thu, 19 Sep 2019 16:50:24 +0000 [thread overview]
Message-ID: <53346693-e4ef-ee75-0438-d223d22b1c27@virtuozzo.com> (raw)
In-Reply-To: <00893c8e-f67b-db95-cfb9-bc1059470091@redhat.com>
19.09.2019 19:45, Max Reitz wrote:
> On 18.09.19 17:38, Vladimir Sementsov-Ogievskiy wrote:
>> 12.09.2019 16:56, Max Reitz wrote:
>>> Hi,
>>>
>>> The fix (patch 1) is pretty straightforward; patch 2 (which I need for
>>> the test) may not be.
>>>
>>> The biggest problem with patch 2 is that you can use it to uncover where
>>> our permission handling is broken. For example, devising the test case
>>> (patch 4) was very difficult because I kept running into the
>>> &error_abort that mirror_exit_common() passes when dropping the
>>> mirror_top_bs.
>>>
>>> The problem is that mirror_top_bs does not take the same permissions
>>> that its parent takes. Ergo using &error_abort when dropping it is
>>> wrong: The parent may require more permissions that mirror_top_bs did,
>>> and so dropping mirror_top_bs may fail.
>>>
>>> Now what’s really bad is that this cannot be fixed with our current
>>> permission system. mirror_top_bs was introduced precisely so it does
>>> not take CONSISTENT_READ, but can still allow parents to take it (for
>>> active commits). But what if there is actually something besides the
>>> mirror job that unshares CONSISTENT_READ?
>>>
>>>
>>> Imagine this:
>>>
>>> mirror target BB mirror source BB
>>> | |
>>> v v
>>> mirror_top_bs -> top -> mid -> base
>>> ^
>>> |
>>> other_parent
>>>
>>> The source BB unshares CONSISTENT_READ on the base. mirror_top_bs
>>> ensures that its parents can read from top even though top itself cannot
>>> allow CONSISTENT_READ to be taken. So far so good.
>>>
>>> But what if other_parent also unshares CONSISTENT_READ? Then,
>>> mirror_top_bs has no business allowing its parents to take it.
>>>
>>> No idea how to fix that. (I suppose mirror_top_bs would need some way
>>> to verify that there is no other party that has unshared CONSISTENT_READ
>>> but its associated source BB.
>>
>> May be we need grouped permissions?
>>
>> Some way to define group of children, which may unshare read permission
>> for other children (out of the group), but still children in group may
>> have read permission?
>
> Hm, is that different from my idea below where one of mirror_top's
> children unshares the read permission, and another is allowed to take it
> still?
I just tried to imagine something generic
>
> (The problem is always that if some BDS has a parent that unshares this
> permission, this condition propagates upwards through its other parents,
> and we need to keep track of who unshared it in the first place.)
>
>> But it don't work here as we are saying about children on different
>> nodes.. And propagated through backing chain permissions..
>
> Yep.
>
>>> In the future, we want the source BB to
>>> go away and instead have the source be an immediate BdrvChild of
>>> mirror_top_bs. Maybe we can then build something into the block layer
>>> so that a node can only restore CONSISTENT_READ when it was that node
>>> that broke it?)
>>>
>>>
>>> Anyway. You can see something arising from this problem simply by
>>> unsharing CONSISTENT_READ on the target node. (Just drop the src-perm
>>> node from the test I add in patch 4.) Replacing the source with the
>>> target will then work fine (because mirror_top_bs doesn’t care about
>>> CONSISTENT_READ being removed), but then you cannot drop mirror_top_bs –
>>> because its parent does want CONSISTENT_READ. Thus, the &error_abort
>>> aborts.
>>>
>>>
>>> While this is a more special case, I have no idea how to fix this one
>>> either.
>>>
>>>
>>> Soo... This series just fixes one thing, and leaves another unfixed
>>> because I have no idea how to fix it. Worse, it adds parameters to
>>> blkdebug to actually see the problem. Do we want to let blkdebug be
>>> able to crash qemu (because of a bug in qemu)?
>>>
>>
>> blkdebug is for debugging and not used by end users like libvirt, yes?
>
> Correct.
>
>
>>>
>>> Max Reitz (4):
>>> mirror: Do not dereference invalid pointers
>>> blkdebug: Allow taking/unsharing permissions
>>> iotests: Add @error to wait_until_completed
>>> iotests: Add test for failing mirror complete
>>>
>>> qapi/block-core.json | 29 +++++++++-
>>> block/blkdebug.c | 106 +++++++++++++++++++++++++++++++++-
>>> block/mirror.c | 13 +++--
>>> tests/qemu-iotests/041 | 44 ++++++++++++++
>>> tests/qemu-iotests/041.out | 4 +-
>>> tests/qemu-iotests/iotests.py | 18 ++++--
>>> 6 files changed, 200 insertions(+), 14 deletions(-)
>>>
>>
>>
>
>
--
Best regards,
Vladimir
prev parent reply other threads:[~2019-09-19 16:53 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-12 13:56 [Qemu-devel] [PATCH 0/4] mirror: Do not dereference invalid pointers Max Reitz
2019-09-12 13:56 ` [Qemu-devel] [PATCH 1/4] " Max Reitz
2019-09-13 22:43 ` John Snow
2019-09-18 15:16 ` Vladimir Sementsov-Ogievskiy
2019-09-12 13:56 ` [Qemu-devel] [PATCH 2/4] blkdebug: Allow taking/unsharing permissions Max Reitz
2019-09-18 16:01 ` Vladimir Sementsov-Ogievskiy
2019-09-19 16:49 ` Max Reitz
2019-09-12 13:56 ` [Qemu-devel] [PATCH 3/4] iotests: Add @error to wait_until_completed Max Reitz
2019-09-13 22:53 ` John Snow
2019-09-16 7:56 ` Max Reitz
2019-09-18 16:09 ` Vladimir Sementsov-Ogievskiy
2019-09-12 13:56 ` [Qemu-devel] [PATCH 4/4] iotests: Add test for failing mirror complete Max Reitz
2019-09-18 16:30 ` Vladimir Sementsov-Ogievskiy
2019-09-19 16:51 ` Max Reitz
2019-09-18 18:46 ` John Snow
2019-09-19 16:58 ` Max Reitz
2019-09-19 17:02 ` John Snow
2019-09-19 17:06 ` Max Reitz
2019-09-18 15:38 ` [Qemu-devel] [PATCH 0/4] mirror: Do not dereference invalid pointers Vladimir Sementsov-Ogievskiy
2019-09-19 16:45 ` Max Reitz
2019-09-19 16:50 ` Vladimir Sementsov-Ogievskiy [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=53346693-e4ef-ee75-0438-d223d22b1c27@virtuozzo.com \
--to=vsementsov@virtuozzo.com \
--cc=armbru@redhat.com \
--cc=jsnow@redhat.com \
--cc=kwolf@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).