On Wed, 26 Oct 2022 at 18:18, Hugh Dickins <hughd@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") Let's tell syzbot about the fix so that it reports similar bugs in future: #syz fix: 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
