[syzbot] [trace?] WARNING in tracing_start_tr

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: 3bde70a2c827 Merge tag 'v6.15-rc1-smb3-client-fixes' of gi..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1240cdac580000
kernel config: https://syzkaller.appspot.com/x/.config?x=7a4e108575159039
dashboard link: https://syzkaller.appspot.com/bug?extid=ccdec3bfe0beec58a38d
compiler: gcc (Debian 12.2.0-14) 12.2.0, 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/385544917b90/disk-3bde70a2.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/8e29d15e8394/vmlinux-3bde70a2.xz
kernel image: https://storage.googleapis.com/syzbot-assets/2dbcc4712371/bzImage-3bde70a2.xz

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

------------[ cut here ]------------
WARNING: CPU: 0 PID: 6325 at kernel/trace/trace.c:2431 tracing_start_tr.part.0+0x1fc/0x2a0 kernel/trace/trace.c:2431
Modules linked in:
CPU: 0 UID: 0 PID: 6325 Comm: syz.2.94 Not tainted 6.15.0-rc1-syzkaller-00301-g3bde70a2c827 #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025
RIP: 0010:tracing_start_tr.part.0+0x1fc/0x2a0 kernel/trace/trace.c:2431
Code: 00 0f 85 97 00 00 00 48 83 3d 7f 52 62 0c 00 74 78 e8 28 55 fb ff 4c 89 ff e8 80 dd b2 09 90 e9 d9 fe ff ff e8 15 55 fb ff 90 <0f> 0b 90 c7 83 94 00 00 00 00 00 00 00 e9 c1 fe ff ff e8 ad c2 5f
RSP: 0018:ffffc9000f3e7b40 EFLAGS: 00010087
RAX: 000000000001dd6a RBX: ffffffff8e445400 RCX: ffffc9000e2a2000
RDX: 0000000000080000 RSI: ffffffff81bfe7ab RDI: 0000000000000005
RBP: 00000000ffffffff R08: 0000000000000005 R09: 0000000000000000
R10: 00000000ffffffff R11: 0000000000000000 R12: 1ffff92001e7cf69
R13: 0000000000000283 R14: ffffffff8e4454e0 R15: ffffffff8e445420
FS: 00007f889698f6c0(0000) GS:ffff8881249b9000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000110c430541 CR3: 0000000034dba000 CR4: 00000000003526f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
tracing_start_tr kernel/trace/trace.c:9410 [inline]
buffer_subbuf_size_write+0x226/0x280 kernel/trace/trace.c:9408
do_loop_readv_writev fs/read_write.c:848 [inline]
do_loop_readv_writev fs/read_write.c:833 [inline]
vfs_writev+0x6c4/0xdc0 fs/read_write.c:1057
do_writev+0x132/0x330 fs/read_write.c:1101
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xcd/0x260 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f8895b8d169
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 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f889698f038 EFLAGS: 00000246 ORIG_RAX: 0000000000000014
RAX: ffffffffffffffda RBX: 00007f8895da6160 RCX: 00007f8895b8d169
RDX: 0000000000000008 RSI: 0000200000000100 RDI: 0000000000000003
RBP: 00007f8895c0e990 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000000 R14: 00007f8895da6160 R15: 00007ffd37f16b28
</TASK>


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

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

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

[syzbot]

syzbot has found a reproducer for the following issue on:

HEAD commit: 4a26e7032d7d Merge tag 'core-bugs-2025-12-01' of git://git..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=12131512580000
kernel config: https://syzkaller.appspot.com/x/.config?x=f17615e99b9a69ec
dashboard link: https://syzkaller.appspot.com/bug?extid=ccdec3bfe0beec58a38d
compiler: gcc (Debian 12.2.0-14+deb12u1) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12b492b4580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16b492b4580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/240381b0df51/disk-4a26e703.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/2bfd9dded97e/vmlinux-4a26e703.xz
kernel image: https://storage.googleapis.com/syzbot-assets/e1ba9d12daee/bzImage-4a26e703.xz

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

------------[ cut here ]------------

WARNING: kernel/trace/trace.c:2497 at tracing_start_tr+0x21d/0x2b0 kernel/trace/trace.c:2497, CPU#0: syz.3.186/6257
Modules linked in:
CPU: 0 UID: 0 PID: 6257 Comm: syz.3.186 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025
RIP: 0010:tracing_start_tr+0x21d/0x2b0 kernel/trace/trace.c:2497
Code: 48 85 db 74 0d e8 73 1c fb ff 48 89 df e8 fb 42 fd ff e8 66 1c fb ff 4c 89 ef e8 be c5 ff ff e9 1e ff ff ff e8 54 1c fb ff 90 <0f> 0b 90 c7 83 94 00 00 00 00 00 00 00 e9 01 ff ff ff e8 3c 1c fb
RSP: 0018:ffffc90003777bd8 EFLAGS: 00010093
RAX: 0000000000000000 RBX: ffffffff8e250de0 RCX: ffffffff81c203e7
RDX: ffff888027699e80 RSI: ffffffff81c204dc RDI: 0000000000000005
RBP: 1ffff920006eef7c R08: 0000000000000005 R09: 0000000000000000
R10: 00000000ffffffff R11: 000000003ca71f67 R12: 00000000ffffffff
R13: dffffc0000000000 R14: 0000000000000293 R15: ffffffff8e250ec0
FS: 0000555561d28500(0000) GS:ffff888124ba8000(0000) knlGS:0000000000000000

CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033

CR2: 0000000000000000 CR3: 0000000075090000 CR4: 00000000003526f0
Call Trace:
<TASK>
buffer_subbuf_size_write+0x1ca/0x260 kernel/trace/trace.c:9702
vfs_write+0x2a0/0x11d0 fs/read_write.c:684
ksys_write+0x12a/0x250 fs/read_write.c:738
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xcd/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f2c50f8f7c9

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 a8 ff ff ff f7 d8 64 89 01 48

RSP: 002b:00007ffe8ab04cc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00007f2c511e5fa0 RCX: 00007f2c50f8f7c9
RDX: 0000000000000040 RSI: 0000200000000280 RDI: 0000000000000004
RBP: 00007f2c51013f91 R08: 0000000000000000 R09: 0000000000000000

R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000

R13: 00007f2c511e5fa0 R14: 00007f2c511e5fa0 R15: 0000000000000003
</TASK>


---
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

[Steven Rostedt]

Thanks, this is a real bug and should be fixed with the following patch:

(not compiled yet)

diff --git a/include/linux/trace_events.h b/include/linux/trace_events.h
index 04307a19cde3..3690221ba3d8 100644
--- a/include/linux/trace_events.h
+++ b/include/linux/trace_events.h
@@ -138,6 +138,7 @@ enum trace_iter_flags {
TRACE_FILE_LAT_FMT = 1,
TRACE_FILE_ANNOTATE = 2,
TRACE_FILE_TIME_IN_NS = 4,
+ TRACE_FILE_PAUSE = 8,
};


diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index d1e527cf2aae..62daff9a10dc 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -4682,8 +4682,10 @@ __tracing_open(struct inode *inode, struct file *file, bool snapshot)
* If pause-on-trace is enabled, then stop the trace while
* dumping, unless this is the "snapshot" file
*/
- if (!iter->snapshot && (tr->trace_flags & TRACE_ITER_PAUSE_ON_TRACE))
+ if (!iter->snapshot && (tr->trace_flags & TRACE_ITER_PAUSE_ON_TRACE)) {
+ iter->iter_flags |= TRACE_FILE_PAUSE;
tracing_stop_tr(tr);
+ }

if (iter->cpu_file == RING_BUFFER_ALL_CPUS) {
for_each_tracing_cpu(cpu) {
@@ -4815,7 +4817,7 @@ static int tracing_release(struct inode *inode, struct file *file)
if (iter->trace && iter->trace->close)
iter->trace->close(iter);

- if (!iter->snapshot && tr->stop_count)
+ if (iter->iter_flags & TRACE_FILE_PAUSE)
/* reenable tracing if it was previously enabled */
tracing_start_tr(tr);


Basically the old code was depending on the state of tr->stop_count to know
if it should re-enable it or not. But that's because the stop_count was
only incremented by a single user when it was created. Now it's incremented
by more than one user. This means if the open didn't increment it, but
something else did, then the close is going to decrement it when it shouldn't.

This fix adds a flag to the trace_iterator (unique per open) that holds the
state if it incremented the stop_count or not. Then the close can check if
its open was what did the increment, and decrement it if it had.

-- Steve