[syzbot] [trace?] WARNING in ring_buffer_nr_dirty_pages (2)

[syzbot] [trace?] WARNING in ring_buffer_nr_dirty_pages (2)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    d48723711bae Merge tag 'arm64-fixes' of git://git.kernel.o..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1075efdd580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=d16c0eae9c338e3c
dashboard link: https://syzkaller.appspot.com/bug?extid=008851bf625629489e75
compiler:       Debian clang version 22.1.8 (1~deb13u4), Debian LLD 22.1.8

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

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/db075c0aa29d/disk-d4872371.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/68dc5cfbbb35/vmlinux-d4872371.xz
kernel image: https://storage.googleapis.com/syzbot-assets/044cdc896523/bzImage-d4872371.xz

AI-generated root cause summary:
ring_buffer_subbuf_order_set() updates the sub-buffer order by allocating new
pages, freeing all old pages, and pointing head_page, tail_page, commit_page,
and reader_page to the newly allocated pages. However, it fails to reset the
per-CPU buffer accounting counters (pages_read, pages_touched, pages_lost, etc.)
or invoke rb_reset_cpu(). When pages had previously been read from the buffer,
pages_read remains positive; subsequent event reads on the newly allocated
buffer further increment pages_read while pages_touched remains 0 (since writes
have not yet filled and advanced the tail page). This violates the ring buffer
invariant that pages_read cannot exceed (pages_touched - pages_lost) + 1,
triggering the WARN_ON_ONCE(read > cnt + 1) warning in
ring_buffer_nr_dirty_pages().

full analysis:  https://syzkaller.appspot.com/x/ai_root_cause?x=008851bf625629489e75

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

------------[ cut here ]------------
read > cnt + 1
WARNING: kernel/trace/ring_buffer.c:866 at ring_buffer_nr_dirty_pages+0x1c6/0x1d0 kernel/trace/ring_buffer.c:866, CPU#1: syz.9.1552/10668
Modules linked in:
CPU: 1 UID: 0 PID: 10668 Comm: syz.9.1552 Tainted: G             L      syzkaller #0 PREEMPT_{RT,(full)} 
Tainted: [L]=SOFTLOCKUP
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/15/2026
RIP: 0010:ring_buffer_nr_dirty_pages+0x1c6/0x1d0 kernel/trace/ring_buffer.c:866
Code: 02 fe ff 4c 89 f8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc e8 19 02 fe ff 90 0f 0b 90 45 31 ff eb df e8 0b 02 fe ff 90 <0f> 0b 90 45 31 ff eb d1 66 90 90 90 90 90 90 90 90 90 90 90 90 90
RSP: 0018:ffffc90005caf880 EFLAGS: 00010087
RAX: ffffffff81c9d795 RBX: 0000000000000002 RCX: 0000000000080000
RDX: ffffc9001e6fa000 RSI: 00000000000000ef RDI: 00000000000000f0
RBP: 1ffff11027fc7a14 R08: 0000000000000000 R09: 0000000000000000
R10: dffffc0000000000 R11: ffffed1027fc8423 R12: 0000000000000000
R13: dffffc0000000000 R14: 0000000000000001 R15: fffffffffffffffe
FS:  00007fbb96ae66c0(0000) GS:ffff888124811000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f5b66f85ff8 CR3: 0000000036bc0000 CR4: 00000000003526f0
Call Trace:
 <TASK>
 full_hit kernel/trace/ring_buffer.c:888 [inline]
 rb_watermark_hit+0x1e3/0x2d0 kernel/trace/ring_buffer.c:984
 ring_buffer_poll_wait+0x254/0x2f0 kernel/trace/ring_buffer.c:1141
 vfs_poll include/linux/poll.h:82 [inline]
 __io_arm_poll_handler+0x395/0xbb0 io_uring/poll.c:612
 io_poll_add+0x1a0/0x2c0 io_uring/poll.c:987
 __io_issue_sqe+0x180/0x450 io_uring/io_uring.c:1514
 io_issue_sqe+0x177/0x12a0 io_uring/io_uring.c:1537
 io_queue_sqe io_uring/io_uring.c:1794 [inline]
 io_submit_sqe io_uring/io_uring.c:2089 [inline]
 io_submit_sqes+0xea7/0x2500 io_uring/io_uring.c:2212
 __do_sys_io_uring_enter io_uring/io_uring.c:2903 [inline]
 __se_sys_io_uring_enter+0x364/0x1bb0 io_uring/io_uring.c:2852
 do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
 do_syscall_64+0x166/0x520 arch/x86/entry/syscall_64.c:84
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fbb9888fb19
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 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 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fbb96ae6028 EFLAGS: 00000246 ORIG_RAX: 00000000000001aa
RAX: ffffffffffffffda RBX: 00007fbb98b15fa0 RCX: 00007fbb9888fb19
RDX: 00000000fffffffd RSI: 0000000000000b38 RDI: 0000000000000004
RBP: 00007fbb98927b70 R08: 0000000000000000 R09: 0000000000000000
R10: 000000000000004b R11: 0000000000000246 R12: 0000000000000000
R13: 00007fbb98b16038 R14: 00007fbb98b15fa0 R15: 00007ffd91292ae8
 </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

[PATCH] ring-buffer: Reset per-CPU buffer state in ring_buffer_subbuf_order_set()

[Shuai Liu]

ring_buffer_subbuf_order_set() replaces every page of a ring buffer
with newly allocated empty pages when the sub-buffer order changes.
However, it does not reset the per-CPU accounting of the discarded
pages. The stale counters (pages_read, pages_touched, pages_lost,
entries, ...) continue to describe pages that no longer exist.

A full waiter (e.g. poll on per_cpu/*/trace_pipe_raw with
buffer_percent set) then causes ring_buffer_nr_dirty_pages() to read
the stale accounting, and the invariant pages_read <= pages_touched -
pages_lost + 1 can be violated, which trips the WARN_ON_ONCE() there:

  WARNING: kernel/trace/ring_buffer.c:866 at ring_buffer_nr_dirty_pages

Since the old pages are gone, the buffer state after swapping in the
new pages is equivalent to a freshly allocated buffer. Replace the
manual head/tail/commit page assignment and the rb_head_page_activate()
call with rb_reset_cpu(), which performs the same page setup and also
resets all per-CPU accounting.

Verified on QEMU (x86_64, v7.4-rc2): enable sched_switch events,
partially consume trace_pipe, set buffer_subbuf_size_kb to 32, then
poll trace_pipe_raw with buffer_percent=50 while writing events. The
unpatched kernel triggers the WARN above, while the patched kernel
does not, and the per-CPU stats report a clean buffer after the order
change.

Fixes: 2808e31ec12e5 ("ring-buffer: Add interface for configuring trace sub buffer size")
Reported-by: syzbot+008851bf625629489e75@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=008851bf625629489e75
Link: https://lore.kernel.org/linux-trace-kernel/6af009ed.4dd4714a.f8d02.000d.GAE@google.com/
Signed-off-by: Shuai Liu <847807867@qq.com>
---
 kernel/trace/ring_buffer.c | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
index 75cd8df23c1b9..2726eb8cb3eeb 100644
--- a/kernel/trace/ring_buffer.c
+++ b/kernel/trace/ring_buffer.c
@@ -7548,10 +7548,6 @@ int ring_buffer_subbuf_order_set(struct trace_buffer *buffer, int order)
 		list_del_init(&cpu_buffer->new_pages);
 		cpu_buffer->cnt++;
 
-		cpu_buffer->head_page
-			= list_entry(cpu_buffer->pages, struct buffer_page, list);
-		cpu_buffer->tail_page = cpu_buffer->commit_page = cpu_buffer->head_page;
-
 		cpu_buffer->nr_pages = cpu_buffer->nr_pages_to_update;
 		cpu_buffer->nr_pages_to_update = 0;
 
@@ -7560,7 +7556,13 @@ int ring_buffer_subbuf_order_set(struct trace_buffer *buffer, int order)
 		cpu_buffer->free_page.data = NULL;
 		arch_spin_unlock(&cpu_buffer->lock);
 
-		rb_head_page_activate(cpu_buffer);
+		/*
+		 * The installed pages are freshly allocated and empty.
+		 * Reset the stale accounting of the discarded pages,
+		 * which can otherwise trip the WARN_ON_ONCE() in
+		 * ring_buffer_nr_dirty_pages().
+		 */
+		rb_reset_cpu(cpu_buffer);
 
 		raw_spin_unlock_irqrestore(&cpu_buffer->reader_lock, flags);
 
-- 
2.43.0

Re: [PATCH] ring-buffer: Reset per-CPU buffer state in ring_buffer_subbuf_order_set()

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Low] ring-buffer: wrong Fixes commit in
  ring_buffer_subbuf_order_set() fix
