[syzbot] memory leak in xas_create

[syzbot] memory leak in xas_create

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    c1084b6c5620 Merge tag 'soc-fixes-5.19-2' of git://git.ker..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=14967ccc080000
kernel config:  https://syzkaller.appspot.com/x/.config?x=916233b7694a38ff
dashboard link: https://syzkaller.appspot.com/bug?extid=a785d07959bc94837d51
compiler:       gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=122ae834080000

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+a785d07959bc94837d51@syzkaller.appspotmail.com

2022/07/05 05:22:17 executed programs: 828
2022/07/05 05:22:23 executed programs: 846
2022/07/05 05:22:30 executed programs: 866
2022/07/05 05:22:37 executed programs: 875
BUG: memory leak
unreferenced object 0xffff888113662480 (size 576):
  comm "khugepaged", pid 32, jiffies 4295002751 (age 22.940s)
  hex dump (first 32 bytes):
    06 15 08 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    58 08 46 1d 81 88 ff ff 98 24 66 13 81 88 ff ff  X.F......$f.....
  backtrace:
    [<ffffffff824aa006>] xas_alloc+0xf6/0x120 lib/xarray.c:377
    [<ffffffff824acc55>] xas_create+0x395/0x820 lib/xarray.c:679
    [<ffffffff824ad180>] xas_create_range+0xa0/0x1c0 lib/xarray.c:719
    [<ffffffff815957f3>] collapse_file+0x283/0x2870 mm/khugepaged.c:1670
    [<ffffffff8159b52c>] khugepaged_scan_file mm/khugepaged.c:2072 [inline]
    [<ffffffff8159b52c>] khugepaged_scan_mm_slot mm/khugepaged.c:2167 [inline]
    [<ffffffff8159b52c>] khugepaged_do_scan mm/khugepaged.c:2251 [inline]
    [<ffffffff8159b52c>] khugepaged+0x227c/0x43a0 mm/khugepaged.c:2296
    [<ffffffff8127b8b5>] kthread+0x125/0x160 kernel/kthread.c:376
    [<ffffffff8100222f>] ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302

BUG: memory leak
unreferenced object 0xffff8881136e2900 (size 576):
  comm "khugepaged", pid 32, jiffies 4295002751 (age 22.940s)
  hex dump (first 32 bytes):
    00 07 00 00 00 00 00 00 80 24 66 13 81 88 ff ff  .........$f.....
    58 08 46 1d 81 88 ff ff 18 29 6e 13 81 88 ff ff  X.F......)n.....
  backtrace:
    [<ffffffff824aa006>] xas_alloc+0xf6/0x120 lib/xarray.c:377
    [<ffffffff824acc55>] xas_create+0x395/0x820 lib/xarray.c:679
    [<ffffffff824ad180>] xas_create_range+0xa0/0x1c0 lib/xarray.c:719
    [<ffffffff815957f3>] collapse_file+0x283/0x2870 mm/khugepaged.c:1670
    [<ffffffff8159b52c>] khugepaged_scan_file mm/khugepaged.c:2072 [inline]
    [<ffffffff8159b52c>] khugepaged_scan_mm_slot mm/khugepaged.c:2167 [inline]
    [<ffffffff8159b52c>] khugepaged_do_scan mm/khugepaged.c:2251 [inline]
    [<ffffffff8159b52c>] khugepaged+0x227c/0x43a0 mm/khugepaged.c:2296
    [<ffffffff8127b8b5>] kthread+0x125/0x160 kernel/kthread.c:376
    [<ffffffff8100222f>] ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302

BUG: memory leak
unreferenced object 0xffff8881136e0480 (size 576):
  comm "khugepaged", pid 32, jiffies 4295002751 (age 22.940s)
  hex dump (first 32 bytes):
    00 06 00 00 00 00 00 00 80 24 66 13 81 88 ff ff  .........$f.....
    58 08 46 1d 81 88 ff ff 98 04 6e 13 81 88 ff ff  X.F.......n.....
  backtrace:
    [<ffffffff824aa006>] xas_alloc+0xf6/0x120 lib/xarray.c:377
    [<ffffffff824acc55>] xas_create+0x395/0x820 lib/xarray.c:679
    [<ffffffff824ad180>] xas_create_range+0xa0/0x1c0 lib/xarray.c:719
    [<ffffffff815957f3>] collapse_file+0x283/0x2870 mm/khugepaged.c:1670
    [<ffffffff8159b52c>] khugepaged_scan_file mm/khugepaged.c:2072 [inline]
    [<ffffffff8159b52c>] khugepaged_scan_mm_slot mm/khugepaged.c:2167 [inline]
    [<ffffffff8159b52c>] khugepaged_do_scan mm/khugepaged.c:2251 [inline]
    [<ffffffff8159b52c>] khugepaged+0x227c/0x43a0 mm/khugepaged.c:2296
    [<ffffffff8127b8b5>] kthread+0x125/0x160 kernel/kthread.c:376
    [<ffffffff8100222f>] ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302

BUG: memory leak
unreferenced object 0xffff8881136de900 (size 576):
  comm "khugepaged", pid 32, jiffies 4295002751 (age 22.940s)
  hex dump (first 32 bytes):
    00 05 00 00 00 00 00 00 80 24 66 13 81 88 ff ff  .........$f.....
    58 08 46 1d 81 88 ff ff 18 e9 6d 13 81 88 ff ff  X.F.......m.....
  backtrace:
    [<ffffffff824aa006>] xas_alloc+0xf6/0x120 lib/xarray.c:377
    [<ffffffff824acc55>] xas_create+0x395/0x820 lib/xarray.c:679
    [<ffffffff824ad180>] xas_create_range+0xa0/0x1c0 lib/xarray.c:719
    [<ffffffff815957f3>] collapse_file+0x283/0x2870 mm/khugepaged.c:1670
    [<ffffffff8159b52c>] khugepaged_scan_file mm/khugepaged.c:2072 [inline]
    [<ffffffff8159b52c>] khugepaged_scan_mm_slot mm/khugepaged.c:2167 [inline]
    [<ffffffff8159b52c>] khugepaged_do_scan mm/khugepaged.c:2251 [inline]
    [<ffffffff8159b52c>] khugepaged+0x227c/0x43a0 mm/khugepaged.c:2296
    [<ffffffff8127b8b5>] kthread+0x125/0x160 kernel/kthread.c:376
    [<ffffffff8100222f>] ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302

