Re: [syzbot] kernel BUG in free_huge_page

[Mike Kravetz]

On 01/24/23 22:00, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    691781f561e9 Add linux-next specific files for 20230123
> git tree:       linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=1393d0ac480000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=804cddf7ddbc6c64
> dashboard link: https://syzkaller.appspot.com/bug?extid=83cc82a0254bc0c17b52
> compiler:       gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
<snip>
> ------------[ cut here ]------------
> kernel BUG at mm/hugetlb.c:1865!
> invalid opcode: 0000 [#1] PREEMPT SMP KASAN
> CPU: 1 PID: 8927 Comm: syz-executor.5 Not tainted 6.2.0-rc5-next-20230123-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023
> RIP: 0010:free_huge_page+0xa5b/0xe80 mm/hugetlb.c:1865
> Code: 0f 0b e8 08 98 b7 ff 4c 89 e7 e8 00 3e f7 ff 89 c3 e9 a0 f9 ff ff e8 f4 97 b7 ff 48 c7 c6 a0 6f 59 8a 4c 89 e7 e8 55 8b ef ff <0f> 0b e8 de 97 b7 ff 48 8d 7b 17 48 b8 00 00 00 00 00 fc ff df 4c
> RSP: 0018:ffffc9000557f908 EFLAGS: 00010246
> RAX: 0000000000040000 RBX: 0000000000000001 RCX: ffffc900062ea000
> RDX: 0000000000040000 RSI: ffffffff81ca564b RDI: 0000000000000000
> RBP: ffffffff91c45bf8 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000001 R11: 1ffffffff21798de R12: ffffea0002580000
> R13: ffffea0002580090 R14: 0000000000000000 R15: ffffea0002580034
> FS:  00007f42bf3be700(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007f2349dabf84 CR3: 0000000021513000 CR4: 00000000003506e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
>  <TASK>
>  __folio_put_large mm/swap.c:119 [inline]
>  __folio_put+0x109/0x140 mm/swap.c:127
>  folio_put include/linux/mm.h:1203 [inline]
>  put_page+0x21b/0x280 include/linux/mm.h:1272
>  hugetlb_fault+0x153e/0x23f0 mm/hugetlb.c:6130
>  follow_hugetlb_page+0x6ab/0x1e40 mm/hugetlb.c:6524
>  __get_user_pages+0x29b/0xfc0 mm/gup.c:1125
>  populate_vma_page_range+0x241/0x320 mm/gup.c:1526
>  __mm_populate+0x105/0x3b0 mm/gup.c:1640
>  do_mlock+0x370/0x6d0 mm/mlock.c:608
>  __do_sys_mlock mm/mlock.c:616 [inline]
>  __se_sys_mlock mm/mlock.c:614 [inline]
>  __x64_sys_mlock+0x59/0x80 mm/mlock.c:614
>  do_syscall_x64 arch/x86/entry/common.c:50 [inline]
>  do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
>  entry_SYSCALL_64_after_hwframe+0x63/0xcd
> RIP: 0033:0x7f42be68c0c9

I believe this has the same root cause as the problem reported here:

https://lore.kernel.org/linux-mm/20230124162346.404985e8@thinkpad/

With the code segment,
[...]
>  	page = pte_page(entry);
> -	if (page != pagecache_page)
> +	if (page_folio(page) != pagecache_folio)
>  		if (!trylock_page(page)) {
>  			need_wait_lock = 1;
>  			goto out_ptl;
>  		}
>  
> -	get_page(page);
> +	folio_get(pagecache_folio);
>  

In Gerald's case, pagecache_folio == NULL.

In addition, note that page_folio(page) and pagecache_folio can refer to
two different folios.  We already have a ref on pagecache_folio from previous
code 'pagecache_folio = filemap_lock_folio()'.  The above would incorrectly
get another ref on pagecache_folio instead of page.  So, page would be
short one ref but still mapped.  At the end of hugetlb_fault(), we will
do a put_page(page) and since we did not take a ref on the page, the ref
count will drop to zero and we end up calling free_huge_page while the page
is still mapped. That triggers the BUG. :(

This looks to be fixed in v2 of the patch.
-- 
Mike Kravetz