From patchwork Wed Feb 28 18:22:27 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Matthew Wilcox X-Patchwork-Id: 13575818 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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id F3953C47DD9 for ; Wed, 28 Feb 2024 18:22:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 55DEA6B009A; Wed, 28 Feb 2024 13:22:40 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 50DF26B00A9; Wed, 28 Feb 2024 13:22:40 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3D58C6B00AA; Wed, 28 Feb 2024 13:22:40 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 27D916B009A for ; Wed, 28 Feb 2024 13:22:40 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id DC96EC0F8B for ; Wed, 28 Feb 2024 18:22:39 +0000 (UTC) X-FDA: 81842033238.28.360655A Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf22.hostedemail.com (Postfix) with ESMTP id 47060C0019 for ; Wed, 28 Feb 2024 18:22:38 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=tgG0Z9FE; dmarc=none; spf=none (imf22.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709144558; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:references:dkim-signature; bh=J/q0ho0MBKAcYMWRNFtI3/6GGZRR/hx2c7R+WtSQaqY=; b=HJin8jKX6w8iW1LkutGRenReliCjWz7Jj/dsFKYIiQ5OteJ2l1HD3QprrRANlFMrKdnb2U 5ydJWlEjoC/JLissL5kmJfMQ5GHfB7EaUewRYs/C55unPz8QlfcKNaB/Zcw44oHZwpTrSi gaFHkfdYZnYz13PLStkq0RhCsGrqBPk= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=tgG0Z9FE; dmarc=none; spf=none (imf22.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709144558; a=rsa-sha256; cv=none; b=KZoOIyufj0gkujcefLGj0gdbvHq4qcKbN5crRrO4s3OftH8ie3TEC04bWZUxEPVyyF5131 TeUOVVQyAnLGFfIbAtQIEyAix5DRfVZkkvsS2zkrINo0x/W8WtHcFNi0PYKGuEJdiCtNSC 9nu4l6HtEXixsZ5Q+nCIv0OtFP1E9Uc= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=Content-Transfer-Encoding:MIME-Version: Message-ID:Date:Subject:Cc:To:From:Sender:Reply-To:Content-Type:Content-ID: Content-Description:In-Reply-To:References; bh=J/q0ho0MBKAcYMWRNFtI3/6GGZRR/hx2c7R+WtSQaqY=; b=tgG0Z9FEdFK4x5PRJuj2S4FhOR UEH2lGJMmWebGXfRfothPzD4Bb4ZCwNJfNch6eYV6yxRw1BD22vGIWb7QjAUouSUxY3E4/1AaOtCa a9v5oqvJIZ8VVOWFcK19DMBsnZhxNKqKLs/rNuyuCK7lQNfVLmtYJciu4Jfemap7cIeshNoSQpy3z z9HoFDN9nzLiocW5RRyC81UrltMrOVeRYjQECsK+Ohm5VR4VgcT7vyyyybBlMSNatkt/jtSKQmXLq V6dQ9Nn7s3hir5CAaPcAoLIw35OCjTeERBGPktV3KaMYnxhcDkCXbp/DXH8gZnaVtf1w6mCRIRpX9 kubFcNsQ==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rfOZf-00000005sUQ-19uQ; Wed, 28 Feb 2024 18:22:35 +0000 From: "Matthew Wilcox (Oracle)" To: linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Cc: "Matthew Wilcox (Oracle)" Subject: [PATCH 0/1] Is pagecache_isize_extended() compatible with large folios? Date: Wed, 28 Feb 2024 18:22:27 +0000 Message-ID: <20240228182230.1401088-1-willy@infradead.org> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 47060C0019 X-Stat-Signature: h146mt175ja4pe1384fhijbmya7y7mye X-HE-Tag: 1709144558-648281 X-HE-Meta: U2FsdGVkX18juVASc2QDYmtDaS6M+bc15L4tCktZ1IUn8XDMnW9hKryUSUZv9IyXOmIL3mz/EsBfAFwpcIdawkMYo2fy4UQ7BRFYPlUzITNIeC10yUC6K62aHQ8Sd140Ec40xDRW70irfuoJRmcUm9+TKX72jljER1DeLqvG4M3hx8G8RFgbjnrvSC4ne474Vtge6U9K8vC5z+xCKraDedVgFDtWLmad3ucMrtTOCvRx6XwecnZtpmaRSF6C8UlaaUxkfNBE+D16+8DMd3uUqZ1f5C/Dj91eCdeloqAsnFv5C6b7Br+LYjzOMFq6EzpRNTAypVYvdp0NMp0o3SdCLCOp8V2cKSZAGa/y5QefLUONxgPsULxx9avqPKVD1yaUXyVUtJ1yhGLKtXN6J+nccZOuX8fR5ZJbbBagfyhjcejADntLg3pmHLXdHdWqTeMA+Hj+lCSEPizLLEwU0RVZFEagbR2iVQofK+2m955nIbFznY+vsBhIMiRKwdiUMCcOKl1cIxxcggmV1dZ/L0Kpbp02bmhjPx7g4gqOMmwBeGKutHN3m1XwXLGYa3tJg56deJkH/R/7qVKB2DZmloP1+U3y53AleaytBV3X9Csi9dOZXjYNUXH0yz9aCebFA1Xun00HTZIAVT7GWFqj3Ma1MYzdhbO0kjzKZwaeSTweX+ao0GSoe9jBYFvaH4KUt2vlAjB7sNywLrIFbQYg8zoadBAxOCLrKvfkHYGJhOoyA7HeewxVxpfRwFvhHkcgT+onCCt53oGP42w5RRQnQQTJkTZonkwHBjbp9YO4lqEWd16qxJrwpBdvOfobzZytGP6WA5zdGREoagGNYc7ylwziFVzLqBEcLi91YdVktgoE+2akJV0bFdmr1XrVa9j+Aee6REGwZ6trJnVAzxTZqjNB5Axw/T6L+dU7+l8FFq51MDoyVaIe7WkdsCRuECkJI/GBoHwje1tEEwjW3EZSo/2 +PA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: I'd appreciate some filesystem people checking my work here (in that pagecache_isize_extended() may already be broken and we didn't notice). As far as I can tell (and it'd be nice to explain this in the kernel-doc a little more thoroughly), the reason pagecache_isize_extended() exists is that some filesystems rely on getting page_mkwrite() calls in order to instantiate blocks. So if you have a filesystem using 512 byte blocks and a 256 byte file mmaped, a store anywhere in the page will only result in block 0 of the file being instantiated and the folio will now be marked as dirty. If we ftruncate the file to 2500 bytes before the folio gets written back, then store to offset 2000, the filesystem will not be notified, so it will not instantiate a block to store that information in. Therefore if we truncate a file up, we need to mark the PTE that straddles the EOF as read-only so that page_mkwrite() is called. Now, I think this patch is safe because it's PAGE_SIZE that's important, not the size of the folio. We mmap files on PAGE_SIZE boundaries and we're only asking if there could be a new store which causes a block to be instantiated. If the block size is >= PAGE_SIZE, there can't be. If the folio size happens to be larger than PAGE_SIZE, it doesn't matter. All that matters is that we protect the folio which crosses i_size if block size < PAGE_SIZE. Matthew Wilcox (Oracle) (1): mm: Convert pagecache_isize_extended to use a folio mm/truncate.c | 22 ++++++++++------------ 1 file changed, 10 insertions(+), 12 deletions(-)