Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp7491102yba; Thu, 2 May 2019 10:45:34 -0700 (PDT) X-Google-Smtp-Source: APXvYqz+qfFgObSiy1OcOre/8CTJD4r3YCBh0dJ6ztSuLmgoIqMGOctYpPKrmpHsEQQs4WG51QWk X-Received: by 2002:aa7:810e:: with SMTP id b14mr5691967pfi.112.1556819134686; Thu, 02 May 2019 10:45:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556819134; cv=none; d=google.com; s=arc-20160816; b=NE1Hd91HsIbADALGHDVTTgKxKr7jxJd4INsEnLbkzwa4YMcodXldzbfSdnMtwz5smf SLeo4TG4ZRk1FKiu/BtMw7PV0MQxhmZ17LiecySL0GTVyVraIXUpkcP77cdT1w2cpF7L a75wPAcDPUN6SvBHwzExvipaUJFHE02QoEUu9tkmQ42pZh4jcnbqEwxPfXirenXDC7Rg Dmu+JjWvLQXqnuKyeGIhBZy4VIQisddqsRsKXm8NpeK2TOMF+axnYM+0sEDyMu1jL9Es XKCoGE4+eW9d6dbpiDX9fiEtIXV3ZceANmSt34jRRgrj2bkdGN5DZsR6O+KVT4tTB3B+ x/dQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=2uN5X8DUEMQPUBTVS1/pgtLkQocX9RzJ+FmBoMdljaw=; b=gNx2S9+0KJiMf05eAQuV7AdTJQ4egh7Puk2t6B6R5hAgWscmuGuQsTcoAffwC0FTWv VRv0FNfCCB30KSnTS5IIfAf4AzSxuj+vhcgth098UErDLC543gQ+NRPGgv8OPbf74IWT r4bZOugHCdy46BfVKqyGJvaM6xLtH8anwtMXReC1eHuJfkK/waFG1bUVYiI9C69UfCmq rRwtF96LAvK902oDFxa14Gd0WaOWLXm7LghzKIYaRylJ1QLFYOxExgjWio66hH/dyWum zSzBf+BKF/Qyfsd1f9daneT2igvImL7cdsb+hbKf+48hQdnluRTjOStVT/CQJ3oz34KQ nLGQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=B8710WYZ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s189si28775787pgb.346.2019.05.02.10.45.19; Thu, 02 May 2019 10:45:34 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=B8710WYZ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726479AbfEBRoV (ORCPT + 99 others); Thu, 2 May 2019 13:44:21 -0400 Received: from mail-pg1-f193.google.com ([209.85.215.193]:45980 "EHLO mail-pg1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726424AbfEBRoU (ORCPT ); Thu, 2 May 2019 13:44:20 -0400 Received: by mail-pg1-f193.google.com with SMTP id i21so1371079pgi.12 for ; Thu, 02 May 2019 10:44:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=2uN5X8DUEMQPUBTVS1/pgtLkQocX9RzJ+FmBoMdljaw=; b=B8710WYZnaCMf4TZVtd6PCJnURCPKXx92qNHChx45j/qLHsi9vAPUtsK3W9179oP3E t666/VxF3lIq8OWdFeJkFc6WShlfeyi7OdcjJywwadlyK1KsRw9oMxXJcFwDW+PYxP6M oEohYkbxS/r/wfEi9jAKVFju4CbYsWmQMr9Gg= 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:mime-version:content-transfer-encoding; bh=2uN5X8DUEMQPUBTVS1/pgtLkQocX9RzJ+FmBoMdljaw=; b=sFmfuDdEQ4wphAASnOhZi/BcF+yHmR/wGeqEE7I5KAq2p6QBhaL54u01q9Fq0aSmiR Op3B5eTbtufCIsIRgkfuRfwwXrFmd3Jfs+cuVxeg7heyY8nI42w+K1511Fq8K++9R7Lb q45geMz07zvg7uKm7T62GgVCvK7tSUP/zwArFjVzK50clNidC5xQ9R+5vw0wTmaNnx63 knCYhXzM8x26Vm7Xw1F3MAihKrjwALIZ+wmqELcPBslWZWIwJC+9fC9sbsaXj4zYqjSw sxMEuKtilX/tfFh6Mjwv0bQSA/Pnr8uw8dkX0UgDcfnjEsYluJZoM+LGf3iZ5zs2JwOH KB5A== X-Gm-Message-State: APjAAAVmRoWku/cTXHzLSt/siLYQ+ogwP38PbVLdQ1UW7cEbR9wJN8AH FG0YTJZunPrXp0fJ+pBnVJOz/w== X-Received: by 2002:a63:4548:: with SMTP id u8mr5203600pgk.435.1556819059317; Thu, 02 May 2019 10:44:19 -0700 (PDT) Received: from evgreen2.mtv.corp.google.com ([2620:15c:202:201:ffda:7716:9afc:1301]) by smtp.gmail.com with ESMTPSA id w38sm48319600pgk.90.2019.05.02.10.44.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 02 May 2019 10:44:18 -0700 (PDT) From: Evan Green To: Jens Axboe , Martin K Petersen Cc: Bart Van Assche , Gwendal Grignou , Alexis Savery , Ming Lei , Evan Green , linux-block@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v4 2/2] loop: Better discard support for block devices Date: Thu, 2 May 2019 10:44:09 -0700 Message-Id: <20190502174409.74623-3-evgreen@chromium.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190502174409.74623-1-evgreen@chromium.org> References: <20190502174409.74623-1-evgreen@chromium.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. While in there, differentiate between REQ_OP_DISCARD and REQ_OP_WRITE_ZEROES, which are different for block devices, but which the loop device had just been lumping together, since they're largely the same for 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 --- 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 | 57 ++++++++++++++++++++++++++++---------------- 1 file changed, 37 insertions(+), 20 deletions(-) diff --git a/drivers/block/loop.c b/drivers/block/loop.c index bbf21ebeccd3..ca6983a2c975 100644 --- a/drivers/block/loop.c +++ b/drivers/block/loop.c @@ -417,19 +417,14 @@ static int lo_read_transfer(struct loop_device *lo, struct request *rq, return ret; } -static int lo_discard(struct loop_device *lo, struct request *rq, loff_t pos) +static int lo_discard(struct loop_device *lo, struct request *rq, + int mode, loff_t pos) { - /* - * 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. - */ struct file *file = lo->lo_backing_file; - int mode = FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE; + struct request_queue *q = lo->lo_queue; int ret; - if ((!file->f_op->fallocate) || lo->lo_encrypt_key_size) { + if (!blk_queue_discard(q)) { ret = -EOPNOTSUPP; goto out; } @@ -599,8 +594,13 @@ static int do_req_filebacked(struct loop_device *lo, struct request *rq) case REQ_OP_FLUSH: return lo_req_flush(lo, rq); case REQ_OP_DISCARD: + return lo_discard(lo, rq, + FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE, pos); + case REQ_OP_WRITE_ZEROES: - return lo_discard(lo, rq, pos); + return lo_discard(lo, rq, + FALLOC_FL_ZERO_RANGE | FALLOC_FL_KEEP_SIZE, pos); + case REQ_OP_WRITE: if (lo->transfer) return lo_write_transfer(lo, rq, pos); @@ -854,6 +854,21 @@ static void loop_config_discard(struct loop_device *lo) struct file *file = lo->lo_backing_file; struct inode *inode = file->f_mapping->host; struct request_queue *q = lo->lo_queue; + struct request_queue *backingq; + + /* + * 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)) { + 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 @@ -861,22 +876,24 @@ static void loop_config_discard(struct loop_device *lo) * 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) -- 2.20.1