From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:38320)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1a3ifs-0005CB-24
	for qemu-devel@nongnu.org; Tue, 01 Dec 2015 06:00:44 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1a3ifo-0007RK-Ot
	for qemu-devel@nongnu.org; Tue, 01 Dec 2015 06:00:44 -0500
Date: Tue, 1 Dec 2015 12:00:28 +0100
From: Kevin Wolf <kwolf@redhat.com>
Message-ID: <20151201110028.GD6527@noname.str.redhat.com>
References: <1448962590-2842-1-git-send-email-famz@redhat.com>
	<1448962590-2842-2-git-send-email-famz@redhat.com>
	<20151201095436.GC6527@noname.str.redhat.com>
	<20151201102658.GA6787@ad.usersys.redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20151201102658.GA6787@ad.usersys.redhat.com>
Subject: Re: [Qemu-devel] [PATCH 1/3] block: Don't wait serialising for
 non-COR read requests
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Fam Zheng <famz@redhat.com>
Cc: Jeff Cody <jcody@redhat.com>, qemu-block@nongnu.org, qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>

Am 01.12.2015 um 11:26 hat Fam Zheng geschrieben:
> On Tue, 12/01 10:54, Kevin Wolf wrote:
> > Am 01.12.2015 um 10:36 hat Fam Zheng geschrieben:
> > > The assertion problem was noticed in 06c3916b35a, but it wasn't
> > > completely fixed, because even though the req is not marked as
> > > serialising, it still gets serialised by wait_serialising_requests
> > > against other serialising requests, which could lead to the same
> > > assertion failure.
> > > 
> > > Fix it by even more explicitly skipping the serialising for this
> > > specific case.
> > > 
> > > Signed-off-by: Fam Zheng <famz@redhat.com>
> > 
> > And this, my friends, is another example why read/write notifiers are
> > wrong and should die sooner rather than later. </broken-record>
> > 
> 
> Yes, I agree, except it's not clear to me what a better alternative solution
> should be. A immediate question is, with whatever approach we will have,
> wouldn't we still need to do this sort of "reentrant" COW before the data is
> overwritten?

If the backup job could temporarily insert a filter driver, you wouldn't
get reentrance, but another BDS in the stack.

Now that much of the blockdev-add stuff seems to be falling into place
at last, dynamic reconfiguration and filters might be the next big nut
for us to crack.

Kevin