Re: [PATCH v9 01/12] user_events: Add minimal support for trace_event into ftrace

[Nathan Chancellor <nathan@kernel.org>]

On Fri, Jan 14, 2022 at 11:30:05PM +0800, kernel test robot wrote:
> Hi Beau,
> 
> Thank you for the patch! Perhaps something to improve:
> 
> [auto build test WARNING on 85c62c8c3749eec02ba81217bdcac26867dc262e]
> 
> url:    https://github.com/0day-ci/linux/commits/Beau-Belgrave/user_events-Enable-user-processes-to-create-and-write-to-trace-events/20220112-014042
> base:   85c62c8c3749eec02ba81217bdcac26867dc262e
> config: hexagon-allmodconfig (https://download.01.org/0day-ci/archive/20220114/202201142322.DpkhCCS2-lkp@intel.com/config)
> compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project 82c8aca93488730ce8f66101e0f3538f14b551dd)
> reproduce (this is a W=1 build):
>         wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
>         chmod +x ~/bin/make.cross
>         # https://github.com/0day-ci/linux/commit/a5a2d34cbaeb90d281d8c13c753f4aaaa447ec11
>         git remote add linux-review https://github.com/0day-ci/linux
>         git fetch --no-tags linux-review Beau-Belgrave/user_events-Enable-user-processes-to-create-and-write-to-trace-events/20220112-014042
>         git checkout a5a2d34cbaeb90d281d8c13c753f4aaaa447ec11
>         # save the config file to linux build tree
>         mkdir build_dir
>         COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=hexagon SHELL=/bin/bash kernel/trace/ sound/soc/sof/
> 
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot <lkp@intel.com>
> 
> All warnings (new ones prefixed by >>):
> 
> >> kernel/trace/trace_events_user.c:1027:14: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
>            return NULL + (*pos == 0);
>                   ~~~~ ^
>    1 warning generated.
> 
> 
> vim +1027 kernel/trace/trace_events_user.c
> 
>   1024	
>   1025	static void *user_seq_start(struct seq_file *m, loff_t *pos)
>   1026	{
> > 1027		return NULL + (*pos == 0);
>   1028	}
>   1029	
> 

Arnd, it looks like [1] never got picked up? That would help solve
this, as this function is the same as single_start(). Should it be
resent or pinged?

[1]: https://lore.kernel.org/r/20201028151202.3074398-1-arnd@kernel.org/

Cheers,
Nathan