Re: [PATCH 08/15] tracing: Introduce names for ring buffers

2023-12-13 Thread kernel test robot 
Hi Alexander,

kernel test robot noticed the following build errors:

[auto build test ERROR on tip/x86/core]
[also build test ERROR on arm64/for-next/core akpm-mm/mm-everything 
linus/master v6.7-rc5 next-20231213]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:
https://github.com/intel-lab-lkp/linux/commits/Alexander-Graf/mm-memblock-Add-support-for-scratch-memory/20231213-080941
base:   tip/x86/core
patch link:
https://lore.kernel.org/r/20231213000452.88295-9-graf%40amazon.com
patch subject: [PATCH 08/15] tracing: Introduce names for ring buffers
config: i386-buildonly-randconfig-003-20231213 
(https://download.01.org/0day-ci/archive/20231213/202312131922.5djorqu4-...@intel.com/config)
compiler: clang version 16.0.4 (https://github.com/llvm/llvm-project.git 
ae42196bc493ffe877a7e3dff8be32035dea4d07)
reproduce (this is a W=1 build): 
(https://download.01.org/0day-ci/archive/20231213/202312131922.5djorqu4-...@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot 
| Closes: 
https://lore.kernel.org/oe-kbuild-all/202312131922.5djorqu4-...@intel.com/

All errors (new ones prefixed by >>):

>> kernel/trace/ring_buffer_benchmark.c:435:53: error: too few arguments 
>> provided to function-like macro invocation
   buffer = ring_buffer_alloc(100, RB_FL_OVERWRITE);
  ^
   include/linux/ring_buffer.h:96:9: note: macro 'ring_buffer_alloc' defined 
here
   #define ring_buffer_alloc(name, size, flags)\
   ^
>> kernel/trace/ring_buffer_benchmark.c:435:11: error: use of undeclared 
>> identifier 'ring_buffer_alloc'; did you mean '__ring_buffer_alloc'?
   buffer = ring_buffer_alloc(100, RB_FL_OVERWRITE);
^
__ring_buffer_alloc
   include/linux/ring_buffer.h:88:1: note: '__ring_buffer_alloc' declared here
   __ring_buffer_alloc(const char *name, unsigned long size, unsigned flags,
   ^
   2 errors generated.
--
>> kernel/trace/ring_buffer.c:6096:65: error: too few arguments provided to 
>> function-like macro invocation
   buffer = ring_buffer_alloc(RB_TEST_BUFFER_SIZE, RB_FL_OVERWRITE);
  ^
   include/linux/ring_buffer.h:96:9: note: macro 'ring_buffer_alloc' defined 
here
   #define ring_buffer_alloc(name, size, flags)\
   ^
>> kernel/trace/ring_buffer.c:6096:11: error: use of undeclared identifier 
>> 'ring_buffer_alloc'; did you mean '__ring_buffer_alloc'?
   buffer = ring_buffer_alloc(RB_TEST_BUFFER_SIZE, RB_FL_OVERWRITE);
^
__ring_buffer_alloc
   kernel/trace/ring_buffer.c:1873:19: note: '__ring_buffer_alloc' declared here
   EXPORT_SYMBOL_GPL(__ring_buffer_alloc);
 ^
   2 errors generated.


vim +435 kernel/trace/ring_buffer_benchmark.c

5092dbc96f3acd Steven Rostedt 2009-05-05  429  
5092dbc96f3acd Steven Rostedt 2009-05-05  430  static int __init 
ring_buffer_benchmark_init(void)
5092dbc96f3acd Steven Rostedt 2009-05-05  431  {
5092dbc96f3acd Steven Rostedt 2009-05-05  432   int ret;
5092dbc96f3acd Steven Rostedt 2009-05-05  433  
5092dbc96f3acd Steven Rostedt 2009-05-05  434   /* make a one meg buffer in 
overwite mode */
5092dbc96f3acd Steven Rostedt 2009-05-05 @435   buffer = 
ring_buffer_alloc(100, RB_FL_OVERWRITE);
5092dbc96f3acd Steven Rostedt 2009-05-05  436   if (!buffer)
5092dbc96f3acd Steven Rostedt 2009-05-05  437   return -ENOMEM;
5092dbc96f3acd Steven Rostedt 2009-05-05  438  
5092dbc96f3acd Steven Rostedt 2009-05-05  439   if (!disable_reader) {
5092dbc96f3acd Steven Rostedt 2009-05-05  440   consumer = 
kthread_create(ring_buffer_consumer_thread,
5092dbc96f3acd Steven Rostedt 2009-05-05  441   
  NULL, "rb_consumer");
5092dbc96f3acd Steven Rostedt 2009-05-05  442   ret = PTR_ERR(consumer);
5092dbc96f3acd Steven Rostedt 2009-05-05  443   if (IS_ERR(consumer))
5092dbc96f3acd Steven Rostedt 2009-05-05  444   goto out_fail;
5092dbc96f3acd Steven Rostedt 2009-05-05  445   }
5092dbc96f3acd Steven Rostedt 2009-05-05  446  
5092dbc96f3acd Steven Rostedt 2009-05-05  447   producer = 
kthread_run(ring_buffer_producer_thread,
5092dbc96f3acd Steven Rostedt 2009-05-05  448  NULL, 
"rb_producer");
5092dbc96f3acd Steven Rostedt 2009-05-05  449   ret = PTR_ERR(producer);
5092dbc96f3acd Steven Rostedt 2009-05-05  450  
5092dbc96f3acd Steven Rostedt 2009-05-05  451   if (IS_ERR(producer))
5092dbc96f3acd Steven Rostedt 2009-05-05  452   goto out_kill;

Re: [PATCH 08/15] tracing: Introduce names for ring buffers

2023-12-12 Thread Steven Rostedt 
On Wed, 13 Dec 2023 01:35:16 +0100
Alexander Graf  wrote:

> > The trace_array is the structure that represents each tracing instance. And
> > it already has a name field. And if you can get the associated ring buffer
> > from that too.
> >
> > struct trace_array *tr;
> >
> >  tr->array_buffer.buffer
> >
> >  tr->name
> >
> > When you do: mkdir /sys/kernel/tracing/instance/foo
> >
> > You create a new trace_array instance where tr->name = "foo" and allocates
> > the buffer for it as well.  
> 
> The name in the ring buffer is pretty much just a copy of the trace 
> array name. I use it to reconstruct which buffer we're actually 
> referring to inside __ring_buffer_alloc().

No, I rather not tie the ring buffer to the trace_array.

> 
> I'm all ears for alternative suggestions. I suppose we could pass tr as 
> argument to ring_buffer_alloc() instead of the name?

I'll have to spend some time (that I don't currently have :-( ) on looking
at this more. I really don't like the copying of the name into the ring
buffer allocation, as it may be an unneeded burden to maintain, not to
mention the duplicate field.

-- Steve

Re: [PATCH 08/15] tracing: Introduce names for ring buffers

2023-12-12 Thread Alexander Graf 

Hi Steve,

On 13.12.23 01:15, Steven Rostedt wrote:


On Wed, 13 Dec 2023 00:04:45 +
Alexander Graf  wrote:


With KHO (Kexec HandOver), we want to preserve trace buffers across
kexec. To carry over their state between kernels, the kernel needs a
common handle for them that exists on both sides. As handle we introduce
names for ring buffers. In a follow-up patch, the kernel can then use
these names to recover buffer contents for specific ring buffers.


Is there a way to use the trace_array name instead?

The trace_array is the structure that represents each tracing instance. And
it already has a name field. And if you can get the associated ring buffer
from that too.

struct trace_array *tr;

 tr->array_buffer.buffer

 tr->name

When you do: mkdir /sys/kernel/tracing/instance/foo

You create a new trace_array instance where tr->name = "foo" and allocates
the buffer for it as well.


The name in the ring buffer is pretty much just a copy of the trace 
array name. I use it to reconstruct which buffer we're actually 
referring to inside __ring_buffer_alloc().


I'm all ears for alternative suggestions. I suppose we could pass tr as 
argument to ring_buffer_alloc() instead of the name?



Alex




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879

Re: [PATCH 08/15] tracing: Introduce names for ring buffers

2023-12-12 Thread Steven Rostedt 
On Wed, 13 Dec 2023 00:04:45 +
Alexander Graf  wrote:

> With KHO (Kexec HandOver), we want to preserve trace buffers across
> kexec. To carry over their state between kernels, the kernel needs a
> common handle for them that exists on both sides. As handle we introduce
> names for ring buffers. In a follow-up patch, the kernel can then use
> these names to recover buffer contents for specific ring buffers.
> 

Is there a way to use the trace_array name instead?

The trace_array is the structure that represents each tracing instance. And
it already has a name field. And if you can get the associated ring buffer
from that too.

struct trace_array *tr;

tr->array_buffer.buffer

tr->name

When you do: mkdir /sys/kernel/tracing/instance/foo

You create a new trace_array instance where tr->name = "foo" and allocates
the buffer for it as well.

-- Steve