BUG: memory leak
unreferenced object 0xffff88811371b6c0 (size 576):
  comm "khugepaged", pid 32, jiffies 4295002751 (age 22.940s)
  hex dump (first 32 bytes):
    00 04 00 00 00 00 00 00 80 24 66 13 81 88 ff ff  .........$f.....
    58 08 46 1d 81 88 ff ff d8 b6 71 13 81 88 ff ff  X.F.......q.....
  backtrace:
    [<ffffffff824aa006>] xas_alloc+0xf6/0x120 lib/xarray.c:377
    [<ffffffff824acc55>] xas_create+0x395/0x820 lib/xarray.c:679
    [<ffffffff824ad180>] xas_create_range+0xa0/0x1c0 lib/xarray.c:719
    [<ffffffff815957f3>] collapse_file+0x283/0x2870 mm/khugepaged.c:1670
    [<ffffffff8159b52c>] khugepaged_scan_file mm/khugepaged.c:2072 [inline]
    [<ffffffff8159b52c>] khugepaged_scan_mm_slot mm/khugepaged.c:2167 [inline]
    [<ffffffff8159b52c>] khugepaged_do_scan mm/khugepaged.c:2251 [inline]
    [<ffffffff8159b52c>] khugepaged+0x227c/0x43a0 mm/khugepaged.c:2296
    [<ffffffff8127b8b5>] kthread+0x125/0x160 kernel/kthread.c:376
    [<ffffffff8100222f>] ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302

BUG: memory leak
unreferenced object 0xffff888113666d80 (size 576):
  comm "khugepaged", pid 32, jiffies 4295002751 (age 22.940s)
  hex dump (first 32 bytes):
    00 03 00 00 00 00 00 00 80 24 66 13 81 88 ff ff  .........$f.....
    58 08 46 1d 81 88 ff ff 98 6d 66 13 81 88 ff ff  X.F......mf.....
  backtrace:
    [<ffffffff824aa006>] xas_alloc+0xf6/0x120 lib/xarray.c:377
    [<ffffffff824acc55>] xas_create+0x395/0x820 lib/xarray.c:679
    [<ffffffff824ad180>] xas_create_range+0xa0/0x1c0 lib/xarray.c:719
    [<ffffffff815957f3>] collapse_file+0x283/0x2870 mm/khugepaged.c:1670
    [<ffffffff8159b52c>] khugepaged_scan_file mm/khugepaged.c:2072 [inline]
    [<ffffffff8159b52c>] khugepaged_scan_mm_slot mm/khugepaged.c:2167 [inline]
    [<ffffffff8159b52c>] khugepaged_do_scan mm/khugepaged.c:2251 [inline]
    [<ffffffff8159b52c>] khugepaged+0x227c/0x43a0 mm/khugepaged.c:2296
    [<ffffffff8127b8b5>] kthread+0x125/0x160 kernel/kthread.c:376
    [<ffffffff8100222f>] ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302



---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches

Re: [syzbot] memory leak in xas_create

[Andrew Morton]

On Sat, 09 Jul 2022 00:13:23 -0700 syzbot <syzbot+a785d07959bc94837d51@syzkaller.appspotmail.com> wrote:

> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    c1084b6c5620 Merge tag 'soc-fixes-5.19-2' of git://git.ker..
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=14967ccc080000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=916233b7694a38ff
> dashboard link: https://syzkaller.appspot.com/bug?extid=a785d07959bc94837d51
> compiler:       gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=122ae834080000
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+a785d07959bc94837d51@syzkaller.appspotmail.com
> 
> 2022/07/05 05:22:17 executed programs: 828
> 2022/07/05 05:22:23 executed programs: 846
> 2022/07/05 05:22:30 executed programs: 866
> 2022/07/05 05:22:37 executed programs: 875
> BUG: memory leak

Thanks.  Presumably due to khugepaged changes.

Can we expect a bisection search?

