[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [PATCH v7 0/3] Fix qcow2+luks corruption introduced by
Re: [Qemu-block] [PATCH v7 0/3] Fix qcow2+luks corruption introduced by commit 8ac0f15f335
Mon, 16 Sep 2019 16:59:51 +0300
On Mon, 2019-09-16 at 15:39 +0200, Max Reitz wrote:
> On 15.09.19 22:36, Maxim Levitsky wrote:
> > Commit 8ac0f15f335 accidently broke the COW of non changed areas
> > of newly allocated clusters, when the write spans multiple clusters,
> > and needs COW both prior and after the write.
> > This results in 'after' COW area being encrypted with wrong
> > sector address, which render it corrupted.
> > Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1745922
> > CC: qemu-stable <address@hidden>
> > V2: grammar, spelling and code style fixes.
> > V3: more fixes after the review.
> > V4: addressed review comments from Max Reitz,
> > and futher refactored the qcow2_co_encrypt to just take full host and
> > guest offset
> > which simplifies everything.
> > V5: reworked the patches so one of them fixes the bug
> > only and other one is just refactoring
> > V6: removed do_perform_cow_encrypt
> > V7: removed do_perform_cow_encrypt take two, this
> > time I hopefully did that correctly :-)
> > Also updated commit names and messages a bit
> Luckily for you (maybe), Vladimir’s series doesn‘t quite pass the
> iotests for me, so unfortunately (I find it unfortunate) I had to remove
> it from my branch. Thus, the conflicts are much more tame and I felt
> comfortable taking the series to my branch (with the remaining trivial
> conflicts resolved, and with Vladimir’s suggestion applied):
First of all, Thanks!
I don't know if this is luckily for me since I already rebased my series on top
and run all qcow2 iotests, and only tests
162 169 194 196 234 262 failed, and I know that 162 always fails
due to that kernel change I talked about here few days ago,
and rest for the AF_UNIX path len, which I need to do something
about in the long term. I sometimes do a separate build in
directory which path doesn't trigger this, and sometimes,
when I know that I haven't done significant changes to the patches,
I just let these tests fail. In long term, maybe even in a few days
I'll allocate some time to rethink the build environment here to
fix that permanently.
Now I am rerunning the iotests just for fun, in short enough directory
to see if I can reproduce the failure that you had. After looking
in your report, that iotest 026 fails, it does pass here, but
then I am only running these iotests on my laptop so I probably
don't trigger the race you were able to.
So thanks again!