From mboxrd@z Thu Jan 1 00:00:00 1970 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 B009AC7EE30 for ; Thu, 26 Jun 2025 12:51:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2AED16B009B; Thu, 26 Jun 2025 08:51:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 260056B009C; Thu, 26 Jun 2025 08:51:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 175D36B009F; Thu, 26 Jun 2025 08:51:39 -0400 (EDT) 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 021476B009B for ; Thu, 26 Jun 2025 08:51:38 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 9F494B7158 for ; Thu, 26 Jun 2025 12:51:38 +0000 (UTC) X-FDA: 83597538276.21.638CA8B Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf01.hostedemail.com (Postfix) with ESMTP id 7C51240002 for ; Thu, 26 Jun 2025 12:51:36 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=dpfCG2ws; dmarc=pass (policy=quarantine) header.from=redhat.com; spf=pass (imf01.hostedemail.com: domain of bfoster@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=bfoster@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750942296; a=rsa-sha256; cv=none; b=kiRQW1Ur5xSb1jKOWaSbH7Twz+yrm1IxyZZGjYN0BAJRoza7mKWVNcu3zfRPvirPYQaWP1 +xJm3OGbb9npzwH7JMMlfVxa/DwZ84+vWpXY5rKg4xX1745k+cDCcBnfgS4KZWoqyxobz7 eaaBX2ERu4n8DrHFYS+YZao/9CkLx/g= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=dpfCG2ws; dmarc=pass (policy=quarantine) header.from=redhat.com; spf=pass (imf01.hostedemail.com: domain of bfoster@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=bfoster@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750942296; 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-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=TOOsb+Sq38AoiGdR7fYv5S5HqDCgNZS1gBNHReeGAL0=; b=X3/qjTVYumiLJwBR63v9VZmnXFOuNgUU+Up4q3XDrHI4qLFY4Le/+Zckl8qY6moW44slu2 xuh29CgRvP/FkkCD/xFu4FbCTYDRiB1BVHQHvGPPIGRb5zavRHuax/BaJ912u84JB0xS9U fR+bCxFy0H6iTQf05jxrbmstjl1CNEo= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1750942295; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=TOOsb+Sq38AoiGdR7fYv5S5HqDCgNZS1gBNHReeGAL0=; b=dpfCG2wsPfYxwu82hzp5fDsUQ7TIhQu7IZ2a8DT4qIDvWTBjF0BOgMdWd0bgEgjPh3MzDx P22m1jEo1dBRsmAawxqTJQnXEENWQEwSIyGPXZGwQWZEIVBMMWSl2uxp6vbIbEmHjAVUoH QhCQQlU9q2cfbCbejB+fWCP+CKxUeTI= Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-16-S2zdDHe_O1ak9K585poBWw-1; Thu, 26 Jun 2025 08:51:30 -0400 X-MC-Unique: S2zdDHe_O1ak9K585poBWw-1 X-Mimecast-MFC-AGG-ID: S2zdDHe_O1ak9K585poBWw_1750942289 Received: from mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.93]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 288D2180028D; Thu, 26 Jun 2025 12:51:29 +0000 (UTC) Received: from bfoster (unknown [10.22.64.142]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id C1C53180045B; Thu, 26 Jun 2025 12:51:27 +0000 (UTC) Date: Thu, 26 Jun 2025 08:55:05 -0400 From: Brian Foster To: Hugh Dickins Cc: Matthew Wilcox , linux-mm@kvack.org, Baolin Wang Subject: Re: [PATCH] tmpfs: zero post-eof folio range on file extension Message-ID: References: <20250625184930.269727-1-bfoster@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.93 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: EWIF67kyc_JyJ6Fm-v-M5O5us3KuJO5wZ3nqwr4rhuo_1750942289 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspam-User: X-Rspamd-Queue-Id: 7C51240002 X-Rspamd-Server: rspam10 X-Stat-Signature: i8oob4hnfeeo148ifpzwi1otjiojezik X-HE-Tag: 1750942296-289800 X-HE-Meta: U2FsdGVkX19o694Gq2b094dDE8IUTajyI9cvOW0ZekncomMg4JEDT2MwQkYmAIIWMfd4q8LdmTA19I+Cs9bHmfezbopQZ7wzQf2Z3pH1HZnN/y5Ai3+8e/gW4xgvEfBs6RdWpaUcSqL2iVO5EsfevgDkESG4A9h37iKsPvyRz1f3YzsN7fzMndGuhGtKsG/zyuVkFa3jXh1fOqn2+IXDBPFWm6UXIuzSkT2uNG3LAL4UXUWb7kl9pK0Am3SQcNgqSrpyfn5jHGKcl2ChSBYmBedAPrFX2QumCzjyCYesSynEAeCK9fPgfiQYRk4Ar2K/eV4QS0RhpgOJaB2FSqvfn1SQyFrEKXqrrJBBAgqGMrjsCrcfA+0AAxQqYoEP876FG0pwAXQF6EJuLEQFyxVcZcUubX/+XfK0LEPzVCaxKCbaTh5kzYRt469N86hbN0dIw2kaJnxfdqICU4q+YZ2ZrJrN6TlN9BRowZG4cyftCBiICvbyA3qM8ouqoWkUlrkPEikBCcZtflsH1pVYsuwckNEF6v9SKaNF85oInzOz6zn8xsxLLf0NGWHU9gxcCnaRhdyekEANcY3N5ei9svtUHC4H5oxHFGC8yYX6KJmVEe3FS3xUAnfsegAIZw8arxoy6O0u/X8VlXCXuhaMCsLWIJUAC3iYx6x24xER9DVqaGkgoXS3J6vkiZFdreLXr2Fj8Y5AT0QpbdZq4aCyxPZQc6/3uD5a17SUhhYaebSK3IP/0W0DtD8KrbKnGbBQ0R5Fh7rOXUghgkdCrLIdAVhq3o9Y/kHzIwOk66kv11XQQwhB3UYkO0gnarItA8ukPiBClXNiGIKg7dGKextrfPhK2pQfvUbQVKpMbU8roM1PblnzaVJ/EPQ3sKK0UroRds02j2xZtQu6D8SPAMi0nYhQR/Dq9oONNSbzWpkJqFzE/+HzAQxB8XZbfmrutOteQ9ce/aZooj2q24WzjyWO8PO WIocy02O JPWnj1xQRvmEcmAb6mDZoyUdzH1ayKqKNWDgRF1Z1xQVJ2DH23NynT4l986UTVABALJqpt63sfZbmzgZgY08HxoqdWcCLg7kbBU9YUJwdGkbW74TGWGbcRnTRnZAFJb3G2xhRYiqUC1UYUhbTOjenb56At13Ta3o0aO4vF4UYuqJchXswlOadsV+G8ZMAlIPr4JQrqU2UVMgwS3coctkKcaEpvuHe1u5iUqvyBzaXXsRsPmJ9187Vtx6NR9KojcRzaQurKeMQwK50p4SU5TAkQivIAMCSYDYU42iIM1jIal1RB0lqisQfsIDmQKzIXMpoz71Fd5Dl4ufuBWf7bRQwvQGjVeHH1twzv21p6whY1PmO1Mho3sX0xkhpgkxu8fl8WuCsAfjrEwtjp6DUxCOT1uMVi7mt+N+FSiKq8btA66oL5ZkZuB7Xd+kgqWqb8qg0r3rmfmmEnHwOpNXSEDPGlfSJO1xscX/9/XZehaUE/LeWQ2Y= 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: On Wed, Jun 25, 2025 at 10:35:44PM -0700, Hugh Dickins wrote: > On Wed, 25 Jun 2025, Matthew Wilcox wrote: > > On Wed, Jun 25, 2025 at 02:49:30PM -0400, Brian Foster wrote: > > > Most traditional filesystems zero the post-eof portion of the eof > > > folio at writeback time, or when the file size is extended by > > > truncate or extending writes. This ensures that the previously > > > post-eof range of the folio is zeroed before it is exposed to the > > > file. > > > > > > tmpfs doesn't implement the writeback path the way a traditional > > > filesystem does, so zeroing behavior won't be exactly the same. > > > However, it can still perform explicit zeroing from the various > > > operations that extend a file and expose a post-eof portion of the > > > eof folio. The current lack of zeroing is observed via failure of > > > fstests test generic/363 on tmpfs. This test injects post-eof mapped > > > writes in certain situations to detect gaps in zeroing behavior. > > > > > > Add a new eof zeroing helper for file extending operations. Look up > > > the current eof folio, and if one exists, zero the range about to be > > > exposed. This allows generic/363 to pass on tmpfs. > > > > This seems like what I did here? > > > > https://lore.kernel.org/linux-fsdevel/20230202204428.3267832-4-willy@infradead.org/ > > > > Which fix should we prefer? > Quite similar, indeed. This is actually about the same as my initial prototype when I was just trying to confirm the problem for truncate. As Hugh notes, we still need to cover other size extension paths (fallocate, buffered write). > Thank you Brian, thank you Matthew. > > Of course my immediate reaction is to prefer the smaller patch, > Matthew's, but generic/363 still fails with that one: I need to look > into what each of you is doing (and that mail thread from 2023) and > make up my own mind. > FWIW, I started off with something trying to use shmem_undo_range() and eventually moved toward the current patch because I couldn't get it working quite right. Explicit zeroing seemed like less complexity than calling through undo_range() on various operations, primarily due to less risk of unintentional side effect. It's possible (likely :P) that was just user error on my part, so now that I have a functional patch I can revisit that approach if it is preferred. However one thing I wasn't aware of at the time was the additional zeroing needed into the target range on fallocate, so that might require care to avoid not immediately punching out the folios that were fallocated just prior. I suspect this would mean we'd need a helper or something to restrict the range to undo to just the eof folio. That seems like a plausible approach, I'm just not so sure the final result will end up much smaller or simpler than this patch. > (I'm worried why I had no copy of Matthew's 2023 patch: it's sadly > common for me to bury patches for long periods of time, but not > usually to lose them completely. But that is my worry, not yours.) > > I haven't been much concerned by generic/383 failing on tmpfs: > but promise to respect your efforts in due course. > It's certainly not the bug of the century. ;) I added the test somewhat recently because we had bigger zeroing issues on other filesystems and I noticed we had no decent test coverage. > I procrastinate "in due course" because (a) the full correct answwer > will depend on what happens with large folios, and (b) large folio > work in 6.14 changed (I'll say broke) the behaviour of huge=always > at eof (I expected a danger of that, and thought I checked before > 6.14-rc settled, but must have messed up my checking somehow). > Interesting.. I assume huge=always refers to a mount option. I need to give that a test. I'm also curious if either of you have any thoughts on the uptodate question. Does filtering zeroing on uptodate folios ensure we'd zero only folios that were previously written to? Thanks for the comments. Brian > So there's more (and more urgent) to sort out before settling on > the right generic/383 fix. > > Thanks, > Hugh >