> unreferenced object 0xffff888113662480 (size 576):
>   comm "khugepaged", pid 32, jiffies 4295002751 (age 22.940s)
>   hex dump (first 32 bytes):
>     06 15 08 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>     58 08 46 1d 81 88 ff ff 98 24 66 13 81 88 ff ff  X.F......$f.....
>   backtrace:
>     [<ffffffff824aa006>] xas_alloc+0xf6/0x120 lib/xarray.c:377
>     [<ffffffff824acc55>] xas_create+0x395/0x820 lib/xarray.c:679
>     [<ffffffff824ad180>] xas_create_range+0xa0/0x1c0 lib/xarray.c:719
>     [<ffffffff815957f3>] collapse_file+0x283/0x2870 mm/khugepaged.c:1670
>     [<ffffffff8159b52c>] khugepaged_scan_file mm/khugepaged.c:2072 [inline]
>     [<ffffffff8159b52c>] khugepaged_scan_mm_slot mm/khugepaged.c:2167 [inline]
>     [<ffffffff8159b52c>] khugepaged_do_scan mm/khugepaged.c:2251 [inline]
>     [<ffffffff8159b52c>] khugepaged+0x227c/0x43a0 mm/khugepaged.c:2296
>     [<ffffffff8127b8b5>] kthread+0x125/0x160 kernel/kthread.c:376
>     [<ffffffff8100222f>] ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302
> 
> BUG: memory leak
> unreferenced object 0xffff8881136e2900 (size 576):
>   comm "khugepaged", pid 32, jiffies 4295002751 (age 22.940s)
>   hex dump (first 32 bytes):
>     00 07 00 00 00 00 00 00 80 24 66 13 81 88 ff ff  .........$f.....
>     58 08 46 1d 81 88 ff ff 18 29 6e 13 81 88 ff ff  X.F......)n.....
>   backtrace:
>     [<ffffffff824aa006>] xas_alloc+0xf6/0x120 lib/xarray.c:377
>     [<ffffffff824acc55>] xas_create+0x395/0x820 lib/xarray.c:679
>     [<ffffffff824ad180>] xas_create_range+0xa0/0x1c0 lib/xarray.c:719
>     [<ffffffff815957f3>] collapse_file+0x283/0x2870 mm/khugepaged.c:1670
>     [<ffffffff8159b52c>] khugepaged_scan_file mm/khugepaged.c:2072 [inline]
>     [<ffffffff8159b52c>] khugepaged_scan_mm_slot mm/khugepaged.c:2167 [inline]
>     [<ffffffff8159b52c>] khugepaged_do_scan mm/khugepaged.c:2251 [inline]
>     [<ffffffff8159b52c>] khugepaged+0x227c/0x43a0 mm/khugepaged.c:2296
>     [<ffffffff8127b8b5>] kthread+0x125/0x160 kernel/kthread.c:376
>     [<ffffffff8100222f>] ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302
> 
> BUG: memory leak
> unreferenced object 0xffff8881136e0480 (size 576):
>   comm "khugepaged", pid 32, jiffies 4295002751 (age 22.940s)
>   hex dump (first 32 bytes):
>     00 06 00 00 00 00 00 00 80 24 66 13 81 88 ff ff  .........$f.....
>     58 08 46 1d 81 88 ff ff 98 04 6e 13 81 88 ff ff  X.F.......n.....
>   backtrace:
>     [<ffffffff824aa006>] xas_alloc+0xf6/0x120 lib/xarray.c:377
>     [<ffffffff824acc55>] xas_create+0x395/0x820 lib/xarray.c:679
>     [<ffffffff824ad180>] xas_create_range+0xa0/0x1c0 lib/xarray.c:719
>     [<ffffffff815957f3>] collapse_file+0x283/0x2870 mm/khugepaged.c:1670
>     [<ffffffff8159b52c>] khugepaged_scan_file mm/khugepaged.c:2072 [inline]
>     [<ffffffff8159b52c>] khugepaged_scan_mm_slot mm/khugepaged.c:2167 [inline]
>     [<ffffffff8159b52c>] khugepaged_do_scan mm/khugepaged.c:2251 [inline]
>     [<ffffffff8159b52c>] khugepaged+0x227c/0x43a0 mm/khugepaged.c:2296
>     [<ffffffff8127b8b5>] kthread+0x125/0x160 kernel/kthread.c:376
>     [<ffffffff8100222f>] ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302
> 
> BUG: memory leak
> unreferenced object 0xffff8881136de900 (size 576):
>   comm "khugepaged", pid 32, jiffies 4295002751 (age 22.940s)
>   hex dump (first 32 bytes):
>     00 05 00 00 00 00 00 00 80 24 66 13 81 88 ff ff  .........$f.....
>     58 08 46 1d 81 88 ff ff 18 e9 6d 13 81 88 ff ff  X.F.......m.....
>   backtrace:
>     [<ffffffff824aa006>] xas_alloc+0xf6/0x120 lib/xarray.c:377
>     [<ffffffff824acc55>] xas_create+0x395/0x820 lib/xarray.c:679
>     [<ffffffff824ad180>] xas_create_range+0xa0/0x1c0 lib/xarray.c:719
>     [<ffffffff815957f3>] collapse_file+0x283/0x2870 mm/khugepaged.c:1670
>     [<ffffffff8159b52c>] khugepaged_scan_file mm/khugepaged.c:2072 [inline]
>     [<ffffffff8159b52c>] khugepaged_scan_mm_slot mm/khugepaged.c:2167 [inline]
>     [<ffffffff8159b52c>] khugepaged_do_scan mm/khugepaged.c:2251 [inline]
>     [<ffffffff8159b52c>] khugepaged+0x227c/0x43a0 mm/khugepaged.c:2296
>     [<ffffffff8127b8b5>] kthread+0x125/0x160 kernel/kthread.c:376
>     [<ffffffff8100222f>] ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302
> 
> BUG: memory leak
> unreferenced object 0xffff88811371b6c0 (size 576):
>   comm "khugepaged", pid 32, jiffies 4295002751 (age 22.940s)
>   hex dump (first 32 bytes):
>     00 04 00 00 00 00 00 00 80 24 66 13 81 88 ff ff  .........$f.....
>     58 08 46 1d 81 88 ff ff d8 b6 71 13 81 88 ff ff  X.F.......q.....
>   backtrace:
>     [<ffffffff824aa006>] xas_alloc+0xf6/0x120 lib/xarray.c:377
>     [<ffffffff824acc55>] xas_create+0x395/0x820 lib/xarray.c:679
>     [<ffffffff824ad180>] xas_create_range+0xa0/0x1c0 lib/xarray.c:719
>     [<ffffffff815957f3>] collapse_file+0x283/0x2870 mm/khugepaged.c:1670
>     [<ffffffff8159b52c>] khugepaged_scan_file mm/khugepaged.c:2072 [inline]
>     [<ffffffff8159b52c>] khugepaged_scan_mm_slot mm/khugepaged.c:2167 [inline]
>     [<ffffffff8159b52c>] khugepaged_do_scan mm/khugepaged.c:2251 [inline]
>     [<ffffffff8159b52c>] khugepaged+0x227c/0x43a0 mm/khugepaged.c:2296
>     [<ffffffff8127b8b5>] kthread+0x125/0x160 kernel/kthread.c:376
>     [<ffffffff8100222f>] ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302
> 
> BUG: memory leak
> unreferenced object 0xffff888113666d80 (size 576):
>   comm "khugepaged", pid 32, jiffies 4295002751 (age 22.940s)
>   hex dump (first 32 bytes):
>     00 03 00 00 00 00 00 00 80 24 66 13 81 88 ff ff  .........$f.....
>     58 08 46 1d 81 88 ff ff 98 6d 66 13 81 88 ff ff  X.F......mf.....
>   backtrace:
>     [<ffffffff824aa006>] xas_alloc+0xf6/0x120 lib/xarray.c:377
>     [<ffffffff824acc55>] xas_create+0x395/0x820 lib/xarray.c:679
>     [<ffffffff824ad180>] xas_create_range+0xa0/0x1c0 lib/xarray.c:719
>     [<ffffffff815957f3>] collapse_file+0x283/0x2870 mm/khugepaged.c:1670
>     [<ffffffff8159b52c>] khugepaged_scan_file mm/khugepaged.c:2072 [inline]
>     [<ffffffff8159b52c>] khugepaged_scan_mm_slot mm/khugepaged.c:2167 [inline]
>     [<ffffffff8159b52c>] khugepaged_do_scan mm/khugepaged.c:2251 [inline]
>     [<ffffffff8159b52c>] khugepaged+0x227c/0x43a0 mm/khugepaged.c:2296
>     [<ffffffff8127b8b5>] kthread+0x125/0x160 kernel/kthread.c:376
>     [<ffffffff8100222f>] ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302
> 
> 
> 
> ---
> This report is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
> 
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> syzbot can test patches for this issue, for details see:
> https://goo.gl/tpsmEJ#testing-patches

