On Wed, 26 Oct 2022, David Hildenbrand wrote: > On 26.10.22 15:25, Dmitry Vyukov wrote: > > On Wed, 26 Oct 2022 at 02:54, David Hildenbrand <david@xxxxxxxxxx> wrote: > >> On 26.10.22 08:59, syzbot wrote: > >>> Hello, > >>> > >>> syzbot found the following issue on: > >>> > >>> HEAD commit: 4da34b7d175d Merge tag 'thermal-6.1-rc2' of > >>> git://git.kern.. > >>> git tree: upstream > >>> console+strace: https://syzkaller.appspot.com/x/log.txt?x=113bd8bc880000 > >>> kernel config: https://syzkaller.appspot.com/x/.config?x=4789759e8a6d5f57 > >>> dashboard link: > >>> https://syzkaller.appspot.com/bug?extid=273b547b15eb58ea35e8 > >>> compiler: Debian clang version > >>> 13.0.1-++20220126092033+75e33f71c2da-1~exp1~20220126212112.63, GNU ld (GNU > >>> Binutils for Debian) 2.35.2 > >>> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=161e1f62880000 > >>> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16dd4fe6880000 > >>> > >>> Downloadable assets: > >>> disk image: > >>> https://storage.googleapis.com/syzbot-assets/a61ddb36c296/disk-4da34b7d.raw.xz > >>> vmlinux: > >>> https://storage.googleapis.com/syzbot-assets/ceee41246252/vmlinux-4da34b7d.xz > >>> > >>> IMPORTANT: if you fix the issue, please add the following tag to the > >>> commit: > >>> Reported-by: syzbot+273b547b15eb58ea35e8@xxxxxxxxxxxxxxxxxxxxxxxxx > >>> > >>> tlb_finish_mmu+0xcb/0x200 mm/mmu_gather.c:363 > >>> exit_mmap+0x2b1/0x670 mm/mmap.c:3098 > >>> __mmput+0x114/0x3b0 kernel/fork.c:1185 > >>> exit_mm+0x217/0x2f0 kernel/exit.c:516 > >>> do_exit+0x5e7/0x2070 kernel/exit.c:807 > >>> do_group_exit+0x1fd/0x2b0 kernel/exit.c:950 > >>> __do_sys_exit_group kernel/exit.c:961 [inline] > >>> __se_sys_exit_group kernel/exit.c:959 [inline] > >>> __x64_sys_exit_group+0x3b/0x40 kernel/exit.c:959 > >>> do_syscall_x64 arch/x86/entry/common.c:50 [inline] > >>> do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 > >>> entry_SYSCALL_64_after_hwframe+0x63/0xcd > >>> ------------[ cut here ]------------ > >>> WARNING: CPU: 0 PID: 3908 at mm/huge_memory.c:2465 > >>> __split_huge_page_tail+0x81c/0x1080 mm/huge_memory.c:2465 > >> > >> Is this the > >> > >> VM_BUG_ON_PAGE(atomic_read(&page_tail->_mapcount) != -1, page_tail); > >> > >> assertion? > > > > Hi David, > > > > You can check the sources for that revision, but on the dashboard > > there are clickable links for all source references: > > https://syzkaller.appspot.com/bug?extid=273b547b15eb58ea35e8 > > > > In this case it points to: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/mm/huge_memory.c?id=4da34b7d175dc99b8befebd69e96546c960d526c#n2465 > > > > Ah, thanks! > > ... so > > if (!folio_test_swapcache(page_folio(head))) { > VM_WARN_ON_ONCE_PAGE(page_tail->private != 0, head); > page_tail->private = 0; > } > > I recall that there was a patch either from Hugh or Mel floating around that > might be related. Yes, it's in akpm's mm-hotfixes-unstable branch, currently at 826367c8c422 ("mm: prep_compound_tail() clear page->private") [PATCH] mm: prep_compound_tail() clear page->private Although page allocation always clears page->private in the first page or head page of an allocation, it has never made a point of clearing page->private in the tails (though 0 is often what is already there). But now commit 71e2d666ef85 ("mm/huge_memory: do not clobber swp_entry_t during THP split") issues a warning when page_tail->private is found to be non-0 (unless it's swapcache). Change that warning to dump page_tail (which also dumps head), instead of just the head: so far we have seen dead000000000122, dead000000000003, dead000000000001 or 0000000000000002 in the raw output for tail private. We could just delete the warning, but today's consensus appears to want page->private to be 0, unless there's a good reason for it to be set: so now clear it in prep_compound_tail() (more general than just for THP; but not for high order allocation, which makes no pass down the tails). Fixes: 71e2d666ef85 ("mm/huge_memory: do not clobber swp_entry_t during THP split") Signed-off-by: Hugh Dickins <hughd@xxxxxxxxxx> Cc: Mel Gorman <mgorman@xxxxxxxxxxxxxxxxxxx> Cc: Matthew Wilcox (Oracle) <willy@xxxxxxxxxxxxx> Cc: <stable@xxxxxxxxxxxxxxx> --- mm/huge_memory.c | 2 +- mm/page_alloc.c | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/mm/huge_memory.c b/mm/huge_memory.c index 03fc7e5edf07..561a42567477 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -2462,7 +2462,7 @@ static void __split_huge_page_tail(struct page *head, int tail, * Fix up and warn once if private is unexpectedly set. */ if (!folio_test_swapcache(page_folio(head))) { - VM_WARN_ON_ONCE_PAGE(page_tail->private != 0, head); + VM_WARN_ON_ONCE_PAGE(page_tail->private != 0, page_tail); page_tail->private = 0; } diff --git a/mm/page_alloc.c b/mm/page_alloc.c index b5a6c815ae28..218b28ee49ed 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -807,6 +807,7 @@ static void prep_compound_tail(struct page *head, int tail_idx) p->mapping = TAIL_MAPPING; set_compound_head(p, head); + set_page_private(p, 0); } void prep_compound_page(struct page *page, unsigned int order) -- 2.35.3
