Hi Steven,

kernel test robot noticed the following build errors:

[auto build test ERROR on v7.0-rc2]
[cannot apply to trace/for-next linus/master next-20260306]
[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/Steven-Rostedt/tracing-Move-snapshot-code-out-of-trace-c-and-into-trace_snapshot-c/20260306-102714
base:   v7.0-rc2
patch link:    https://lore.kernel.org/r/20260305211810.3f48aa07%40robin
patch subject: [PATCH] tracing: Move snapshot code out of trace.c and into 
trace_snapshot.c
config: arc-randconfig-002-20260307 
(https://download.01.org/0day-ci/archive/20260307/[email protected]/config)
compiler: arc-linux-gcc (GCC) 14.3.0
reproduce (this is a W=1 build): 
(https://download.01.org/0day-ci/archive/20260307/[email protected]/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 <[email protected]>
| Closes: 
https://lore.kernel.org/oe-kbuild-all/[email protected]/

All errors (new ones prefixed by >>):

>> kernel/trace/trace_snapshot.c:395:20: error: redefinition of 
>> 'latency_fsnotify'
     395 | static inline void latency_fsnotify(struct trace_array *tr) { }
         |                    ^~~~~~~~~~~~~~~~
   In file included from kernel/trace/trace_snapshot.c:6:
   kernel/trace/trace.h:852:20: note: previous definition of 'latency_fsnotify' 
with type 'void(struct trace_array *)'
     852 | static inline void latency_fsnotify(struct trace_array *tr) { }
         |                    ^~~~~~~~~~~~~~~~


vim +/latency_fsnotify +395 kernel/trace/trace_snapshot.c

   382  
   383  void latency_fsnotify(struct trace_array *tr)
   384  {
   385          if (!fsnotify_wq)
   386                  return;
   387          /*
   388           * We cannot call queue_work(&tr->fsnotify_work) from here 
because it's
   389           * possible that we are called from __schedule() or do_idle(), 
which
   390           * could cause a deadlock.
   391           */
   392          irq_work_queue(&tr->fsnotify_irqwork);
   393  }
   394  #else
 > 395  static inline void latency_fsnotify(struct trace_array *tr) { }
   396  #endif /* LATENCY_FS_NOTIFY */
   397  static const struct file_operations tracing_max_lat_fops;
   398  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Reply via email to