From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44529) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VgxAt-0000YW-CX for qemu-devel@nongnu.org; Thu, 14 Nov 2013 08:41:43 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VgxAk-0001tN-VQ for qemu-devel@nongnu.org; Thu, 14 Nov 2013 08:41:35 -0500 Received: from mail-bk0-x235.google.com ([2a00:1450:4008:c01::235]:45992) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VgxAk-0001tD-6R for qemu-devel@nongnu.org; Thu, 14 Nov 2013 08:41:26 -0500 Received: by mail-bk0-f53.google.com with SMTP id na10so1071262bkb.12 for ; Thu, 14 Nov 2013 05:41:25 -0800 (PST) Date: Thu, 14 Nov 2013 14:41:22 +0100 From: Stefan Hajnoczi Message-ID: <20131114134122.GC26847@stefanha-thinkpad.redhat.com> References: <1384371478-20021-1-git-send-email-mreitz@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1384371478-20021-1-git-send-email-mreitz@redhat.com> Subject: Re: [Qemu-devel] [PATCH] block/stream: Don't stream unbacked devices List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Reitz Cc: Kevin Wolf , Paolo Bonzini , qemu-devel@nongnu.org, Stefan Hajnoczi On Wed, Nov 13, 2013 at 08:37:58PM +0100, Max Reitz wrote: > If a block device is unbacked, a streaming blockjob should immediately > finish instead of beginning to try to stream, then noticing the backing > file does not contain even the first sector (since it does not exist) > and then finishing normally. > > Signed-off-by: Max Reitz > --- > block/stream.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/block/stream.c b/block/stream.c > index 694fd42..46bec7d 100644 > --- a/block/stream.c > +++ b/block/stream.c > @@ -88,6 +88,11 @@ static void coroutine_fn stream_run(void *opaque) > int n = 0; > void *buf; > > + if (!bs->backing_hd) { > + block_job_completed(&s->common, 0); > + return; > + } > + Thanks for raising this, it's a bug that we don't verify that the image has a backing file. I'd rather return an error that the user attempted to do something pointless. It was a mistake on their part and it helps to bring this to their attention right away. CCing Eric Blake because strictly speaking, adding a error where we previously used to return success breaks API compatibility. Any suggestions (I guess QEMU could just log a warning instead of failing the command)? Stefan