From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 8236A4E781F; Fri, 18 Sep 2026 11:16:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789730197; cv=none; b=M30l4TmCS7/3HqOscm88SIP+XLW0npeIj1hE9wZFIFBMBuf9hT5hK7UVDNgqx86CZFyAtTiMDAMcBp0vppNiXwqxx7t5lGrNdj0YddXk1IQlpGJp/NbLzmijM4J6E9mK7KP+KcleuQT0LoABhEkmfdk5RCDV1WIVLTEF7M/2has= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789730197; c=relaxed/simple; bh=/nls4ykTox73U+HacuJ3TRHhqBlSPN1qx/JXsR08c5E=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=jtKfmlDsa48eoqM02G6AfbTUuxFwgppbN5W865DDqzxZL4doqglR7A+tJq3aI6eoWngldilT+x+HVgMCloLauWzAG68X/RKBMf0VFNbpa2UaLMQIMv7u88ntQ+OWh7r0sp0AMMmV2VAuVZ3ekEMvM/PB2pZg/6GUPbPB6ggiM2E= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=dptXv+sN; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="dptXv+sN" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6B28C1F00899; Fri, 18 Sep 2026 11:16:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789730196; bh=v3Ncvjf0hwtJJZK9pRrZLdGb+szlbnZRxACnVZ65HjM=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=dptXv+sNkIxYDgXRi1/EPcntOCS7ZJhaCpmsZjtPQdyYbVkCY1+Mrd/sHGMuIXBf9 WPuvtMKlTM9CRFZh9dg0BFqqg7XQOcLU9FrxIvKlHtLHmFP6MN1tp5V8kss3evWJWC V0h8gXL4JGXtWUzmCkJNv9WyCuGm7fmJnKkZ9R9pM5Pldm3UttN9syapBYxIVs/Q4K E1shcEWQUGtpERN3mYzA6VerwR1/y0T4SvyE6BUv6ZJysHeK/50VjRbivTqnpuJnPd Tnnd3V5NUfLa5jNLrJY9VTpClfxLwxuirdEMl18rwPZRh6NE2weoKDrvJb7B5NV4+3 NrFVTW0aJ7xoA== From: Andrey Albershteyn To: djwong@kernel.org, ebiggers@kernel.org, hch@lst.de, Carlos Maiolino Cc: Andrey Albershteyn , fsverity@lists.linux.dev, linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org, linux-unionfs@vger.kernel.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-btrfs@vger.kernel.org, david@fromorbit.com Subject: [PATCH v16 14/21] xfs: don't remove written extents past EOF on fsverity inodes Date: Fri, 18 Sep 2026 13:15:26 +0200 Message-ID: <20260918111539.1003439-15-aalbersh@kernel.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260918111539.1003439-1-aalbersh@kernel.org> References: <20260918111539.1003439-1-aalbersh@kernel.org> Precedence: bulk X-Mailing-List: linux-btrfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit xfs_free_eofblocks() removes all extents past EOF unless the XFS_DIFLAG_PREALLOC or XFS_DIFLAG_APPEND flags are set. This is undesired for fsverity as it stores metadata beyond EOF. However, while merkle tree is being built, delayed preallocation and unwritten extents are used. After metadata construction is done, fsverity inodes becomes read-only and won't be changed anymore, none of these unwritten extents or preallocations in post EOF region will be used. Let xfs_free_eofblocks() be called on fsverity inode as usual to remove anything which is not written extent. However, inodes which are undergoing merkle tree construction need to be skipped in case reclaim takes place. Signed-off-by: Andrey Albershteyn --- fs/xfs/xfs_bmap_util.c | 25 ++++++++++++++++++++++--- 1 file changed, 22 insertions(+), 3 deletions(-) diff --git a/fs/xfs/xfs_bmap_util.c b/fs/xfs/xfs_bmap_util.c index 268d159339d0..7fd951992557 100644 --- a/fs/xfs/xfs_bmap_util.c +++ b/fs/xfs/xfs_bmap_util.c @@ -31,6 +31,7 @@ #include "xfs_rtbitmap.h" #include "xfs_rtgroup.h" #include "xfs_zone_alloc.h" +#include /* Kernel only BMAP related definitions and functions */ @@ -553,6 +554,13 @@ xfs_can_free_eofblocks( if (last_fsb <= end_fsb) return false; + /* + * Don't clean fsverity inodes which have merkle tree being built, the + * merkle tree is written beyond EOF + */ + if (xfs_iflags_test(ip, XFS_VERITY_CONSTRUCTION)) + return false; + /* * Check if there is an post-EOF extent to free. If there are any * delalloc blocks attached to the inode (data fork delalloc @@ -579,6 +587,9 @@ xfs_free_eofblocks( struct xfs_trans *tp; struct xfs_mount *mp = ip->i_mount; int error; + int bmapi_flags = XFS_BMAPI_NODISCARD; + bool has_verity = + ip->i_diflags2 & XFS_DIFLAG2_VERITY; /* Attach the dquots to the inode up front. */ error = xfs_qm_dqattach(ip); @@ -593,15 +604,20 @@ xfs_free_eofblocks( * * Note that this means we also leave speculative preallocations in * place for preallocated files. + * + * Clean up delalloc reservations for fsverity too as those won't be + * used */ - if (ip->i_diflags & (XFS_DIFLAG_PREALLOC | XFS_DIFLAG_APPEND)) { + if (ip->i_diflags & (XFS_DIFLAG_PREALLOC | XFS_DIFLAG_APPEND) || + has_verity) { if (ip->i_delayed_blks) { xfs_bmap_punch_delalloc_range(ip, XFS_DATA_FORK, round_up(XFS_ISIZE(ip), mp->m_sb.sb_blocksize), LLONG_MAX, NULL); } xfs_inode_clear_eofblocks_tag(ip); - return 0; + if (!has_verity) + return 0; } error = xfs_trans_alloc(mp, &M_RES(mp)->tr_itruncate, 0, 0, 0, &tp); @@ -613,6 +629,9 @@ xfs_free_eofblocks( xfs_ilock(ip, XFS_ILOCK_EXCL); xfs_trans_ijoin(tp, ip, 0); + if (has_verity) + bmapi_flags |= XFS_BMAPI_UNWRITTEN; + /* * Do not update the on-disk file size. If we update the on-disk file * size and then the system crashes before the contents of the file are @@ -620,7 +639,7 @@ xfs_free_eofblocks( * bug). */ error = xfs_itruncate_extents_flags(&tp, ip, XFS_DATA_FORK, - XFS_ISIZE(ip), XFS_BMAPI_NODISCARD); + XFS_ISIZE(ip), bmapi_flags); if (error) goto err_cancel; -- 2.54.0