On Wed, 10 Feb 2021 10:01:57 +0800 Wen Gong <wgong@xxxxxxxxxxxxxx> wrote: > Not tested with latest kernel. > The reason is below which I said in > https://lore.kernel.org/lkml/b504b3d7e989cae108669a0cd3072454@xxxxxxxxxxxxxx/ > > the per cpu buffer seems it is initilized in > trace_buffered_event_enable, > it is only 1 page size as below: > void trace_buffered_event_enable(void) > { > ... > for_each_tracing_cpu(cpu) { > page = alloc_pages_node(cpu_to_node(cpu), > GFP_KERNEL | __GFP_NORETRY, 0); > If the size of buffer to trace is more than 1 page, such as 46680, then > it trigger kernel crash/panic in my case while run trace-cmd. > After debugging, the trace_file->flags in > trace_event_buffer_lock_reserve is 0x40b while run trace-cmd, and it is > 0x403 while collecting ftrace log. Yeah, looking at this, I do see that this is a bug upstream. Can you test this patch? -- Steve diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index b79bcacdd6f9..a0b352aa23fe 100644 --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -2739,7 +2739,7 @@ trace_event_buffer_lock_reserve(struct trace_buffer **current_rb, (entry = this_cpu_read(trace_buffered_event))) { /* Try to use the per cpu buffer first */ val = this_cpu_inc_return(trace_buffered_event_cnt); - if (val == 1) { + if (len < PAGE_SIZE && val == 1) { trace_event_setup(entry, type, trace_ctx); entry->array[0] = len; return entry;