Re: [syzbot] memory leak in xas_create

[Matthew Wilcox]

On Mon, Jul 11, 2022 at 01:38:08PM -0700, Andrew Morton wrote:
> On Sat, 09 Jul 2022 00:13:23 -0700 syzbot <syzbot+a785d07959bc94837d51@syzkaller.appspotmail.com> wrote:
> 
> > Hello,
> > 
> > syzbot found the following issue on:
> > 
> > HEAD commit:    c1084b6c5620 Merge tag 'soc-fixes-5.19-2' of git://git.ker..
> > git tree:       upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=14967ccc080000
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=916233b7694a38ff
> > dashboard link: https://syzkaller.appspot.com/bug?extid=a785d07959bc94837d51
> > compiler:       gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
> > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=122ae834080000
> > 
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+a785d07959bc94837d51@syzkaller.appspotmail.com
> > 
> > 2022/07/05 05:22:17 executed programs: 828
> > 2022/07/05 05:22:23 executed programs: 846
> > 2022/07/05 05:22:30 executed programs: 866
> > 2022/07/05 05:22:37 executed programs: 875
> > BUG: memory leak
> 
> Thanks.  Presumably due to khugepaged changes.

Huh, I was expecting it to be something I'd messed up.  I've been
looking at it today, but no luck figuring it out so far.

> Can we expect a bisection search?

We only have a syz reproducer so far, and if I understand correctly,
it's probably because this is a flaky test (because it's trying to
find something that's a race condition).

I expect a bisection search to go badly wrong if this is true.

Re: [syzbot] memory leak in xas_create

[Dmitry Vyukov]

On Mon, 11 Jul 2022 at 22:47, Matthew Wilcox <willy@infradead.org> wrote:
>
> On Mon, Jul 11, 2022 at 01:38:08PM -0700, Andrew Morton wrote:
> > On Sat, 09 Jul 2022 00:13:23 -0700 syzbot <syzbot+a785d07959bc94837d51@syzkaller.appspotmail.com> wrote:
> >
> > > Hello,
> > >
> > > syzbot found the following issue on:
> > >
> > > HEAD commit:    c1084b6c5620 Merge tag 'soc-fixes-5.19-2' of git://git.ker..
> > > git tree:       upstream
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=14967ccc080000
> > > kernel config:  https://syzkaller.appspot.com/x/.config?x=916233b7694a38ff
> > > dashboard link: https://syzkaller.appspot.com/bug?extid=a785d07959bc94837d51
> > > compiler:       gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
> > > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=122ae834080000
> > >
> > > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > > Reported-by: syzbot+a785d07959bc94837d51@syzkaller.appspotmail.com
> > >
> > > 2022/07/05 05:22:17 executed programs: 828
> > > 2022/07/05 05:22:23 executed programs: 846
> > > 2022/07/05 05:22:30 executed programs: 866
> > > 2022/07/05 05:22:37 executed programs: 875
> > > BUG: memory leak
> >
> > Thanks.  Presumably due to khugepaged changes.
>
> Huh, I was expecting it to be something I'd messed up.  I've been
> looking at it today, but no luck figuring it out so far.
>
> > Can we expect a bisection search?
>
> We only have a syz reproducer so far, and if I understand correctly,
> it's probably because this is a flaky test (because it's trying to
> find something that's a race condition).
>
> I expect a bisection search to go badly wrong if this is true.

Is it possible that parts of xas are not freed on the error paths?
I don't immediately see where anything is freed on these error paths:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/lib/xarray.c?id=c1084b6c5620a743f86947caca66d90f24060f56#n681
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/lib/xarray.c?id=c1084b6c5620a743f86947caca66d90f24060f56#n721
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/mm/khugepaged.c?id=c1084b6c5620a743f86947caca66d90f24060f56#n1675

Re: [syzbot] memory leak in xas_create

[Matthew Wilcox]

On Tue, Jul 12, 2022 at 08:54:28AM +0200, Dmitry Vyukov wrote:
> On Mon, 11 Jul 2022 at 22:47, Matthew Wilcox <willy@infradead.org> wrote:
> >
> > On Mon, Jul 11, 2022 at 01:38:08PM -0700, Andrew Morton wrote:
> > > On Sat, 09 Jul 2022 00:13:23 -0700 syzbot <syzbot+a785d07959bc94837d51@syzkaller.appspotmail.com> wrote:
> > >
> > > > Hello,
> > > >
> > > > syzbot found the following issue on:
> > > >
> > > > HEAD commit:    c1084b6c5620 Merge tag 'soc-fixes-5.19-2' of git://git.ker..
> > > > git tree:       upstream
> > > > console output: https://syzkaller.appspot.com/x/log.txt?x=14967ccc080000
> > > > kernel config:  https://syzkaller.appspot.com/x/.config?x=916233b7694a38ff
> > > > dashboard link: https://syzkaller.appspot.com/bug?extid=a785d07959bc94837d51
> > > > compiler:       gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
> > > > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=122ae834080000
> > > >
> > > > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > > > Reported-by: syzbot+a785d07959bc94837d51@syzkaller.appspotmail.com
> > > >
> > > > 2022/07/05 05:22:17 executed programs: 828
> > > > 2022/07/05 05:22:23 executed programs: 846
> > > > 2022/07/05 05:22:30 executed programs: 866
> > > > 2022/07/05 05:22:37 executed programs: 875
> > > > BUG: memory leak
> > >
> > > Thanks.  Presumably due to khugepaged changes.
> >
> > Huh, I was expecting it to be something I'd messed up.  I've been
> > looking at it today, but no luck figuring it out so far.
> >
> > > Can we expect a bisection search?
> >
> > We only have a syz reproducer so far, and if I understand correctly,
> > it's probably because this is a flaky test (because it's trying to
> > find something that's a race condition).
> >
> > I expect a bisection search to go badly wrong if this is true.
> 
> Is it possible that parts of xas are not freed on the error paths?
> I don't immediately see where anything is freed on these error paths:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/lib/xarray.c?id=c1084b6c5620a743f86947caca66d90f24060f56#n681
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/lib/xarray.c?id=c1084b6c5620a743f86947caca66d90f24060f56#n721
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/mm/khugepaged.c?id=c1084b6c5620a743f86947caca66d90f24060f56#n1675

