From nobody Sat Feb 7 10:45:26 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5671227A127; Wed, 14 May 2025 13:39:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747229953; cv=none; b=MW+EKyGb0eXw5IzcCBDupLT/MxPaxGUFPUOwRzqfhhNRc6DdIotPSE+wehX4EJOIhU0iXaiEvq1oxGG2ch4bO3MIL/fCnvgvbrb0QyqyF3rGUVmQxoRpunjXJMr0o/0QA+eyVYuAmd2KD3/6h61TjKTWMI+ZAjK4ry697GwjeV4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747229953; c=relaxed/simple; bh=FcYsyyjQ4yo4y6vB0svJMUVQfor0h6fo43IOHfdiXwQ=; h=Message-ID:Date:From:To:Cc:Subject:References:MIME-Version: Content-Type; b=Ege0ulOiUj+4zaqh4KPJlOGOGbkQMoPRQhOX42VZwhj6QgjHYFxhKJNoYHWJsppG5PP0tYwHUC9m8nm4Eihnjqk/68RbT3PSa+QUEDq+Ae7EYSWzzYqlr9qGhU3PzLF4XG96RmEndOFYOCf3/3ks4OKyELDYs7vfSpvQJ/ABgRQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id E568AC4CEEF; Wed, 14 May 2025 13:39:12 +0000 (UTC) Received: from rostedt by gandalf with local (Exim 4.98.2) (envelope-from ) id 1uFCKi-00000005IEx-1NfX; Wed, 14 May 2025 09:39:40 -0400 Message-ID: <20250514133940.182905408@goodmis.org> User-Agent: quilt/0.68 Date: Wed, 14 May 2025 09:38:32 -0400 From: Steven Rostedt To: linux-kernel@vger.kernel.org Cc: Masami Hiramatsu , Mark Rutland , Mathieu Desnoyers , Andrew Morton , stable@vger.kernel.org, Divya Indi Subject: [for-linus][PATCH 1/4] tracing: samples: Initialize trace_array_printk() with the correct function References: <20250514133831.110736154@goodmis.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Steven Rostedt When using trace_array_printk() on a created instance, the correct function to use to initialize it is: trace_array_init_printk() Not trace_printk_init_buffer() The former is a proper function to use, the latter is for initializing trace_printk() and causes the NOTICE banner to be displayed. Cc: stable@vger.kernel.org Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Cc: Divya Indi Link: https://lore.kernel.org/20250509152657.0f6744d9@gandalf.local.home Fixes: 89ed42495ef4a ("tracing: Sample module to demonstrate kernel access = to Ftrace instances.") Fixes: 38ce2a9e33db6 ("tracing: Add trace_array_init_printk() to initialize= instance trace_printk() buffers") Signed-off-by: Steven Rostedt (Google) --- samples/ftrace/sample-trace-array.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/samples/ftrace/sample-trace-array.c b/samples/ftrace/sample-tr= ace-array.c index dac67c367457..4147616102f9 100644 --- a/samples/ftrace/sample-trace-array.c +++ b/samples/ftrace/sample-trace-array.c @@ -112,7 +112,7 @@ static int __init sample_trace_array_init(void) /* * If context specific per-cpu buffers havent already been allocated. */ - trace_printk_init_buffers(); + trace_array_init_printk(tr); =20 simple_tsk =3D kthread_run(simple_thread, NULL, "sample-instance"); if (IS_ERR(simple_tsk)) { --=20 2.47.2 From nobody Sat Feb 7 10:45:26 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 92FA727A930; Wed, 14 May 2025 13:39:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747229953; cv=none; b=FUTEFz+9udUpakRgHUBB6SFRxQf7Q4nmZhnhIdUWrOoM4dYwQkAbZ1gi3rCXHjzv8I9f/dGKJ6J9NP+R1pehe6BWK+VKG+dChR01DXQ3kH7xOjBXQil5vUvJ1lQuILQWZeRztPUt7tQt3bKxgCPg8lrba9MYCo6B180b9/93/ew= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747229953; c=relaxed/simple; bh=BEz47Ay0SnXLo032kX/uxFeO2wQ0x6Fp0KUQIe8W76g=; h=Message-ID:Date:From:To:Cc:Subject:References:MIME-Version: Content-Type; b=m87NTfXD99QbkMsMI69dLxpcMnW+Ak0EuuDCTRC4/VCAT+yPXHW+Q98N1m6g8LnxsyOCXZe/NM+fH97OtHdt8xR+NGQtUahpO09bh/P40T9DEdTTSonB/2CbOXh6HuxEYOCgbj6Q/Ti70nIWANUwM5oM7PjPLPiPpNpOmw6CrYU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2814AC4CEED; Wed, 14 May 2025 13:39:13 +0000 (UTC) Received: from rostedt by gandalf with local (Exim 4.98.2) (envelope-from ) id 1uFCKi-00000005IFS-23ps; Wed, 14 May 2025 09:39:40 -0400 Message-ID: <20250514133940.348447868@goodmis.org> User-Agent: quilt/0.68 Date: Wed, 14 May 2025 09:38:33 -0400 From: Steven Rostedt To: linux-kernel@vger.kernel.org Cc: Masami Hiramatsu , Mark Rutland , Mathieu Desnoyers , Andrew Morton , stable@vger.kernel.org, pengdonglin Subject: [for-linus][PATCH 2/4] ftrace: Fix preemption acounting for stacktrace trigger command References: <20250514133831.110736154@goodmis.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: pengdonglin When using the stacktrace trigger command to trace syscalls, the preemption count was consistently reported as 1 when the system call event itself had 0 ("."). For example: root@ubuntu22-vm:/sys/kernel/tracing/events/syscalls/sys_enter_read $ echo stacktrace > trigger $ echo 1 > enable sshd-416 [002] ..... 232.864910: sys_read(fd: a, buf: 556b1f3221d= 0, count: 8000) sshd-416 [002] ...1. 232.864913: =3D> ftrace_syscall_enter =3D> syscall_trace_enter =3D> do_syscall_64 =3D> entry_SYSCALL_64_after_hwframe The root cause is that the trace framework disables preemption in __DO_TRAC= E before invoking the trigger callback. Use the tracing_gen_ctx_dec() that will accommodate for the increase of the preemption count in __DO_TRACE when calling the callback. The result is the accurate reporting of: sshd-410 [004] ..... 210.117660: sys_read(fd: 4, buf: 559b725ba13= 0, count: 40000) sshd-410 [004] ..... 210.117662: =3D> ftrace_syscall_enter =3D> syscall_trace_enter =3D> do_syscall_64 =3D> entry_SYSCALL_64_after_hwframe Cc: stable@vger.kernel.org Fixes: ce33c845b030c ("tracing: Dump stacktrace trigger to the correspondin= g instance") Link: https://lore.kernel.org/20250512094246.1167956-1-dolinux.peng@gmail.c= om Signed-off-by: pengdonglin Signed-off-by: Steven Rostedt (Google) --- kernel/trace/trace_events_trigger.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/trace/trace_events_trigger.c b/kernel/trace/trace_event= s_trigger.c index b66b6d235d91..6e87ae2a1a66 100644 --- a/kernel/trace/trace_events_trigger.c +++ b/kernel/trace/trace_events_trigger.c @@ -1560,7 +1560,7 @@ stacktrace_trigger(struct event_trigger_data *data, struct trace_event_file *file =3D data->private_data; =20 if (file) - __trace_stack(file->tr, tracing_gen_ctx(), STACK_SKIP); + __trace_stack(file->tr, tracing_gen_ctx_dec(), STACK_SKIP); else trace_dump_stack(STACK_SKIP); } --=20 2.47.2 From nobody Sat Feb 7 10:45:26 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9301F27A93D; Wed, 14 May 2025 13:39:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747229953; cv=none; b=R84PmKz8bbBM7hKTn70W2Z6D0UXdt9FFR8AT1b6Ih8PNL3NchwZ8ABfzizoL1ge0gL1f9BnsX5I3R/KELSZwLrYlD4/GbPVMbvLNMPD0iE4wyndAz8kgS7ynvSJTgA+qLMWbhgx2rqX4I9g4USoy6GSxZ3CnkYCZO8dg1+yG1cQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747229953; c=relaxed/simple; bh=qbwUGFv1DkuSVC49ZkVjHRjYMnyc2G0IE7s8hrins3I=; h=Message-ID:Date:From:To:Cc:Subject:References:MIME-Version: Content-Type; b=KTVkX53MJBD8k8uJIks0qSQd1+dl/fklVdnO84mdukNJClZS2cqV7yd8nWS6jRlc5+ygOj/RO0fnhu26001T+P+9Yjx/87vTW0mmjQiDzx01HVrohFwogwE4rgTJ3MARvE9xs+td4BT68i9l/w2QyYDXlNG96JF/RbyPR06E+5s= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4DFDDC4CEF0; Wed, 14 May 2025 13:39:13 +0000 (UTC) Received: from rostedt by gandalf with local (Exim 4.98.2) (envelope-from ) id 1uFCKi-00000005IFw-2kmN; Wed, 14 May 2025 09:39:40 -0400 Message-ID: <20250514133940.513093734@goodmis.org> User-Agent: quilt/0.68 Date: Wed, 14 May 2025 09:38:34 -0400 From: Steven Rostedt To: linux-kernel@vger.kernel.org Cc: Masami Hiramatsu , Mark Rutland , Mathieu Desnoyers , Andrew Morton , stable@vger.kernel.org, pengdonglin Subject: [for-linus][PATCH 3/4] ftrace: Fix preemption accounting for stacktrace filter command References: <20250514133831.110736154@goodmis.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: pengdonglin The preemption count of the stacktrace filter command to trace ksys_read is consistently incorrect: $ echo ksys_read:stacktrace > set_ftrace_filter <...>-453 [004] ...1. 38.308956: =3D> ksys_read =3D> do_syscall_64 =3D> entry_SYSCALL_64_after_hwframe The root cause is that the trace framework disables preemption when invoking the filter command callback in function_trace_probe_call: preempt_disable_notrace(); probe_ops->func(ip, parent_ip, probe_opsbe->tr, probe_ops, probe->data); preempt_enable_notrace(); Use tracing_gen_ctx_dec() to account for the preempt_disable_notrace(), which will output the correct preemption count: $ echo ksys_read:stacktrace > set_ftrace_filter <...>-410 [006] ..... 31.420396: =3D> ksys_read =3D> do_syscall_64 =3D> entry_SYSCALL_64_after_hwframe Cc: stable@vger.kernel.org Fixes: 36590c50b2d07 ("tracing: Merge irqflags + preempt counter.") Link: https://lore.kernel.org/20250512094246.1167956-2-dolinux.peng@gmail.c= om Signed-off-by: pengdonglin Signed-off-by: Steven Rostedt (Google) --- kernel/trace/trace_functions.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/kernel/trace/trace_functions.c b/kernel/trace/trace_functions.c index 98ccf3f00c51..4e37a0f6aaa3 100644 --- a/kernel/trace/trace_functions.c +++ b/kernel/trace/trace_functions.c @@ -633,11 +633,7 @@ ftrace_traceoff(unsigned long ip, unsigned long parent= _ip, =20 static __always_inline void trace_stack(struct trace_array *tr) { - unsigned int trace_ctx; - - trace_ctx =3D tracing_gen_ctx(); - - __trace_stack(tr, trace_ctx, FTRACE_STACK_SKIP); + __trace_stack(tr, tracing_gen_ctx_dec(), FTRACE_STACK_SKIP); } =20 static void --=20 2.47.2 From nobody Sat Feb 7 10:45:26 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BE4A327B4E5; Wed, 14 May 2025 13:39:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747229953; cv=none; b=Ywkwaarvh3FJ9JbLg9rLSwqWgqBzXx4vnf1Sj/R/DyiVIm8hzTLvjJ1exc8/MZbwZtFwxkJJ2cGrTtpq1ttJRu35//62+arUAEnV45N8v+Z+Lo8PxmeTMw+MBn45NjkhnYyFN5xPNZ1dSiWLMdfZT9gjuVWODRppIXvMrnSg0KM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747229953; c=relaxed/simple; bh=gGOrCyi8ITMcqduWweSJPI6d6U7NRQA/OcOVTwNnYe8=; h=Message-ID:Date:From:To:Cc:Subject:References:MIME-Version: Content-Type; b=OJb3eU5WYs4kOHjLuHmYxecpNVzKDWoPV2+AeaqWpTLSyU8qIlRqHFJC/a79x1x41FFxsIpxmL96F6QNpeBv+ass95tuQBMUa32N4vmNr6WYOKkv7g4m6cBZGAtpdeejHbnk0SlW3n+5uQx+6FJrTI9OzQlOqQM3LXVDX9WvUso= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 70D7AC4CEEF; Wed, 14 May 2025 13:39:13 +0000 (UTC) Received: from rostedt by gandalf with local (Exim 4.98.2) (envelope-from ) id 1uFCKi-00000005IGR-3Tnt; Wed, 14 May 2025 09:39:40 -0400 Message-ID: <20250514133940.677423482@goodmis.org> User-Agent: quilt/0.68 Date: Wed, 14 May 2025 09:38:35 -0400 From: Steven Rostedt To: linux-kernel@vger.kernel.org Cc: Masami Hiramatsu , Mark Rutland , Mathieu Desnoyers , Andrew Morton , stable@vger.kernel.org, Tasos Sahanidis Subject: [for-linus][PATCH 4/4] ring-buffer: Fix persistent buffer when commit page is the reader page References: <20250514133831.110736154@goodmis.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Steven Rostedt The ring buffer is made up of sub buffers (sometimes called pages as they are by default PAGE_SIZE). It has the following "pages": "tail page" - this is the page that the next write will write to "head page" - this is the page that the reader will swap the reader page = with. "reader page" - This belongs to the reader, where it will swap the head page from the ring buffer so that the reader does not race with the writer. The writer may end up on the "reader page" if the ring buffer hasn't written more than one page, where the "tail page" and the "head page" are the same. The persistent ring buffer has meta data that points to where these pages exist so on reboot it can re-create the pointers to the cpu_buffer descriptor. But when the commit page is on the reader page, the logic is incorrect. The check to see if the commit page is on the reader page checked if the head page was the reader page, which would never happen, as the head page is always in the ring buffer. The correct check would be to test if the commit page is on the reader page. If that's the case, then it can exit out early as the commit page is only on the reader page when there's only one page of data in the buffer. There's no reason to iterate the ring buffer pages to find the "commit page" as it is already found. To trigger this bug: # echo 1 > /sys/kernel/tracing/instances/boot_mapped/events/syscalls/sys_= enter_fchownat/enable # touch /tmp/x # chown sshd /tmp/x # reboot On boot up, the dmesg will have: Ring buffer meta [0] is from previous boot! Ring buffer meta [1] is from previous boot! Ring buffer meta [2] is from previous boot! Ring buffer meta [3] is from previous boot! Ring buffer meta [4] commit page not found Ring buffer meta [5] is from previous boot! Ring buffer meta [6] is from previous boot! Ring buffer meta [7] is from previous boot! Where the buffer on CPU 4 had a "commit page not found" error and that buffer is cleared and reset causing the output to be empty and the data los= t. When it works correctly, it has: # cat /sys/kernel/tracing/instances/boot_mapped/trace_pipe <...>-1137 [004] ..... 998.205323: sys_enter_fchownat: __sysca= ll_nr=3D0x104 (260) dfd=3D0xffffff9c (4294967196) filename=3D(0xffffc90000a= 0002c) user=3D0x3e8 (1000) group=3D0xffffffff (4294967295) flag=3D0x0 (0 Cc: stable@vger.kernel.org Cc: Mathieu Desnoyers Link: https://lore.kernel.org/20250513115032.3e0b97f7@gandalf.local.home Fixes: 5f3b6e839f3ce ("ring-buffer: Validate boot range memory events") Reported-by: Tasos Sahanidis Tested-by: Tasos Sahanidis Reviewed-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt (Google) --- kernel/trace/ring_buffer.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c index c0f877d39a24..3f9bf562beea 100644 --- a/kernel/trace/ring_buffer.c +++ b/kernel/trace/ring_buffer.c @@ -1887,10 +1887,12 @@ static void rb_meta_validate_events(struct ring_buf= fer_per_cpu *cpu_buffer) =20 head_page =3D cpu_buffer->head_page; =20 - /* If both the head and commit are on the reader_page then we are done. */ - if (head_page =3D=3D cpu_buffer->reader_page && - head_page =3D=3D cpu_buffer->commit_page) + /* If the commit_buffer is the reader page, update the commit page */ + if (meta->commit_buffer =3D=3D (unsigned long)cpu_buffer->reader_page->pa= ge) { + cpu_buffer->commit_page =3D cpu_buffer->reader_page; + /* Nothing more to do, the only page is the reader page */ goto done; + } =20 /* Iterate until finding the commit page */ for (i =3D 0; i < meta->nr_subbufs + 1; i++, rb_inc_page(&head_page)) { --=20 2.47.2