From patchwork Tue Mar 17 15:11:10 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrzej Pietrasiewicz X-Patchwork-Id: 11443115 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 507FB14DD for ; Tue, 17 Mar 2020 15:11:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2E3BC20714 for ; Tue, 17 Mar 2020 15:11:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726765AbgCQPLU (ORCPT ); Tue, 17 Mar 2020 11:11:20 -0400 Received: from bhuna.collabora.co.uk ([46.235.227.227]:33854 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726754AbgCQPLU (ORCPT ); Tue, 17 Mar 2020 11:11:20 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: andrzej.p) with ESMTPSA id 28492290AC5 From: Andrzej Pietrasiewicz To: linux-block@vger.kernel.org Cc: Jens Axboe , kernel@collabora.com, andrzej.p@collabora.com, Evan Green Subject: [PATCH 1/2] loop: Report EOPNOTSUPP properly Date: Tue, 17 Mar 2020 16:11:10 +0100 Message-Id: <20200317151111.25749-2-andrzej.p@collabora.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200317151111.25749-1-andrzej.p@collabora.com> References: <20200317151111.25749-1-andrzej.p@collabora.com> Sender: linux-block-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org From: Evan Green Properly plumb out EOPNOTSUPP from loop driver operations, which may get returned when for instance a discard operation is attempted but not supported by the underlying block device. Before this change, everything was reported in the log as an I/O error, which is scary and not helpful in debugging. Signed-off-by: Evan Green Reviewed-by: Ming Lei Reviewed-by: Bart Van Assche Reviewed-by: Martin K. Petersen Reviewed-by: Gwendal Grignou Reviewed-by: Chaitanya Kulkarni --- drivers/block/loop.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/block/loop.c b/drivers/block/loop.c index 739b372a5112..87307454f768 100644 --- a/drivers/block/loop.c +++ b/drivers/block/loop.c @@ -460,7 +460,9 @@ static void lo_complete_rq(struct request *rq) if (!cmd->use_aio || cmd->ret < 0 || cmd->ret == blk_rq_bytes(rq) || req_op(rq) != REQ_OP_READ) { - if (cmd->ret < 0) + if (cmd->ret == -EOPNOTSUPP) + ret = BLK_STS_NOTSUPP; + else if (cmd->ret < 0) ret = BLK_STS_IOERR; goto end_io; } @@ -1953,7 +1955,10 @@ static void loop_handle_cmd(struct loop_cmd *cmd) failed: /* complete non-aio request */ if (!cmd->use_aio || ret) { - cmd->ret = ret ? -EIO : 0; + if (ret == -EOPNOTSUPP) + cmd->ret = ret; + else + cmd->ret = ret ? -EIO : 0; blk_mq_complete_request(rq); } } From patchwork Tue Mar 17 15:11:11 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrzej Pietrasiewicz X-Patchwork-Id: 11443119 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id C2A5F14DD for ; Tue, 17 Mar 2020 15:11:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id AD02520754 for ; Tue, 17 Mar 2020 15:11:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726781AbgCQPLW (ORCPT ); Tue, 17 Mar 2020 11:11:22 -0400 Received: from bhuna.collabora.co.uk ([46.235.227.227]:33860 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726478AbgCQPLW (ORCPT ); Tue, 17 Mar 2020 11:11:22 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: andrzej.p) with ESMTPSA id A0A06290AD2 From: Andrzej Pietrasiewicz To: linux-block@vger.kernel.org Cc: Jens Axboe , kernel@collabora.com, andrzej.p@collabora.com, Evan Green Subject: [PATCH 2/2] loop: Better discard support for block devices Date: Tue, 17 Mar 2020 16:11:11 +0100 Message-Id: <20200317151111.25749-3-andrzej.p@collabora.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200317151111.25749-1-andrzej.p@collabora.com> References: <20200317151111.25749-1-andrzej.p@collabora.com> Sender: linux-block-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org From: Evan Green If the backing device for a loop device is a block device, then mirror the "write zeroes" capabilities of the underlying block device into the loop device. Copy this capability into both max_write_zeroes_sectors and max_discard_sectors of the loop device. The reason for this is that REQ_OP_DISCARD on a loop device translates into blkdev_issue_zeroout(), rather than blkdev_issue_discard(). This presents a consistent interface for loop devices (that discarded data is zeroed), regardless of the backing device type of the loop device. There should be no behavior change for loop devices backed by regular files. This change fixes blktest block/003, and removes an extraneous error print in block/013 when testing on a loop device backed by a block device that does not support discard. Signed-off-by: Evan Green [rebase onto v5.6-rc6] Signed-off-by: Andrzej Pietrasiewicz --- Changes in v5: - Don't mirror discard if lo_encrypt_key_size is non-zero (Gwendal) Changes in v4: - Mirror blkdev's write_zeroes into loopdev's discard_sectors. Changes in v3: - Updated commit description Changes in v2: None --- drivers/block/loop.c | 42 +++++++++++++++++++++++++++++++----------- 1 file changed, 31 insertions(+), 11 deletions(-) diff --git a/drivers/block/loop.c b/drivers/block/loop.c index 87307454f768..8de3b2b098d3 100644 --- a/drivers/block/loop.c +++ b/drivers/block/loop.c @@ -427,11 +427,12 @@ static int lo_fallocate(struct loop_device *lo, struct request *rq, loff_t pos, * information. */ struct file *file = lo->lo_backing_file; + struct request_queue *q = lo->lo_queue; int ret; mode |= FALLOC_FL_KEEP_SIZE; - if ((!file->f_op->fallocate) || lo->lo_encrypt_key_size) { + if (!blk_queue_discard(q)) { ret = -EOPNOTSUPP; goto out; } @@ -867,28 +868,47 @@ static void loop_config_discard(struct loop_device *lo) struct inode *inode = file->f_mapping->host; struct request_queue *q = lo->lo_queue; + + /* + * If the backing device is a block device, mirror its zeroing + * capability. REQ_OP_DISCARD translates to a zero-out even when backed + * by block devices to keep consistent behavior with file-backed loop + * devices. + */ + if (S_ISBLK(inode->i_mode) && !lo->lo_encrypt_key_size) { + struct request_queue *backingq; + + backingq = bdev_get_queue(inode->i_bdev); + blk_queue_max_discard_sectors(q, + backingq->limits.max_write_zeroes_sectors); + + blk_queue_max_write_zeroes_sectors(q, + backingq->limits.max_write_zeroes_sectors); + /* * We use punch hole to reclaim the free space used by the * image a.k.a. discard. However we do not support discard if * encryption is enabled, because it may give an attacker * useful information. */ - if ((!file->f_op->fallocate) || - lo->lo_encrypt_key_size) { + } else if ((!file->f_op->fallocate) || lo->lo_encrypt_key_size) { q->limits.discard_granularity = 0; q->limits.discard_alignment = 0; blk_queue_max_discard_sectors(q, 0); blk_queue_max_write_zeroes_sectors(q, 0); - blk_queue_flag_clear(QUEUE_FLAG_DISCARD, q); - return; - } - q->limits.discard_granularity = inode->i_sb->s_blocksize; - q->limits.discard_alignment = 0; + } else { + q->limits.discard_granularity = inode->i_sb->s_blocksize; + q->limits.discard_alignment = 0; + + blk_queue_max_discard_sectors(q, UINT_MAX >> 9); + blk_queue_max_write_zeroes_sectors(q, UINT_MAX >> 9); + } - blk_queue_max_discard_sectors(q, UINT_MAX >> 9); - blk_queue_max_write_zeroes_sectors(q, UINT_MAX >> 9); - blk_queue_flag_set(QUEUE_FLAG_DISCARD, q); + if (q->limits.max_write_zeroes_sectors) + blk_queue_flag_set(QUEUE_FLAG_DISCARD, q); + else + blk_queue_flag_clear(QUEUE_FLAG_DISCARD, q); } static void loop_unprepare_queue(struct loop_device *lo)