Re: Patch "btrfs: move large data folios out of experimental features" has been added to the 7.1-stable tree

Re: Patch "btrfs: move large data folios out of experimental features" has been added to the 7.1-stable tree

[Qu Wenruo]

在 2026/8/12 09:37, Sasha Levin 写道:
> This is a note to let you know that I've just added the patch titled
> 
>      btrfs: move large data folios out of experimental features
> 
> to the 7.1-stable tree which can be found at:
>      http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
> 
> The filename of the patch is:
>       btrfs-move-large-data-folios-out-of-experimental-fea.patch
> and it can be found in the queue-7.1 subdirectory.
> 
> If you, or anyone else, feels it should not be added to the stable tree,
> please let <stable@vger.kernel.org> know about it.

Please don't merge this new feature into any stable tree.

This feature is not compatible with the COW fixup mechanism in old kernels.

Thanks,
Qu

> 
> 
> 
> commit 3d8483065b9a103c8f10a57dd8638ce0f29b1dba
> Author: Qu Wenruo <wqu@suse.com>
> Date:   Fri Apr 24 10:20:25 2026 +0930
> 
>      btrfs: move large data folios out of experimental features
>      
>      [ Upstream commit 9bce95edb1b4d2802de9273b5170bfcff3090d24 ]
>      
>      This feature was introduced in v6.17 under experimental, and we had
>      several small bugs related to or exposed by that:
>      
>        e9e3b22ddfa7 ("btrfs: fix beyond-EOF write handling")
>        18de34daa7c6 ("btrfs: truncate ordered extent when skipping writeback past i_size")
>      
>      Otherwise, the feature has been frequently tested by btrfs developers.
>      
>      The latest fix only arrived in v6.19. After three releases, I think it's
>      time to move this feature out of experimental.
>      
>      And since we're here, also remove the comment about the bitmap size
>      limit, which is no longer relevant in the context. It will soon be
>      outdated for the incoming huge folio support.
>      
>      Reviewed-by: Neal Gompa <neal@gompa.dev>
>      Signed-off-by: Qu Wenruo <wqu@suse.com>
>      Signed-off-by: David Sterba <dsterba@suse.com>
>      Stable-dep-of: 4c375ac546ea ("btrfs: disable bs > ps support if no transparent hugepage support")
>      Signed-off-by: Sasha Levin <sashal@kernel.org>
> 
> diff --git a/fs/btrfs/Kconfig b/fs/btrfs/Kconfig
> index 5e75438e0b738..55eba4f1b6c79 100644
> --- a/fs/btrfs/Kconfig
> +++ b/fs/btrfs/Kconfig
> @@ -110,7 +110,7 @@ config BTRFS_EXPERIMENTAL
>   
>   	  - extent tree v2 - complex rework of extent tracking
>   
> -	  - large folio and block size (> page size) support
> +	  - block size > page size support
>   
>   	  - asynchronous checksum generation for data writes
>   
> diff --git a/fs/btrfs/btrfs_inode.h b/fs/btrfs/btrfs_inode.h
> index beb75f152d5cd..8a802e3675cd8 100644
> --- a/fs/btrfs/btrfs_inode.h
> +++ b/fs/btrfs/btrfs_inode.h
> @@ -533,12 +533,9 @@ static inline void btrfs_set_inode_mapping_order(struct btrfs_inode *inode)
>   	/* Metadata inode should not reach here. */
>   	ASSERT(is_data_inode(inode));
>   
> -	/* We only allow BITS_PER_LONGS blocks for each bitmap. */
> -#ifdef CONFIG_BTRFS_EXPERIMENTAL
>   	mapping_set_folio_order_range(inode->vfs_inode.i_mapping,
>   				      inode->root->fs_info->block_min_order,
>   				      inode->root->fs_info->block_max_order);
> -#endif
>   }
>   
>   void btrfs_calculate_block_csum_folio(struct btrfs_fs_info *fs_info,
> diff --git a/fs/btrfs/defrag.c b/fs/btrfs/defrag.c
> index 7e2db5d3a4d4c..9111308351f82 100644
> --- a/fs/btrfs/defrag.c
> +++ b/fs/btrfs/defrag.c
> @@ -859,23 +859,6 @@ static struct folio *defrag_prepare_one_folio(struct btrfs_inode *inode, pgoff_t
>   	if (IS_ERR(folio))
>   		return folio;
>   
> -	/*
> -	 * Since we can defragment files opened read-only, we can encounter
> -	 * transparent huge pages here (see CONFIG_READ_ONLY_THP_FOR_FS).
> -	 *
> -	 * The IO for such large folios is not fully tested, thus return
> -	 * an error to reject such folios unless it's an experimental build.
> -	 *
> -	 * Filesystem transparent huge pages are typically only used for
> -	 * executables that explicitly enable them, so this isn't very
> -	 * restrictive.
> -	 */
> -	if (!IS_ENABLED(CONFIG_BTRFS_EXPERIMENTAL) && folio_test_large(folio)) {
> -		folio_unlock(folio);
> -		folio_put(folio);
> -		return ERR_PTR(-ETXTBSY);
> -	}
> -
>   	ret = set_folio_extent_mapped(folio);
>   	if (ret < 0) {
>   		folio_unlock(folio);

Re: Patch "btrfs: move large data folios out of experimental features" has been added to the 7.1-stable tree

[Sasha Levin]

On Wed, Aug 12, 2026 at 10:13:09AM +0930, Qu Wenruo wrote:
> Please don't merge this new feature into any stable tree.
>
> This feature is not compatible with the COW fixup mechanism in old kernels.

Dropped from the 7.1 and 6.18 queues, thanks.

--
Thanks,
Sasha

Re: Patch "btrfs: move large data folios out of experimental features" has been added to the 7.1-stable tree

[David Sterba]

On Wed, Aug 12, 2026 at 07:44:44AM -0400, Sasha Levin wrote:
> On Wed, Aug 12, 2026 at 10:13:09AM +0930, Qu Wenruo wrote:
> > Please don't merge this new feature into any stable tree.
> >
> > This feature is not compatible with the COW fixup mechanism in old kernels.
> 
> Dropped from the 7.1 and 6.18 queues, thanks.

Can this be handled in a more generic way, the fixes to experimental
features? If you pass that through AI, it should be clear from the
context (changelog or code).

The config option has been added also for that purpose, it does not make
sense to backport that and assign CVE's eventually. Experimental
features are only for those following the most recent release.

Thanks.

Re: Patch "btrfs: move large data folios out of experimental features" has been added to the 7.1-stable tree

[Sasha Levin]

> Can this be handled in a more generic way, the fixes to experimental
> features? If you pass that through AI, it should be clear from the
> context (changelog or code).

Agreed, and done: the selection rules now reject both commits that
promote a feature out from behind a CONFIG_*_EXPERIMENTAL (or equivalent
staging) gate, and fixes to code that is only reachable when such a
symbol is enabled. It keys off the config gate in the diff rather than
the changelog wording, since neither commit here reads as "experimental"
in prose.

> The config option has been added also for that purpose, it does not make
> sense to backport that and assign CVE's eventually.

CVE assignment runs separately from the stable queue; I will pass the
same signal along there.

-- 
Thanks,
Sasha