--

commit 2d978229f2f9c796f8090fdee8cc2744974a320c
Author: Shuai Liu <847807867@qq.com>

> ring-buffer: Reset per-CPU buffer state in ring_buffer_subbuf_order_set()
>
> ring_buffer_subbuf_order_set() replaces every page of a ring buffer
> with newly allocated empty pages when the sub-buffer order changes.
> However, it does not reset the per-CPU accounting of the discarded
> pages. The stale counters (pages_read, pages_touched, pages_lost,
> entries, ...) continue to describe pages that no longer exist.
>
> A full waiter (e.g. poll on per_cpu/*/trace_pipe_raw with
> buffer_percent set) then causes ring_buffer_nr_dirty_pages() to read
> the stale accounting, and the invariant pages_read <= pages_touched -
> pages_lost + 1 can be violated, which trips the WARN_ON_ONCE() there:
>
>   WARNING: kernel/trace/ring_buffer.c:866 at ring_buffer_nr_dirty_pages
>
> Since the old pages are gone, the buffer state after swapping in the
> new pages is equivalent to a freshly allocated buffer. Replace the
> manual head/tail/commit page assignment and the rb_head_page_activate()
> call with rb_reset_cpu(), which performs the same page setup and also
> resets all per-CPU accounting.
>
> Verified on QEMU (x86_64, v7.4-rc2): enable sched_switch events,
> partially consume trace_pipe, set buffer_subbuf_size_kb to 32, then
> poll trace_pipe_raw with buffer_percent=50 while writing events. The
> unpatched kernel triggers the WARN above, while the patched kernel
> does not, and the per-CPU stats report a clean buffer after the order
> change.
>
> Fixes: 2808e31ec12e5 ("ring-buffer: Add interface for configuring trace sub buffer size")
> Reported-by: syzbot+008851bf625629489e75@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=008851bf625629489e75
> Link: https://lore.kernel.org/linux-trace-kernel/6af009ed.4dd4714a.f8d02.000d.GAE@google.com/
> Signed-off-by: Shuai Liu <847807867@qq.com>

[Severity: Low]
2808e31ec12e ("ring-buffer: Add interface for configuring trace sub buffer
size") only added a stub for ring_buffer_subbuf_order_set(), and
f9b94daa542a ("ring-buffer: Set new size of the ring buffer sub page")
initially implemented it by allocating fresh ring_buffer_per_cpu structures
with zeroed counters.  The in-place page swap that leaves stale per-CPU
accounting was introduced in 8e7b58c27b3c ("ring-buffer: Just update the
subbuffers when changing their allocation order").

Should the Fixes tag be:

  Fixes: 8e7b58c27b3c ("ring-buffer: Just update the subbuffers when changing their allocation order")

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/tencent_1C5982E4E79A087063C5142622DDF7A4B909@qq.com?part=1

[PATCH v2] ring-buffer: Reset per-CPU buffer state in ring_buffer_subbuf_order_set()

[Shuai Liu]

ring_buffer_subbuf_order_set() replaces every page of a ring buffer
with newly allocated empty pages when the sub-buffer order changes.
However, it does not reset the per-CPU accounting of the discarded
pages. The stale counters (pages_read, pages_touched, pages_lost,
entries, ...) continue to describe pages that no longer exist.

A full waiter (e.g. poll on per_cpu/*/trace_pipe_raw with
buffer_percent set) then causes ring_buffer_nr_dirty_pages() to read
the stale accounting, and the invariant pages_read <= pages_touched -
pages_lost + 1 can be violated, which trips the WARN_ON_ONCE() there:

  WARNING: kernel/trace/ring_buffer.c:866 at ring_buffer_nr_dirty_pages

