All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hugh Dickins <hughd@google.com>
To: David Hildenbrand <david@redhat.com>
Cc: Dmitry Vyukov <dvyukov@google.com>,
	 syzbot <syzbot+273b547b15eb58ea35e8@syzkaller.appspotmail.com>,
	 akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
	 linux-mm@kvack.org, syzkaller-bugs@googlegroups.com,
	 Mel Gorman <mgorman@techsingularity.net>,
	Hugh Dickins <hughd@google.com>
Subject: Re: [syzbot] WARNING in __split_huge_page_tail
Date: Wed, 26 Oct 2022 09:17:53 -0700 (PDT)	[thread overview]
Message-ID: <cc37ae88-e526-2bec-d727-a748f6bd69ec@google.com> (raw)
In-Reply-To: <c17502a0-2e43-bf34-239b-1e9b0bde46db@redhat.com>

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@redhat.com> 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@syzkaller.appspotmail.com
> >>>
> >>>    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@google.com>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: <stable@vger.kernel.org>
---
 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


  reply	other threads:[~2022-10-26 16:18 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-26  6:59 [syzbot] WARNING in __split_huge_page_tail syzbot
2022-10-26  9:54 ` David Hildenbrand
2022-10-26 13:25   ` Dmitry Vyukov
2022-10-26 14:46     ` David Hildenbrand
2022-10-26 16:17       ` Hugh Dickins [this message]
2022-11-13 16:44         ` Dmitry Vyukov

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=cc37ae88-e526-2bec-d727-a748f6bd69ec@google.com \
    --to=hughd@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=david@redhat.com \
    --cc=dvyukov@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=syzbot+273b547b15eb58ea35e8@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.