There's nothing to free; if a node is allocated, then it's stored in
the tree where it can later be found and reused.

Re: [syzbot] memory leak in xas_create

[Dmitry Vyukov]

On Tue, 12 Jul 2022 at 14:40, Matthew Wilcox <willy@infradead.org> wrote:
>
> On Tue, Jul 12, 2022 at 08:54:28AM +0200, Dmitry Vyukov wrote:
> > On Mon, 11 Jul 2022 at 22:47, Matthew Wilcox <willy@infradead.org> wrote:
> > >
> > > On Mon, Jul 11, 2022 at 01:38:08PM -0700, Andrew Morton wrote:
> > > > On Sat, 09 Jul 2022 00:13:23 -0700 syzbot <syzbot+a785d07959bc94837d51@syzkaller.appspotmail.com> wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > syzbot found the following issue on:
> > > > >
> > > > > HEAD commit:    c1084b6c5620 Merge tag 'soc-fixes-5.19-2' of git://git.ker..
> > > > > git tree:       upstream
> > > > > console output: https://syzkaller.appspot.com/x/log.txt?x=14967ccc080000
> > > > > kernel config:  https://syzkaller.appspot.com/x/.config?x=916233b7694a38ff
> > > > > dashboard link: https://syzkaller.appspot.com/bug?extid=a785d07959bc94837d51
> > > > > compiler:       gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
> > > > > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=122ae834080000
> > > > >
> > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > > > > Reported-by: syzbot+a785d07959bc94837d51@syzkaller.appspotmail.com
> > > > >
> > > > > 2022/07/05 05:22:17 executed programs: 828
> > > > > 2022/07/05 05:22:23 executed programs: 846
> > > > > 2022/07/05 05:22:30 executed programs: 866
> > > > > 2022/07/05 05:22:37 executed programs: 875
> > > > > BUG: memory leak
> > > >
> > > > Thanks.  Presumably due to khugepaged changes.
> > >
> > > Huh, I was expecting it to be something I'd messed up.  I've been
> > > looking at it today, but no luck figuring it out so far.
> > >
> > > > Can we expect a bisection search?
> > >
> > > We only have a syz reproducer so far, and if I understand correctly,
> > > it's probably because this is a flaky test (because it's trying to
> > > find something that's a race condition).
> > >
> > > I expect a bisection search to go badly wrong if this is true.
> >
> > Is it possible that parts of xas are not freed on the error paths?
> > I don't immediately see where anything is freed on these error paths:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/lib/xarray.c?id=c1084b6c5620a743f86947caca66d90f24060f56#n681
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/lib/xarray.c?id=c1084b6c5620a743f86947caca66d90f24060f56#n721
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/mm/khugepaged.c?id=c1084b6c5620a743f86947caca66d90f24060f56#n1675
>
> There's nothing to free; if a node is allocated, then it's stored in
> the tree where it can later be found and reused.

What I was thinking of is:

The leaked memory is allocated with:
xas_create_range(&xas);
here:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/mm/khugepaged.c?id=c1084b6c5620a743f86947caca66d90f24060f56#n1670

So I assumed the nodes stored in the xas object, which is local to the
collapse_file() function.

So if we do "goto out" here:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/mm/khugepaged.c?id=c1084b6c5620a743f86947caca66d90f24060f56#n1676

There does not seem to be anything that frees anything stored in the xas:

out:
    VM_BUG_ON(!list_empty(&pagelist));
    if (!IS_ERR_OR_NULL(*hpage))
        mem_cgroup_uncharge(page_folio(*hpage));
    /* TODO: tracepoints */
}

Re: [syzbot] memory leak in xas_create

[Matthew Wilcox]

On Tue, Jul 12, 2022 at 02:50:50PM +0200, Dmitry Vyukov wrote:
> On Tue, 12 Jul 2022 at 14:40, Matthew Wilcox <willy@infradead.org> wrote:
> >
> > On Tue, Jul 12, 2022 at 08:54:28AM +0200, Dmitry Vyukov wrote:
> > > On Mon, 11 Jul 2022 at 22:47, Matthew Wilcox <willy@infradead.org> wrote:
> > > >
> > > > On Mon, Jul 11, 2022 at 01:38:08PM -0700, Andrew Morton wrote:
> > > > > On Sat, 09 Jul 2022 00:13:23 -0700 syzbot <syzbot+a785d07959bc94837d51@syzkaller.appspotmail.com> wrote:
> > > > >
> > > > > > Hello,
> > > > > >
> > > > > > syzbot found the following issue on:
> > > > > >
> > > > > > HEAD commit:    c1084b6c5620 Merge tag 'soc-fixes-5.19-2' of git://git.ker..
> > > > > > git tree:       upstream
> > > > > > console output: https://syzkaller.appspot.com/x/log.txt?x=14967ccc080000
> > > > > > kernel config:  https://syzkaller.appspot.com/x/.config?x=916233b7694a38ff
> > > > > > dashboard link: https://syzkaller.appspot.com/bug?extid=a785d07959bc94837d51
> > > > > > compiler:       gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
> > > > > > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=122ae834080000
> > > > > >
> > > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > > > > > Reported-by: syzbot+a785d07959bc94837d51@syzkaller.appspotmail.com
> > > > > >
> > > > > > 2022/07/05 05:22:17 executed programs: 828
> > > > > > 2022/07/05 05:22:23 executed programs: 846
> > > > > > 2022/07/05 05:22:30 executed programs: 866
> > > > > > 2022/07/05 05:22:37 executed programs: 875
> > > > > > BUG: memory leak
> > > > >
> > > > > Thanks.  Presumably due to khugepaged changes.
> > > >
> > > > Huh, I was expecting it to be something I'd messed up.  I've been
> > > > looking at it today, but no luck figuring it out so far.
> > > >
> > > > > Can we expect a bisection search?
> > > >
> > > > We only have a syz reproducer so far, and if I understand correctly,
> > > > it's probably because this is a flaky test (because it's trying to
> > > > find something that's a race condition).
> > > >
> > > > I expect a bisection search to go badly wrong if this is true.
> > >
> > > Is it possible that parts of xas are not freed on the error paths?
> > > I don't immediately see where anything is freed on these error paths:
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/lib/xarray.c?id=c1084b6c5620a743f86947caca66d90f24060f56#n681
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/lib/xarray.c?id=c1084b6c5620a743f86947caca66d90f24060f56#n721
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/mm/khugepaged.c?id=c1084b6c5620a743f86947caca66d90f24060f56#n1675
> >
> > There's nothing to free; if a node is allocated, then it's stored in
> > the tree where it can later be found and reused.
> 
> What I was thinking of is:
> 
> The leaked memory is allocated with:
> xas_create_range(&xas);
> here:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/mm/khugepaged.c?id=c1084b6c5620a743f86947caca66d90f24060f56#n1670
> 
> So I assumed the nodes stored in the xas object, which is local to the
> collapse_file() function.

