Re: [PATCH 6.15.y 1/2] mm: add folio_expected_ref_count() for reference count calculation

[Greg KH <gregkh@linuxfoundation.org>]

On Fri, Jun 20, 2025 at 10:28:16AM +0000, Shivank Garg wrote:
> Patch series " JFS: Implement migrate_folio for jfs_metapage_aops" v5.
> 
> This patchset addresses a warning that occurs during memory compaction due
> to JFS's missing migrate_folio operation.  The warning was introduced by
> commit 7ee3647243e5 ("migrate: Remove call to ->writepage") which added
> explicit warnings when filesystem don't implement migrate_folio.
> 
> The syzbot reported following [1]:
>   jfs_metapage_aops does not implement migrate_folio
>   WARNING: CPU: 1 PID: 5861 at mm/migrate.c:955 fallback_migrate_folio mm/migrate.c:953 [inline]
>   WARNING: CPU: 1 PID: 5861 at mm/migrate.c:955 move_to_new_folio+0x70e/0x840 mm/migrate.c:1007
>   Modules linked in:
>   CPU: 1 UID: 0 PID: 5861 Comm: syz-executor280 Not tainted 6.15.0-rc1-next-20250411-syzkaller #0 PREEMPT(full)
>   Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025
>   RIP: 0010:fallback_migrate_folio mm/migrate.c:953 [inline]
>   RIP: 0010:move_to_new_folio+0x70e/0x840 mm/migrate.c:1007
> 
> To fix this issue, this series implement metapage_migrate_folio() for JFS
> which handles both single and multiple metapages per page configurations.
> 
> While most filesystems leverage existing migration implementations like
> filemap_migrate_folio(), buffer_migrate_folio_norefs() or
> buffer_migrate_folio() (which internally used folio_expected_refs()),
> JFS's metapage architecture requires special handling of its private data
> during migration.  To support this, this series introduce the
> folio_expected_ref_count(), which calculates external references to a
> folio from page/swap cache, private data, and page table mappings.
> 
> This standardized implementation replaces the previous ad-hoc
> folio_expected_refs() function and enables JFS to accurately determine
> whether a folio has unexpected references before attempting migration.
> 
> Implement folio_expected_ref_count() to calculate expected folio reference
> counts from:
> - Page/swap cache (1 per page)
> - Private data (1)
> - Page table mappings (1 per map)
> 
> While originally needed for page migration operations, this improved
> implementation standardizes reference counting by consolidating all
> refcount contributors into a single, reusable function that can benefit
> any subsystem needing to detect unexpected references to folios.
> 
> The folio_expected_ref_count() returns the sum of these external
> references without including any reference the caller itself might hold.
> Callers comparing against the actual folio_ref_count() must account for
> their own references separately.
> 
> Link: https://syzkaller.appspot.com/bug?extid=8bb6fd945af4e0ad9299 [1]
> Link: https://lkml.kernel.org/r/20250430100150.279751-1-shivankg@amd.com
> Link: https://lkml.kernel.org/r/20250430100150.279751-2-shivankg@amd.com
> Signed-off-by: David Hildenbrand <david@redhat.com>
> Signed-off-by: Shivank Garg <shivankg@amd.com>
> Suggested-by: Matthew Wilcox <willy@infradead.org>
> Co-developed-by: David Hildenbrand <david@redhat.com>
> Cc: Alistair Popple <apopple@nvidia.com>
> Cc: Dave Kleikamp <shaggy@kernel.org>
> Cc: Donet Tom <donettom@linux.ibm.com>
> Cc: Jane Chu <jane.chu@oracle.com>
> Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
> Cc: Zi Yan <ziy@nvidia.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
>  include/linux/mm.h | 55 ++++++++++++++++++++++++++++++++++++++++++++++
>  mm/migrate.c       | 22 ++++---------------
>  2 files changed, 59 insertions(+), 18 deletions(-)
> 


<formletter>

This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read:
    https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.

</formletter>