[syzbot] BUG: sleeping function called from invalid context in vm_area_dup

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: acee3e83b493 Add linux-next specific files for 20221020
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=13cdacba880000
kernel config: https://syzkaller.appspot.com/x/.config?x=c82245cfb913f766
dashboard link: https://syzkaller.appspot.com/bug?extid=b910411d3d253dab25d8
compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2

Unfortunately, I don't have any reproducer for this issue yet.

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/98cc5896cded/disk-acee3e83.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/b3d3eb3aa10a/vmlinux-acee3e83.xz

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

BUG: sleeping function called from invalid context at include/linux/sched/mm.h:274
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 8806, name: syz-executor.0
preempt_count: 1, expected: 0
RCU nest depth: 0, expected: 0
INFO: lockdep is turned off.
Preemption disabled at:
[<0000000000000000>] 0x0
CPU: 1 PID: 8806 Comm: syz-executor.0 Not tainted 6.1.0-rc1-next-20221020-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
__might_resched.cold+0x222/0x26b kernel/sched/core.c:9890
might_alloc include/linux/sched/mm.h:274 [inline]
slab_pre_alloc_hook mm/slab.h:727 [inline]
slab_alloc_node mm/slub.c:3323 [inline]
slab_alloc mm/slub.c:3411 [inline]
__kmem_cache_alloc_lru mm/slub.c:3418 [inline]
kmem_cache_alloc+0x2e6/0x3c0 mm/slub.c:3427
vm_area_dup+0x81/0x380 kernel/fork.c:466
copy_vma+0x376/0x8d0 mm/mmap.c:3216
move_vma+0x449/0xf60 mm/mremap.c:626
__do_sys_mremap+0x487/0x16b0 mm/mremap.c:1075
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7fe5a1e8b5a9
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fe5a30a7168 EFLAGS: 00000246 ORIG_RAX: 0000000000000019
RAX: ffffffffffffffda RBX: 00007fe5a1fabf80 RCX: 00007fe5a1e8b5a9
RDX: 0000000000001000 RSI: 0000000000004000 RDI: 00000000201c4000
RBP: 00007fe5a1ee6580 R08: 00000000202ef000 R09: 0000000000000000
R10: 0000000000000003 R11: 0000000000000246 R12: 0000000000000000
R13: 00007ffee646383f R14: 00007fe5a30a7300 R15: 0000000000022000
</TASK>


---
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 syzk...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

[syzbot]

syzbot has found a reproducer for the following issue on:

HEAD commit: acee3e83b493 Add linux-next specific files for 20221020
git tree: linux-next

console+strace: https://syzkaller.appspot.com/x/log.txt?x=170a8016880000

kernel config: https://syzkaller.appspot.com/x/.config?x=c82245cfb913f766
dashboard link: https://syzkaller.appspot.com/bug?extid=b910411d3d253dab25d8
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=109e0372880000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1770d752880000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/98cc5896cded/disk-acee3e83.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/b3d3eb3aa10a/vmlinux-acee3e83.xz

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

BUG: sleeping function called from invalid context at include/linux/sched/mm.h:274

in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 3602, name: syz-executor107

preempt_count: 1, expected: 0
RCU nest depth: 0, expected: 0
INFO: lockdep is turned off.
Preemption disabled at:
[<0000000000000000>] 0x0

CPU: 0 PID: 3602 Comm: syz-executor107 Not tainted 6.1.0-rc1-next-20221020-syzkaller #0

Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
__might_resched.cold+0x222/0x26b kernel/sched/core.c:9890
might_alloc include/linux/sched/mm.h:274 [inline]
slab_pre_alloc_hook mm/slab.h:727 [inline]
slab_alloc_node mm/slub.c:3323 [inline]
slab_alloc mm/slub.c:3411 [inline]
__kmem_cache_alloc_lru mm/slub.c:3418 [inline]
kmem_cache_alloc+0x2e6/0x3c0 mm/slub.c:3427
vm_area_dup+0x81/0x380 kernel/fork.c:466
copy_vma+0x376/0x8d0 mm/mmap.c:3216
move_vma+0x449/0xf60 mm/mremap.c:626
__do_sys_mremap+0x487/0x16b0 mm/mremap.c:1075
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd

RIP: 0033:0x7fd090fa5b29
Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffc2e90bd38 EFLAGS: 00000246 ORIG_RAX: 0000000000000019
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fd090fa5b29

RDX: 0000000000001000 RSI: 0000000000004000 RDI: 00000000201c4000

RBP: 00007fd090f69cd0 R08: 00000000202ef000 R09: 0000000000000000
R10: 0000000000000003 R11: 0000000000000246 R12: 00007fd090f69d60
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
</TASK>

[Andrew Morton]

On Thu, 20 Oct 2022 05:40:43 -0700 syzbot <syzbot+b91041...@syzkaller.appspotmail.com> wrote:

> syzbot has found a reproducer for the following issue on:

Thanks.

> HEAD commit: acee3e83b493 Add linux-next specific files for 20221020
> git tree: linux-next
> console+strace: https://syzkaller.appspot.com/x/log.txt?x=170a8016880000
> kernel config: https://syzkaller.appspot.com/x/.config?x=c82245cfb913f766
> dashboard link: https://syzkaller.appspot.com/bug?extid=b910411d3d253dab25d8
> 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=109e0372880000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1770d752880000
>
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/98cc5896cded/disk-acee3e83.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/b3d3eb3aa10a/vmlinux-acee3e83.xz
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+b91041...@syzkaller.appspotmail.com
>
> BUG: sleeping function called from invalid context at include/linux/sched/mm.h:274

This is happening under dup_anon_vma_name().

I can't spot preemption being disabled on that call path, and I assume
this code has been exercised for some time.

I wonder if this could be fallout from the KSM locking error which
https://lkml.kernel.org/r/8c86678a-3bfb-3854...@redhat.com
addresses. Seems quite unlikely.

[Suren Baghdasaryan]

On Thu, Oct 20, 2022 at 6:22 PM Andrew Morton <ak...@linux-foundation.org> wrote:
>
> On Thu, 20 Oct 2022 05:40:43 -0700 syzbot <syzbot+b91041...@syzkaller.appspotmail.com> wrote:
>
> > syzbot has found a reproducer for the following issue on:
>
> Thanks.
>
>
> > HEAD commit: acee3e83b493 Add linux-next specific files for 20221020
> > git tree: linux-next
> > console+strace: https://syzkaller.appspot.com/x/log.txt?x=170a8016880000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=c82245cfb913f766
> > dashboard link: https://syzkaller.appspot.com/bug?extid=b910411d3d253dab25d8
> > 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=109e0372880000
> > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1770d752880000
> >
> > Downloadable assets:
> > disk image: https://storage.googleapis.com/syzbot-assets/98cc5896cded/disk-acee3e83.raw.xz
> > vmlinux: https://storage.googleapis.com/syzbot-assets/b3d3eb3aa10a/vmlinux-acee3e83.xz
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+b91041...@syzkaller.appspotmail.com
> >
> > BUG: sleeping function called from invalid context at include/linux/sched/mm.h:274
>
> This is happening under dup_anon_vma_name().
>
> I can't spot preemption being disabled on that call path, and I assume
> this code has been exercised for some time.

Indeed, it is unclear why copy_vma() would be called in atomic
context. I'll try to reproduce tomorrow. Maybe with lockdep enabled we
can get something interesting.

[Suren Baghdasaryan]

Sorry for the delay. Having trouble booting the image built with the
attached config. My qemu crashes with a "sched: CPU #1's llc-sibling
CPU #0 is not on the same node! [node: 1 != 0]." warning before the
crash. Trying to figure out why.
defconfig with CONFIG_ANON_VMA_NAME=y boots fine but does not
reproduce the issue.

[Aleksandr Nogikh]

qemu 6.2 changed the core-to-socket assignment and it looks like we
get such errors when a kernel with "numa=fake=" is run under qemu on a
system with multiple CPUs.

You can try removing numa=fake=... from the CMDLINE config or just
manually setting the smp argument of the qemu process (e.g. -smp
2,sockets=2,cores=1)

See https://gitlab.com/qemu-project/qemu/-/issues/877

> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bug...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/CAJuCfpF7xsZJevfj6ERsJi5tPFj0o6FATAm4k%3DCMsONFG86EmQ%40mail.gmail.com.

[Suren Baghdasaryan]

That was it. Thank you, Aleksandr!
I can boot with the image built using the attached config but still
can't reproduce the issue using the C reproducer... Will keep it
running for some time to see if it eventually shows up.
Thanks,
Suren.

[Aleksandr Nogikh]

Just in case -- did you also try executing the reproducer against the
attached bootable disk image? Syzbot attaches the exact images on
which it managed to find the bug. The image should work for both GCE
and qemu.

[Suren Baghdasaryan]

I just tried replacing stretch.img in my qemu command line with the
attached disk-acee3e83.raw and that didn't work ("VFS: Unable to mount
root fs on unknown-block(8,0)"), so I'm obviously doing something
stupid. Any instructions on how to use the attached raw image?

[Aleksandr Nogikh]

It worked for me:

wget 'https://storage.googleapis.com/syzbot-assets/98cc5896cded/disk-acee3e83.raw.xz'
unxz disk-acee3e83.raw.xz
qemu-system-x86_64 -smp 2,sockets=2,cores=1 -m 4G -drive
file=disk-acee3e83.raw,format=raw -snapshot -nographic -enable-kvm

[Tetsuo Handa]

On 2022/10/22 13:55, Aleksandr Nogikh wrote:
> It worked for me:
>
> wget 'https://storage.googleapis.com/syzbot-assets/98cc5896cded/disk-acee3e83.raw.xz'
> unxz disk-acee3e83.raw.xz
> qemu-system-x86_64 -smp 2,sockets=2,cores=1 -m 4G -drive file=disk-acee3e83.raw,format=raw -snapshot -nographic -enable-kvm

Thanks for command line example.

I tried to add -append option in order to disable modules which cause lockdep splat, but failed
due to missing -kernel option. Then, I tried to pass downloaded vmlinux to -kernel option in order
to be able to use -append option, but failed again due to file format difference.

Downloadable vmlinux might be useful for calculating symbol addresses, but downloadable vmlinuz
would be more helpful for passing to boot loader (with modified kernel command line options).

Anyway, already fixed by commit b232a629b70cccb65d0c in linux-next-20221021.

#syz fix: mm/ksm: convert break_ksm() to use walk_page_range_vma()