Yes, that's a reasonable thing to think, but it's actually not how
it works.  When we allocate a node in xas_create(), we put it straight
into the tree without storing it in xas->xa_alloc.  We may then end
up not using it, but the node isn't leaked because it's in the tree.

If the GFP_NOWAIT allocation fails (it didn't in these stack traces),
we call xas_nomem(), which sees an -ENOMEM, allocates a node and stores
it in xas->xa_alloc; then we go round the loop again where xas_create()
will take the node from xas->xa_alloc.  But the backtraces here don't
implicate xas_nomem().

> So if we do "goto out" here:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/mm/khugepaged.c?id=c1084b6c5620a743f86947caca66d90f24060f56#n1676
> 
> There does not seem to be anything that frees anything stored in the xas:
> 
> out:
>     VM_BUG_ON(!list_empty(&pagelist));
>     if (!IS_ERR_OR_NULL(*hpage))
>         mem_cgroup_uncharge(page_folio(*hpage));
>     /* TODO: tracepoints */
> }
> 

Re: [syzbot] memory leak in xas_create

[Dmitry Vyukov]

On Tue, 12 Jul 2022 at 14:58, Matthew Wilcox <willy@infradead.org> wrote:
> > > > > > On Sat, 09 Jul 2022 00:13:23 -0700 syzbot <syzbot+a785d07959bc94837d51@syzkaller.appspotmail.com> wrote:
> > > > > >
> > > > > > > Hello,
> > > > > > >
> > > > > > > syzbot found the following issue on:
> > > > > > >
> > > > > > > HEAD commit:    c1084b6c5620 Merge tag 'soc-fixes-5.19-2' of git://git.ker..
> > > > > > > git tree:       upstream
> > > > > > > console output: https://syzkaller.appspot.com/x/log.txt?x=14967ccc080000
> > > > > > > kernel config:  https://syzkaller.appspot.com/x/.config?x=916233b7694a38ff
> > > > > > > dashboard link: https://syzkaller.appspot.com/bug?extid=a785d07959bc94837d51
> > > > > > > compiler:       gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
> > > > > > > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=122ae834080000
> > > > > > >
> > > > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > > > > > > Reported-by: syzbot+a785d07959bc94837d51@syzkaller.appspotmail.com
> > > > > > >
> > > > > > > 2022/07/05 05:22:17 executed programs: 828
> > > > > > > 2022/07/05 05:22:23 executed programs: 846
> > > > > > > 2022/07/05 05:22:30 executed programs: 866
> > > > > > > 2022/07/05 05:22:37 executed programs: 875
> > > > > > > BUG: memory leak
> > > > > >
> > > > > > Thanks.  Presumably due to khugepaged changes.
> > > > >
> > > > > Huh, I was expecting it to be something I'd messed up.  I've been
> > > > > looking at it today, but no luck figuring it out so far.
> > > > >
> > > > > > Can we expect a bisection search?
> > > > >
> > > > > We only have a syz reproducer so far, and if I understand correctly,
> > > > > it's probably because this is a flaky test (because it's trying to
> > > > > find something that's a race condition).
> > > > >
> > > > > I expect a bisection search to go badly wrong if this is true.
> > > >
> > > > Is it possible that parts of xas are not freed on the error paths?
> > > > I don't immediately see where anything is freed on these error paths:
> > > >
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/lib/xarray.c?id=c1084b6c5620a743f86947caca66d90f24060f56#n681
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/lib/xarray.c?id=c1084b6c5620a743f86947caca66d90f24060f56#n721
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/mm/khugepaged.c?id=c1084b6c5620a743f86947caca66d90f24060f56#n1675
> > >
> > > There's nothing to free; if a node is allocated, then it's stored in
> > > the tree where it can later be found and reused.
> >
> > What I was thinking of is:
> >
> > The leaked memory is allocated with:
> > xas_create_range(&xas);
> > here:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/mm/khugepaged.c?id=c1084b6c5620a743f86947caca66d90f24060f56#n1670
> >
> > So I assumed the nodes stored in the xas object, which is local to the
> > collapse_file() function.
>
> Yes, that's a reasonable thing to think, but it's actually not how
> it works.  When we allocate a node in xas_create(), we put it straight
> into the tree without storing it in xas->xa_alloc.  We may then end
> up not using it, but the node isn't leaked because it's in the tree.
>
> If the GFP_NOWAIT allocation fails (it didn't in these stack traces),
> we call xas_nomem(), which sees an -ENOMEM, allocates a node and stores
> it in xas->xa_alloc; then we go round the loop again where xas_create()
> will take the node from xas->xa_alloc.  But the backtraces here don't
> implicate xas_nomem().

I see. Thanks for the explanation.

Then I think it's still possible that this is a KMEMLEAK false
positive. IIRC it may have some false positives since it does not do
full stop-the-world before scanning memory/registers. syzkaller tries
to circumvent this by doing multiple scans with some delays, but it
does not give 100% guarantee.
And I am assuming this code does not try to hide pointers by storing
something in low/high bits, etc.


> > So if we do "goto out" here:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/mm/khugepaged.c?id=c1084b6c5620a743f86947caca66d90f24060f56#n1676
> >
> > There does not seem to be anything that frees anything stored in the xas:
> >
> > out:
> >     VM_BUG_ON(!list_empty(&pagelist));
> >     if (!IS_ERR_OR_NULL(*hpage))
> >         mem_cgroup_uncharge(page_folio(*hpage));
> >     /* TODO: tracepoints */
> > }
> >

