From: David Hildenbrand <david@redhat.com>
To: Muchun Song <muchun.song@linux.dev>,
syzbot <syzbot+3b9148f91b7869120e81@syzkaller.appspotmail.com>,
Oscar Salvador <osalvador@suse.de>,
Matthew Wilcox <willy@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>,
Linux-MM <linux-mm@kvack.org>,
syzkaller-bugs@googlegroups.com
Subject: Re: [syzbot] [mm?] kernel BUG in const_folio_flags
Date: Thu, 21 Mar 2024 10:58:01 +0100 [thread overview]
Message-ID: <989d5e03-d18e-4fbf-8b55-a847a928c8fd@redhat.com> (raw)
In-Reply-To: <812E97E8-668F-414D-9480-1D284834A034@linux.dev>
On 21.03.24 10:49, Muchun Song wrote:
>
>
>> On Mar 21, 2024, at 12:04, syzbot <syzbot+3b9148f91b7869120e81@syzkaller.appspotmail.com> wrote:
>>
>> Hello,
>>
>> syzbot found the following issue on:
>>
>> HEAD commit: 78c3925c048c Merge tag 'soc-late-6.9' of git://git.kernel...
>> git tree: upstream
>> console output: https://syzkaller.appspot.com/x/log.txt?x=1267d879180000
>> kernel config: https://syzkaller.appspot.com/x/.config?x=f3c2635ded15fbc9
>> dashboard link: https://syzkaller.appspot.com/bug?extid=3b9148f91b7869120e81
>> compiler: gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
>> userspace arch: i386
>>
>> Unfortunately, I don't have any reproducer for this issue yet.
>>
>> Downloadable assets:
>> disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/7bc7510fe41f/non_bootable_disk-78c3925c.raw.xz
>> vmlinux: https://storage.googleapis.com/syzbot-assets/cf2bceeccde3/vmlinux-78c3925c.xz
>> kernel image: https://storage.googleapis.com/syzbot-assets/fc938dfaea6d/bzImage-78c3925c.xz
>>
>> IMPORTANT: if you fix the issue, please add the following tag to the commit:
>> Reported-by: syzbot+3b9148f91b7869120e81@syzkaller.appspotmail.com
>>
>> veth_newlink+0x627/0xa10 drivers/net/veth.c:1895
>> rtnl_newlink_create net/core/rtnetlink.c:3494 [inline]
>> __rtnl_newlink+0x119c/0x1960 net/core/rtnetlink.c:3714
>> rtnl_newlink+0x67/0xa0 net/core/rtnetlink.c:3727
>> rtnetlink_rcv_msg+0x3c7/0xe60 net/core/rtnetlink.c:6595
>> ------------[ cut here ]------------
>> kernel BUG at include/linux/page-flags.h:315!
>
> There are some more page dumping information from console:
>
> [ 61.367144][ T42] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff888028132880 pfn:0x28130
> [ 61.371430][ T42] flags: 0xfff80000000000(node=0|zone=1|lastcpupid=0xfff)
> [ 61.374455][ T42] page_type: 0xffffffff()
> [ 61.376096][ T42] raw: 00fff80000000000 ffff888015ecd540 dead000000000100 0000000000000000
> [ 61.379994][ T42] raw: ffff888028132880 0000000000190000 00000000ffffffff 0000000000000000
>
> Alright, the page is freed (with a refcount of 0).
>
>> invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI
>> CPU: 1 PID: 42 Comm: kcompactd0 Not tainted 6.8.0-syzkaller-11725-g78c3925c048c #0
>> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
>> RIP: 0010:const_folio_flags+0x1bd/0x1f0 include/linux/page-flags.h:315
>
> The RIP is in const_folio_flags() (called from folio_test_hugetlb()):
>
> VM_BUG_ON_PGFLAGS(n > 0 && !test_bit(PG_head, &page->flags), page);
>
> It is reasonable to WARN because the page is freed (PG_head is not set
> in this case).
>
> The comments from folio_test_hugetlb() says "Caller should have a
> reference on the folio", so the caller of PageHuge() should grab
> a refcount before calling folio_test_hugetlb() since commit
> 9c5ccf2db04b. But it does not mean that the @page must be a HugeTLB page
> even if PageHuge(@page) returns true when the user does not hold
> a extra refcount on the @page. Seems the WARN could be acceptable, so
> should we remove this WARN? I am not sure. Cc more experts.
Isn't this the problem Willy is fixing with the upcoing
folio_test_hugetlb() changes?
We cannot always grab a folio reference on hugetlb folios: free hugetlb
folios have a refcount of 0.
--
Cheers,
David / dhildenb
next prev parent reply other threads:[~2024-03-21 9:58 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-21 4:04 syzbot
2024-03-21 9:49 ` Muchun Song
2024-03-21 9:58 ` David Hildenbrand [this message]
2024-03-21 10:20 ` Oscar Salvador
2024-03-22 3:24 ` Muchun Song
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=989d5e03-d18e-4fbf-8b55-a847a928c8fd@redhat.com \
--to=david@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=muchun.song@linux.dev \
--cc=osalvador@suse.de \
--cc=syzbot+3b9148f91b7869120e81@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
--cc=willy@infradead.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox