This patch 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.

[1]: https://syzkaller.appspot.com/bug?extid=8bb6fd945af4e0ad9299

Changelogs:
V5 (current):
- Add folio_expected_ref_count() for refcount calculation
- Add details about need of folio_expected_ref_count() for JFS

V4:
- https://lore.kernel.org/all/20250422114000.15003-1-shivankg@amd.com
- Make folio_expected_refs() inline and rename to folio_migration_expected_refs()

V3:
- https://lore.kernel.org/all/20250417060630.197278-1-shivankg@amd.com
- Fix typos

V1/V2:
- https://lore.kernel.org/all/20250413172356.561544-1-shivankg@amd.com
- Implement metapage_migrate_folio() similar to buffer_migrate_folio() but
  specialized to move JFS metapage data

#syz test: https://github.com/shivankgarg98/linux.git 69a58d5260

Shivank Garg (2):
  mm: Add folio_expected_ref_count() for reference count calculation
  jfs: implement migrate_folio for jfs_metapage_aops

 fs/jfs/jfs_metapage.c | 94 +++++++++++++++++++++++++++++++++++++++++++
 include/linux/mm.h    | 55 +++++++++++++++++++++++++
 mm/migrate.c          | 22 ++--------
 3 files changed, 153 insertions(+), 18 deletions(-)

-- 
2.34.1

On Wed, 30 Apr 2025 10:01:49 +0000 Shivank Garg <shivankg@amd.com> wrote:

> This patch 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.

Thanks, I'll add these to mm.git for some testing while discussion
proceeds.

Do we think these patches should be backported into -stable kernels?

Or maybe we should simply remove the warning from -stable kernels then
re-add it when we're confident that all in-tree filesystems are good?

On Wed, Apr 30, 2025 at 02:21:35PM -0700, Andrew Morton wrote:
> On Wed, 30 Apr 2025 10:01:49 +0000 Shivank Garg <shivankg@amd.com> wrote:
> > This patch 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.
> 
> Do we think these patches should be backported into -stable kernels?
> 
> Or maybe we should simply remove the warning from -stable kernels then
> re-add it when we're confident that all in-tree filesystems are good?

7ee3647243e5 is not yet in Linus' tree, let alone in -stable.

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+8bb6fd945af4e0ad9299@syzkaller.appspotmail.com
Tested-by: syzbot+8bb6fd945af4e0ad9299@syzkaller.appspotmail.com

Tested on:

commit:         69a58d52 Revert "x86/mm: Add 'mm' argument to unuse_te..
git tree:       https://github.com/shivankgarg98/linux.git
console output: https://syzkaller.appspot.com/x/log.txt?x=137a68d4580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=f002bbe3fe2ccafa
dashboard link: https://syzkaller.appspot.com/bug?extid=8bb6fd945af4e0ad9299
compiler:       Debian clang version 20.1.2 (++20250402124445+58df0ef89dd6-1~exp1~20250402004600.97), Debian LLD 20.1.2

Note: no patches were applied.
Note: testing is done by a robot and is best-effort only.