Re: [syzbot] memory leak in xas_create

[Matthew Wilcox]

On Tue, Jul 12, 2022 at 01:57:59PM +0100, Matthew Wilcox wrote:
> > So I assumed the nodes stored in the xas object, which is local to the
> > collapse_file() function.
> 
> Yes, that's a reasonable thing to think, but it's actually not how
> it works.  When we allocate a node in xas_create(), we put it straight
> into the tree without storing it in xas->xa_alloc.  We may then end
> up not using it, but the node isn't leaked because it's in the tree.
> 
> If the GFP_NOWAIT allocation fails (it didn't in these stack traces),
> we call xas_nomem(), which sees an -ENOMEM, allocates a node and stores
> it in xas->xa_alloc; then we go round the loop again where xas_create()
> will take the node from xas->xa_alloc.  But the backtraces here don't
> implicate xas_nomem().

There is actually a leak here, but it's not the one that's been found.

        do {
                xas_lock_irq(&xas);
                xas_create_range(&xas);
                if (!xas_error(&xas))
                        break;
                xas_unlock_irq(&xas);
                if (!xas_nomem(&xas, GFP_KERNEL)) {
                        result = SCAN_FAIL;
                        goto out;
                }
        } while (1);

If xas_create() fails, it sets xas error to -ENOMEM.  So we unlock the
xarray lock and call xas_nomem().  xas_nomem() sees the error is -ENOMEM
and allocates a node with GFP_KERNEL, putting the node in xas->xa_alloc.
We re-take the spinlock and call xas_create() again.  If we still need
a node, xas_alloc() will take the node stored in xas->xa_alloc.  If we
raced and don't need a node, xas_create_range() succeeds and we break out,
failing to free the xas->xa_alloc node.

We should call xas_destroy() at the out: label.  However, this does not
explain what is going on, and will not fix what is going on, since any
nodes allocated during xas_create_range() will be stored safely in the
tree and will not be freed by xas_destroy().

Re: [syzbot] memory leak in xas_create

[Matthew Wilcox]

On Tue, Jul 12, 2022 at 03:29:29PM +0200, Dmitry Vyukov wrote:
> Then I think it's still possible that this is a KMEMLEAK false
> positive. IIRC it may have some false positives since it does not do
> full stop-the-world before scanning memory/registers. syzkaller tries
> to circumvent this by doing multiple scans with some delays, but it
> does not give 100% guarantee.
> And I am assuming this code does not try to hide pointers by storing
> something in low/high bits, etc.

Oh, I meant to answer this.  The XArray does set bit 1 of the pointer
when it's stored in the tree.  However, this shouldn't affect kmemleak
(I would think) because it looks like a pointer to the third byte of the
allocation, so the allocation is still referenced, even if the first
byte of the allocation isn't referenced.

Also, I would expect kmemleak to report bugs all over if this were the
problem, because every node no matter how it's allocated gets its bit 1
set.

Re: [syzbot] memory leak in xas_create

[syzbot]

syzbot has found a reproducer for the following issue on:

HEAD commit:    2f5065a0bc9d Merge tag 'acpi-6.1-rc4' of git://git.kernel...
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=12351e76880000
kernel config:  https://syzkaller.appspot.com/x/.config?x=7da85296f1024c6a
dashboard link: https://syzkaller.appspot.com/bug?extid=a785d07959bc94837d51
compiler:       gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=110bbf39880000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=12fff099880000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/2e34093711ff/disk-2f5065a0.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/73117023c3a9/vmlinux-2f5065a0.xz
kernel image: https://storage.googleapis.com/syzbot-assets/c708621825f8/bzImage-2f5065a0.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+a785d07959bc94837d51@syzkaller.appspotmail.com

write to /proc/sys/kernel/hung_task_check_interval_secs failed: No such file or directory
write to /proc/sys/kernel/softlockup_all_cpu_backtrace failed: No such file or directory
BUG: memory leak
unreferenced object 0xffff88810fd216c0 (size 576):
  comm "syz-executor159", pid 3686, jiffies 4295064650 (age 50.150s)
  hex dump (first 32 bytes):
    06 00 08 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    20 85 98 0f 81 88 ff ff d8 16 d2 0f 81 88 ff ff   ...............
  backtrace:
    [<ffffffff844153c6>] xas_alloc+0xf6/0x120 lib/xarray.c:377
    [<ffffffff84418039>] xas_create+0x3b9/0x800 lib/xarray.c:679
    [<ffffffff84418520>] xas_create_range+0xa0/0x1c0 lib/xarray.c:719
    [<ffffffff8159f11c>] collapse_file+0x13c/0x2730 mm/khugepaged.c:1725
    [<ffffffff815a1b28>] hpage_collapse_scan_file+0x418/0x9a0 mm/khugepaged.c:2156
    [<ffffffff815a4001>] madvise_collapse+0x211/0x5e0 mm/khugepaged.c:2611
    [<ffffffff8153ba2d>] madvise_vma_behavior+0x5dd/0x1030 mm/madvise.c:1076
    [<ffffffff81537257>] madvise_walk_vmas+0x127/0x1d0 mm/madvise.c:1250
    [<ffffffff81537eb0>] do_madvise.part.0+0x1c0/0x2b0 mm/madvise.c:1429
    [<ffffffff8153c6e8>] do_madvise mm/madvise.c:1440 [inline]
    [<ffffffff8153c6e8>] __do_sys_madvise mm/madvise.c:1442 [inline]
    [<ffffffff8153c6e8>] __se_sys_madvise mm/madvise.c:1440 [inline]
    [<ffffffff8153c6e8>] __x64_sys_madvise+0x98/0xa0 mm/madvise.c:1440
    [<ffffffff84608225>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
    [<ffffffff84608225>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
    [<ffffffff84800087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd

BUG: memory leak
unreferenced object 0xffff88810fd21480 (size 576):
  comm "syz-executor159", pid 3686, jiffies 4295064650 (age 50.150s)
  hex dump (first 32 bytes):
    00 07 00 00 00 00 00 00 c0 16 d2 0f 81 88 ff ff  ................
    20 85 98 0f 81 88 ff ff 98 14 d2 0f 81 88 ff ff   ...............
  backtrace:
    [<ffffffff844153c6>] xas_alloc+0xf6/0x120 lib/xarray.c:377
    [<ffffffff84418039>] xas_create+0x3b9/0x800 lib/xarray.c:679
    [<ffffffff84418520>] xas_create_range+0xa0/0x1c0 lib/xarray.c:719
    [<ffffffff8159f11c>] collapse_file+0x13c/0x2730 mm/khugepaged.c:1725
    [<ffffffff815a1b28>] hpage_collapse_scan_file+0x418/0x9a0 mm/khugepaged.c:2156
    [<ffffffff815a4001>] madvise_collapse+0x211/0x5e0 mm/khugepaged.c:2611
    [<ffffffff8153ba2d>] madvise_vma_behavior+0x5dd/0x1030 mm/madvise.c:1076
    [<ffffffff81537257>] madvise_walk_vmas+0x127/0x1d0 mm/madvise.c:1250
    [<ffffffff81537eb0>] do_madvise.part.0+0x1c0/0x2b0 mm/madvise.c:1429
    [<ffffffff8153c6e8>] do_madvise mm/madvise.c:1440 [inline]
    [<ffffffff8153c6e8>] __do_sys_madvise mm/madvise.c:1442 [inline]
    [<ffffffff8153c6e8>] __se_sys_madvise mm/madvise.c:1440 [inline]
    [<ffffffff8153c6e8>] __x64_sys_madvise+0x98/0xa0 mm/madvise.c:1440
    [<ffffffff84608225>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
    [<ffffffff84608225>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
    [<ffffffff84800087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd

BUG: memory leak
unreferenced object 0xffff88810fd21240 (size 576):
  comm "syz-executor159", pid 3686, jiffies 4295064650 (age 50.150s)
  hex dump (first 32 bytes):
    00 06 00 00 00 00 00 00 c0 16 d2 0f 81 88 ff ff  ................
    20 85 98 0f 81 88 ff ff 58 12 d2 0f 81 88 ff ff   .......X.......
  backtrace:
    [<ffffffff844153c6>] xas_alloc+0xf6/0x120 lib/xarray.c:377
    [<ffffffff84418039>] xas_create+0x3b9/0x800 lib/xarray.c:679
    [<ffffffff84418520>] xas_create_range+0xa0/0x1c0 lib/xarray.c:719
    [<ffffffff8159f11c>] collapse_file+0x13c/0x2730 mm/khugepaged.c:1725
    [<ffffffff815a1b28>] hpage_collapse_scan_file+0x418/0x9a0 mm/khugepaged.c:2156
    [<ffffffff815a4001>] madvise_collapse+0x211/0x5e0 mm/khugepaged.c:2611
    [<ffffffff8153ba2d>] madvise_vma_behavior+0x5dd/0x1030 mm/madvise.c:1076
    [<ffffffff81537257>] madvise_walk_vmas+0x127/0x1d0 mm/madvise.c:1250
    [<ffffffff81537eb0>] do_madvise.part.0+0x1c0/0x2b0 mm/madvise.c:1429
    [<ffffffff8153c6e8>] do_madvise mm/madvise.c:1440 [inline]
    [<ffffffff8153c6e8>] __do_sys_madvise mm/madvise.c:1442 [inline]
    [<ffffffff8153c6e8>] __se_sys_madvise mm/madvise.c:1440 [inline]
    [<ffffffff8153c6e8>] __x64_sys_madvise+0x98/0xa0 mm/madvise.c:1440
    [<ffffffff84608225>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
    [<ffffffff84608225>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
    [<ffffffff84800087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd

BUG: memory leak
unreferenced object 0xffff88810fd24d80 (size 576):
  comm "syz-executor159", pid 3686, jiffies 4295064650 (age 50.150s)
  hex dump (first 32 bytes):
    00 05 00 00 00 00 00 00 c0 16 d2 0f 81 88 ff ff  ................
    20 85 98 0f 81 88 ff ff 98 4d d2 0f 81 88 ff ff   ........M......
  backtrace:
    [<ffffffff844153c6>] xas_alloc+0xf6/0x120 lib/xarray.c:377
    [<ffffffff84418039>] xas_create+0x3b9/0x800 lib/xarray.c:679
    [<ffffffff84418520>] xas_create_range+0xa0/0x1c0 lib/xarray.c:719
    [<ffffffff8159f11c>] collapse_file+0x13c/0x2730 mm/khugepaged.c:1725
    [<ffffffff815a1b28>] hpage_collapse_scan_file+0x418/0x9a0 mm/khugepaged.c:2156
    [<ffffffff815a4001>] madvise_collapse+0x211/0x5e0 mm/khugepaged.c:2611
    [<ffffffff8153ba2d>] madvise_vma_behavior+0x5dd/0x1030 mm/madvise.c:1076
    [<ffffffff81537257>] madvise_walk_vmas+0x127/0x1d0 mm/madvise.c:1250
    [<ffffffff81537eb0>] do_madvise.part.0+0x1c0/0x2b0 mm/madvise.c:1429
    [<ffffffff8153c6e8>] do_madvise mm/madvise.c:1440 [inline]
    [<ffffffff8153c6e8>] __do_sys_madvise mm/madvise.c:1442 [inline]
    [<ffffffff8153c6e8>] __se_sys_madvise mm/madvise.c:1440 [inline]
    [<ffffffff8153c6e8>] __x64_sys_madvise+0x98/0xa0 mm/madvise.c:1440
    [<ffffffff84608225>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
    [<ffffffff84608225>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
    [<ffffffff84800087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd

write to /proc/sys/kernel/hung_task_check_interval_secs failed: No such file or directory
write to /proc/sys/kernel/softlockup_all_cpu_backtrace failed: No such file or directory
write to /proc/sys/kernel/hung_task_check_interval_secs failed: No such file or directory
write to /proc/sys/kernel/softlockup_all_cpu_backtrace failed: No such file or directory