Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp1323img; Wed, 27 Mar 2019 15:30:01 -0700 (PDT) X-Google-Smtp-Source: APXvYqyYY5NefxOyZPwrIwR8ud1bsm0u9yiKupk7ePMLT1BQzMPwosV63iCkwr6DrlguxnWqttvc X-Received: by 2002:a63:e445:: with SMTP id i5mr6424280pgk.383.1553725801013; Wed, 27 Mar 2019 15:30:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553725801; cv=none; d=google.com; s=arc-20160816; b=zf34/Ql6WGchvmmTCUoA2FjSSttsM0liIfF8E3HeBXPZvSLCdEN7KqJIbMKTBOpAAC En0/qQbhCvYKnP0QveaFvu3cFWdK8l4s7IERQoqYTMHnfrUUHCFqYrdQflr3bQRQdR/Y 8PXbmrozFR9hEfy2Li0LwxIlUqX+UZpqGdzGO05ttymhP/mxiSACDEr6Yu1R4OzB+e5B nsmQD+iGNJ4eRljc7eeiRa+s666JA1h9rX9cG5LZy8W+GL5OmuxGbj6o3vM8H1slSAAF 49sMSvqXmxp0ndmLUl/mwUWVSlPVOxPn154vCjZsZsg6Pidn2oXEwPl3Hqle1FUijEVC /0lw== 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=eYWuwfE/DeGo/A1CHMZZFvsRrpeE2/SycqG1x6uy3nw=; b=dHt8ADjjdMK9GM25fJmLNoSomHLH3dSgS60BEcdcg+q/ILLm15mcYVjfAfeQDXipEM BpKixPDL8H+S0eR9Xn8b1gyfN82124ogqv0yTdj8ei35aoIU6OiqrzecuK6t/SR3/b3t KGlGHOaSv2uAb6IOLPWjhFALPUOgISVcEQJ1UNmFowxaT++Es5auAoIVGSCszHG/Yx5T ZYJ0QfmGiB8jhnqdvZmAyOZrRkY38JFEujgaZRV5D+Rm4sjq7Sv1hTzNf9r+TpxPGvS4 xC5cDlE6yyMHzjpwtfCEFXCeTypSzp6N+feqlFDHmL5BjakjVvJxx22wqQr6RmzqczBH FK7Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=UuxxeyOm; 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 d6si19390875pfg.66.2019.03.27.15.29.45; Wed, 27 Mar 2019 15:30:00 -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=UuxxeyOm; 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 S1730868AbfC0W27 (ORCPT + 99 others); Wed, 27 Mar 2019 18:28:59 -0400 Received: from mail-pg1-f195.google.com ([209.85.215.195]:41624 "EHLO mail-pg1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729355AbfC0W25 (ORCPT ); Wed, 27 Mar 2019 18:28:57 -0400 Received: by mail-pg1-f195.google.com with SMTP id f6so6482327pgs.8 for ; Wed, 27 Mar 2019 15:28:56 -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=eYWuwfE/DeGo/A1CHMZZFvsRrpeE2/SycqG1x6uy3nw=; b=UuxxeyOmOFarpObTwkTeOFvi6Yr1E8o5qMwOWd7tt84GNSA08rUaTrCP4uGjLrAuPA N6GM4MD3hU1NczbHS0fklLSKVkUeOBFooMUJ1hIK38pP1pKiuWX9zzQhPjChhy+Xjvxr DeWixwsSy5NxR/T+ql2Ml7/4lgctS3M+H3irg= 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=eYWuwfE/DeGo/A1CHMZZFvsRrpeE2/SycqG1x6uy3nw=; b=MjbgEewNPqr0hjnaEG/+4pJH93IeFRFO6ihaGPHtZzNiQvr7sNSxnlT7MXoQ1Nw9fK RgOGJybrLiXN1D4WtS61cduzT4BuwW+aE9DcQfxFC7VIpzVpLv0uEv29WBls2STsLMmO WsNUSeTG+Ws8ROaIn/GYIm3JgqIcg9gnDXX56mtfVZl1nxNrmHk2ht/IDz8FWthapoSa oy9tURP9/GUaHVQ1YKjUon+/z0wzG5RWXPFZLjm+6BAQ36hbhv2Yn1IE3/NDMAnTGJu2 BMUhE4HCNlbwihZjLFxytOMqXqDqT14AFqTt0fOMUBbcYlklBxCEK0YqQl4Yk1AJM8nW uVDw== X-Gm-Message-State: APjAAAXHHIZQFxYXvToRU/WfoErodhissGjLINucgJ9x3x/gCCtAFdUF i16apIcILHV0gKehvfK+8OH3Gw== X-Received: by 2002:a62:59cb:: with SMTP id k72mr38709411pfj.111.1553725736019; Wed, 27 Mar 2019 15:28:56 -0700 (PDT) Received: from evgreen2.mtv.corp.google.com ([2620:15c:202:201:ffda:7716:9afc:1301]) by smtp.gmail.com with ESMTPSA id p88sm36928347pfa.80.2019.03.27.15.28.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 27 Mar 2019 15:28:55 -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 v3 2/2] loop: Better discard support for block devices Date: Wed, 27 Mar 2019 15:28:41 -0700 Message-Id: <20190327222841.38650-3-evgreen@chromium.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190327222841.38650-1-evgreen@chromium.org> References: <20190327222841.38650-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 discard properties of the underlying block device into the loop device. This new change only applies to loop devices backed directly by a block device, not 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 v3: - Updated commit description Changes in v2: None drivers/block/loop.c | 61 +++++++++++++++++++++++++++++--------------- 1 file changed, 41 insertions(+), 20 deletions(-) diff --git a/drivers/block/loop.c b/drivers/block/loop.c index bbf21ebeccd3..e1edd004298a 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,25 @@ 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 discard + * capabilities. + */ + if (S_ISBLK(inode->i_mode)) { + backingq = bdev_get_queue(inode->i_bdev); + blk_queue_max_discard_sectors(q, + backingq->limits.max_discard_sectors); + + blk_queue_max_write_zeroes_sectors(q, + backingq->limits.max_write_zeroes_sectors); + + q->limits.discard_granularity = + backingq->limits.discard_granularity; + + q->limits.discard_alignment = + backingq->limits.discard_alignment; /* * We use punch hole to reclaim the free space used by the @@ -861,22 +880,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_discard_sectors || 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