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 08226C7EE2A for ; Wed, 25 Jun 2025 19:21:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9F17A6B00D2; Wed, 25 Jun 2025 15:21:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9C9896B00D3; Wed, 25 Jun 2025 15:21:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9069E6B00D4; Wed, 25 Jun 2025 15:21:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 819946B00D2 for ; Wed, 25 Jun 2025 15:21:10 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id EF7BF8073C for ; Wed, 25 Jun 2025 19:21:09 +0000 (UTC) X-FDA: 83594891058.30.0067A5F Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf23.hostedemail.com (Postfix) with ESMTP id 5946E140006 for ; Wed, 25 Jun 2025 19:21:07 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=Typo5mb9 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750879267; 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=Gx6yWAgZx66zmOCxVCdzBIYNUmya9Fkgc8oUxuB0P+Q=; b=CVDbc+HsGJhVhFiQy/TBMuE+q8PRyZ6N+1IGKei3+GfW+uakCzY8khd8dvfu6At9P8XDzc J8zLMBnSO86re9SQAoel/VT8gkX3rMJATJb78zS9VGlJJafzD7jP+hcWnNujLs2yRttjug z2sZQ+HJrv+NQIdNQQfE02Bs+FBPSQ0= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=Typo5mb9; spf=none (imf23.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750879267; a=rsa-sha256; cv=none; b=GhDRcsMImJTZGRhrHfYsJUx/lqtTYQfq9Bek7Cra13y7+vfAULrSxL1uzIqHhv79XLsdB8 eqsBYOUrQhrnubnv0mVEhqXr454UE+nxRQjDBGdti+WBQjEvmwRKxYXaM/i/cobwIs7uMD 8oPTVtCkAxx0Af9b6AYe0+BQHRV4YKE= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=Gx6yWAgZx66zmOCxVCdzBIYNUmya9Fkgc8oUxuB0P+Q=; b=Typo5mb9tu2Y2Abu9SU0AdYHs2 Ji5wqWuX5y2TzmI7dLSX05Xj1tHnkeZj/y68ZFVFCQZDlcHAECAy0F4k7tBv+qvrEeVJSC2WezPbg bM5Fc5cxnnHQ3zrLAoMnCwfdZr8ZM8z51LjkF/YDBfCIVuuzWDvOyUsiAr8vqunPsgVY92oNSpYLb m4QjGF8OW5qWeRhJAEYltWcPMikMKAKU3y7kmtVaXjt9bzQ9h8XGpKnnA6IF9KKxP4Vfsl0MFMd5f 6XmwMQcHQyTbutke3Fhd6dpPk6Cg9E0wPUvpe5j5xzKschlqXiBnuSi6FpKOh3rJvZKIGApgRvqPu jBVeM6bw==; Received: from willy by casper.infradead.org with local (Exim 4.98.2 #2 (Red Hat Linux)) id 1uUVg7-0000000A2xW-32rS; Wed, 25 Jun 2025 19:21:03 +0000 Date: Wed, 25 Jun 2025 20:21:03 +0100 From: Matthew Wilcox To: Brian Foster Cc: linux-mm@kvack.org, Hugh Dickins , 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250625184930.269727-1-bfoster@redhat.com> X-Rspamd-Queue-Id: 5946E140006 X-Stat-Signature: dkkqsafb74jp84uz9m4prjxg4ip6ga8z X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1750879267-180127 X-HE-Meta: U2FsdGVkX19Mz8YKx47toJJTF5MCD5sI6maAn45CwF6gIN+YseY5jVO2Gjk+VOO2Yflk49aU7J8Fu/P9rfH4nO+0PcE/4r40Eoomcy8PkdIyh25Yl9c7i8bbKdN0GNOrWGqcn0B0lcXkeQtewJw8VjRhiJrrKFTmX/8tTysAg6aLrmRVCs+NtMs05GtEQFA9z6nKXgO7E39KMI7udO/fX0pyDXkIgF6KvB+5bGPi6zr/vmcNsWcnGdz6/34gEWaGWub5PLQCKTjEkrUKOUIJhef52n8z31xRFMWpd2OgWhc291K+WHYZICbhgR5iPOryREcrt5qtWfoSEL0LABbQqqzs+CdWjd4CXTkDmfjqubYxGkXwJs13L37SRF8UuP+VKw5qV+Y3RizXFETaVkOHuRk4L5l627/Db7gYhazmyi0xxOElas+ggl3a0aBALG3XKrLdVRzORj/T0VPcplnBGRNOVBURhtxytj7rJ+Q5ZyBRb73pTwCtrBNPxEINufuy3fPDrjFbPFQEsxwTfKD1kBXyLXyeqsbh6fPPycHWFE5elM+LP8kAOsQe593yt3Piv6fKppBWdmergvrPp1qQKLDFpWUX71Xc23eYmbM06kE3ZIi6xuuNOkO3ld+nwrEQZmBZrf5xFWfYA8VA5lHtS3V7df02gXaQh4cI5QldKIglAEmt+fwtDlmm6IASIp9yJz0xoM9/YpttMQ4Opoylp3/iNnzWq7RB17yaueivD7r/WwP7OeK/+7MeQXzmSQfVS/cD2LmwdlW75/fgxl228wk+sUJS/EWIAZRjiwV6lS/2yNiFkVr5RRVNz2+kcfj1MjLfjoa3SUVY/uP0UkYkGtYVNgtLXl9ghvLsMPGTBrhJkoDta4GBHAnWKKNX8zERfCiS9uf2HcYi09Ag8UDpjhly0IipWet+8Xcsh3AMeHnpza4Jb6DAjQrjD4+13n5wNIzW5NCmQU9wPRQl59j JzYIvosC c+NJjEgS/1eCk7jLhFmEyFxLu8rSaStqKrq8OlKk1pfF2QALmmPtJ9nglyyi05L18pdwZ5W70TUlihMOv0p47RyT8D4Bx92FoeQeErfUWeUJ8npHxdqMlxZAfqZCF5NT8vBJy6J5mb7jdEMmJOsx05QHMGXb9SzPI+DhrC+TYyonKQxFrivAZ11YQn+WoErKcT/y93wCyEAUMDFzw2/ivQriZdL/8nloz1uxx/7oPkzVa5kwoYeDDqNRCjJGyTiGLrM0K 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 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?