[PATCH] staging: vc04_services: make a couple of functions static

[Dan Carpenter]

On Mon, Jan 31, 2022 at 02:07:02PM +0100, Greg Kroah-Hartman wrote:
> On Mon, Jan 31, 2022 at 07:16:01PM +0800, kernel test robot wrote:
> > Hi Nguyen,
> > 
> > Thank you for the patch! Perhaps something to improve:
> > 
> > [auto build test WARNING on staging/staging-testing]
> > 
> > url:    https://github.com/0day-ci/linux/commits/Nguyen-Dinh-Phi/staging-vc04_services-make-a-couple-of-functions-static/20220131-151209
> > base:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git 64b2d6ffff862c0e7278198b4229e42e1abb3bb1
> > config: arm-randconfig-r002-20220130 (https://download.01.org/0day-ci/archive/20220131/202201311901.HT4PtVja-lkp@intel.com/config)
> > compiler: arm-linux-gnueabi-gcc (GCC) 11.2.0
> > 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/1b64825a2b5b3312ae309c1714239df049b018ac
> >         git remote add linux-review https://github.com/0day-ci/linux
> >         git fetch --no-tags linux-review Nguyen-Dinh-Phi/staging-vc04_services-make-a-couple-of-functions-static/20220131-151209
> >         git checkout 1b64825a2b5b3312ae309c1714239df049b018ac
> >         # save the config file to linux build tree
> >         mkdir build_dir
> >         COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross O=build_dir ARCH=arm SHELL=/bin/bash drivers/staging/vc04_services/
> > 
> > If you fix the issue, kindly add following tag as appropriate
> > Reported-by: kernel test robot <lkp at intel.com>
> > 
> > All warnings (new ones prefixed by >>):
> > 
> >    drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c: In function 'free_pagelist':
> > >> drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:434:25: warning: argument 2 null where non-null expected [-Wnonnull]
> >      434 |                         memcpy((char *)kmap(pages[0]) +
> >          |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >      435 |                                 pagelist->offset,
> >          |                                 ~~~~~~~~~~~~~~~~~
> >      436 |                                 fragments,
> >          |                                 ~~~~~~~~~~
> >      437 |                                 head_bytes);
> >          |                                 ~~~~~~~~~~~
> >    In file included from include/linux/string.h:20,
> >                     from include/linux/bitmap.h:11,
> >                     from include/linux/cpumask.h:12,
> >                     from include/linux/mm_types_task.h:14,
> >                     from include/linux/mm_types.h:5,
> >                     from include/linux/buildid.h:5,
> >                     from include/linux/module.h:14,
> >                     from drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:8:
> >    arch/arm/include/asm/string.h:20:15: note: in a call to function 'memcpy' declared 'nonnull'
> >       20 | extern void * memcpy(void *, const void *, __kernel_size_t);
> >          |               ^~~~~~
> > 
> 
> Oddly, your patch caused these build errors to happen, which implies
> that you did not test-build your patch?
> 
> I remember seeing this before and being confused as to why this type of
> change would cause this error, but it must be for some reason, which
> means we can't take this patch.
> 
> Always test-build your changes before sending them out.
> 

This is an annoying thing.

Unless I'm mistaken, it's a totally nonsense GCC false positive.  In
Smatch, I have a similar NULL dereference check, but I have never felt
confident enough to harrass people with false positives even though mine
are fewer.  (Smatch has *way* better flow analysis than GCC but the
tradeoff is that Smatch is slower.)

I can't understand why this warning triggers on this particular patch.
It has to do with the .config.  A make allmodconfig will not trigger it,
but the kbuild .config does.  Possibly to do with chance and inlining.

regards,
dan carpenter