From patchwork Sat Apr 30 21:48:56 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Blake X-Patchwork-Id: 8987531 Return-Path: X-Original-To: patchwork-qemu-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 4E87D9F1D3 for ; Sat, 30 Apr 2016 21:49:49 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 9FB5B20166 for ; Sat, 30 Apr 2016 21:49:46 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B01C520155 for ; Sat, 30 Apr 2016 21:49:45 +0000 (UTC) Received: from localhost ([::1]:59840 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1awclh-0007Fo-ER for patchwork-qemu-devel@patchwork.kernel.org; Sat, 30 Apr 2016 17:49:41 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56216) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1awclV-00075s-BN for qemu-devel@nongnu.org; Sat, 30 Apr 2016 17:49:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1awclJ-00013m-Iw for qemu-devel@nongnu.org; Sat, 30 Apr 2016 17:49:23 -0400 Received: from resqmta-po-03v.sys.comcast.net ([2001:558:fe16:19:96:114:154:162]:60371) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1awclI-0000zO-7y for qemu-devel@nongnu.org; Sat, 30 Apr 2016 17:49:17 -0400 Received: from resomta-po-15v.sys.comcast.net ([96.114.154.239]) by comcast with SMTP id wcl5a124TYPZXwcl5aVN2k; Sat, 30 Apr 2016 21:49:03 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1462052943; bh=7kVD1CqQEZyAchdponDf/+TCK7+vvrkEbeE8WaETspE=; h=Received:Received:From:To:Subject:Date:Message-Id; b=meGJWqv4ZqpUHLFgQ5grH1MG1nt+wLGZ3p9kH2jigS0k8xhtgANTieRb6zpM5tvzJ CrrGOsgDexieRA2N7F2A5F3eylYzbycZ5eDb/1DfaZHqvauW4NNMbUNWN7/4Mx+iWr v02iK6xJURJ2pU4L2kjzOjOl1k+x+D09+BGZTCo8WSSvAO0ZIwgOeSZ/1g2eVrHq1Q N26H32HZSoe+xSCSUCZ2uBjNa3aRrK8PWtowlrYDICy4I0RYZmod9xPPS5W64OQbBA LzoS2q6+MQFuMWRJWsFFqySKwN+KucVkjhB5x/7pyuDOpM17uIk1skJptlDoSqOQTJ z2AMQgkywsoEw== Received: from red.redhat.com ([24.10.254.122]) by resomta-po-15v.sys.comcast.net with comcast id oloy1s00M2fD5rL01lp2xq; Sat, 30 Apr 2016 21:49:03 +0000 From: Eric Blake To: qemu-devel@nongnu.org Date: Sat, 30 Apr 2016 15:48:56 -0600 Message-Id: <1462052936-16933-1-git-send-email-eblake@redhat.com> X-Mailer: git-send-email 2.5.5 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2001:558:fe16:19:96:114:154:162 Subject: [Qemu-devel] [PATCH] block: Don't lose FUA flag during ZERO_WRITE fallback X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Kevin Wolf , Fam Zheng , "open list:Block I/O path" , qemu-stable@nongnu.org, Max Reitz , Stefan Hajnoczi Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: "Qemu-devel" X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI, T_DKIM_INVALID, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP NBD has situations where it can support FUA but not ZERO_WRITE; when that happens, the generic block layer fallback was losing the FUA flag. The problem of losing flags unrelated to ZERO_WRITE has been latent in bdrv_co_do_write_zeroes() since aa7bfbff, but back then, it did not matter because there was no FUA flag. But ever since 93f5e6d8 added bdrv_co_writev_flags(), the loss of flags can impact correctness. Compare to commit 9eeb6dd, which got it right in bdrv_co_do_zero_pwritev(). Symptoms: I tested with qemu-io with default writethrough cache (which is supposed to use FUA semantics on every write), and targetted an NBD client connected to a server that intentionally did not advertise NBD_FLAG_SEND_FUA. When doing 'write 0 512', the NBD client sent two operations (NBD_CMD_WRITE then NBD_CMD_FLUSH) to get the fallback FUA semantics; but when doing 'write -z 0 512', the NBD client sent only NBD_CMD_WRITE; the missing flush meant that an ill-timed disconnect could leave the zeroes unflushed. CC: qemu-stable@nongnu.org Signed-off-by: Eric Blake --- As written, this patch applies to 2.7 on top of Kevin's block-next branch. Since it's (probably) too late for 2.6, we'll need to backport it to there, but the backport will have to use bdrv_co_writev_flags since 2.6 lacks bdrv_driver_pwritev(). block/io.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/block/io.c b/block/io.c index 0db1146..bd46e47 100644 --- a/block/io.c +++ b/block/io.c @@ -1213,7 +1213,8 @@ static int coroutine_fn bdrv_co_do_write_zeroes(BlockDriverState *bs, qemu_iovec_init_external(&qiov, &iov, 1); ret = bdrv_driver_pwritev(bs, sector_num * BDRV_SECTOR_SIZE, - num * BDRV_SECTOR_SIZE, &qiov, 0); + num * BDRV_SECTOR_SIZE, &qiov, + flags & ~BDRV_REQ_ZERO_WRITE); /* Keep bounce buffer around if it is big enough for all * all future requests.