From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B20DC2475E3; Mon, 19 Jan 2026 19:33:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768851192; cv=none; b=W5f69SQ7qV8sI7+G1CfvmQG9KID1UPVH0R6pFadM+qWOAHgttap2EAsfpBhLh3bbZch0XF2UBivV+2o6vZHBL0TiMkqQ1JbipC1j5uJsnbqajLqGMPWdrkG3KJX6SuFy41P0MygSGnl8CGNwE2UgA3SoExl0IYbnJqJHF3P52wc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768851192; c=relaxed/simple; bh=DRwpJER0zNtSisDlkiJN+FTgXeZjOjDYzJNLIcn5ABk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=XF9AkStbdQj6PLkwN9kyFJTmZQbyTiTqHhDU2+OcmyssKKBJ16Anea8AKidwBqMV2hyg8qA3W9KJbVuVQ8CMSibbym9I3eNdt+FBm7SKrH9nmCh+9Xu1gzhxyqgDXyZvBZVhN0j+bn2WfCP+uIpo+3MCLjZm7a9KNn9mLi+zvlk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=jw7k18TD; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="jw7k18TD" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D422AC116C6; Mon, 19 Jan 2026 19:33:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768851192; bh=DRwpJER0zNtSisDlkiJN+FTgXeZjOjDYzJNLIcn5ABk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=jw7k18TD+nCinzSLCmqVLxQkjg5CgI7PnZdMEwclGtPNqjYkv75T9CBDSzRqmhX0u kx17q8IjvxsNPC+l9alIryTVAy5smNgyar40kJYHj17+XBJA+540VQmnIvT5fikUGj TsymiyMNwaQKQjtj6lMmNnzfuN4Vwn/H1Xlg13ieA/3Ebeg/UCX39/oaXxSO/kYyhR Kd3MTq69spYuw5hRebVSN3a+l3dIYI2tWzXgG2q1Jd/m6XmmC97c7Io92EOut/d+fY HnW7c2NcOm/rzAgYDYnG6IDd1YYJtUJ5C9nZXxZ0+jY75m4jTfPi+/BhiJvngOMa72 iUuaEbQfF+Aag== Date: Mon, 19 Jan 2026 11:32:42 -0800 From: Eric Biggers To: Christoph Hellwig Cc: Andrey Albershteyn , "Darrick J. Wong" , Matthew Wilcox , fsverity@lists.linux.dev, linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, aalbersh@kernel.org, david@fromorbit.com, tytso@mit.edu, linux-ext4@vger.kernel.org, jaegeuk@kernel.org, chao@kernel.org, linux-f2fs-devel@lists.sourceforge.net Subject: Re: fsverity metadata offset, was: Re: [PATCH v2 0/23] fs-verity support for XFS with post EOF merkle tree Message-ID: <20260119193242.GB13800@sol> References: <20260114061536.GG15551@frogsfrogsfrogs> <5z5r6jizgxqz5axvzwbdmtkadehgdf7semqy2oxsfytmzzu6ik@zfvhexcp3fz2> <6r24wj3o3gctl3vz4n3tdrfjx5ftkybdjmmye2hejdcdl6qseh@c2yvpd5d4ocf> <20260119063349.GA643@lst.de> Precedence: bulk X-Mailing-List: fsverity@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260119063349.GA643@lst.de> On Mon, Jan 19, 2026 at 07:33:49AM +0100, Christoph Hellwig wrote: > While looking at fsverity I'd like to understand the choise of offset > in ext4 and f2fs, and wonder about an issue. > > Both ext4 and f2fs round up the inode size to the next 64k boundary > and place the metadata there. Both use the 65536 magic number for that > instead of a well documented constant unfortunately. > > I assume this was picked to align up to the largest reasonable page > size? Unfortunately for that: > > a) not all architectures are reasonable. As Darrick pointed out > hexagon seems to support page size up to 1MiB. While I don't know > if they exist in real life, powerpc supports up to 256kiB pages, > and I know they are used for real in various embedded settings > b) with large folio support in the page cache, the folios used to > map files can be much larger than the base page size, with all > the same issues as a larger page size > > So assuming that fsverity is trying to avoid the issue of a page/folio > that covers both data and fsverity metadata, how does it copy with that? > Do we need to disable fsverity on > 64k page size and disable large > folios on fsverity files? The latter would mean writing back all cached > data first as well. > > And going forward, should we have a v2 format that fixes this? For that > we'd still need a maximum folio size of course. And of course I'd like > to get all these things right from the start in XFS, while still being as > similar as possible to ext4/f2fs. Yes, if I recall correctly it was intended to be the "largest reasonable page size". It looks like PAGE_SIZE > 65536 can't work as-is, so indeed we should disable fsverity support in that configuration. I don't think large folios are quite as problematic. ext4_read_merkle_tree_page() and f2fs_read_merkle_tree_page() read a folio and return the appropriate page in it, and fs/verity/verify.c operates on the page. If it's a page in the folio that spans EOF, I think everything will actually still work, except userspace will be able to see Merkle tree data after a 64K boundary past EOF if the file is mmapped using huge pages. The mmap issue isn't great, but I'm not sure how much it matters, especially when the zeroes do still go up to a 64K boundary. If we do need to fix this, there are a couple things we could consider doing without changing the on-disk format in ext4 or f2fs: putting the data in the page cache at a different offset than it exists on-disk, or using "small" pages for EOF specifically. But yes, XFS should choose a larger alignment than 64K. - Eric 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 lists.sourceforge.net (lists.sourceforge.net [216.105.38.7]) (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 B4B57CCF2DE for ; Mon, 19 Jan 2026 19:33:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.sourceforge.net; s=beta; h=Content-Transfer-Encoding:Content-Type:Cc: Reply-To:From:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Subject:In-Reply-To:MIME-Version:References: Message-ID:To:Date:Sender:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=BbHLpEIGJQC64cFBegCcb/ctXJn5uXSNCh757X1p7AA=; b=jSYNxruQ5hT4Ii6azPhSpK4mTv kg8tuNeDJvqXUVmYIllGvLZI7SkCVR8jnixJKpEAOoLMdf1Ad9ZuSmWJbuLTpL2lEroiz/oilgDvf QPg2hkvBwzN1NCgu5VzN9Vur0rpXWvXCi+ZGc6kLFK0NvTro+wOaGhq2Md3ToQcHGXBE=; Received: from [127.0.0.1] (helo=sfs-ml-1.v29.lw.sourceforge.com) by sfs-ml-1.v29.lw.sourceforge.com with esmtp (Exim 4.95) (envelope-from ) id 1vhv09-000427-9W; Mon, 19 Jan 2026 19:33:25 +0000 Received: from [172.30.29.66] (helo=mx.sourceforge.net) by sfs-ml-1.v29.lw.sourceforge.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1vhv07-000420-Qy for linux-f2fs-devel@lists.sourceforge.net; Mon, 19 Jan 2026 19:33:23 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; 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:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=sDDx2FNkrgssEAKuJ+Cqr0aZUsSk4/zZO1VPKIoSSuE=; b=YzI3OQ+et4DAt33pkCE2Vgh7O9 MzjsDXbDMRBW7Q69ZU9c64ChmmmCImVe4tQUe98ql8drik6O1nidYpMdUBxQzRc5mck80Ugr3UxBu pnwI3J1oPWrQeVFpIWbVFJTUi7wsWOQr/YSlgMsgCOPHsz4WuB1hldvrC0r7vjRiohr0=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; 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:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=sDDx2FNkrgssEAKuJ+Cqr0aZUsSk4/zZO1VPKIoSSuE=; b=Fic/It6z1L7DPosrmQtgAOqli7 5gQDnA/SYjUvVNRVmAwUJtv9HVYrcttNh1ZiMlOhG1UzO1B9mXIbATZFqsdtrjjWh7o82sp/q+IwD iTqQ15pT92RYyjhb2fU8oweoYGG/3r26BRgxBVOTPjoVtoHjpIbDyP0hCpg9Lk+M6chU=; Received: from tor.source.kernel.org ([172.105.4.254]) by sfi-mx-2.v28.lw.sourceforge.com with esmtps (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.95) id 1vhv07-00005z-9R for linux-f2fs-devel@lists.sourceforge.net; Mon, 19 Jan 2026 19:33:23 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 942E160155; Mon, 19 Jan 2026 19:33:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D422AC116C6; Mon, 19 Jan 2026 19:33:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768851192; bh=DRwpJER0zNtSisDlkiJN+FTgXeZjOjDYzJNLIcn5ABk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=jw7k18TD+nCinzSLCmqVLxQkjg5CgI7PnZdMEwclGtPNqjYkv75T9CBDSzRqmhX0u kx17q8IjvxsNPC+l9alIryTVAy5smNgyar40kJYHj17+XBJA+540VQmnIvT5fikUGj TsymiyMNwaQKQjtj6lMmNnzfuN4Vwn/H1Xlg13ieA/3Ebeg/UCX39/oaXxSO/kYyhR Kd3MTq69spYuw5hRebVSN3a+l3dIYI2tWzXgG2q1Jd/m6XmmC97c7Io92EOut/d+fY HnW7c2NcOm/rzAgYDYnG6IDd1YYJtUJ5C9nZXxZ0+jY75m4jTfPi+/BhiJvngOMa72 iUuaEbQfF+Aag== Date: Mon, 19 Jan 2026 11:32:42 -0800 To: Christoph Hellwig Message-ID: <20260119193242.GB13800@sol> References: <20260114061536.GG15551@frogsfrogsfrogs> <5z5r6jizgxqz5axvzwbdmtkadehgdf7semqy2oxsfytmzzu6ik@zfvhexcp3fz2> <6r24wj3o3gctl3vz4n3tdrfjx5ftkybdjmmye2hejdcdl6qseh@c2yvpd5d4ocf> <20260119063349.GA643@lst.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20260119063349.GA643@lst.de> X-Headers-End: 1vhv07-00005z-9R Subject: Re: [f2fs-dev] fsverity metadata offset, was: Re: [PATCH v2 0/23] fs-verity support for XFS with post EOF merkle tree X-BeenThere: linux-f2fs-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Eric Biggers via Linux-f2fs-devel Reply-To: Eric Biggers Cc: fsverity@lists.linux.dev, aalbersh@kernel.org, "Darrick J. Wong" , Andrey Albershteyn , david@fromorbit.com, Matthew Wilcox , linux-f2fs-devel@lists.sourceforge.net, linux-xfs@vger.kernel.org, jaegeuk@kernel.org, linux-fsdevel@vger.kernel.org, tytso@mit.edu, linux-ext4@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net On Mon, Jan 19, 2026 at 07:33:49AM +0100, Christoph Hellwig wrote: > While looking at fsverity I'd like to understand the choise of offset > in ext4 and f2fs, and wonder about an issue. > > Both ext4 and f2fs round up the inode size to the next 64k boundary > and place the metadata there. Both use the 65536 magic number for that > instead of a well documented constant unfortunately. > > I assume this was picked to align up to the largest reasonable page > size? Unfortunately for that: > > a) not all architectures are reasonable. As Darrick pointed out > hexagon seems to support page size up to 1MiB. While I don't know > if they exist in real life, powerpc supports up to 256kiB pages, > and I know they are used for real in various embedded settings > b) with large folio support in the page cache, the folios used to > map files can be much larger than the base page size, with all > the same issues as a larger page size > > So assuming that fsverity is trying to avoid the issue of a page/folio > that covers both data and fsverity metadata, how does it copy with that? > Do we need to disable fsverity on > 64k page size and disable large > folios on fsverity files? The latter would mean writing back all cached > data first as well. > > And going forward, should we have a v2 format that fixes this? For that > we'd still need a maximum folio size of course. And of course I'd like > to get all these things right from the start in XFS, while still being as > similar as possible to ext4/f2fs. Yes, if I recall correctly it was intended to be the "largest reasonable page size". It looks like PAGE_SIZE > 65536 can't work as-is, so indeed we should disable fsverity support in that configuration. I don't think large folios are quite as problematic. ext4_read_merkle_tree_page() and f2fs_read_merkle_tree_page() read a folio and return the appropriate page in it, and fs/verity/verify.c operates on the page. If it's a page in the folio that spans EOF, I think everything will actually still work, except userspace will be able to see Merkle tree data after a 64K boundary past EOF if the file is mmapped using huge pages. The mmap issue isn't great, but I'm not sure how much it matters, especially when the zeroes do still go up to a 64K boundary. If we do need to fix this, there are a couple things we could consider doing without changing the on-disk format in ext4 or f2fs: putting the data in the page cache at a different offset than it exists on-disk, or using "small" pages for EOF specifically. But yes, XFS should choose a larger alignment than 64K. - Eric _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel