From patchwork Thu Sep 21 17:12:52 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ilya Dryomov X-Patchwork-Id: 9964519 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 57EE06020C for ; Thu, 21 Sep 2017 17:13:11 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 3DA3728662 for ; Thu, 21 Sep 2017 17:13:11 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 321BE28944; Thu, 21 Sep 2017 17:13:11 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.5 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 6060228675 for ; Thu, 21 Sep 2017 17:13:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751919AbdIURNJ (ORCPT ); Thu, 21 Sep 2017 13:13:09 -0400 Received: from mail-wr0-f193.google.com ([209.85.128.193]:35825 "EHLO mail-wr0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751693AbdIURNG (ORCPT ); Thu, 21 Sep 2017 13:13:06 -0400 Received: by mail-wr0-f193.google.com with SMTP id n64so3477110wrb.2 for ; Thu, 21 Sep 2017 10:13:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=nc98Te+mWXN2JnmAGU66r910JyIuk13JmdN6A0wIitk=; b=PNey8MgYjrs+pK2A8AhG9a8RiHxE8Tn8xRIhodFSzNGz3fZWn3W73U7q459oS7pS4G 8lkzPG3ao45HsRJhJP3e28G5jauPvrxvHDUoqn5XGq17EKB/BcUXl+XblHhnlu6Y11mF 5kJxE69rCvAcm+E2VPdqpMwc3M2U9ZOal/wuJI968vKKmGTkNqCHPGCiSrOHLGm9luPn dHp4j27wsbd8imTA4+yh4Xizj/GuOx+6lOsXGwgAnTknC4UOpLmZwtwFch3elK/mleXN 4HojFsRsh6astlVmR4ievRaFjYOmbWCzWa/E750qdkpU08yrAmGeFsvtidJSn2U5CwQn /0uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=nc98Te+mWXN2JnmAGU66r910JyIuk13JmdN6A0wIitk=; b=oaYHktTFhE9Erh0OcvTQ442axVd11F6KYclCQhWI8nhn/LR/x//r4QpsadsCMU7nPO bteXVY/LMBsN8pVcqA3cNlmUhObHE87qTLWzF7zJXD3G4LaXBG2ezXiYg3WeTSv8DGmz 9wdRvj5esM0SJuP2kTfuh8JiB81XlczM17Hdzq7p+0Q1NfX3hbShmoxnqmjRlyfOf9I5 f+SdEE4qxxYSvtCeud1hnLzvAGBkarLuWGWUJEOVIM2itPiUuAWT+qdkjbwCJ+NE968L TVUGDyO3zGq82kXjtKALqTckiUjpqw2SNSW9qQ4jTwIcIdOlWnJXg591zlIyr32elARd r77g== X-Gm-Message-State: AHPjjUiyRjqV9ns6YfUmBKo7Ba1DmI1si27gVcCT+6VGfSH47Y4AN/B6 Xm5k4Cr7VK/Xwcp/7XuoTqE= X-Google-Smtp-Source: AOwi7QDp+gqVaByLXEmEXlfvdZLV+ZUWZh8dFs0SIXBoL7DFAVNKF4qPTL8uDYzz9mGOQTATa2M6Rg== X-Received: by 10.223.169.247 with SMTP id b110mr2402465wrd.31.1506013985361; Thu, 21 Sep 2017 10:13:05 -0700 (PDT) Received: from orange.redhat.com ([213.175.37.12]) by smtp.gmail.com with ESMTPSA id i13sm1083021wre.93.2017.09.21.10.13.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Sep 2017 10:13:04 -0700 (PDT) From: Ilya Dryomov To: Christoph Hellwig Cc: "Martin K. Petersen" , Hannes Reinecke , Jens Axboe , linux-block@vger.kernel.org Subject: [PATCH 2/2] block: cope with WRITE ZEROES failing in blkdev_issue_zeroout() Date: Thu, 21 Sep 2017 19:12:52 +0200 Message-Id: <1506013972-23049-3-git-send-email-idryomov@gmail.com> X-Mailer: git-send-email 2.4.3 In-Reply-To: <1506013972-23049-1-git-send-email-idryomov@gmail.com> References: <1506013972-23049-1-git-send-email-idryomov@gmail.com> Sender: linux-block-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP sd_config_write_same() ignores ->max_ws_blocks == 0 and resets it to permit trying WRITE SAME on older SCSI devices, unless ->no_write_same is set. Because REQ_OP_WRITE_ZEROES is implemented in terms of WRITE SAME, blkdev_issue_zeroout() may fail with -EREMOTEIO: $ fallocate -zn -l 1k /dev/sdg fallocate: fallocate failed: Remote I/O error $ fallocate -zn -l 1k /dev/sdg # OK $ fallocate -zn -l 1k /dev/sdg # OK The following calls succeed because sd_done() sets ->no_write_same in response to a sense that would become BLK_STS_TARGET/-EREMOTEIO, causing __blkdev_issue_zeroout() to fall back to generating ZERO_PAGE bios. This means blkdev_issue_zeroout() must cope with WRITE ZEROES failing and fall back to manually zeroing, unless BLKDEV_ZERO_NOFALLBACK is specified. For BLKDEV_ZERO_NOFALLBACK case, return -EOPNOTSUPP if sd_done() has just set ->no_write_same thus indicating lack of offload support. Fixes: c20cfc27a473 ("block: stop using blkdev_issue_write_same for zeroing") Cc: Christoph Hellwig Cc: "Martin K. Petersen" Cc: Hannes Reinecke Signed-off-by: Ilya Dryomov --- block/blk-lib.c | 27 +++++++++++++++++++++------ 1 file changed, 21 insertions(+), 6 deletions(-) diff --git a/block/blk-lib.c b/block/blk-lib.c index 6b97feb71065..1cb402beb983 100644 --- a/block/blk-lib.c +++ b/block/blk-lib.c @@ -316,12 +316,6 @@ static void __blkdev_issue_zero_pages(struct block_device *bdev, * Zero-fill a block range, either using hardware offload or by explicitly * writing zeroes to the device. * - * Note that this function may fail with -EOPNOTSUPP if the driver signals - * zeroing offload support, but the device fails to process the command (for - * some devices there is no non-destructive way to verify whether this - * operation is actually supported). In this case the caller should call - * retry the call to blkdev_issue_zeroout() and the fallback path will be used. - * * If a device is using logical block provisioning, the underlying space will * not be released if %flags contains BLKDEV_ZERO_NOUNMAP. * @@ -374,6 +368,27 @@ int blkdev_issue_zeroout(struct block_device *bdev, sector_t sector, &bio, flags); if (ret == 0 && bio) { ret = submit_bio_wait(bio); + /* + * Fall back to a manual zeroout on any error, if allowed. + * + * Particularly, WRITE ZEROES may fail with -EREMOTEIO if the + * driver signals zeroing offload support, but the device + * fails to process the command (for some devices there is no + * non-destructive way to verify whether this operation is + * actually supported). + */ + if (ret && bio_op(bio) == REQ_OP_WRITE_ZEROES) { + if (flags & BLKDEV_ZERO_NOFALLBACK) { + if (!bdev_write_zeroes_sectors(bdev)) + ret = -EOPNOTSUPP; + } else { + bio_put(bio); + bio = NULL; + __blkdev_issue_zero_pages(bdev, sector, + nr_sects, gfp_mask, &bio); + ret = submit_bio_wait(bio); + } + } bio_put(bio); } blk_finish_plug(&plug);