From: David Hildenbrand <david@redhat.com>
To: syzbot <syzbot+5e8feb543ca8e12e0ede@syzkaller.appspotmail.com>,
akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, syzkaller-bugs@googlegroups.com
Subject: Re: [syzbot] [mm?] WARNING in do_wp_page
Date: Sun, 13 Apr 2025 22:20:17 +0200 [thread overview]
Message-ID: <ec2c31e4-f7f2-4ec0-bbfe-e6d6e080429f@redhat.com> (raw)
In-Reply-To: <67fab4fe.050a0220.2c5fcf.0011.GAE@google.com>
On 12.04.25 20:46, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
Related to my recent changes
>
> HEAD commit: 0af2f6be1b42 Linux 6.15-rc1
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1766323f980000
> kernel config: https://syzkaller.appspot.com/x/.config?x=f175b153b655dbb3
CONFIG_ARCH_WANTS_THP_SWAP=y
CONFIG_MM_ID=y
CONFIG_TRANSPARENT_HUGEPAGE=y
# CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS is not set
CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y
# CONFIG_TRANSPARENT_HUGEPAGE_NEVER is not set
CONFIG_THP_SWAP=y
CONFIG_READ_ONLY_THP_FOR_FS=y
# CONFIG_NO_PAGE_MAPCOUNT is not set
CONFIG_PAGE_MAPCOUNT=y
> dashboard link: https://syzkaller.appspot.com/bug?extid=5e8feb543ca8e12e0ede
> compiler: gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
>
> Unfortunately, I don't have any reproducer for this issue yet.
>
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/f1d71d1bf77d/disk-0af2f6be.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/7f1638f065da/vmlinux-0af2f6be.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/9b3e49834705/bzImage-0af2f6be.xz
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+5e8feb543ca8e12e0ede@syzkaller.appspotmail.com
>
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 7165 at mm/memory.c:3738 __wp_can_reuse_large_anon_folio mm/memory.c:3738 [inline]
VM_WARN_ON_ONCE(folio_entire_mapcount(folio));
Which is rather unexpected. I know we had a scenario (remapping a THP?)
where we would have a PMD mapping and a PTE mapping of an exclusive anon
folio for a very short time. But, IIRC locking should make sure that
that cannot be observed by some other page table walker.
Unfortunately o reproducer. I'll do some digging ...
> WARNING: CPU: 0 PID: 7165 at mm/memory.c:3738 wp_can_reuse_anon_folio mm/memory.c:3788 [inline]
> WARNING: CPU: 0 PID: 7165 at mm/memory.c:3738 do_wp_page+0x4c62/0x59f0 mm/memory.c:3918
> Modules linked in:
> CPU: 0 UID: 0 PID: 7165 Comm: syz.3.280 Not tainted 6.15.0-rc1-syzkaller #0 PREEMPT(full)
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025
> RIP: 0010:__wp_can_reuse_large_anon_folio mm/memory.c:3738 [inline]
> RIP: 0010:wp_can_reuse_anon_folio mm/memory.c:3788 [inline]
> RIP: 0010:do_wp_page+0x4c62/0x59f0 mm/memory.c:3918
> Code: 48 89 ef e8 50 c3 ea ff e9 62 b8 ff ff e8 c6 e0 b4 ff 48 c7 c6 20 43 9b 8b 4c 89 e7 e8 f7 a0 fc ff 90 0f 0b e8 af e0 b4 ff 90 <0f> 0b 90 e9 df ed ff ff e8 a1 e0 b4 ff 48 c7 c6 60 46 9b 8b 48 89
> RSP: 0018:ffffc900039f77e0 EFLAGS: 00010287
> RAX: 0000000000041ec0 RBX: ffffc900039f7a00 RCX: ffffc9000d0c6000
> RDX: 0000000000080000 RSI: ffffffff82065c61 RDI: 0000000000000005
> RBP: ffffea0001320000 R08: 0000000000000005 R09: 00000000ffffffff
> R10: 0000000000000000 R11: 0000000000000000 R12: ffff888012935dc0
> R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000001
> FS: 00007f57215806c0(0000) GS:ffff8881249b9000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 000020000001e000 CR3: 000000006cd88000 CR4: 0000000000350ef0
> Call Trace:
> <TASK>
> handle_pte_fault mm/memory.c:6013 [inline]
> __handle_mm_fault+0x1ada/0x2a40 mm/memory.c:6140
> handle_mm_fault+0x3fe/0xad0 mm/memory.c:6309
> faultin_page mm/gup.c:1193 [inline]
> __get_user_pages+0x771/0x36f0 mm/gup.c:1491
> populate_vma_page_range+0x278/0x3a0 mm/gup.c:1929
> __mm_populate+0x1d8/0x380 mm/gup.c:2032
> do_mlock+0x448/0x810 mm/mlock.c:655
During do_mlock() we should be holding the mmap lock in write mode I
assume once we reach do_wp_page.
--
Cheers,
David / dhildenb
next prev parent reply other threads:[~2025-04-13 20:20 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-12 18:46 [syzbot] [mm?] WARNING in do_wp_page syzbot
2025-04-13 20:20 ` David Hildenbrand [this message]
2025-04-13 20:45 ` David Hildenbrand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ec2c31e4-f7f2-4ec0-bbfe-e6d6e080429f@redhat.com \
--to=david@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=syzbot+5e8feb543ca8e12e0ede@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.