* Re: [syzbot] [kernel?] WARNING in audit_log_start [not found] <000000000000f11da7062091eb85@google.com> @ 2024-09-02 8:37 ` Thomas Gleixner 2024-09-03 19:22 ` Paul Moore 0 siblings, 1 reply; 6+ messages in thread From: Thomas Gleixner @ 2024-09-02 8:37 UTC (permalink / raw) To: syzbot, linux-kernel, luto, peterz, syzkaller-bugs, Kees Cook, audit On Mon, Aug 26 2024 at 01:29, syzbot wrote: Cc:+ seccomp and audit folks > syzbot found the following issue on: > > HEAD commit: 6a7917c89f21 Add linux-next specific files for 20240822 > git tree: linux-next > console output: https://syzkaller.appspot.com/x/log.txt?x=15c8680b980000 > kernel config: https://syzkaller.appspot.com/x/.config?x=897bd7c53a10fcfc > dashboard link: https://syzkaller.appspot.com/bug?extid=4576eaa688ef747b8d6c > compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40 > > Unfortunately, I don't have any reproducer for this issue yet. > > Downloadable assets: > disk image: https://storage.googleapis.com/syzbot-assets/47820545bc51/disk-6a7917c8.raw.xz > vmlinux: https://storage.googleapis.com/syzbot-assets/e300f3a38860/vmlinux-6a7917c8.xz > kernel image: https://storage.googleapis.com/syzbot-assets/9146afef58aa/bzImage-6a7917c8.xz > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+4576eaa688ef747b8d6c@syzkaller.appspotmail.com > > WARNING: CPU: 1 PID: 8527 at kernel/sched/core.c:8556 __might_sleep+0xb9/0xe0 kernel/sched/core.c:8552 > Modules linked in: > CPU: 1 UID: 0 PID: 8527 Comm: syz.4.642 Not tainted 6.11.0-rc4-next-20240822-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 > RIP: 0010:__might_sleep+0xb9/0xe0 kernel/sched/core.c:8552 > Code: a1 0e 01 90 42 80 3c 23 00 74 08 48 89 ef e8 ce e6 97 00 48 8b 4d 00 48 c7 c7 c0 60 0a 8c 44 89 ee 48 89 ca e8 f8 02 f1 ff 90 <0f> 0b 90 90 eb b5 89 d9 80 e1 07 80 c1 03 38 c1 0f 8c 70 ff ff ff > RSP: 0018:ffffc90009ab7a20 EFLAGS: 00010246 > RAX: a60a1ffb5c104900 RBX: 1ffff11004257a6c RCX: 0000000000040000 > RDX: ffffc90003e59000 RSI: 000000000001b727 RDI: 000000000001b728 > RBP: ffff8880212bd360 R08: ffffffff8155a632 R09: fffffbfff1cfa364 > R10: dffffc0000000000 R11: fffffbfff1cfa364 R12: dffffc0000000000 > R13: 0000000000000002 R14: 0000000000000151 R15: ffffffff8e0a492c > FS: 00007f4cf5b6a6c0(0000) GS:ffff8880b9100000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 00007f7e0f003000 CR3: 000000001feec000 CR4: 00000000003506f0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > Call Trace: > <TASK> > might_alloc include/linux/sched/mm.h:337 [inline] > slab_pre_alloc_hook mm/slub.c:3987 [inline] > slab_alloc_node mm/slub.c:4065 [inline] > kmem_cache_alloc_noprof+0x5d/0x2a0 mm/slub.c:4092 > audit_buffer_alloc kernel/audit.c:1790 [inline] > audit_log_start+0x15e/0xa30 kernel/audit.c:1912 > audit_seccomp+0x63/0x1f0 kernel/auditsc.c:3007 > seccomp_log kernel/seccomp.c:1016 [inline] > __seccomp_filter+0xb38/0x1fe0 kernel/seccomp.c:1305 > syscall_trace_enter+0xa8/0x150 kernel/entry/common.c:52 > syscall_enter_from_user_mode_work include/linux/entry-common.h:168 [inline] > syscall_enter_from_user_mode include/linux/entry-common.h:198 [inline] > do_syscall_64+0xcc/0x230 arch/x86/entry/common.c:79 > entry_SYSCALL_64_after_hwframe+0x77/0x7f > RIP: 0033:0x7f4cf4d157e9 > Code: 64 c7 00 16 00 00 00 b8 ff ff ff ff c3 0f 1f 40 00 90 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 c7 c0 0f 00 00 00 0f 05 <0f> 1f 80 00 00 00 00 48 81 ec 48 01 00 00 49 89 d0 64 48 8b 04 25 > RSP: 002b:00007f4cf5b69b40 EFLAGS: 00000206 ORIG_RAX: 000000000000000f > RAX: ffffffffffffffda RBX: 00007f4cf4f15f88 RCX: 00007f4cf4d157e9 > RDX: 00007f4cf5b69b40 RSI: 00007f4cf5b69c70 RDI: 0000000000000021 > RBP: 00007f4cf4f15f80 R08: 0000000000000000 R09: 0000000000000000 > R10: 0000000000000000 R11: 0000000000000206 R12: 00007f4cf4f15f8c > R13: 0000000000000000 R14: 00007fffe8828e10 R15: 00007fffe8828ef8 > </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. > > If the report is already addressed, let syzbot know by replying with: > #syz fix: exact-commit-title > > If you want to overwrite report's subsystems, reply with: > #syz set subsystems: new-subsystem > (See the list of subsystem names on the web dashboard) > > If the report is a duplicate of another one, reply with: > #syz dup: exact-subject-of-another-report > > If you want to undo deduplication, reply with: > #syz undup ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [syzbot] [kernel?] WARNING in audit_log_start 2024-09-02 8:37 ` [syzbot] [kernel?] WARNING in audit_log_start Thomas Gleixner @ 2024-09-03 19:22 ` Paul Moore 2024-09-03 19:24 ` Kees Cook 0 siblings, 1 reply; 6+ messages in thread From: Paul Moore @ 2024-09-03 19:22 UTC (permalink / raw) To: Thomas Gleixner Cc: syzbot, linux-kernel, luto, peterz, syzkaller-bugs, Kees Cook, audit On Mon, Sep 2, 2024 at 4:37 AM Thomas Gleixner <tglx@linutronix.de> wrote: > > On Mon, Aug 26 2024 at 01:29, syzbot wrote: > > Cc:+ seccomp and audit folks > > > syzbot found the following issue on: > > > > HEAD commit: 6a7917c89f21 Add linux-next specific files for 20240822 > > git tree: linux-next > > console output: https://syzkaller.appspot.com/x/log.txt?x=15c8680b980000 > > kernel config: https://syzkaller.appspot.com/x/.config?x=897bd7c53a10fcfc > > dashboard link: https://syzkaller.appspot.com/bug?extid=4576eaa688ef747b8d6c > > compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40 > > > > Unfortunately, I don't have any reproducer for this issue yet. > > > > Downloadable assets: > > disk image: https://storage.googleapis.com/syzbot-assets/47820545bc51/disk-6a7917c8.raw.xz > > vmlinux: https://storage.googleapis.com/syzbot-assets/e300f3a38860/vmlinux-6a7917c8.xz > > kernel image: https://storage.googleapis.com/syzbot-assets/9146afef58aa/bzImage-6a7917c8.xz > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > > Reported-by: syzbot+4576eaa688ef747b8d6c@syzkaller.appspotmail.com > > > > WARNING: CPU: 1 PID: 8527 at kernel/sched/core.c:8556 __might_sleep+0xb9/0xe0 kernel/sched/core.c:8552 > > Modules linked in: > > CPU: 1 UID: 0 PID: 8527 Comm: syz.4.642 Not tainted 6.11.0-rc4-next-20240822-syzkaller #0 > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 > > RIP: 0010:__might_sleep+0xb9/0xe0 kernel/sched/core.c:8552 > > Code: a1 0e 01 90 42 80 3c 23 00 74 08 48 89 ef e8 ce e6 97 00 48 8b 4d 00 48 c7 c7 c0 60 0a 8c 44 89 ee 48 89 ca e8 f8 02 f1 ff 90 <0f> 0b 90 90 eb b5 89 d9 80 e1 07 80 c1 03 38 c1 0f 8c 70 ff ff ff > > RSP: 0018:ffffc90009ab7a20 EFLAGS: 00010246 > > RAX: a60a1ffb5c104900 RBX: 1ffff11004257a6c RCX: 0000000000040000 > > RDX: ffffc90003e59000 RSI: 000000000001b727 RDI: 000000000001b728 > > RBP: ffff8880212bd360 R08: ffffffff8155a632 R09: fffffbfff1cfa364 > > R10: dffffc0000000000 R11: fffffbfff1cfa364 R12: dffffc0000000000 > > R13: 0000000000000002 R14: 0000000000000151 R15: ffffffff8e0a492c > > FS: 00007f4cf5b6a6c0(0000) GS:ffff8880b9100000(0000) knlGS:0000000000000000 > > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > CR2: 00007f7e0f003000 CR3: 000000001feec000 CR4: 00000000003506f0 > > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > > Call Trace: > > <TASK> > > might_alloc include/linux/sched/mm.h:337 [inline] > > slab_pre_alloc_hook mm/slub.c:3987 [inline] > > slab_alloc_node mm/slub.c:4065 [inline] > > kmem_cache_alloc_noprof+0x5d/0x2a0 mm/slub.c:4092 > > audit_buffer_alloc kernel/audit.c:1790 [inline] > > audit_log_start+0x15e/0xa30 kernel/audit.c:1912 > > audit_seccomp+0x63/0x1f0 kernel/auditsc.c:3007 The audit_seccomp() function allocates an audit buffer using GFP_KERNEL, which should be the source of the might_sleep. We can fix that easily enough by moving to GFP_ATOMIC (either for just this code path or all callers, need to check that), but I just want to confirm that we can't sleep here? I haven't dug into the syscall code in a while, so I don't recall all the details, but it seems odd to me that we can't safely sleep here ... > > seccomp_log kernel/seccomp.c:1016 [inline] > > __seccomp_filter+0xb38/0x1fe0 kernel/seccomp.c:1305 > > syscall_trace_enter+0xa8/0x150 kernel/entry/common.c:52 > > syscall_enter_from_user_mode_work include/linux/entry-common.h:168 [inline] > > syscall_enter_from_user_mode include/linux/entry-common.h:198 [inline] > > do_syscall_64+0xcc/0x230 arch/x86/entry/common.c:79 > > entry_SYSCALL_64_after_hwframe+0x77/0x7f > > RIP: 0033:0x7f4cf4d157e9 > > Code: 64 c7 00 16 00 00 00 b8 ff ff ff ff c3 0f 1f 40 00 90 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 c7 c0 0f 00 00 00 0f 05 <0f> 1f 80 00 00 00 00 48 81 ec 48 01 00 00 49 89 d0 64 48 8b 04 25 > > RSP: 002b:00007f4cf5b69b40 EFLAGS: 00000206 ORIG_RAX: 000000000000000f > > RAX: ffffffffffffffda RBX: 00007f4cf4f15f88 RCX: 00007f4cf4d157e9 > > RDX: 00007f4cf5b69b40 RSI: 00007f4cf5b69c70 RDI: 0000000000000021 > > RBP: 00007f4cf4f15f80 R08: 0000000000000000 R09: 0000000000000000 > > R10: 0000000000000000 R11: 0000000000000206 R12: 00007f4cf4f15f8c > > R13: 0000000000000000 R14: 00007fffe8828e10 R15: 00007fffe8828ef8 > > </TASK> -- paul-moore.com ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [syzbot] [kernel?] WARNING in audit_log_start 2024-09-03 19:22 ` Paul Moore @ 2024-09-03 19:24 ` Kees Cook 2024-09-03 20:54 ` Thomas Gleixner 0 siblings, 1 reply; 6+ messages in thread From: Kees Cook @ 2024-09-03 19:24 UTC (permalink / raw) To: Paul Moore Cc: Thomas Gleixner, syzbot, linux-kernel, luto, peterz, syzkaller-bugs, audit On Tue, Sep 03, 2024 at 03:22:17PM -0400, Paul Moore wrote: > On Mon, Sep 2, 2024 at 4:37 AM Thomas Gleixner <tglx@linutronix.de> wrote: > > > > On Mon, Aug 26 2024 at 01:29, syzbot wrote: > > > > Cc:+ seccomp and audit folks > > > > > syzbot found the following issue on: > > > > > > HEAD commit: 6a7917c89f21 Add linux-next specific files for 20240822 > > > git tree: linux-next > > > console output: https://syzkaller.appspot.com/x/log.txt?x=15c8680b980000 > > > kernel config: https://syzkaller.appspot.com/x/.config?x=897bd7c53a10fcfc > > > dashboard link: https://syzkaller.appspot.com/bug?extid=4576eaa688ef747b8d6c > > > compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40 > > > > > > Unfortunately, I don't have any reproducer for this issue yet. > > > > > > Downloadable assets: > > > disk image: https://storage.googleapis.com/syzbot-assets/47820545bc51/disk-6a7917c8.raw.xz > > > vmlinux: https://storage.googleapis.com/syzbot-assets/e300f3a38860/vmlinux-6a7917c8.xz > > > kernel image: https://storage.googleapis.com/syzbot-assets/9146afef58aa/bzImage-6a7917c8.xz > > > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > > > Reported-by: syzbot+4576eaa688ef747b8d6c@syzkaller.appspotmail.com > > > > > > WARNING: CPU: 1 PID: 8527 at kernel/sched/core.c:8556 __might_sleep+0xb9/0xe0 kernel/sched/core.c:8552 > > > Modules linked in: > > > CPU: 1 UID: 0 PID: 8527 Comm: syz.4.642 Not tainted 6.11.0-rc4-next-20240822-syzkaller #0 > > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 > > > RIP: 0010:__might_sleep+0xb9/0xe0 kernel/sched/core.c:8552 > > > Code: a1 0e 01 90 42 80 3c 23 00 74 08 48 89 ef e8 ce e6 97 00 48 8b 4d 00 48 c7 c7 c0 60 0a 8c 44 89 ee 48 89 ca e8 f8 02 f1 ff 90 <0f> 0b 90 90 eb b5 89 d9 80 e1 07 80 c1 03 38 c1 0f 8c 70 ff ff ff > > > RSP: 0018:ffffc90009ab7a20 EFLAGS: 00010246 > > > RAX: a60a1ffb5c104900 RBX: 1ffff11004257a6c RCX: 0000000000040000 > > > RDX: ffffc90003e59000 RSI: 000000000001b727 RDI: 000000000001b728 > > > RBP: ffff8880212bd360 R08: ffffffff8155a632 R09: fffffbfff1cfa364 > > > R10: dffffc0000000000 R11: fffffbfff1cfa364 R12: dffffc0000000000 > > > R13: 0000000000000002 R14: 0000000000000151 R15: ffffffff8e0a492c > > > FS: 00007f4cf5b6a6c0(0000) GS:ffff8880b9100000(0000) knlGS:0000000000000000 > > > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > > CR2: 00007f7e0f003000 CR3: 000000001feec000 CR4: 00000000003506f0 > > > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > > > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > > > Call Trace: > > > <TASK> > > > might_alloc include/linux/sched/mm.h:337 [inline] > > > slab_pre_alloc_hook mm/slub.c:3987 [inline] > > > slab_alloc_node mm/slub.c:4065 [inline] > > > kmem_cache_alloc_noprof+0x5d/0x2a0 mm/slub.c:4092 > > > audit_buffer_alloc kernel/audit.c:1790 [inline] > > > audit_log_start+0x15e/0xa30 kernel/audit.c:1912 > > > audit_seccomp+0x63/0x1f0 kernel/auditsc.c:3007 > > The audit_seccomp() function allocates an audit buffer using > GFP_KERNEL, which should be the source of the might_sleep. We can fix > that easily enough by moving to GFP_ATOMIC (either for just this code > path or all callers, need to check that), but I just want to confirm > that we can't sleep here? I haven't dug into the syscall code in a > while, so I don't recall all the details, but it seems odd to me that > we can't safely sleep here ... I had a similar question.. this is at syscall entry time. What is suddenly different here? We've been doing seccomp logging here for years... -Kees -- Kees Cook ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [syzbot] [kernel?] WARNING in audit_log_start 2024-09-03 19:24 ` Kees Cook @ 2024-09-03 20:54 ` Thomas Gleixner 2024-09-03 21:21 ` Paul Moore 2024-09-03 21:22 ` Aleksandr Nogikh 0 siblings, 2 replies; 6+ messages in thread From: Thomas Gleixner @ 2024-09-03 20:54 UTC (permalink / raw) To: Kees Cook, Paul Moore Cc: syzbot, linux-kernel, luto, peterz, syzkaller-bugs, audit On Tue, Sep 03 2024 at 12:24, Kees Cook wrote: > On Tue, Sep 03, 2024 at 03:22:17PM -0400, Paul Moore wrote: >> > > might_alloc include/linux/sched/mm.h:337 [inline] >> > > slab_pre_alloc_hook mm/slub.c:3987 [inline] >> > > slab_alloc_node mm/slub.c:4065 [inline] >> > > kmem_cache_alloc_noprof+0x5d/0x2a0 mm/slub.c:4092 >> > > audit_buffer_alloc kernel/audit.c:1790 [inline] >> > > audit_log_start+0x15e/0xa30 kernel/audit.c:1912 >> > > audit_seccomp+0x63/0x1f0 kernel/auditsc.c:3007 >> >> The audit_seccomp() function allocates an audit buffer using >> GFP_KERNEL, which should be the source of the might_sleep. We can fix >> that easily enough by moving to GFP_ATOMIC (either for just this code >> path or all callers, need to check that), but I just want to confirm >> that we can't sleep here? I haven't dug into the syscall code in a >> while, so I don't recall all the details, but it seems odd to me that >> we can't safely sleep here ... > > I had a similar question.. this is at syscall entry time. What is > suddenly different here? We've been doing seccomp logging here for > years... Correct. syscall_enter_from_user_mode() enables interrupts. At that point preempt_count is 0. So after that the task can sleep and schedule. Nothing in the call chain leading up to the allocation disables preemption or interrupts. From the actual console log: do not call blocking ops when !TASK_RUNNING; state=2 set at [<ffffffff81908f9e>] audit_log_start+0x37e/0xa30 I have no idea how that state would leak accross schedule_timeout(). Thanks, tglx ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [syzbot] [kernel?] WARNING in audit_log_start 2024-09-03 20:54 ` Thomas Gleixner @ 2024-09-03 21:21 ` Paul Moore 2024-09-03 21:22 ` Aleksandr Nogikh 1 sibling, 0 replies; 6+ messages in thread From: Paul Moore @ 2024-09-03 21:21 UTC (permalink / raw) To: Thomas Gleixner Cc: Kees Cook, syzbot, linux-kernel, luto, peterz, syzkaller-bugs, audit On Tue, Sep 3, 2024 at 4:54 PM Thomas Gleixner <tglx@linutronix.de> wrote: > On Tue, Sep 03 2024 at 12:24, Kees Cook wrote: > > On Tue, Sep 03, 2024 at 03:22:17PM -0400, Paul Moore wrote: > >> > > might_alloc include/linux/sched/mm.h:337 [inline] > >> > > slab_pre_alloc_hook mm/slub.c:3987 [inline] > >> > > slab_alloc_node mm/slub.c:4065 [inline] > >> > > kmem_cache_alloc_noprof+0x5d/0x2a0 mm/slub.c:4092 > >> > > audit_buffer_alloc kernel/audit.c:1790 [inline] > >> > > audit_log_start+0x15e/0xa30 kernel/audit.c:1912 > >> > > audit_seccomp+0x63/0x1f0 kernel/auditsc.c:3007 > >> > >> The audit_seccomp() function allocates an audit buffer using > >> GFP_KERNEL, which should be the source of the might_sleep. We can fix > >> that easily enough by moving to GFP_ATOMIC (either for just this code > >> path or all callers, need to check that), but I just want to confirm > >> that we can't sleep here? I haven't dug into the syscall code in a > >> while, so I don't recall all the details, but it seems odd to me that > >> we can't safely sleep here ... > > > > I had a similar question.. this is at syscall entry time. What is > > suddenly different here? We've been doing seccomp logging here for > > years... > > Correct. > > syscall_enter_from_user_mode() enables interrupts. At that point > preempt_count is 0. So after that the task can sleep and schedule. > Nothing in the call chain leading up to the allocation disables > preemption or interrupts. > > From the actual console log: > > do not call blocking ops when !TASK_RUNNING; state=2 set at [<ffffffff81908f9e>] audit_log_start+0x37e/0xa30 > > I have no idea how that state would leak accross schedule_timeout(). Okay, with no obvious root cause and no reproducer, I'm going to ignore this for now. If we start to see this pop up on real systems and/or syzbot finds a reproducer we can dig into it more. -- paul-moore.com ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [syzbot] [kernel?] WARNING in audit_log_start 2024-09-03 20:54 ` Thomas Gleixner 2024-09-03 21:21 ` Paul Moore @ 2024-09-03 21:22 ` Aleksandr Nogikh 1 sibling, 0 replies; 6+ messages in thread From: Aleksandr Nogikh @ 2024-09-03 21:22 UTC (permalink / raw) To: Thomas Gleixner Cc: Kees Cook, Paul Moore, syzbot, linux-kernel, luto, peterz, syzkaller-bugs, audit On Tue, Sep 3, 2024 at 10:54 PM Thomas Gleixner <tglx@linutronix.de> wrote: > > On Tue, Sep 03 2024 at 12:24, Kees Cook wrote: > > On Tue, Sep 03, 2024 at 03:22:17PM -0400, Paul Moore wrote: > >> > > might_alloc include/linux/sched/mm.h:337 [inline] > >> > > slab_pre_alloc_hook mm/slub.c:3987 [inline] > >> > > slab_alloc_node mm/slub.c:4065 [inline] > >> > > kmem_cache_alloc_noprof+0x5d/0x2a0 mm/slub.c:4092 > >> > > audit_buffer_alloc kernel/audit.c:1790 [inline] > >> > > audit_log_start+0x15e/0xa30 kernel/audit.c:1912 > >> > > audit_seccomp+0x63/0x1f0 kernel/auditsc.c:3007 > >> > >> The audit_seccomp() function allocates an audit buffer using > >> GFP_KERNEL, which should be the source of the might_sleep. We can fix > >> that easily enough by moving to GFP_ATOMIC (either for just this code > >> path or all callers, need to check that), but I just want to confirm > >> that we can't sleep here? I haven't dug into the syscall code in a > >> while, so I don't recall all the details, but it seems odd to me that > >> we can't safely sleep here ... > > > > I had a similar question.. this is at syscall entry time. What is > > suddenly different here? We've been doing seccomp logging here for > > years... > > Correct. > > syscall_enter_from_user_mode() enables interrupts. At that point > preempt_count is 0. So after that the task can sleep and schedule. > Nothing in the call chain leading up to the allocation disables > preemption or interrupts. > > From the actual console log: > > do not call blocking ops when !TASK_RUNNING; state=2 set at [<ffffffff81908f9e>] audit_log_start+0x37e/0xa30 > > I have no idea how that state would leak accross schedule_timeout(). > There has been a spike in strange crash reports on linux-next lately, supposedly due to this large patch series: https://lore.kernel.org/all/20240727102732.960974693@infradead.org/ So if this report is not easily explainable, possibly it is best to take it with a grain of salt.. Aleksandr > Thanks, > > tglx > ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2024-09-03 21:23 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <000000000000f11da7062091eb85@google.com>
2024-09-02 8:37 ` [syzbot] [kernel?] WARNING in audit_log_start Thomas Gleixner
2024-09-03 19:22 ` Paul Moore
2024-09-03 19:24 ` Kees Cook
2024-09-03 20:54 ` Thomas Gleixner
2024-09-03 21:21 ` Paul Moore
2024-09-03 21:22 ` Aleksandr Nogikh
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox