From patchwork Fri Apr 15 04:52:38 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Christoph Hellwig X-Patchwork-Id: 12814504 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aib29ajc247.phx1.oracleemaildelivery.com (aib29ajc247.phx1.oracleemaildelivery.com [192.29.103.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 542EFC47080 for ; Fri, 15 Apr 2022 04:54:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=oss-phx-1109; d=oss.oracle.com; h=Date:To:From:Subject:Message-Id:MIME-Version:Sender; bh=g3rSiNQ5HognllHl5GpPkZiZwU6IWTo9nuhx2adGhrc=; b=eiE2N3YR7rxNsfXf1R/3oDDmQwotSoWNSX3qS3myFMVeA8MHD39lYhdFl9cETz5+EgAJQMbXo72m XwYVkxRv324iZuWPAwqJZTThN9gehK8uZZsaZ4gI0CCD/gKWON7Z3mLo1e/hdGjXjSW65B0h7nrv TGI+MdoglFFkBwet03RfF7GRQ6a5jWdK1JL+Ye2XlEbL/O3QJR/HahuOD/XnihY8scMDEpj38Xqx 6Tn+p7LWVpDpcCiuL/TIHzhYoUAZmLLFEeX3DQcfLYitt6Utql7RvLTSLd7QA7Us+Deo2qZUqgFS 03TkxBLYPIAWOAlqrxTwPgjwB6twAwNpHgIUfg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=prod-phx-20191217; d=phx1.rp.oracleemaildelivery.com; h=Date:To:From:Subject:Message-Id:MIME-Version:Sender; bh=g3rSiNQ5HognllHl5GpPkZiZwU6IWTo9nuhx2adGhrc=; b=Cy7tD2tue91523HntPZ0SJYPb8UgmA8JHvvXulFu19+oJH0ycW+CUg2N4HpxBR5sSjP3FboAT5fZ OxKVshvM71m6H7Z1FXH3jDce0Mq4UEfLLwbvJa/zssU62Jv85Q/JUvVHt9Nmijfty0ZPCh+N37vX 6EWWsT8Mc0qyOUh6gzwsFgvOYM3hpcSuo/Wl03VXJZXjV6rdlbea9x94gsmdEXScBZ+JcehZJ0Bn hkThEl2vtolUG/kmqDzmEv6kDXssQG0c/hK0H8bB+xPGcL1ZVlAumXM8H0Uc+eEOnkXet4Gb6Jbf ohR1IiXBmHNeOPRQos6osubNNxLLD/Xlf1hs+g== Received: by omta-ad1-fd3-102-us-phoenix-1.omtaad1.vcndpphx.oraclevcn.com (Oracle Communications Messaging Server 8.1.0.1.20220319 64bit (built Mar 19 2022)) with ESMTPS id <0RAD009HJ6YS3Q60@omta-ad1-fd3-102-us-phoenix-1.omtaad1.vcndpphx.oraclevcn.com> for ocfs2-devel@archiver.kernel.org; Fri, 15 Apr 2022 04:54:28 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Content-Transfer-Encoding: Content-Type:MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc: To:From:Sender:Reply-To:Content-ID:Content-Description; bh=9tUaZULhEmteAuYmNe/S5K85i8mY+zpV/R7NWj8li0M=; b=AjCBuPx/UHSGTakXv8HXmgNw4N Iyofq9wNNzfgjbG93scprq/gUs5OOhFUGL0tKjcj2IWWkpHNBkXqusk5CV5Uj/P/70TymjB6Unzdu VnxSzUtQb3ldimIkXALq/IfCXSo1TL1NzeISVmz+Ea7q6xFf02zHvxp+FndxH2zbBXHBFRTOnXe4c nAXrXpjx27cFTMs0mjOzvEq3gOjLOY6hKIcglkznMntAYg+vXORRN23xzGalvjS8R6ccxTXJWj8QW sdXJMYerLCI2QfFcDPA/f8tI4pucu7JSpv7rjXlKJh5WSo2NBa1UXNlyVf9emnFeALezPoiPRp2d8 jaVM4Jaw==; To: Jens Axboe Date: Fri, 15 Apr 2022 06:52:38 +0200 Message-id: <20220415045258.199825-8-hch@lst.de> X-Mailer: git-send-email 2.30.2 In-reply-to: <20220415045258.199825-1-hch@lst.de> References: <20220415045258.199825-1-hch@lst.de> MIME-version: 1.0 X-Source-IP: 198.137.202.133 X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10317 signatures=695566 X-Proofpoint-Spam-Details: rule=tap_notspam policy=tap score=0 priorityscore=0 mlxscore=0 malwarescore=0 mlxlogscore=999 bulkscore=0 spamscore=0 phishscore=0 lowpriorityscore=0 clxscore=226 adultscore=0 suspectscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2204150029 Cc: jfs-discussion@lists.sourceforge.net, linux-nvme@lists.infradead.org, virtualization@lists.linux-foundation.org, linux-mm@kvack.org, dm-devel@redhat.com, target-devel@vger.kernel.org, linux-mtd@lists.infradead.org, drbd-dev@lists.linbit.com, linux-s390@vger.kernel.org, linux-nilfs@vger.kernel.org, linux-scsi@vger.kernel.org, cluster-devel@redhat.com, xen-devel@lists.xenproject.org, linux-ext4@vger.kernel.org, linux-um@lists.infradead.org, nbd@other.debian.org, linux-block@vger.kernel.org, linux-bcache@vger.kernel.org, ceph-devel@vger.kernel.org, linux-raid@vger.kernel.org, linux-mmc@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-xfs@vger.kernel.org, =?utf-8?q?Christoph_B=C3=B6hmwalder?= , ocfs2-devel@oss.oracle.com, linux-fsdevel@vger.kernel.org, ntfs3@lists.linux.dev, linux-btrfs@vger.kernel.org Subject: [Ocfs2-devel] [PATCH 07/27] drbd: cleanup decide_on_discard_support X-BeenThere: ocfs2-devel@oss.oracle.com X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Christoph Hellwig via Ocfs2-devel Reply-to: Christoph Hellwig Content-type: text/plain; charset="utf-8" Content-transfer-encoding: base64 Errors-to: ocfs2-devel-bounces@oss.oracle.com X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html X-ServerName: bombadil.infradead.org X-Proofpoint-SPF-Result: None X-Spam: Clean X-Proofpoint-ORIG-GUID: GjMCo7tTzgmSCHmYLALwFbaE-KjGpTeA X-Proofpoint-GUID: GjMCo7tTzgmSCHmYLALwFbaE-KjGpTeA Reporting-Meta: AAFomgJZ4DbE0jTlh+UyhWKHwOqbji2A/911JkcNY9g52CWEyJbHf0jBaXSfZC2u Og5h+qe0RVQNHopTfTS0fDvp3NqxlOzkm2dFKVFoNnqzPbryO7kaVpnLhDzgKAPK NEIq3yQIvM1yd1JDoO7g53reuGxlHT3XSbc4/ZdrmPh/O9/qnDvM49a9KMDnH0RG 2+Qc1dn/aqJ4c7qPHDimOLhTWA/5qQU2jFSYI6tNQltViq05BIikny1CoBZyEm9e yKKP/S2HI7DOjkdW0EIWyHBe/ZqqyvJN+ARXVDZ7M+Z6kaF/2bcQLH/XvagWJigO ngIcin8JIs2Z51xmMjm1ALmW+3midgt+567Y4ib3o24etxC71AmXnSLliXdAd6Hr dBSAT36p4XSHYPJ0vA8dx6TkfvvmdEWD0rpPFztx8cmtR+f133tguxoJ++98fW7l trh8IvFOurn+n5oQ64xblTNX69c9bgFdKspdkoDvrxbgS4OrydBHiBEa4klQMF5L NRBnHJ6vf+nuLA7tu1j4/rU4IsyUI2Z6etseJV72tzoHBA== Sanitize the calling conventions and use a goto label to cleanup the code flow. Signed-off-by: Christoph Hellwig Acked-by: Christoph Böhmwalder --- drivers/block/drbd/drbd_nl.c | 68 +++++++++++++++++++----------------- 1 file changed, 35 insertions(+), 33 deletions(-) diff --git a/drivers/block/drbd/drbd_nl.c b/drivers/block/drbd/drbd_nl.c index b7216c186ba4d..4d00986d6f588 100644 --- a/drivers/block/drbd/drbd_nl.c +++ b/drivers/block/drbd/drbd_nl.c @@ -1204,38 +1204,42 @@ static unsigned int drbd_max_discard_sectors(struct drbd_connection *connection) } static void decide_on_discard_support(struct drbd_device *device, - struct request_queue *q, - struct request_queue *b, - bool discard_zeroes_if_aligned) + struct drbd_backing_dev *bdev) { - /* q = drbd device queue (device->rq_queue) - * b = backing device queue (device->ldev->backing_bdev->bd_disk->queue), - * or NULL if diskless - */ - struct drbd_connection *connection = first_peer_device(device)->connection; - bool can_do = b ? blk_queue_discard(b) : true; - - if (can_do && connection->cstate >= C_CONNECTED && !(connection->agreed_features & DRBD_FF_TRIM)) { - can_do = false; - drbd_info(connection, "peer DRBD too old, does not support TRIM: disabling discards\n"); - } - if (can_do) { - /* We don't care for the granularity, really. - * Stacking limits below should fix it for the local - * device. Whether or not it is a suitable granularity - * on the remote device is not our problem, really. If - * you care, you need to use devices with similar - * topology on all peers. */ - blk_queue_discard_granularity(q, 512); - q->limits.max_discard_sectors = drbd_max_discard_sectors(connection); - blk_queue_flag_set(QUEUE_FLAG_DISCARD, q); - q->limits.max_write_zeroes_sectors = drbd_max_discard_sectors(connection); - } else { - blk_queue_flag_clear(QUEUE_FLAG_DISCARD, q); - blk_queue_discard_granularity(q, 0); - q->limits.max_discard_sectors = 0; - q->limits.max_write_zeroes_sectors = 0; + struct drbd_connection *connection = + first_peer_device(device)->connection; + struct request_queue *q = device->rq_queue; + + if (bdev && !blk_queue_discard(bdev->backing_bdev->bd_disk->queue)) + goto not_supported; + + if (connection->cstate >= C_CONNECTED && + !(connection->agreed_features & DRBD_FF_TRIM)) { + drbd_info(connection, + "peer DRBD too old, does not support TRIM: disabling discards\n"); + goto not_supported; } + + /* + * We don't care for the granularity, really. + * + * Stacking limits below should fix it for the local device. Whether or + * not it is a suitable granularity on the remote device is not our + * problem, really. If you care, you need to use devices with similar + * topology on all peers. + */ + blk_queue_discard_granularity(q, 512); + q->limits.max_discard_sectors = drbd_max_discard_sectors(connection); + blk_queue_flag_set(QUEUE_FLAG_DISCARD, q); + q->limits.max_write_zeroes_sectors = + drbd_max_discard_sectors(connection); + return; + +not_supported: + blk_queue_flag_clear(QUEUE_FLAG_DISCARD, q); + blk_queue_discard_granularity(q, 0); + q->limits.max_discard_sectors = 0; + q->limits.max_write_zeroes_sectors = 0; } static void fixup_discard_if_not_supported(struct request_queue *q) @@ -1273,7 +1277,6 @@ static void drbd_setup_queue_param(struct drbd_device *device, struct drbd_backi unsigned int max_segments = 0; struct request_queue *b = NULL; struct disk_conf *dc; - bool discard_zeroes_if_aligned = true; if (bdev) { b = bdev->backing_bdev->bd_disk->queue; @@ -1282,7 +1285,6 @@ static void drbd_setup_queue_param(struct drbd_device *device, struct drbd_backi rcu_read_lock(); dc = rcu_dereference(device->ldev->disk_conf); max_segments = dc->max_bio_bvecs; - discard_zeroes_if_aligned = dc->discard_zeroes_if_aligned; rcu_read_unlock(); blk_set_stacking_limits(&q->limits); @@ -1292,7 +1294,7 @@ static void drbd_setup_queue_param(struct drbd_device *device, struct drbd_backi /* This is the workaround for "bio would need to, but cannot, be split" */ blk_queue_max_segments(q, max_segments ? max_segments : BLK_MAX_SEGMENTS); blk_queue_segment_boundary(q, PAGE_SIZE-1); - decide_on_discard_support(device, q, b, discard_zeroes_if_aligned); + decide_on_discard_support(device, bdev); if (b) { blk_stack_limits(&q->limits, &b->limits, 0);