Since the old pages are gone, the buffer state after swapping in the
new pages is equivalent to a freshly allocated buffer. Replace the
manual head/tail/commit page assignment and the rb_head_page_activate()
call with rb_reset_cpu(), which performs the same page setup and also
resets all per-CPU accounting.

Verified on QEMU (x86_64, v7.4-rc2): enable sched_switch events,
partially consume trace_pipe, set buffer_subbuf_size_kb to 32, then
poll trace_pipe_raw with buffer_percent=50 while writing events. The
unpatched kernel triggers the WARN above, while the patched kernel
does not, and the per-CPU stats report a clean buffer after the order
change.

Fixes: 8e7b58c27b3c ("ring-buffer: Just update the subbuffers when changing their allocation order")
Reported-by: syzbot+008851bf625629489e75@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=008851bf625629489e75
Link: https://lore.kernel.org/linux-trace-kernel/6af009ed.4dd4714a.f8d02.000d.GAE@google.com/
Signed-off-by: Shuai Liu <847807867@qq.com>
---

Changes in v2:
  - Fix the Fixes tag: the stale per-CPU accounting was introduced by
    8e7b58c27b3c ("ring-buffer: Just update the subbuffers when changing
    their allocation order"), not 2808e31ec12e5 which only added the
    interface stub (Sashiko)

 kernel/trace/ring_buffer.c | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
index 75cd8df23c1b9..2726eb8cb3eeb 100644
--- a/kernel/trace/ring_buffer.c
+++ b/kernel/trace/ring_buffer.c
@@ -7548,10 +7548,6 @@ int ring_buffer_subbuf_order_set(struct trace_buffer *buffer, int order)
 		list_del_init(&cpu_buffer->new_pages);
 		cpu_buffer->cnt++;
 
-		cpu_buffer->head_page
-			= list_entry(cpu_buffer->pages, struct buffer_page, list);
-		cpu_buffer->tail_page = cpu_buffer->commit_page = cpu_buffer->head_page;
-
 		cpu_buffer->nr_pages = cpu_buffer->nr_pages_to_update;
 		cpu_buffer->nr_pages_to_update = 0;
 
@@ -7560,7 +7556,13 @@ int ring_buffer_subbuf_order_set(struct trace_buffer *buffer, int order)
 		cpu_buffer->free_page.data = NULL;
 		arch_spin_unlock(&cpu_buffer->lock);
 
-		rb_head_page_activate(cpu_buffer);
+		/*
+		 * The installed pages are freshly allocated and empty.
+		 * Reset the stale accounting of the discarded pages,
+		 * which can otherwise trip the WARN_ON_ONCE() in
+		 * ring_buffer_nr_dirty_pages().
+		 */
+		rb_reset_cpu(cpu_buffer);
 
 		raw_spin_unlock_irqrestore(&cpu_buffer->reader_lock, flags);
 
-- 
2.43.0

Re: [PATCH v2] ring-buffer: Reset per-CPU buffer state in ring_buffer_subbuf_order_set()

[Vincent Donnefort]

On Mon, Nov 09, 2026 at 11:06:53AM +0800, Shuai Liu wrote:
> ring_buffer_subbuf_order_set() replaces every page of a ring buffer
> with newly allocated empty pages when the sub-buffer order changes.
> However, it does not reset the per-CPU accounting of the discarded
> pages. The stale counters (pages_read, pages_touched, pages_lost,
> entries, ...) continue to describe pages that no longer exist.
> 
> A full waiter (e.g. poll on per_cpu/*/trace_pipe_raw with
> buffer_percent set) then causes ring_buffer_nr_dirty_pages() to read
> the stale accounting, and the invariant pages_read <= pages_touched -
> pages_lost + 1 can be violated, which trips the WARN_ON_ONCE() there:
> 
>   WARNING: kernel/trace/ring_buffer.c:866 at ring_buffer_nr_dirty_pages
> 
> Since the old pages are gone, the buffer state after swapping in the
> new pages is equivalent to a freshly allocated buffer. Replace the
> manual head/tail/commit page assignment and the rb_head_page_activate()
> call with rb_reset_cpu(), which performs the same page setup and also
> resets all per-CPU accounting.
> 
> Verified on QEMU (x86_64, v7.4-rc2): enable sched_switch events,
> partially consume trace_pipe, set buffer_subbuf_size_kb to 32, then
> poll trace_pipe_raw with buffer_percent=50 while writing events. The
> unpatched kernel triggers the WARN above, while the patched kernel
> does not, and the per-CPU stats report a clean buffer after the order
> change.
> 
> Fixes: 8e7b58c27b3c ("ring-buffer: Just update the subbuffers when changing their allocation order")
> Reported-by: syzbot+008851bf625629489e75@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=008851bf625629489e75
> Link: https://lore.kernel.org/linux-trace-kernel/6af009ed.4dd4714a.f8d02.000d.GAE@google.com/
> Signed-off-by: Shuai Liu <847807867@qq.com>

Please, ratelimit posting and do not use in-reply-to.

> ---
> 
> Changes in v2:
>   - Fix the Fixes tag: the stale per-CPU accounting was introduced by
>     8e7b58c27b3c ("ring-buffer: Just update the subbuffers when changing
>     their allocation order"), not 2808e31ec12e5 which only added the
>     interface stub (Sashiko)
> 
>  kernel/trace/ring_buffer.c | 12 +++++++-----
>  1 file changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
> index 75cd8df23c1b9..2726eb8cb3eeb 100644
> --- a/kernel/trace/ring_buffer.c
> +++ b/kernel/trace/ring_buffer.c
> @@ -7548,10 +7548,6 @@ int ring_buffer_subbuf_order_set(struct trace_buffer *buffer, int order)
>  		list_del_init(&cpu_buffer->new_pages);
>  		cpu_buffer->cnt++;
>  
> -		cpu_buffer->head_page
> -			= list_entry(cpu_buffer->pages, struct buffer_page, list);
> -		cpu_buffer->tail_page = cpu_buffer->commit_page = cpu_buffer->head_page;
> -
>  		cpu_buffer->nr_pages = cpu_buffer->nr_pages_to_update;
>  		cpu_buffer->nr_pages_to_update = 0;
>  
> @@ -7560,7 +7556,13 @@ int ring_buffer_subbuf_order_set(struct trace_buffer *buffer, int order)
>  		cpu_buffer->free_page.data = NULL;
>  		arch_spin_unlock(&cpu_buffer->lock);
>  
> -		rb_head_page_activate(cpu_buffer);
> +		/*
> +		 * The installed pages are freshly allocated and empty.
> +		 * Reset the stale accounting of the discarded pages,
> +		 * which can otherwise trip the WARN_ON_ONCE() in
> +		 * ring_buffer_nr_dirty_pages().

This comment isn't necessary.

> +		 */
> +		rb_reset_cpu(cpu_buffer);
>  
>  		raw_spin_unlock_irqrestore(&cpu_buffer->reader_lock, flags);
>  
> -- 
> 2.43.0
> 

-- 
Vincent