qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Cc: "psyhomb@gmail.com" <psyhomb@gmail.com>,
	"michael@weiser.dinsnail.net" <michael@weiser.dinsnail.net>,
	Denis Lunev <den@virtuozzo.com>,
	"qemu-block@nongnu.org" <qemu-block@nongnu.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"qemu-stable@nongnu.org" <qemu-stable@nongnu.org>,
	"dgilbert@redhat.com" <dgilbert@redhat.com>,
	"mreitz@redhat.com" <mreitz@redhat.com>,
	"lersek@redhat.com" <lersek@redhat.com>
Subject: Re: [PATCH 3/3] qcow2: Fix corruption bug in qcow2_detect_metadata_preallocation()
Date: Thu, 24 Oct 2019 13:17:10 +0200	[thread overview]
Message-ID: <20191024111710.GC6200@linux.fritz.box> (raw)
In-Reply-To: <3cfee2ed-cebb-44ef-82ce-77a77c1a9e6a@virtuozzo.com>

Am 24.10.2019 um 12:46 hat Vladimir Sementsov-Ogievskiy geschrieben:
> 23.10.2019 18:26, Kevin Wolf wrote:
> > qcow2_detect_metadata_preallocation() calls qcow2_get_refcount() which
> > requires s->lock to be taken to protect its accesses to the refcount
> > table and refcount blocks. However, nothing in this code path actually
> > took the lock. This could cause the same cache entry to be used by two
> > requests at the same time, for different tables at different offsets,
> > resulting in image corruption.
> > 
> > As it would be preferable to base the detection on consistent data (even
> > though it's just heuristics), let's take the lock not only around the
> > qcow2_get_refcount() calls, but around the whole function.
> > 
> > This patch takes the lock in qcow2_co_block_status() earlier and asserts
> > in qcow2_detect_metadata_preallocation() that we hold the lock.
> > 
> > Fixes: 69f47505ee66afaa513305de0c1895a224e52c45
> > Cc: qemu-stable@nongnu.org
> > Reported-by: Michael Weiser <michael@weiser.dinsnail.net>
> > Signed-off-by: Kevin Wolf <kwolf@redhat.com>
> 
> Oh, I'm very sorry. I was going to backport this patch, and found that it's
> fixed in our downstream long ago, even before last upstream version patch sent :(

Seriously? Is your downstream QEMU so divergent from upstream that you
wouldn't notice something like this? I think you really have to improve
something there.

I mean, we have a serious data corruptor in the 4.1 release and I wasted
days to debug this, and you've been sitting on a fix for months without
telling anyone? This isn't a memory leak or something, this kills
people's images. It's eating their data.

Modifying an image format driver requires utmost care and I think I'll
try to make sure to allow only few qcow2 changes per release in the
future. Too many changes were made in too short time, and with too
little care, and there are even more qcow2 patches pending. Please check
whether these series actually match your downstream code. Anyway, we'll
tread very carefully now with the pending patches, even if it means
delaying them for another release or two. Stability is way more
important for an image format driver than new features and
optimisations.

Do whatever you need to fix your downstream process, but seriously, this
must not ever happen again.

Kevin



  reply	other threads:[~2019-10-24 11:53 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-23 15:26 [PATCH 0/3] qcow2: Fix image corruption bug in 4.1 Kevin Wolf
2019-10-23 15:26 ` [PATCH 1/3] coroutine: Add qemu_co_mutex_assert_locked() Kevin Wolf
2019-10-24  9:59   ` Denis Lunev
2019-10-24 10:54     ` Kevin Wolf
2019-10-24 11:11       ` Denis Lunev
2019-10-23 15:26 ` [PATCH 2/3] qcow2: Assert that qcow2_cache_get() callers hold s->lock Kevin Wolf
2019-10-23 15:37   ` Kevin Wolf
2019-10-25 10:35     ` Michael Weiser
2019-10-25 12:42       ` Kevin Wolf
2019-10-24 10:01   ` Denis Lunev
2019-10-24 10:57     ` Kevin Wolf
2019-10-24 11:14       ` Denis Lunev
2019-10-24 12:07         ` Kevin Wolf
2019-10-24 13:03       ` Vladimir Sementsov-Ogievskiy
2019-10-24 13:17         ` Kevin Wolf
2019-10-23 15:26 ` [PATCH 3/3] qcow2: Fix corruption bug in qcow2_detect_metadata_preallocation() Kevin Wolf
2019-10-24 10:46   ` Vladimir Sementsov-Ogievskiy
2019-10-24 11:17     ` Kevin Wolf [this message]
2019-10-24 12:41       ` Vladimir Sementsov-Ogievskiy

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=20191024111710.GC6200@linux.fritz.box \
    --to=kwolf@redhat.com \
    --cc=den@virtuozzo.com \
    --cc=dgilbert@redhat.com \
    --cc=lersek@redhat.com \
    --cc=michael@weiser.dinsnail.net \
    --cc=mreitz@redhat.com \
    --cc=psyhomb@gmail.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-stable@nongnu.org \
    --cc=vsementsov@virtuozzo.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 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).