[ 43.563343]
[ 43.564256] ======================================================
[ 43.565865] WARNING: possible circular locking dependency detected
[ 43.567533] 6.1.0-rc1-next-20221021+ #2 Not tainted
[ 43.568874] ------------------------------------------------------
[ 43.571009] a.out/853 is trying to acquire lock:
[ 43.572628] ffffffffa72c0b20 (fs_reclaim){+.+.}-{0:0}, at: kmem_cache_alloc+0x46/0x2b0
[ 43.574677]
[ 43.574677] but task is already holding lock:
[ 43.576837] ffff889d041e3498 (ptlock_ptr(page)#2){+.+.}-{2:2}, at: break_ksm_pmd_entry+0xf8/0x290
[ 43.579093]
[ 43.579093] which lock already depends on the new lock.
[ 43.579093]
[ 43.582819]
[ 43.582819] the existing dependency chain (in reverse order) is:
[ 43.585488]
[ 43.585488] -> #2 (ptlock_ptr(page)#2){+.+.}-{2:2}:
[ 43.587988] _raw_spin_lock+0x39/0x90
[ 43.589391] page_vma_mapped_walk+0x737/0xa80
[ 43.590934] page_vma_mkclean_one.constprop.0+0xf3/0x240
[ 43.592609] page_mkclean_one+0x94/0xe0
[ 43.594110] rmap_walk_file+0xf5/0x360
[ 43.595560] folio_mkclean+0xb3/0xf0
[ 43.597006] folio_clear_dirty_for_io+0x60/0x2b0
[ 43.598681] clear_page_dirty_for_io+0x18/0x60
[ 43.600626] mpage_submit_page+0x24/0x90
[ 43.602020] mpage_process_page_bufs+0x16c/0x190
[ 43.603635] mpage_prepare_extent_to_map+0x240/0x4f0
[ 43.605437] ext4_writepages+0x3cf/0x1400
[ 43.606957] do_writepages+0xd6/0x1f0
[ 43.608400] filemap_fdatawrite_wbc+0x75/0xb0
[ 43.609942] __filemap_fdatawrite_range+0x54/0x80
[ 43.611580] file_write_and_wait_range+0x53/0xc0
[ 43.613146] ext4_sync_file+0x135/0x480
[ 43.614603] vfs_fsync_range+0x49/0xa0
[ 43.615996] __x64_sys_fsync+0x38/0x80
[ 43.617405] do_syscall_64+0x5c/0xa0
[ 43.618758] entry_SYSCALL_64_after_hwframe+0x72/0xdc
[ 43.620390]
[ 43.620390] -> #1 (&mapping->i_mmap_rwsem){++++}-{3:3}:
[ 43.622828] down_write+0x46/0x120
[ 43.624209] dma_resv_lockdep+0x1d3/0x2cc
[ 43.625681] do_one_initcall+0x62/0x350
[ 43.627076] kernel_init_freeable+0x2ec/0x364
[ 43.628517] kernel_init+0x1b/0x170
[ 43.629846] ret_from_fork+0x2c/0x50
[ 43.631195]
[ 43.631195] -> #0 (fs_reclaim){+.+.}-{0:0}:
[ 43.633265] __lock_acquire+0x1300/0x2200
[ 43.634630] lock_acquire+0xd6/0x320
[ 43.635920] fs_reclaim_acquire+0xaa/0xf0
[ 43.637324] kmem_cache_alloc+0x46/0x2b0
[ 43.638762] vm_area_dup+0x25/0xa0
[ 43.640067] copy_vma+0x102/0x270
[ 43.641271] move_vma+0x147/0x4d0
[ 43.642509] __do_sys_mremap+0x206/0x970
[ 43.643826] __x64_sys_mremap+0x25/0x40
[ 43.645106] do_syscall_64+0x5c/0xa0
[ 43.646367] entry_SYSCALL_64_after_hwframe+0x72/0xdc
[ 43.647894]
[ 43.647894] other info that might help us debug this:
[ 43.647894]
[ 43.650937] Chain exists of:
[ 43.650937] fs_reclaim --> &mapping->i_mmap_rwsem --> ptlock_ptr(page)#2
[ 43.650937]
[ 43.650953] Possible unsafe locking scenario:
[ 43.650953]
[ 43.650955] CPU0 CPU1
[ 43.650956] ---- ----
[ 43.650958] lock(ptlock_ptr(page)#2);
[ 43.650965] lock(&mapping->i_mmap_rwsem);
[ 43.661146] lock(ptlock_ptr(page)#2);
[ 43.662821] lock(fs_reclaim);
[ 43.663892]
[ 43.663892] *** DEADLOCK ***
[ 43.663892]
[ 43.666474] 2 locks held by a.out/853:
[ 43.667641] #0: ffff889d062d1730 (&mm->mmap_lock#2){++++}-{3:3}, at: __do_sys_mremap+0xfe/0x970
[ 43.669803] #1: ffff889d041e3498 (ptlock_ptr(page)#2){+.+.}-{2:2}, at: break_ksm_pmd_entry+0xf8/0x290
[ 43.672539]
[ 43.672539] stack backtrace:
[ 43.674396] CPU: 3 PID: 853 Comm: a.out Not tainted 6.1.0-rc1-next-20221021+ #2
[ 43.676232] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
[ 43.678257] Call Trace:
[ 43.679255] <TASK>
[ 43.680192] dump_stack_lvl+0x5a/0x88
[ 43.681416] find_cpio_data.cold-0x6/0x5b
[ 43.682714] print_shortest_lock_dependencies.cold-0x5/0x8d
[ 43.684297] check_noncircular+0x103/0x130
[ 43.685630] __lock_acquire+0x1300/0x2200
[ 43.686973] lock_acquire+0xd6/0x320
[ 43.688182] ? kmem_cache_alloc+0x46/0x2b0
[ 43.689489] ? __lock_acquire+0x3e1/0x2200
[ 43.691049] fs_reclaim_acquire+0xaa/0xf0
[ 43.692395] ? kmem_cache_alloc+0x46/0x2b0
[ 43.693760] kmem_cache_alloc+0x46/0x2b0
[ 43.695117] ? vm_area_dup+0x25/0xa0
[ 43.696337] vm_area_dup+0x25/0xa0
[ 43.697570] ? sched_clock+0x9/0x20
[ 43.698812] ? __memcpy-0xd/0x30
[ 43.699955] ? lock_release+0x14e/0x4b0
[ 43.701206] ? mt_find+0x179/0x660
[ 43.702346] ? vma_merge+0x232/0x340
[ 43.703597] ? copy_vma+0xa0/0x270
[ 43.704748] copy_vma+0x102/0x270
[ 43.705956] move_vma+0x147/0x4d0
[ 43.707157] ? thp_get_unmapped_area+0xca/0xf0
[ 43.708528] __do_sys_mremap+0x206/0x970
[ 43.709786] ? syscall_enter_from_user_mode+0x21/0x70
[ 43.711208] ? __memcpy-0xd/0x30
[ 43.712369] ? lockdep_hardirqs_on+0x86/0x120
[ 43.713722] __x64_sys_mremap+0x25/0x40
[ 43.715013] do_syscall_64+0x5c/0xa0
[ 43.716269] ? syscall_exit_to_user_mode+0x37/0x60
[ 43.717682] ? do_syscall_64+0x69/0xa0
[ 43.718826] entry_SYSCALL_64_after_hwframe+0x72/0xdc
[ 43.720245] RIP: 0033:0x447e8d
[ 43.721412] Code: 28 c3 e8 46 1e 00 00 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
[ 43.726518] RSP: 002b:00007fffb8598528 EFLAGS: 00000246 ORIG_RAX: 0000000000000019
[ 43.728446] RAX: ffffffffffffffda RBX: 00007fffb8598738 RCX: 0000000000447e8d
[ 43.730346] RDX: 0000000000001000 RSI: 0000000000004000 RDI: 00000000201c4000
[ 43.732299] RBP: 0000000000000001 R08: 00000000202ef000 R09: 0000000000000000
[ 43.734174] R10: 0000000000000003 R11: 0000000000000246 R12: 0000000000000001
[ 43.735999] R13: 00007fffb8598728 R14: 00000000004c17d0 R15: 0000000000000001
[ 43.737958] </TASK>
[ 43.739102] BUG: sleeping function called from invalid context at include/linux/sched/mm.h:274
[ 43.741273] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 853, name: a.out
[ 43.743400] preempt_count: 1, expected: 0
[ 43.744780] RCU nest depth: 0, expected: 0
[ 43.746249] INFO: lockdep is turned off.
[ 43.747628] Preemption disabled at:
[ 43.747631] [<ffffffffa5c04158>] break_ksm_pmd_entry+0xf8/0x290
[ 43.750708] CPU: 3 PID: 853 Comm: a.out Not tainted 6.1.0-rc1-next-20221021+ #2
[ 43.752741] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
[ 43.754964] Call Trace:
[ 43.756143] <TASK>
[ 43.757235] dump_stack_lvl+0x5a/0x88
[ 43.758628] find_cpio_data.cold-0x6/0x5b
[ 43.760044] __might_resched.cold+0x13c/0x162
[ 43.761536] __might_sleep+0x50/0xa0
[ 43.762967] kmem_cache_alloc+0x265/0x2b0
[ 43.764408] ? vm_area_dup+0x25/0xa0
[ 43.765785] vm_area_dup+0x25/0xa0
[ 43.767175] ? sched_clock+0x9/0x20
[ 43.768530] ? __memcpy-0xd/0x30
[ 43.769802] ? lock_release+0x14e/0x4b0
[ 43.771288] ? mt_find+0x179/0x660
[ 43.772931] ? vma_merge+0x232/0x340
[ 43.774290] ? copy_vma+0xa0/0x270
[ 43.775603] copy_vma+0x102/0x270
[ 43.776899] move_vma+0x147/0x4d0
[ 43.778168] ? thp_get_unmapped_area+0xca/0xf0
[ 43.779641] __do_sys_mremap+0x206/0x970
[ 43.780984] ? syscall_enter_from_user_mode+0x21/0x70
[ 43.782511] ? __memcpy-0xd/0x30
[ 43.783682] ? lockdep_hardirqs_on+0x86/0x120
[ 43.785057] __x64_sys_mremap+0x25/0x40
[ 43.786346] do_syscall_64+0x5c/0xa0
[ 43.787603] ? syscall_exit_to_user_mode+0x37/0x60
[ 43.789037] ? do_syscall_64+0x69/0xa0
[ 43.790337] entry_SYSCALL_64_after_hwframe+0x72/0xdc
[ 43.791934] RIP: 0033:0x447e8d
[ 43.793053] Code: 28 c3 e8 46 1e 00 00 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
[ 43.798111] RSP: 002b:00007fffb8598528 EFLAGS: 00000246 ORIG_RAX: 0000000000000019
[ 43.800098] RAX: ffffffffffffffda RBX: 00007fffb8598738 RCX: 0000000000447e8d
[ 43.802002] RDX: 0000000000001000 RSI: 0000000000004000 RDI: 00000000201c4000
[ 43.803916] RBP: 0000000000000001 R08: 00000000202ef000 R09: 0000000000000000
[ 43.805887] R10: 0000000000000003 R11: 0000000000000246 R12: 0000000000000001
[ 43.807773] R13: 00007fffb8598728 R14: 00000000004c17d0 R15: 0000000000000001
[ 43.809648] </TASK>

[Suren Baghdasaryan]

On Sat, Oct 22, 2022 at 3:07 AM Tetsuo Handa
<penguin...@i-love.sakura.ne.jp> wrote:
>
> On 2022/10/22 13:55, Aleksandr Nogikh wrote:
> > It worked for me:
> >
> > wget 'https://storage.googleapis.com/syzbot-assets/98cc5896cded/disk-acee3e83.raw.xz'
> > unxz disk-acee3e83.raw.xz
> > qemu-system-x86_64 -smp 2,sockets=2,cores=1 -m 4G -drive file=disk-acee3e83.raw,format=raw -snapshot -nographic -enable-kvm

Yep, that worked, thanks!

>
> Thanks for command line example.
>
> I tried to add -append option in order to disable modules which cause lockdep splat, but failed
> due to missing -kernel option. Then, I tried to pass downloaded vmlinux to -kernel option in order
> to be able to use -append option, but failed again due to file format difference.
>
> Downloadable vmlinux might be useful for calculating symbol addresses, but downloadable vmlinuz
> would be more helpful for passing to boot loader (with modified kernel command line options).
>
> Anyway, already fixed by commit b232a629b70cccb65d0c in linux-next-20221021.

Thank you for confirming, Tetsuo!

[Aleksandr Nogikh]

On Sat, Oct 22, 2022 at 3:08 AM Tetsuo Handa
<penguin...@i-love.sakura.ne.jp> wrote:
>
> On 2022/10/22 13:55, Aleksandr Nogikh wrote:
> > It worked for me:
> >
> > wget 'https://storage.googleapis.com/syzbot-assets/98cc5896cded/disk-acee3e83.raw.xz'
> > unxz disk-acee3e83.raw.xz
> > qemu-system-x86_64 -smp 2,sockets=2,cores=1 -m 4G -drive file=disk-acee3e83.raw,format=raw -snapshot -nographic -enable-kvm
>
> Thanks for command line example.
>
> I tried to add -append option in order to disable modules which cause lockdep splat, but failed
> due to missing -kernel option. Then, I tried to pass downloaded vmlinux to -kernel option in order
> to be able to use -append option, but failed again due to file format difference.
>
> Downloadable vmlinux might be useful for calculating symbol addresses, but downloadable vmlinuz
> would be more helpful for passing to boot loader (with modified kernel command line options).

That's a very good point, thanks!
I've pushed a PR that should make syzbot also upload the kernel image
file (https://github.com/google/syzkaller/pull/3462).

For now, should you still need such file, you can extract it from the
attached bootable image (it's in one of the first partitions).

> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bug...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/9317bb19-5404-aada-a314-731f3ebe655c%40I-love.SAKURA.ne.jp.