[PATCH] btrfs: fix a stupid bug masked by CONFIG_BTRFS_DEBUG

[PATCH] btrfs: fix a stupid bug masked by CONFIG_BTRFS_DEBUG

[Qu Wenruo]

[BUG]
Naohiro reported a weird bug that with CONFIG_BTRFS_DEBUG=n and
CONFIG_BTRFS_EXPERIMENTAL=y, test case btrfs/005 will crash with the
following call trace:

 page: refcount:5 mapcount:0 mapping:00000000a5ae9eff index:0x1c pfn:0x113658
 head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
 memcg:ffff888116d31280
 aops:btrfs_aops [btrfs] ino:101 dentry name(?):"tmp_file"
 flags: 0x2ffff800000406c(referenced|uptodate|lru|private|head|node=0|zone=2|lastcpupid=0x1ffff)
 page dumped because: VM_BUG_ON_FOLIO(!folio_test_locked(folio))
 ------------[ cut here ]------------
 kernel BUG at mm/filemap.c:1498!
 Oops: invalid opcode: 0000 [#1] SMP NOPTI
 CPU: 9 UID: 0 PID: 264 Comm: kworker/u50:3 Not tainted 6.16.0-rc1-custom+ #261 PREEMPT(full)
 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022
 Workqueue: btrfs-endio btrfs_end_bio_work [btrfs]
 RIP: 0010:folio_unlock+0x42/0x50
 Code: 37 01 78 05 c3 cc cc cc cc 31 f6 e9 38 fb ff ff 48 c7 c6 58 e6 45 82 e8 4c 69 05 00 0f 0b 48 c7 c6 b8 f3 47 82 e8 3e 69 05 00 <0f> 0b 90 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90
 Call Trace:
  <TASK>
  end_bbio_data_read+0x10d/0x4c0 [btrfs]
  ? end_bbio_compressed_read+0x49/0x140 [btrfs]
  end_bbio_compressed_read+0x56/0x140 [btrfs]
  process_one_work+0x1ff/0x570
  worker_thread+0x1cb/0x3a0
  ? __pfx_worker_thread+0x10/0x10
  kthread+0xff/0x260
  ? ret_from_fork+0x1b/0x1b0
  ? lock_release+0xdd/0x2e0
  ? __pfx_kthread+0x10/0x10
  ret_from_fork+0x161/0x1b0
  ? __pfx_kthread+0x10/0x10
  ret_from_fork_asm+0x1a/0x30
  </TASK>

[CAUSE]
CONFIG_BTRFS_EXPERIMENTAL=y enables the large data folio support for
btrfs, as can be seen from the "order: 2" output.

On the other hand function btrfs_is_subpage() checks if we need to go
through the subpage routine.

Meanwhile CONFIG_BTRFS_DEBUG enables another debug-only feature, 2k
block size, making BTRFS_MIN_BLOCKSIZE to be 2K.

And at compile time if page size is larger than the minimal block size,
btrfs_is_subpage() will do the proper check.
But if page size is no larger than minimal block size,
btrfs_is_subpage() is hard coded to return false as we believe there is
no need for subpage support.

But CONFIG_BTRFS_EXPERIMENTAL enables large data folio support, and
without CONFIG_BTRFS_DEBUG, btrfs_is_subpage() will always return false,
causing bugs when hitting a large folio.

[FIX]
Remove the PAGE_SIZE > BTRFS_MIN_BLOCKSIZE checks completely.

This fix will be folded into the large data folio enablement patch.

Reported-by: Naohiro Aota <Naohiro.Aota@wdc.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
---
 fs/btrfs/subpage.h | 14 --------------
 1 file changed, 14 deletions(-)

diff --git a/fs/btrfs/subpage.h b/fs/btrfs/subpage.h
index 7889a97365f0..453857f6c14d 100644
--- a/fs/btrfs/subpage.h
+++ b/fs/btrfs/subpage.h
@@ -93,7 +93,6 @@ enum btrfs_folio_type {
 	BTRFS_SUBPAGE_DATA,
 };
 
-#if PAGE_SIZE > BTRFS_MIN_BLOCKSIZE
 /*
  * Subpage support for metadata is more complex, as we can have dummy extent
  * buffers, where folios have no mapping to determine the owning inode.
@@ -114,19 +113,6 @@ static inline bool btrfs_is_subpage(const struct btrfs_fs_info *fs_info,
 		ASSERT(is_data_inode(BTRFS_I(folio->mapping->host)));
 	return fs_info->sectorsize < folio_size(folio);
 }
-#else
-static inline bool btrfs_meta_is_subpage(const struct btrfs_fs_info *fs_info)
-{
-	return false;
-}
-static inline bool btrfs_is_subpage(const struct btrfs_fs_info *fs_info,
-				    struct folio *folio)
-{
-	if (folio->mapping && folio->mapping->host)
-		ASSERT(is_data_inode(BTRFS_I(folio->mapping->host)));
-	return false;
-}
-#endif
 
 int btrfs_attach_folio_state(const struct btrfs_fs_info *fs_info,
 			     struct folio *folio, enum btrfs_folio_type type);
-- 
2.49.0

Re: [PATCH] btrfs: fix a stupid bug masked by CONFIG_BTRFS_DEBUG

[Naohiro Aota]

On Tue Jun 24, 2025 at 3:35 PM JST, Qu Wenruo wrote:
> [BUG]
> Naohiro reported a weird bug that with CONFIG_BTRFS_DEBUG=n and
> CONFIG_BTRFS_EXPERIMENTAL=y, test case btrfs/005 will crash with the
> following call trace:
>
>  page: refcount:5 mapcount:0 mapping:00000000a5ae9eff index:0x1c pfn:0x113658
>  head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
>  memcg:ffff888116d31280
>  aops:btrfs_aops [btrfs] ino:101 dentry name(?):"tmp_file"
>  flags: 0x2ffff800000406c(referenced|uptodate|lru|private|head|node=0|zone=2|lastcpupid=0x1ffff)
>  page dumped because: VM_BUG_ON_FOLIO(!folio_test_locked(folio))
>  ------------[ cut here ]------------
>  kernel BUG at mm/filemap.c:1498!
>  Oops: invalid opcode: 0000 [#1] SMP NOPTI
>  CPU: 9 UID: 0 PID: 264 Comm: kworker/u50:3 Not tainted 6.16.0-rc1-custom+ #261 PREEMPT(full)
>  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022
>  Workqueue: btrfs-endio btrfs_end_bio_work [btrfs]
>  RIP: 0010:folio_unlock+0x42/0x50
>  Code: 37 01 78 05 c3 cc cc cc cc 31 f6 e9 38 fb ff ff 48 c7 c6 58 e6 45 82 e8 4c 69 05 00 0f 0b 48 c7 c6 b8 f3 47 82 e8 3e 69 05 00 <0f> 0b 90 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90
>  Call Trace:
>   <TASK>
>   end_bbio_data_read+0x10d/0x4c0 [btrfs]
>   ? end_bbio_compressed_read+0x49/0x140 [btrfs]
>   end_bbio_compressed_read+0x56/0x140 [btrfs]
>   process_one_work+0x1ff/0x570
>   worker_thread+0x1cb/0x3a0
>   ? __pfx_worker_thread+0x10/0x10
>   kthread+0xff/0x260
>   ? ret_from_fork+0x1b/0x1b0
>   ? lock_release+0xdd/0x2e0
>   ? __pfx_kthread+0x10/0x10
>   ret_from_fork+0x161/0x1b0
>   ? __pfx_kthread+0x10/0x10
>   ret_from_fork_asm+0x1a/0x30
>   </TASK>
>
> [CAUSE]
> CONFIG_BTRFS_EXPERIMENTAL=y enables the large data folio support for
> btrfs, as can be seen from the "order: 2" output.
>
> On the other hand function btrfs_is_subpage() checks if we need to go
> through the subpage routine.
>
> Meanwhile CONFIG_BTRFS_DEBUG enables another debug-only feature, 2k
> block size, making BTRFS_MIN_BLOCKSIZE to be 2K.
>
> And at compile time if page size is larger than the minimal block size,
> btrfs_is_subpage() will do the proper check.
> But if page size is no larger than minimal block size,
> btrfs_is_subpage() is hard coded to return false as we believe there is
> no need for subpage support.
>
> But CONFIG_BTRFS_EXPERIMENTAL enables large data folio support, and
> without CONFIG_BTRFS_DEBUG, btrfs_is_subpage() will always return false,
> causing bugs when hitting a large folio.
>
> [FIX]
> Remove the PAGE_SIZE > BTRFS_MIN_BLOCKSIZE checks completely.
>
> This fix will be folded into the large data folio enablement patch.
>
> Reported-by: Naohiro Aota <Naohiro.Aota@wdc.com>
> Signed-off-by: Qu Wenruo <wqu@suse.com>
> ---
>  fs/btrfs/subpage.h | 14 --------------
>  1 file changed, 14 deletions(-)

I did a similar hack (putting "return fs_info->sectorsize <
folio_size(folio);" to btrfs_is_subpage() in the "#else" branch) and it
worked well. So, this patch itself seems fine.

But, doesn't this mean some code under "btrfs_is_subpage()" condition is
necessray even on the non-subpage setup? Then, should we promote the
code to the "normal" case, instead? Sorry if I get the "subpage" concept wrong.

>
> diff --git a/fs/btrfs/subpage.h b/fs/btrfs/subpage.h
> index 7889a97365f0..453857f6c14d 100644
> --- a/fs/btrfs/subpage.h
> +++ b/fs/btrfs/subpage.h
> @@ -93,7 +93,6 @@ enum btrfs_folio_type {
>  	BTRFS_SUBPAGE_DATA,
>  };
>  
> -#if PAGE_SIZE > BTRFS_MIN_BLOCKSIZE
>  /*
>   * Subpage support for metadata is more complex, as we can have dummy extent
>   * buffers, where folios have no mapping to determine the owning inode.
> @@ -114,19 +113,6 @@ static inline bool btrfs_is_subpage(const struct btrfs_fs_info *fs_info,
>  		ASSERT(is_data_inode(BTRFS_I(folio->mapping->host)));
>  	return fs_info->sectorsize < folio_size(folio);
>  }
> -#else
> -static inline bool btrfs_meta_is_subpage(const struct btrfs_fs_info *fs_info)
> -{
> -	return false;
> -}
> -static inline bool btrfs_is_subpage(const struct btrfs_fs_info *fs_info,
> -				    struct folio *folio)
> -{
> -	if (folio->mapping && folio->mapping->host)
> -		ASSERT(is_data_inode(BTRFS_I(folio->mapping->host)));
> -	return false;
> -}
> -#endif
>  
>  int btrfs_attach_folio_state(const struct btrfs_fs_info *fs_info,
>  			     struct folio *folio, enum btrfs_folio_type type);

Re: [PATCH] btrfs: fix a stupid bug masked by CONFIG_BTRFS_DEBUG

[Qu Wenruo]

在 2025/6/24 22:59, Naohiro Aota 写道:
> On Tue Jun 24, 2025 at 3:35 PM JST, Qu Wenruo wrote:
>> [BUG]
>> Naohiro reported a weird bug that with CONFIG_BTRFS_DEBUG=n and
>> CONFIG_BTRFS_EXPERIMENTAL=y, test case btrfs/005 will crash with the
>> following call trace:
>>
>>   page: refcount:5 mapcount:0 mapping:00000000a5ae9eff index:0x1c pfn:0x113658
>>   head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
>>   memcg:ffff888116d31280
>>   aops:btrfs_aops [btrfs] ino:101 dentry name(?):"tmp_file"
>>   flags: 0x2ffff800000406c(referenced|uptodate|lru|private|head|node=0|zone=2|lastcpupid=0x1ffff)
>>   page dumped because: VM_BUG_ON_FOLIO(!folio_test_locked(folio))
>>   ------------[ cut here ]------------
>>   kernel BUG at mm/filemap.c:1498!
>>   Oops: invalid opcode: 0000 [#1] SMP NOPTI
>>   CPU: 9 UID: 0 PID: 264 Comm: kworker/u50:3 Not tainted 6.16.0-rc1-custom+ #261 PREEMPT(full)
>>   Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022
>>   Workqueue: btrfs-endio btrfs_end_bio_work [btrfs]
>>   RIP: 0010:folio_unlock+0x42/0x50
>>   Code: 37 01 78 05 c3 cc cc cc cc 31 f6 e9 38 fb ff ff 48 c7 c6 58 e6 45 82 e8 4c 69 05 00 0f 0b 48 c7 c6 b8 f3 47 82 e8 3e 69 05 00 <0f> 0b 90 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90
>>   Call Trace:
>>    <TASK>
>>    end_bbio_data_read+0x10d/0x4c0 [btrfs]
>>    ? end_bbio_compressed_read+0x49/0x140 [btrfs]
>>    end_bbio_compressed_read+0x56/0x140 [btrfs]
>>    process_one_work+0x1ff/0x570
>>    worker_thread+0x1cb/0x3a0
>>    ? __pfx_worker_thread+0x10/0x10
>>    kthread+0xff/0x260
>>    ? ret_from_fork+0x1b/0x1b0
>>    ? lock_release+0xdd/0x2e0
>>    ? __pfx_kthread+0x10/0x10
>>    ret_from_fork+0x161/0x1b0
>>    ? __pfx_kthread+0x10/0x10
>>    ret_from_fork_asm+0x1a/0x30
>>    </TASK>
>>
>> [CAUSE]
>> CONFIG_BTRFS_EXPERIMENTAL=y enables the large data folio support for
>> btrfs, as can be seen from the "order: 2" output.
>>
>> On the other hand function btrfs_is_subpage() checks if we need to go
>> through the subpage routine.
>>
>> Meanwhile CONFIG_BTRFS_DEBUG enables another debug-only feature, 2k
>> block size, making BTRFS_MIN_BLOCKSIZE to be 2K.
>>
>> And at compile time if page size is larger than the minimal block size,
>> btrfs_is_subpage() will do the proper check.
>> But if page size is no larger than minimal block size,
>> btrfs_is_subpage() is hard coded to return false as we believe there is
>> no need for subpage support.
>>
>> But CONFIG_BTRFS_EXPERIMENTAL enables large data folio support, and
>> without CONFIG_BTRFS_DEBUG, btrfs_is_subpage() will always return false,
>> causing bugs when hitting a large folio.
>>
>> [FIX]
>> Remove the PAGE_SIZE > BTRFS_MIN_BLOCKSIZE checks completely.
>>
>> This fix will be folded into the large data folio enablement patch.
>>
>> Reported-by: Naohiro Aota <Naohiro.Aota@wdc.com>
>> Signed-off-by: Qu Wenruo <wqu@suse.com>
>> ---
>>   fs/btrfs/subpage.h | 14 --------------
>>   1 file changed, 14 deletions(-)
> 
> I did a similar hack (putting "return fs_info->sectorsize <
> folio_size(folio);" to btrfs_is_subpage() in the "#else" branch) and it
> worked well. So, this patch itself seems fine.
> 
> But, doesn't this mean some code under "btrfs_is_subpage()" condition is
> necessray even on the non-subpage setup? Then, should we promote the
> code to the "normal" case, instead? Sorry if I get the "subpage" concept wrong.

The name "subpage" is no longer proper with larger folios.

The original term "subpage" is there because at that time our target is 
still page, thus only when block size < page size needs the extra 
infrastructure to record per-block status.

But with large folios, even if block size == page size, we can still 
have a large folio covering multiple pages, and we need the 
infrastructures to track per-block status inside a large folio.

The more correct term would be "subfolio", but that also implies a folio 
can be larger than a page.

Hopes this would resolve your concern.

Thanks,
Qu

> 
>>
>> diff --git a/fs/btrfs/subpage.h b/fs/btrfs/subpage.h
>> index 7889a97365f0..453857f6c14d 100644
>> --- a/fs/btrfs/subpage.h
>> +++ b/fs/btrfs/subpage.h
>> @@ -93,7 +93,6 @@ enum btrfs_folio_type {
>>   	BTRFS_SUBPAGE_DATA,
>>   };
>>   
>> -#if PAGE_SIZE > BTRFS_MIN_BLOCKSIZE
>>   /*
>>    * Subpage support for metadata is more complex, as we can have dummy extent
>>    * buffers, where folios have no mapping to determine the owning inode.
>> @@ -114,19 +113,6 @@ static inline bool btrfs_is_subpage(const struct btrfs_fs_info *fs_info,
>>   		ASSERT(is_data_inode(BTRFS_I(folio->mapping->host)));
>>   	return fs_info->sectorsize < folio_size(folio);
>>   }
>> -#else
>> -static inline bool btrfs_meta_is_subpage(const struct btrfs_fs_info *fs_info)
>> -{
>> -	return false;
>> -}
>> -static inline bool btrfs_is_subpage(const struct btrfs_fs_info *fs_info,
>> -				    struct folio *folio)
>> -{
>> -	if (folio->mapping && folio->mapping->host)
>> -		ASSERT(is_data_inode(BTRFS_I(folio->mapping->host)));
>> -	return false;
>> -}
>> -#endif
>>   
>>   int btrfs_attach_folio_state(const struct btrfs_fs_info *fs_info,
>>   			     struct folio *folio, enum btrfs_folio_type type);

Re: [PATCH] btrfs: fix a stupid bug masked by CONFIG_BTRFS_DEBUG

[Naohiro Aota]

On Wed Jun 25, 2025 at 5:46 AM JST, Qu Wenruo wrote:
>
>
> 在 2025/6/24 22:59, Naohiro Aota 写道:
>> On Tue Jun 24, 2025 at 3:35 PM JST, Qu Wenruo wrote:
>>> [BUG]
>>> Naohiro reported a weird bug that with CONFIG_BTRFS_DEBUG=n and
>>> CONFIG_BTRFS_EXPERIMENTAL=y, test case btrfs/005 will crash with the
>>> following call trace:
>>>
>>>   page: refcount:5 mapcount:0 mapping:00000000a5ae9eff index:0x1c pfn:0x113658
>>>   head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
>>>   memcg:ffff888116d31280
>>>   aops:btrfs_aops [btrfs] ino:101 dentry name(?):"tmp_file"
>>>   flags: 0x2ffff800000406c(referenced|uptodate|lru|private|head|node=0|zone=2|lastcpupid=0x1ffff)
>>>   page dumped because: VM_BUG_ON_FOLIO(!folio_test_locked(folio))
>>>   ------------[ cut here ]------------
>>>   kernel BUG at mm/filemap.c:1498!
>>>   Oops: invalid opcode: 0000 [#1] SMP NOPTI
>>>   CPU: 9 UID: 0 PID: 264 Comm: kworker/u50:3 Not tainted 6.16.0-rc1-custom+ #261 PREEMPT(full)
>>>   Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022
>>>   Workqueue: btrfs-endio btrfs_end_bio_work [btrfs]
>>>   RIP: 0010:folio_unlock+0x42/0x50
>>>   Code: 37 01 78 05 c3 cc cc cc cc 31 f6 e9 38 fb ff ff 48 c7 c6 58 e6 45 82 e8 4c 69 05 00 0f 0b 48 c7 c6 b8 f3 47 82 e8 3e 69 05 00 <0f> 0b 90 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90
>>>   Call Trace:
>>>    <TASK>
>>>    end_bbio_data_read+0x10d/0x4c0 [btrfs]
>>>    ? end_bbio_compressed_read+0x49/0x140 [btrfs]
>>>    end_bbio_compressed_read+0x56/0x140 [btrfs]
>>>    process_one_work+0x1ff/0x570
>>>    worker_thread+0x1cb/0x3a0
>>>    ? __pfx_worker_thread+0x10/0x10
>>>    kthread+0xff/0x260
>>>    ? ret_from_fork+0x1b/0x1b0
>>>    ? lock_release+0xdd/0x2e0
>>>    ? __pfx_kthread+0x10/0x10
>>>    ret_from_fork+0x161/0x1b0
>>>    ? __pfx_kthread+0x10/0x10
>>>    ret_from_fork_asm+0x1a/0x30
>>>    </TASK>
>>>
>>> [CAUSE]
>>> CONFIG_BTRFS_EXPERIMENTAL=y enables the large data folio support for
>>> btrfs, as can be seen from the "order: 2" output.
>>>
>>> On the other hand function btrfs_is_subpage() checks if we need to go
>>> through the subpage routine.
>>>
>>> Meanwhile CONFIG_BTRFS_DEBUG enables another debug-only feature, 2k
>>> block size, making BTRFS_MIN_BLOCKSIZE to be 2K.
>>>
>>> And at compile time if page size is larger than the minimal block size,
>>> btrfs_is_subpage() will do the proper check.
>>> But if page size is no larger than minimal block size,
>>> btrfs_is_subpage() is hard coded to return false as we believe there is
>>> no need for subpage support.
>>>
>>> But CONFIG_BTRFS_EXPERIMENTAL enables large data folio support, and
>>> without CONFIG_BTRFS_DEBUG, btrfs_is_subpage() will always return false,
>>> causing bugs when hitting a large folio.
>>>
>>> [FIX]
>>> Remove the PAGE_SIZE > BTRFS_MIN_BLOCKSIZE checks completely.
>>>
>>> This fix will be folded into the large data folio enablement patch.
>>>
>>> Reported-by: Naohiro Aota <Naohiro.Aota@wdc.com>
>>> Signed-off-by: Qu Wenruo <wqu@suse.com>
>>> ---
>>>   fs/btrfs/subpage.h | 14 --------------
>>>   1 file changed, 14 deletions(-)
>> 
>> I did a similar hack (putting "return fs_info->sectorsize <
>> folio_size(folio);" to btrfs_is_subpage() in the "#else" branch) and it
>> worked well. So, this patch itself seems fine.
>> 
>> But, doesn't this mean some code under "btrfs_is_subpage()" condition is
>> necessray even on the non-subpage setup? Then, should we promote the
>> code to the "normal" case, instead? Sorry if I get the "subpage" concept wrong.
>
> The name "subpage" is no longer proper with larger folios.
>
> The original term "subpage" is there because at that time our target is 
> still page, thus only when block size < page size needs the extra 
> infrastructure to record per-block status.
>
> But with large folios, even if block size == page size, we can still 
> have a large folio covering multiple pages, and we need the 
> infrastructures to track per-block status inside a large folio.
>
> The more correct term would be "subfolio", but that also implies a folio 
> can be larger than a page.
>
> Hopes this would resolve your concern.

I see. I thought "subpage" was still some kind of an extension like the
zoned code.

I confirmed btrfs/005 passed without CONFIG_BTRFS_DEBUG.

Reviewed-by: Naohiro Aota <naohiro.aota@wdc.com>
Tested-by: Naohiro Aota <naohiro.aota@wdc.com>

>
> Thanks,
> Qu
>
>> 
>>>
>>> diff --git a/fs/btrfs/subpage.h b/fs/btrfs/subpage.h
>>> index 7889a97365f0..453857f6c14d 100644
>>> --- a/fs/btrfs/subpage.h
>>> +++ b/fs/btrfs/subpage.h
>>> @@ -93,7 +93,6 @@ enum btrfs_folio_type {
>>>   	BTRFS_SUBPAGE_DATA,
>>>   };
>>>   
>>> -#if PAGE_SIZE > BTRFS_MIN_BLOCKSIZE
>>>   /*
>>>    * Subpage support for metadata is more complex, as we can have dummy extent
>>>    * buffers, where folios have no mapping to determine the owning inode.
>>> @@ -114,19 +113,6 @@ static inline bool btrfs_is_subpage(const struct btrfs_fs_info *fs_info,
>>>   		ASSERT(is_data_inode(BTRFS_I(folio->mapping->host)));
>>>   	return fs_info->sectorsize < folio_size(folio);
>>>   }
>>> -#else
>>> -static inline bool btrfs_meta_is_subpage(const struct btrfs_fs_info *fs_info)
>>> -{
>>> -	return false;
>>> -}
>>> -static inline bool btrfs_is_subpage(const struct btrfs_fs_info *fs_info,
>>> -				    struct folio *folio)
>>> -{
>>> -	if (folio->mapping && folio->mapping->host)
>>> -		ASSERT(is_data_inode(BTRFS_I(folio->mapping->host)));
>>> -	return false;
>>> -}
>>> -#endif
>>>   
>>>   int btrfs_attach_folio_state(const struct btrfs_fs_info *fs_info,
>>>   			     struct folio *folio, enum btrfs_folio_type type);