Re: [PATCH v2 1/2] Provide READ_ONCE_NOCHECK()

[Ingo Molnar <mingo@kernel.org>]

* Andrey Ryabinin <aryabinin@virtuozzo.com> wrote:

> 
> 
> On 10/13/2015 07:02 PM, kbuild test robot wrote:
> > Hi Andrey,
> > 
> > [auto build test WARNING on tip/auto-latest -- if it's inappropriate base, please suggest rules for selecting the more suitable base]
> > 
> > url:    https://github.com/0day-ci/linux/commits/Andrey-Ryabinin/Provide-READ_ONCE_NOCHECK/20151013-204127
> > config: mn10300-allyesconfig (attached as .config)
> > reproduce:
> >         wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
> >         chmod +x ~/bin/make.cross
> >         # save the attached .config to linux build tree
> >         make.cross ARCH=mn10300 
> > 
> > All warnings (new ones prefixed by >>):
> > 
> >    fs/nfs/filelayout/filelayout.c: In function 'filelayout_read_pagelist':
> >    fs/nfs/filelayout/filelayout.c:476:2: warning: format '%Zu' expects argument of type 'size_t', but argument 5 has type '__u32' [-Wformat=]
> >      dprintk("--> %s ino %lu pgbase %u req %Zu@%llu\n",
> >      ^
> 
> So the actual warning is here. And it's not new.
> 
> >    In file included from include/linux/nfs_fs.h:28:0,
> >                     from fs/nfs/filelayout/filelayout.c:32:
> >    fs/nfs/filelayout/filelayout.c: In function 'filelayout_write_pagelist':
> >    include/linux/compiler.h:270:8: warning: format '%Zu' expects argument of type 'size_t', but argument 5 has type '__u32' [-Wformat=]
> >      union { typeof(x) __val; char __c[1]; } __u;  \
> >            ^
> >    include/linux/sunrpc/debug.h:33:24: note: in definition of macro 'dfprintk'
> >        printk(KERN_DEFAULT args); \
> >                            ^
> >>> include/linux/compiler.h:274:22: note: in expansion of macro '__READ_ONCE'
> >     #define READ_ONCE(x) __READ_ONCE(x, _check)
> >                          ^
> 
> And this 'note: in expansion of macro' belongs to the warning above.
> So it's a false-positive. 

So if this is a new warning introduced by these patches then the warning needs to 
be addresses - regardless of whether it's a false positive or not.

Thanks,

	Ingo