Message ID | 20231011201230.750105-1-sarthakkukreti@chromium.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2908:b0:403:3b70:6f57 with SMTP id ib8csp788174vqb; Wed, 11 Oct 2023 13:13:06 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEN4juX8wem3r3GnljXYGWFpQNShkDFmcE9LF8Z6yJKZXIWTXGzVOlRuB9Y7/qnS4z0HByW X-Received: by 2002:a05:6602:2e03:b0:792:6068:dcc8 with SMTP id o3-20020a0566022e0300b007926068dcc8mr29001833iow.2.1697055186129; Wed, 11 Oct 2023 13:13:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697055186; cv=none; d=google.com; s=arc-20160816; b=rgwLTvHupx4HupfZnfYbn4fxwWv0k9BT30j9vqYuxx4yjIPUVXhDHkDwB+ku4HPFzV xRjYC8L5fXEElLr6FYC0mLyfNZv19jKCUFUGK6pchZGKCQ8QF8rPjj6bg3foirYZfO8N Y8qxO1ruO1GLXjKtiGedWxbbHPqJyonRtG9KAGuyilJTiyGrw94krpV9W5vhTQTqaFgH W7H3agUP7v9Q1uCfDmkuVKokP0o6wZyrh/q7eXedvkMIGOg80SC/W3aGsuiv5w1srcj3 DqMnthucfhp+p7aUnwtPJGA5BANgoCk7eZym6payBpyq3B4sY010Pz6QdJPDKPa3c4OB LqFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=rQNnXBnSwzfsN2zrI7/k3aUY1SO1WpMoDwjEZpkrIxM=; fh=2usozlpsZ8CglmChI7F8CPp08ZkDOpyk5ZwVFt3KyDE=; b=aeLRNAyI02Qmzi45B/U5r8CIpSdTqMSWplrYQRf6HWtEhq2IONumFhW8en+dyyWK/g 5SaLg3MDtDq/MlLY3CHjqSSUupQKYaD42bY+4BSFd+TQW1OPpsG5Tz3m4bxMEOJwcLL6 wE5ys/y02AIHsC61zUOvO2gjyA2PBCh8Y9pJXK45hmebxV60HKCVSwuLHfHZ4p9jgBn7 EF/nuSLOIIGpBtVSw4OmSMq9yYNbrDCufh+d98sYOq0PN2mBnBB2756y6FMwL8kN65e+ GIGGFq/J5wrry9psaLAI7/ic5xHmyfaAMfTrspDGEfgVygggslUCCQtpDXpsu5IYGTYw ruEA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=Yo4Q9xdI; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: from groat.vger.email (groat.vger.email. [23.128.96.35]) by mx.google.com with ESMTPS id cn7-20020a056a00340700b0068a4ba92eafsi12885379pfb.54.2023.10.11.13.13.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 Oct 2023 13:13:06 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) client-ip=23.128.96.35; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=Yo4Q9xdI; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by groat.vger.email (Postfix) with ESMTP id AA1E081142C2; Wed, 11 Oct 2023 13:13:01 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346890AbjJKUMo (ORCPT <rfc822;kartikey406@gmail.com> + 18 others); Wed, 11 Oct 2023 16:12:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36718 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233353AbjJKUMn (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 11 Oct 2023 16:12:43 -0400 Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9C0F59E for <linux-kernel@vger.kernel.org>; Wed, 11 Oct 2023 13:12:36 -0700 (PDT) Received: by mail-pl1-x62b.google.com with SMTP id d9443c01a7336-1c9b70b9656so1685435ad.1 for <linux-kernel@vger.kernel.org>; Wed, 11 Oct 2023 13:12:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1697055156; x=1697659956; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=rQNnXBnSwzfsN2zrI7/k3aUY1SO1WpMoDwjEZpkrIxM=; b=Yo4Q9xdIFr68Wucs1ifeWk5zzo6mpTk23PUK4877tDeNxUT6CDiDDdTOUGHGLNeMTR GBM7NgfKkr2feCVJQypkGgCDDHNkU6H7toLWftB1Q92P6gbcuutxH9NDa5WZjDWaIFg6 Ew+8TxPS2uFzCf/LZx7OBa1ncesTw7KwgK0Zg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697055156; x=1697659956; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=rQNnXBnSwzfsN2zrI7/k3aUY1SO1WpMoDwjEZpkrIxM=; b=l1umNgkABV6OVm+uu0hqH8e3OnOhteweSegvpFErzyDVyUTJd5PiUXU/OSOyExSxUv 3I/5DW22Bii9jib5J0gxqE3qF3ofcMs4Vty5msP+D5ZkLMu3pcY+El9IL0Q8rDLqjN3Y u94NrV1lSwOAGaJMkOLek7mr5G51dhkWsYJQaAvuOMpXozjQHSfEgrH2G0LgSwn2Hu0y xK3oR5SI3KyYhjoszjhvlAJFG9rdi+ePuUBPnACMj85cvrluOmwtaoAdH7s9mPFEvJJ6 HN2asb1OsP/W5hy/zk6yoozSFXLjQZmTU03x2MOj/+9PZ34dF/LDVk/ceEpbb7ytnvoP 7dHw== X-Gm-Message-State: AOJu0YwsrwhDeTSyc+xta7IEs3K+slF3RCtOINJmQMyu20hwNwJ/lO3q BkVd7vujtorVqBuYK2NFyKNOmg== X-Received: by 2002:a17:902:db10:b0:1bd:f7d7:3bcd with SMTP id m16-20020a170902db1000b001bdf7d73bcdmr21362238plx.50.1697055156027; Wed, 11 Oct 2023 13:12:36 -0700 (PDT) Received: from localhost ([2620:15c:9d:2:2c44:f765:835a:f6b3]) by smtp.gmail.com with UTF8SMTPSA id jc5-20020a17090325c500b001bf8779e051sm233685plb.289.2023.10.11.13.12.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 11 Oct 2023 13:12:35 -0700 (PDT) From: Sarthak Kukreti <sarthakkukreti@chromium.org> To: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Bart Van Assche <bvanassche@acm.org>, "Darrick J. Wong" <darrick.wong@oracle.com>, Jens Axboe <axboe@kernel.dk>, Sarthak Kukreti <sarthakkukreti@chromium.org>, stable@vger.kernel.org, "Darrick J . Wong" <djwong@kernel.org>, Christoph Hellwig <hch@lst.de>, Mike Snitzer <snitzer@kernel.org> Subject: [PATCH] block: Don't invalidate pagecache for invalid falloc modes Date: Wed, 11 Oct 2023 13:12:30 -0700 Message-ID: <20231011201230.750105-1-sarthakkukreti@chromium.org> X-Mailer: git-send-email 2.42.0.609.gbb76f46606-goog MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=2.7 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_SBL_CSS,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Wed, 11 Oct 2023 13:13:01 -0700 (PDT) X-Spam-Level: ** X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1779491339100126833 X-GMAIL-MSGID: 1779491339100126833 |
Series |
block: Don't invalidate pagecache for invalid falloc modes
|
|
Commit Message
Sarthak Kukreti
Oct. 11, 2023, 8:12 p.m. UTC
Only call truncate_bdev_range() if the fallocate mode is supported. This fixes a bug where data in the pagecache could be invalidated if the fallocate() was called on the block device with an invalid mode. Fixes: 25f4c41415e5 ("block: implement (some of) fallocate for block devices") Cc: stable@vger.kernel.org Reported-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Sarthak Kukreti <sarthakkukreti@chromium.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Mike Snitzer <snitzer@kernel.org> --- block/fops.c | 21 ++++++++++++++++----- 1 file changed, 16 insertions(+), 5 deletions(-)
Comments
On 10/11/23 2:12 PM, Sarthak Kukreti wrote: > Only call truncate_bdev_range() if the fallocate mode is > supported. This fixes a bug where data in the pagecache > could be invalidated if the fallocate() was called on the > block device with an invalid mode. Fix looks fine, but would be nicer if we didn't have to duplicate the truncate_bdev_range() in each switch clause. Can we check this upfront instead? Also, please wrap commit messages at 72-74 chars.
On Wed, Oct 11 2023 at 4:20P -0400, Jens Axboe <axboe@kernel.dk> wrote: > On 10/11/23 2:12 PM, Sarthak Kukreti wrote: > > Only call truncate_bdev_range() if the fallocate mode is > > supported. This fixes a bug where data in the pagecache > > could be invalidated if the fallocate() was called on the > > block device with an invalid mode. > > Fix looks fine, but would be nicer if we didn't have to duplicate the > truncate_bdev_range() in each switch clause. Can we check this upfront > instead? No, if you look at the function (rather than just the patch in isolation) we need to make the call for each case rather than collapse to a single call at the front (that's the reason for this fix, because otherwise the default: error case will invalidate the page cache too). Just so you're aware, I also had this feedback that shaped the patch a bit back in April: https://listman.redhat.com/archives/dm-devel/2023-April/053986.html > Also, please wrap commit messages at 72-74 chars. Not seeing where the header should be wrapped. You referring to the Fixes: line? I've never seen those wrapped. Mike
On 10/11/23 2:50 PM, Mike Snitzer wrote: > On Wed, Oct 11 2023 at 4:20P -0400, > Jens Axboe <axboe@kernel.dk> wrote: > >> On 10/11/23 2:12 PM, Sarthak Kukreti wrote: >>> Only call truncate_bdev_range() if the fallocate mode is >>> supported. This fixes a bug where data in the pagecache >>> could be invalidated if the fallocate() was called on the >>> block device with an invalid mode. >> >> Fix looks fine, but would be nicer if we didn't have to duplicate the >> truncate_bdev_range() in each switch clause. Can we check this upfront >> instead? > > No, if you look at the function (rather than just the patch in > isolation) we need to make the call for each case rather than collapse > to a single call at the front (that's the reason for this fix, because > otherwise the default: error case will invalidate the page cache too). Yes that part is clear, but it might look cleaner to check a valid mask first rather than have 3 duplicate calls. > Just so you're aware, I also had this feedback that shaped the patch a > bit back in April: > https://listman.redhat.com/archives/dm-devel/2023-April/053986.html > >> Also, please wrap commit messages at 72-74 chars. > > Not seeing where the header should be wrapped. You referring to the > Fixes: line? I've never seen those wrapped. I'm referring to the commit message itself.
On Wed, Oct 11 2023 at 4:53P -0400, Jens Axboe <axboe@kernel.dk> wrote: > On 10/11/23 2:50 PM, Mike Snitzer wrote: > > On Wed, Oct 11 2023 at 4:20P -0400, > > Jens Axboe <axboe@kernel.dk> wrote: > > > >> On 10/11/23 2:12 PM, Sarthak Kukreti wrote: > >>> Only call truncate_bdev_range() if the fallocate mode is > >>> supported. This fixes a bug where data in the pagecache > >>> could be invalidated if the fallocate() was called on the > >>> block device with an invalid mode. > >> > >> Fix looks fine, but would be nicer if we didn't have to duplicate the > >> truncate_bdev_range() in each switch clause. Can we check this upfront > >> instead? > > > > No, if you look at the function (rather than just the patch in > > isolation) we need to make the call for each case rather than collapse > > to a single call at the front (that's the reason for this fix, because > > otherwise the default: error case will invalidate the page cache too). > > Yes that part is clear, but it might look cleaner to check a valid mask > first rather than have 3 duplicate calls. OK. > > Just so you're aware, I also had this feedback that shaped the patch a > > bit back in April: > > https://listman.redhat.com/archives/dm-devel/2023-April/053986.html > > > >> Also, please wrap commit messages at 72-74 chars. > > > > Not seeing where the header should be wrapped. You referring to the > > Fixes: line? I've never seen those wrapped. > > I'm referring to the commit message itself. Ah, you'd like lines extended because they are too short.
On 10/11/23 3:08 PM, Mike Snitzer wrote: >>>> Also, please wrap commit messages at 72-74 chars. >>> >>> Not seeing where the header should be wrapped. You referring to the >>> Fixes: line? I've never seen those wrapped. >> >> I'm referring to the commit message itself. > > Ah, you'd like lines extended because they are too short. Exactly, it's way too short.
On 10/11/23 2:20 PM, Jens Axboe wrote: > On 10/11/23 2:12 PM, Sarthak Kukreti wrote: >> Only call truncate_bdev_range() if the fallocate mode is >> supported. This fixes a bug where data in the pagecache >> could be invalidated if the fallocate() was called on the >> block device with an invalid mode. > > Fix looks fine, but would be nicer if we didn't have to duplicate the > truncate_bdev_range() in each switch clause. Can we check this upfront > instead? Don't see a good way to do it on my end, so let's just go with what is there now. I applied it with the commit message reformatted.
On Wed, 11 Oct 2023 13:12:30 -0700, Sarthak Kukreti wrote: > Only call truncate_bdev_range() if the fallocate mode is > supported. This fixes a bug where data in the pagecache > could be invalidated if the fallocate() was called on the > block device with an invalid mode. > > Applied, thanks! [1/1] block: Don't invalidate pagecache for invalid falloc modes commit: 1364a3c391aedfeb32aa025303ead3d7c91cdf9d Best regards,
diff --git a/block/fops.c b/block/fops.c index acff3d5d22d4..73e42742543f 100644 --- a/block/fops.c +++ b/block/fops.c @@ -772,24 +772,35 @@ static long blkdev_fallocate(struct file *file, int mode, loff_t start, filemap_invalidate_lock(inode->i_mapping); - /* Invalidate the page cache, including dirty pages. */ - error = truncate_bdev_range(bdev, file_to_blk_mode(file), start, end); - if (error) - goto fail; - + /* + * Invalidate the page cache, including dirty pages, for valid + * de-allocate mode calls to fallocate(). + */ switch (mode) { case FALLOC_FL_ZERO_RANGE: case FALLOC_FL_ZERO_RANGE | FALLOC_FL_KEEP_SIZE: + error = truncate_bdev_range(bdev, file_to_blk_mode(file), start, end); + if (error) + goto fail; + error = blkdev_issue_zeroout(bdev, start >> SECTOR_SHIFT, len >> SECTOR_SHIFT, GFP_KERNEL, BLKDEV_ZERO_NOUNMAP); break; case FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE: + error = truncate_bdev_range(bdev, file_to_blk_mode(file), start, end); + if (error) + goto fail; + error = blkdev_issue_zeroout(bdev, start >> SECTOR_SHIFT, len >> SECTOR_SHIFT, GFP_KERNEL, BLKDEV_ZERO_NOFALLBACK); break; case FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE | FALLOC_FL_NO_HIDE_STALE: + error = truncate_bdev_range(bdev, file_to_blk_mode(file), start, end); + if (error) + goto fail; + error = blkdev_issue_discard(bdev, start >> SECTOR_SHIFT, len >> SECTOR_SHIFT, GFP_KERNEL); break;