[PATCH] tracing/events: Expand ring buffer for in-kernel event enables

[PATCH] tracing/events: Expand ring buffer for in-kernel event enables

[Manjunath Patil]

Ftrace keeps trace arrays at a boot-minimum ring-buffer size until
tracing is used. Tracefs event-enable paths already call
tracing_update_buffers() before enabling events, but the exported
in-kernel helpers trace_set_clr_event() and trace_array_set_clr_event()
directly enable events through __ftrace_set_clr_event().

This can leave events enabled by in-kernel users recording into the tiny
boot-minimum buffer instead of the configured default-sized buffer. Any
caller that enables events through these exported helpers observes
different buffer-expansion behavior than a userspace tracefs event enable.

Expand the relevant trace array before enabling events through the
exported in-kernel helpers, matching the tracefs event-enable behavior.
Disabling events remains unchanged.

Assisted-by: Codex:gpt-5
Signed-off-by: Manjunath Patil <manjunath.b.patil@oracle.com>
---
 kernel/trace/trace_events.c | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index c46e623e7e0d..3ce5b0121c5c 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -1479,10 +1479,22 @@ int ftrace_set_clr_event(struct trace_array *tr, char *buf, int set)
 int trace_set_clr_event(const char *system, const char *event, int set)
 {
 	struct trace_array *tr = top_trace_array();
+	int ret;
 
 	if (!tr)
 		return -ENODEV;
 
+	/*
+	 * Keep in-kernel event enabling consistent with tracefs event
+	 * enabling: once an event is being enabled, expand the boot-minimum
+	 * ring buffer to the configured default size before records arrive.
+	 */
+	if (set) {
+		ret = tracing_update_buffers(tr);
+		if (ret < 0)
+			return ret;
+	}
+
 	return __ftrace_set_clr_event(tr, NULL, system, event, set, NULL);
 }
 EXPORT_SYMBOL_GPL(trace_set_clr_event);
@@ -1504,11 +1516,24 @@ int trace_array_set_clr_event(struct trace_array *tr, const char *system,
 		const char *event, bool enable)
 {
 	int set;
+	int ret;
 
 	if (!tr)
 		return -ENOENT;
 
 	set = (enable == true) ? 1 : 0;
+
+	/*
+	 * Keep in-kernel event enabling consistent with tracefs event
+	 * enabling: once an event is being enabled, expand the boot-minimum
+	 * ring buffer to the configured default size before records arrive.
+	 */
+	if (set) {
+		ret = tracing_update_buffers(tr);
+		if (ret < 0)
+			return ret;
+	}
+
 	return __ftrace_set_clr_event(tr, NULL, system, event, set, NULL);
 }
 EXPORT_SYMBOL_GPL(trace_array_set_clr_event);

base-commit: e43ffb69e0438cddd72aaa30898b4dc446f664f8
-- 
2.47.3

Re: [PATCH] tracing/events: Expand ring buffer for in-kernel event enables

[Steven Rostedt]

On Mon,  1 Jun 2026 16:24:43 -0700
Manjunath Patil <manjunath.b.patil@oracle.com> wrote:

> Ftrace keeps trace arrays at a boot-minimum ring-buffer size until
> tracing is used. Tracefs event-enable paths already call
> tracing_update_buffers() before enabling events, but the exported
> in-kernel helpers trace_set_clr_event() and trace_array_set_clr_event()
> directly enable events through __ftrace_set_clr_event().
> 
> This can leave events enabled by in-kernel users recording into the tiny
> boot-minimum buffer instead of the configured default-sized buffer. Any
> caller that enables events through these exported helpers observes
> different buffer-expansion behavior than a userspace tracefs event enable.
> 
> Expand the relevant trace array before enabling events through the
> exported in-kernel helpers, matching the tracefs event-enable behavior.
> Disabling events remains unchanged.

The above explains everything correctly, but you left out what needs this?

Internal code should not be using the main ring buffer except for
debugging, in which case you can use trace_printk(), which will cause the
tracing buffers to be expanded by default.

Other areas of the kernel should create their own trace array which will be
created expanded by default too.

-- Steve

Re: [PATCH] tracing/events: Expand ring buffer for in-kernel event enables

[manjunath.b.patil]

On 6/2/26 6:00 AM, Steven Rostedt wrote:
> On Mon,  1 Jun 2026 16:24:43 -0700
> Manjunath Patil <manjunath.b.patil@oracle.com> wrote:
> 
>> Ftrace keeps trace arrays at a boot-minimum ring-buffer size until
>> tracing is used. Tracefs event-enable paths already call
>> tracing_update_buffers() before enabling events, but the exported
>> in-kernel helpers trace_set_clr_event() and trace_array_set_clr_event()
>> directly enable events through __ftrace_set_clr_event().
>>
>> This can leave events enabled by in-kernel users recording into the tiny
>> boot-minimum buffer instead of the configured default-sized buffer. Any
>> caller that enables events through these exported helpers observes
>> different buffer-expansion behavior than a userspace tracefs event enable.
>>
>> Expand the relevant trace array before enabling events through the
>> exported in-kernel helpers, matching the tracefs event-enable behavior.
>> Disabling events remains unchanged.
> 
> The above explains everything correctly, but you left out what needs this?
> 
> Internal code should not be using the main ring buffer except for
> debugging, in which case you can use trace_printk(), which will cause the
> tracing buffers to be expanded by default.
> 
> Other areas of the kernel should create their own trace array which will be
> created expanded by default too.
> 
> -- Steve


Thanks Steve, that makes sense.

The concrete case I was trying to address is not an upstream in-tree 
user. It is a downstream UEK RDS compatibility path where the legacy 
  
             rds_rt_debug_bitmap module parameter is mapped to RDS 
tracepoints by calling trace_set_clr_event() against the global trace 
array during module init. That can leave the default RDS tracepoints 
recording into the boot-minimum buffer unless userspace expands tracing 
first.

Looking at mainline again, trace-array users are already created 
expanded by default, and the remaining global-buffer use is 
debugging-style. So I agree this generic tracing/events change does not 
have a good upstream justification.

Please drop this patch. We will handle the downstream RDS compatibility 
case downstream, or move it to an explicit userspace/trace-array setup.

Thanks,
Manjunath