* [syzbot] BUG: sleeping function called from invalid context in vm_area_dup @ 2022-10-20 12:15 syzbot 2022-10-20 12:40 ` syzbot 0 siblings, 1 reply; 13+ messages in thread From: syzbot @ 2022-10-20 12:15 UTC (permalink / raw) To: akpm, bigeasy, bpf, brauner, ebiederm, linux-kernel, syzkaller-bugs, tglx 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+b910411d3d253dab25d8@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 syzkaller@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [syzbot] BUG: sleeping function called from invalid context in vm_area_dup 2022-10-20 12:15 [syzbot] BUG: sleeping function called from invalid context in vm_area_dup syzbot @ 2022-10-20 12:40 ` syzbot 2022-10-21 1:21 ` Andrew Morton 0 siblings, 1 reply; 13+ messages in thread From: syzbot @ 2022-10-20 12:40 UTC (permalink / raw) To: akpm, bigeasy, bpf, brauner, ebiederm, linux-kernel, syzkaller-bugs, tglx 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+b910411d3d253dab25d8@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> ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [syzbot] BUG: sleeping function called from invalid context in vm_area_dup 2022-10-20 12:40 ` syzbot @ 2022-10-21 1:21 ` Andrew Morton 2022-10-21 1:58 ` Suren Baghdasaryan 0 siblings, 1 reply; 13+ messages in thread From: Andrew Morton @ 2022-10-21 1:21 UTC (permalink / raw) To: syzbot Cc: bigeasy, bpf, brauner, ebiederm, linux-kernel, syzkaller-bugs, tglx, linux-mm, Suren Baghdasaryan, David Hildenbrand On Thu, 20 Oct 2022 05:40:43 -0700 syzbot <syzbot+b910411d3d253dab25d8@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+b910411d3d253dab25d8@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-b1a9-ae5969e730b8@redhat.com addresses. Seems quite unlikely. > 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> ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [syzbot] BUG: sleeping function called from invalid context in vm_area_dup 2022-10-21 1:21 ` Andrew Morton @ 2022-10-21 1:58 ` Suren Baghdasaryan 2022-10-21 21:52 ` Suren Baghdasaryan 0 siblings, 1 reply; 13+ messages in thread From: Suren Baghdasaryan @ 2022-10-21 1:58 UTC (permalink / raw) To: Andrew Morton Cc: syzbot, bigeasy, bpf, brauner, ebiederm, linux-kernel, syzkaller-bugs, tglx, linux-mm, David Hildenbrand On Thu, Oct 20, 2022 at 6:22 PM Andrew Morton <akpm@linux-foundation.org> wrote: > > On Thu, 20 Oct 2022 05:40:43 -0700 syzbot <syzbot+b910411d3d253dab25d8@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+b910411d3d253dab25d8@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. > > I wonder if this could be fallout from the KSM locking error which > https://lkml.kernel.org/r/8c86678a-3bfb-3854-b1a9-ae5969e730b8@redhat.com > addresses. Seems quite unlikely. > > > 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> ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [syzbot] BUG: sleeping function called from invalid context in vm_area_dup 2022-10-21 1:58 ` Suren Baghdasaryan @ 2022-10-21 21:52 ` Suren Baghdasaryan 2022-10-21 23:12 ` Aleksandr Nogikh 0 siblings, 1 reply; 13+ messages in thread From: Suren Baghdasaryan @ 2022-10-21 21:52 UTC (permalink / raw) To: Andrew Morton Cc: syzbot, bigeasy, bpf, brauner, ebiederm, linux-kernel, syzkaller-bugs, tglx, linux-mm, David Hildenbrand On Thu, Oct 20, 2022 at 6:58 PM Suren Baghdasaryan <surenb@google.com> wrote: > > On Thu, Oct 20, 2022 at 6:22 PM Andrew Morton <akpm@linux-foundation.org> wrote: > > > > On Thu, 20 Oct 2022 05:40:43 -0700 syzbot <syzbot+b910411d3d253dab25d8@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+b910411d3d253dab25d8@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. 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. > > > > > I wonder if this could be fallout from the KSM locking error which > > https://lkml.kernel.org/r/8c86678a-3bfb-3854-b1a9-ae5969e730b8@redhat.com > > addresses. Seems quite unlikely. > > > > > 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> ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [syzbot] BUG: sleeping function called from invalid context in vm_area_dup 2022-10-21 21:52 ` Suren Baghdasaryan @ 2022-10-21 23:12 ` Aleksandr Nogikh 2022-10-21 23:49 ` Suren Baghdasaryan 0 siblings, 1 reply; 13+ messages in thread From: Aleksandr Nogikh @ 2022-10-21 23:12 UTC (permalink / raw) To: Suren Baghdasaryan Cc: Andrew Morton, syzbot, bigeasy, bpf, brauner, ebiederm, linux-kernel, syzkaller-bugs, tglx, linux-mm, David Hildenbrand On Fri, Oct 21, 2022 at 2:52 PM 'Suren Baghdasaryan' via syzkaller-bugs <syzkaller-bugs@googlegroups.com> wrote: > > On Thu, Oct 20, 2022 at 6:58 PM Suren Baghdasaryan <surenb@google.com> wrote: > > > > On Thu, Oct 20, 2022 at 6:22 PM Andrew Morton <akpm@linux-foundation.org> wrote: > > > > > > On Thu, 20 Oct 2022 05:40:43 -0700 syzbot <syzbot+b910411d3d253dab25d8@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+b910411d3d253dab25d8@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. > > 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. 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 > defconfig with CONFIG_ANON_VMA_NAME=y boots fine but does not > reproduce the issue. > > > > > > > > > I wonder if this could be fallout from the KSM locking error which > > > https://lkml.kernel.org/r/8c86678a-3bfb-3854-b1a9-ae5969e730b8@redhat.com > > > addresses. Seems quite unlikely. > > > > > > > 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> > > -- > 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-bugs+unsubscribe@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/CAJuCfpF7xsZJevfj6ERsJi5tPFj0o6FATAm4k%3DCMsONFG86EmQ%40mail.gmail.com. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [syzbot] BUG: sleeping function called from invalid context in vm_area_dup 2022-10-21 23:12 ` Aleksandr Nogikh @ 2022-10-21 23:49 ` Suren Baghdasaryan 2022-10-22 0:22 ` Aleksandr Nogikh 0 siblings, 1 reply; 13+ messages in thread From: Suren Baghdasaryan @ 2022-10-21 23:49 UTC (permalink / raw) To: Aleksandr Nogikh Cc: Andrew Morton, syzbot, bigeasy, bpf, brauner, ebiederm, linux-kernel, syzkaller-bugs, tglx, linux-mm, David Hildenbrand On Fri, Oct 21, 2022 at 4:12 PM Aleksandr Nogikh <nogikh@google.com> wrote: > > On Fri, Oct 21, 2022 at 2:52 PM 'Suren Baghdasaryan' via > syzkaller-bugs <syzkaller-bugs@googlegroups.com> wrote: > > > > On Thu, Oct 20, 2022 at 6:58 PM Suren Baghdasaryan <surenb@google.com> wrote: > > > > > > On Thu, Oct 20, 2022 at 6:22 PM Andrew Morton <akpm@linux-foundation.org> wrote: > > > > > > > > On Thu, 20 Oct 2022 05:40:43 -0700 syzbot <syzbot+b910411d3d253dab25d8@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+b910411d3d253dab25d8@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. > > > > 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. > > 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 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. > > > defconfig with CONFIG_ANON_VMA_NAME=y boots fine but does not > > reproduce the issue. > > > > > > > > > > > > > I wonder if this could be fallout from the KSM locking error which > > > > https://lkml.kernel.org/r/8c86678a-3bfb-3854-b1a9-ae5969e730b8@redhat.com > > > > addresses. Seems quite unlikely. > > > > > > > > > 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> > > > > -- > > 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-bugs+unsubscribe@googlegroups.com. > > To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/CAJuCfpF7xsZJevfj6ERsJi5tPFj0o6FATAm4k%3DCMsONFG86EmQ%40mail.gmail.com. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [syzbot] BUG: sleeping function called from invalid context in vm_area_dup 2022-10-21 23:49 ` Suren Baghdasaryan @ 2022-10-22 0:22 ` Aleksandr Nogikh 2022-10-22 0:39 ` Suren Baghdasaryan 0 siblings, 1 reply; 13+ messages in thread From: Aleksandr Nogikh @ 2022-10-22 0:22 UTC (permalink / raw) To: Suren Baghdasaryan Cc: Andrew Morton, syzbot, bigeasy, bpf, brauner, ebiederm, linux-kernel, syzkaller-bugs, tglx, linux-mm, David Hildenbrand On Fri, Oct 21, 2022 at 4:50 PM Suren Baghdasaryan <surenb@google.com> wrote: > > On Fri, Oct 21, 2022 at 4:12 PM Aleksandr Nogikh <nogikh@google.com> wrote: > > > > On Fri, Oct 21, 2022 at 2:52 PM 'Suren Baghdasaryan' via > > syzkaller-bugs <syzkaller-bugs@googlegroups.com> wrote: > > > > > > On Thu, Oct 20, 2022 at 6:58 PM Suren Baghdasaryan <surenb@google.com> wrote: > > > > > > > > On Thu, Oct 20, 2022 at 6:22 PM Andrew Morton <akpm@linux-foundation.org> wrote: > > > > > > > > > > On Thu, 20 Oct 2022 05:40:43 -0700 syzbot <syzbot+b910411d3d253dab25d8@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+b910411d3d253dab25d8@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. > > > > > > 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. > > > > 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 > > 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. 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. > Thanks, > Suren. > > > > > > defconfig with CONFIG_ANON_VMA_NAME=y boots fine but does not > > > reproduce the issue. > > > > > > > > > > > > > > > > > I wonder if this could be fallout from the KSM locking error which > > > > > https://lkml.kernel.org/r/8c86678a-3bfb-3854-b1a9-ae5969e730b8@redhat.com > > > > > addresses. Seems quite unlikely. > > > > > > > > > > > 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> > > > > > > -- > > > 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-bugs+unsubscribe@googlegroups.com. > > > To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/CAJuCfpF7xsZJevfj6ERsJi5tPFj0o6FATAm4k%3DCMsONFG86EmQ%40mail.gmail.com. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [syzbot] BUG: sleeping function called from invalid context in vm_area_dup 2022-10-22 0:22 ` Aleksandr Nogikh @ 2022-10-22 0:39 ` Suren Baghdasaryan 2022-10-22 4:55 ` Aleksandr Nogikh 0 siblings, 1 reply; 13+ messages in thread From: Suren Baghdasaryan @ 2022-10-22 0:39 UTC (permalink / raw) To: Aleksandr Nogikh Cc: Andrew Morton, syzbot, bigeasy, bpf, brauner, ebiederm, linux-kernel, syzkaller-bugs, tglx, linux-mm, David Hildenbrand On Fri, Oct 21, 2022 at 5:22 PM Aleksandr Nogikh <nogikh@google.com> wrote: > > On Fri, Oct 21, 2022 at 4:50 PM Suren Baghdasaryan <surenb@google.com> wrote: > > > > On Fri, Oct 21, 2022 at 4:12 PM Aleksandr Nogikh <nogikh@google.com> wrote: > > > > > > On Fri, Oct 21, 2022 at 2:52 PM 'Suren Baghdasaryan' via > > > syzkaller-bugs <syzkaller-bugs@googlegroups.com> wrote: > > > > > > > > On Thu, Oct 20, 2022 at 6:58 PM Suren Baghdasaryan <surenb@google.com> wrote: > > > > > > > > > > On Thu, Oct 20, 2022 at 6:22 PM Andrew Morton <akpm@linux-foundation.org> wrote: > > > > > > > > > > > > On Thu, 20 Oct 2022 05:40:43 -0700 syzbot <syzbot+b910411d3d253dab25d8@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+b910411d3d253dab25d8@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. > > > > > > > > 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. > > > > > > 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 > > > > 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. > > 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. 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? > > > Thanks, > > Suren. > > > > > > > > > defconfig with CONFIG_ANON_VMA_NAME=y boots fine but does not > > > > reproduce the issue. > > > > > > > > > > > > > > > > > > > > > I wonder if this could be fallout from the KSM locking error which > > > > > > https://lkml.kernel.org/r/8c86678a-3bfb-3854-b1a9-ae5969e730b8@redhat.com > > > > > > addresses. Seems quite unlikely. > > > > > > > > > > > > > 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> > > > > > > > > -- > > > > 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-bugs+unsubscribe@googlegroups.com. > > > > To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/CAJuCfpF7xsZJevfj6ERsJi5tPFj0o6FATAm4k%3DCMsONFG86EmQ%40mail.gmail.com. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [syzbot] BUG: sleeping function called from invalid context in vm_area_dup 2022-10-22 0:39 ` Suren Baghdasaryan @ 2022-10-22 4:55 ` Aleksandr Nogikh 2022-10-22 10:07 ` Tetsuo Handa 0 siblings, 1 reply; 13+ messages in thread From: Aleksandr Nogikh @ 2022-10-22 4:55 UTC (permalink / raw) To: Suren Baghdasaryan Cc: Andrew Morton, syzbot, bigeasy, bpf, brauner, ebiederm, linux-kernel, syzkaller-bugs, tglx, linux-mm, David Hildenbrand On Fri, Oct 21, 2022 at 5:39 PM Suren Baghdasaryan <surenb@google.com> wrote: > > On Fri, Oct 21, 2022 at 5:22 PM Aleksandr Nogikh <nogikh@google.com> wrote: > > > > On Fri, Oct 21, 2022 at 4:50 PM Suren Baghdasaryan <surenb@google.com> wrote: > > > > > > On Fri, Oct 21, 2022 at 4:12 PM Aleksandr Nogikh <nogikh@google.com> wrote: > > > > > > > > On Fri, Oct 21, 2022 at 2:52 PM 'Suren Baghdasaryan' via > > > > syzkaller-bugs <syzkaller-bugs@googlegroups.com> wrote: > > > > > > > > > > On Thu, Oct 20, 2022 at 6:58 PM Suren Baghdasaryan <surenb@google.com> wrote: > > > > > > > > > > > > On Thu, Oct 20, 2022 at 6:22 PM Andrew Morton <akpm@linux-foundation.org> wrote: > > > > > > > > > > > > > > On Thu, 20 Oct 2022 05:40:43 -0700 syzbot <syzbot+b910411d3d253dab25d8@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+b910411d3d253dab25d8@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. > > > > > > > > > > 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. > > > > > > > > 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 > > > > > > 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. > > > > 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. > > 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? 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, > > > Suren. > > > > > > > > > > > > defconfig with CONFIG_ANON_VMA_NAME=y boots fine but does not > > > > > reproduce the issue. > > > > > > > > > > > > > > > > > > > > > > > > > I wonder if this could be fallout from the KSM locking error which > > > > > > > https://lkml.kernel.org/r/8c86678a-3bfb-3854-b1a9-ae5969e730b8@redhat.com > > > > > > > addresses. Seems quite unlikely. > > > > > > > > > > > > > > > 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> > > > > > > > > > > -- > > > > > 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-bugs+unsubscribe@googlegroups.com. > > > > > To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/CAJuCfpF7xsZJevfj6ERsJi5tPFj0o6FATAm4k%3DCMsONFG86EmQ%40mail.gmail.com. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [syzbot] BUG: sleeping function called from invalid context in vm_area_dup 2022-10-22 4:55 ` Aleksandr Nogikh @ 2022-10-22 10:07 ` Tetsuo Handa 2022-10-23 19:44 ` Suren Baghdasaryan 2022-10-24 4:52 ` Aleksandr Nogikh 0 siblings, 2 replies; 13+ messages in thread From: Tetsuo Handa @ 2022-10-22 10:07 UTC (permalink / raw) To: Aleksandr Nogikh, Suren Baghdasaryan Cc: Andrew Morton, syzbot, bigeasy, bpf, brauner, ebiederm, linux-kernel, syzkaller-bugs, tglx, linux-mm, David Hildenbrand 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> ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [syzbot] BUG: sleeping function called from invalid context in vm_area_dup 2022-10-22 10:07 ` Tetsuo Handa @ 2022-10-23 19:44 ` Suren Baghdasaryan 2022-10-24 4:52 ` Aleksandr Nogikh 1 sibling, 0 replies; 13+ messages in thread From: Suren Baghdasaryan @ 2022-10-23 19:44 UTC (permalink / raw) To: Tetsuo Handa Cc: Aleksandr Nogikh, Andrew Morton, syzbot, bigeasy, bpf, brauner, ebiederm, linux-kernel, syzkaller-bugs, tglx, linux-mm, David Hildenbrand On Sat, Oct 22, 2022 at 3:07 AM Tetsuo Handa <penguin-kernel@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! > > #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> > > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [syzbot] BUG: sleeping function called from invalid context in vm_area_dup 2022-10-22 10:07 ` Tetsuo Handa 2022-10-23 19:44 ` Suren Baghdasaryan @ 2022-10-24 4:52 ` Aleksandr Nogikh 1 sibling, 0 replies; 13+ messages in thread From: Aleksandr Nogikh @ 2022-10-24 4:52 UTC (permalink / raw) To: Tetsuo Handa Cc: Suren Baghdasaryan, Andrew Morton, syzbot, bigeasy, bpf, brauner, ebiederm, linux-kernel, syzkaller-bugs, tglx, linux-mm, David Hildenbrand On Sat, Oct 22, 2022 at 3:08 AM Tetsuo Handa <penguin-kernel@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). > > 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> > > > -- > 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-bugs+unsubscribe@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. ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2022-10-24 4:53 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-10-20 12:15 [syzbot] BUG: sleeping function called from invalid context in vm_area_dup syzbot 2022-10-20 12:40 ` syzbot 2022-10-21 1:21 ` Andrew Morton 2022-10-21 1:58 ` Suren Baghdasaryan 2022-10-21 21:52 ` Suren Baghdasaryan 2022-10-21 23:12 ` Aleksandr Nogikh 2022-10-21 23:49 ` Suren Baghdasaryan 2022-10-22 0:22 ` Aleksandr Nogikh 2022-10-22 0:39 ` Suren Baghdasaryan 2022-10-22 4:55 ` Aleksandr Nogikh 2022-10-22 10:07 ` Tetsuo Handa 2022-10-23 19:44 ` Suren Baghdasaryan 2022-10-24 4:52 ` Aleksandr Nogikh
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.