linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi all,

After merging the akpm-current tree, yesterday's linux-next build
(htmldocs) produced this warning:

mm/vmalloc.c:425: warning: expecting prototype for vunmap_range_noflush(). 
Prototype was for vunmap_range() instead

Introduced by commit

  cde193f42509 ("mm/vmalloc: remove unmap_kernel_range")

-- 
Cheers,
Stephen Rothwell


pgpdxtMoHErye.pgp
Description: OpenPGP digital signature

Re: linux-next: build warning after merge of the akpm-current tree

[Mauro Carvalho Chehab]

Em Tue, 16 Mar 2021 17:09:20 -0600
Jonathan Corbet  escreveu:

> Stephen Rothwell  writes:
> 
> [Adding Mauro]
> 
> > On Tue, 16 Mar 2021 11:18:11 -0700 Minchan Kim  wrote:
> >>
> >> On Mon, Mar 15, 2021 at 04:35:22PM +1100, Stephen Rothwell wrote:
> >> > Hi all,
> >> > 
> >> > After merging the akpm-current tree, today's linux-next build (htmldocs)
> >> > produced this warning:
> >> > 
> >> > Documentation/ABI/testing/sysfs-kernel-mm-cma:2: WARNING: Inline 
> >> > interpreted text or phrase reference start-string without end-string.
> >> > 
> >> > Introduced by commit
> >> > 
> >> >   ("mm: cma: support sysfs")
> >> >   
> >> 
> >> Hmm, I don't get it what happened here. Was it false-positive?
> >
> > I get the above from a "make htmldocs" run ... I don't know what causes
> > it, sorry.  [cc'ing Jon]
> 
> OK, this took a while to figure out.  The problem is this text in
> sysfs-kernel-mm-cma:
> 
> > Each CMA heap subdirectory (that is, each
> > /sys/kernel/mm/cma/ directory) contains the
> > following items:
> 
> When scripts/get_abi.pl sees the /sys/kernel/mm/... string it wants to
> turn it into a link to the matching ABI entry; at that point, the
>  collides with the Sphinx directive and you get
> that totally useless warning.
> 
> I think this is a bug in get_abi.pl. Honestly I wonder if all these
> cross-links are needed at all; if they truly are, then we shouldn't be
> making bogus ones.  Mauro, how hard would it be to make this do the
> right thing?

Actually, we need the "<>" syntax a the output document.

Basically, the script assumes that everything inside the ABI description
is ReST. So, it preserves the text untouched, except when creating
cross-references, which is the case here. The script expects an entry
for every cross-referenced symbol. In other words, something like:

/sys/kernel/mm/cma/ 

should be converted into:

:ref:`/sys/kernel/mm/cma/ `

The actual output is more complex than that, as there are some special
chars that need to be escaped at the naming part.

You can check the full output of this single file with:

$ mkdir Documentation/ABI/aa && cp 
Documentation/ABI/testing/sysfs-kernel-mm-cma
$ ./scripts/get_abi.pl --dir=Documentation/ABI/aa rest

Symbols under /sys/kernel
-

.. _abi_sys_kernel_mm_cma:

+-+
| **/sys/kernel/mm/cma/** |
+-+

Defined on file :ref:`sysfs-kernel-mm-cma 
`

:ref:`\/sys\/kernel\/mm\/cma\/ ` contains a 
subdirectory for each CMA
heap name (also sometimes called CMA areas).

Each CMA heap subdirectory (that is, each
:ref:`\/sys\/kernel\/mm\/cma\/ ` 
directory) contains the
following items:

alloc_pages_success
alloc_pages_fail


.. _abi_sys_kernel_mm_cma_cma_heap_name_alloc_pages_fail:

+-+
| **/sys/kernel/mm/cma//alloc\_pages\_fail** |
+-+

Defined on file :ref:`sysfs-kernel-mm-cma 
`

the number of pages CMA API failed to allocate


.. _abi_sys_kernel_mm_cma_cma_heap_name_alloc_pages_success:

++
| **/sys/kernel/mm/cma//alloc\_pages\_success** |
++

Defined on file :ref:`sysfs-kernel-mm-cma 
`

the number of pages CMA API succeeded to allocate


.. _abi_file_aa_sysfs_kernel_mm_cma:

File aa/sysfs\-kernel\-mm\-cma
--

Has the following ABI:

- :ref:`\/sys\/kernel\/mm\/cma\/ `

- 
:ref:`\/sys\/kernel\/mm\/cma\/\\/alloc_pages_success 
`

- :ref:`\/sys\/kernel\/mm\/cma\/\\/alloc_pages_fail 
`

There are two separated issues here:

1) the cross-reference for "/sys/kernel/mm/cma/"
   doesn't exist. The fix would be to do something like:

What:   /sys/kernel/mm/cma/
Date:   Feb 2021
Contact:Minchan Kim 
Description:
/sys/kernel/mm/cma/ contains a subdirectory for each CMA
heap name (also sometimes called CMA areas).

Each CMA heap subdirectory contains the following items:


/sys/kernel/mm/cma//alloc_pages_success

/sys/kernel/mm/cma//alloc_pages_fail

  This way, the /sys/kernel/mm/cma//* will produce the
  right cross-references;

2) The get_abi.pl doesn't escape "<" and ">" chars.

  The 

Re: linux-next: build warning after merge of the akpm-current tree

[Jonathan Corbet]

Stephen Rothwell  writes:

[Adding Mauro]

> On Tue, 16 Mar 2021 11:18:11 -0700 Minchan Kim  wrote:
>>
>> On Mon, Mar 15, 2021 at 04:35:22PM +1100, Stephen Rothwell wrote:
>> > Hi all,
>> > 
>> > After merging the akpm-current tree, today's linux-next build (htmldocs)
>> > produced this warning:
>> > 
>> > Documentation/ABI/testing/sysfs-kernel-mm-cma:2: WARNING: Inline 
>> > interpreted text or phrase reference start-string without end-string.
>> > 
>> > Introduced by commit
>> > 
>> >   439d477342a3 ("mm: cma: support sysfs")
>> >   
>> 
>> Hmm, I don't get it what happened here. Was it false-positive?
>
> I get the above from a "make htmldocs" run ... I don't know what causes
> it, sorry.  [cc'ing Jon]

OK, this took a while to figure out.  The problem is this text in
sysfs-kernel-mm-cma:

>   Each CMA heap subdirectory (that is, each
>   /sys/kernel/mm/cma/ directory) contains the
>   following items:

When scripts/get_abi.pl sees the /sys/kernel/mm/... string it wants to
turn it into a link to the matching ABI entry; at that point, the
 collides with the Sphinx directive and you get
that totally useless warning.

I think this is a bug in get_abi.pl.  Honestly I wonder if all these
cross-links are needed at all; if they truly are, then we shouldn't be
making bogus ones.  Mauro, how hard would it be to make this do the
right thing?

Thanks,

jon

Re: linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi Minchan,

On Tue, 16 Mar 2021 11:18:11 -0700 Minchan Kim  wrote:
>
> On Mon, Mar 15, 2021 at 04:35:22PM +1100, Stephen Rothwell wrote:
> > Hi all,
> > 
> > After merging the akpm-current tree, today's linux-next build (htmldocs)
> > produced this warning:
> > 
> > Documentation/ABI/testing/sysfs-kernel-mm-cma:2: WARNING: Inline 
> > interpreted text or phrase reference start-string without end-string.
> > 
> > Introduced by commit
> > 
> >   439d477342a3 ("mm: cma: support sysfs")
> >   
> 
> Hmm, I don't get it what happened here. Was it false-positive?

I get the above from a "make htmldocs" run ... I don't know what causes
it, sorry.  [cc'ing Jon]

-- 
Cheers,
Stephen Rothwell


pgpm1e8cx4j7N.pgp
Description: OpenPGP digital signature

Re: linux-next: build warning after merge of the akpm-current tree

[Minchan Kim]

On Mon, Mar 15, 2021 at 04:35:22PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the akpm-current tree, today's linux-next build (htmldocs)
> produced this warning:
> 
> Documentation/ABI/testing/sysfs-kernel-mm-cma:2: WARNING: Inline interpreted 
> text or phrase reference start-string without end-string.
> 
> Introduced by commit
> 
>   439d477342a3 ("mm: cma: support sysfs")
> 

Hmm, I don't get it what happened here. Was it false-positive?

linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi all,

After merging the akpm-current tree, today's linux-next build (htmldocs)
produced this warning:

Documentation/ABI/testing/sysfs-kernel-mm-cma:2: WARNING: Inline interpreted 
text or phrase reference start-string without end-string.

Introduced by commit

  439d477342a3 ("mm: cma: support sysfs")

-- 
Cheers,
Stephen Rothwell


pgpxETm1WAzk7.pgp
Description: OpenPGP digital signature

Re: linux-next: build warning after merge of the akpm-current tree

[Georgi Djakov]

Thanks for the report Stephen!

Andrew, I have sent you an updated patch. Please let me know if you prefer
a follow-up fix instead.

BR,
Georgi

On 12/10/20 11:38, Stephen Rothwell wrote:

Hi all,

After merging the akpm-current tree, today's linux-next build (htmldocs)
produced this warning:

Documentation/vm/page_owner.rst:44: WARNING: Literal block ends without a blank 
line; unexpected unindent.
Documentation/vm/page_owner.rst:49: WARNING: Literal block ends without a blank 
line; unexpected unindent.

Introduced by commit

   6cf22751938a ("mm/page_owner: Record timestamp and pid")

linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi all,

After merging the akpm-current tree, today's linux-next build (htmldocs)
produced this warning:

Documentation/vm/page_owner.rst:44: WARNING: Literal block ends without a blank 
line; unexpected unindent.
Documentation/vm/page_owner.rst:49: WARNING: Literal block ends without a blank 
line; unexpected unindent.

Introduced by commit

  6cf22751938a ("mm/page_owner: Record timestamp and pid")

-- 
Cheers,
Stephen Rothwell


pgp0Xpdj1SewG.pgp
Description: OpenPGP digital signature

Re: linux-next: build warning after merge of the akpm-current tree

[Andy Shevchenko]

On Fri, Nov 13, 2020 at 05:01:01PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the akpm-current tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
> 
> WARNING: modpost: missing MODULE_LICENSE() in lib/cmdline_kunit.o
> 
> Introduced by commit
> 
>   f1a15df76475 ("lib/cmdline_kunit: add a new test suite for cmdline API")

I'm on it right now, thanks!

-- 
With Best Regards,
Andy Shevchenko

linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi all,

After merging the akpm-current tree, today's linux-next build (x86_64
allmodconfig) produced this warning:

WARNING: modpost: missing MODULE_LICENSE() in lib/cmdline_kunit.o

Introduced by commit

  f1a15df76475 ("lib/cmdline_kunit: add a new test suite for cmdline API")

-- 
Cheers,
Stephen Rothwell


pgpwOq2BtzM_F.pgp
Description: OpenPGP digital signature

linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi all,

After merging the akpm-current tree, today's linux-next build (htmldocs)
produced this warning:

include/linux/kfence.h:138: warning: Function parameter or member 'addr' not 
described in 'kfence_object_start'

Introduced by patch

  mm: add Kernel Electric-Fence infrastructure

-- 
Cheers,
Stephen Rothwell


pgphXPy92mog5.pgp
Description: OpenPGP digital signature

Re: linux-next: build warning after merge of the akpm-current tree

[Mike Rapoport]

On Thu, Nov 05, 2020 at 06:45:04PM +1100, Anand K. Mistry wrote:
> SNIPPED
> 
> > >
> > > Looks like left column became too wide, so rather than shift the right
> > > column to the right, I'd suggest to drop underscores in Speculation*.
> >
> > Hm. That makes it inconsistent with Speculation_Store_Bypass. I guess
> > it's the lesser of two evils.
> 
> Oh, do you mean renaming the existing Speculation_Store_Bypass? I
> thought that was a big no-no for the kernel?

Right, renaming is not an option :)

I thought Speculation_Store_Bypass was also introduced by the same
patch, sorry about the confusion. 

-- 
Sincerely yours,
Mike.

Re: linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi Anand,

On Thu, 5 Nov 2020 19:00:11 +1100 Stephen Rothwell  
wrote:
>
> On Thu, 5 Nov 2020 18:42:23 +1100 "Anand K. Mistry"  
> wrote:
> >
> > How would I go about fixing this? Send a new (v2), fixed patch to the
> > mailing list? I'm not that familiar with how patches get merged
> > through the branches.  
> 
> Since this is in Andrew's quilt series, either a v2, or an incremental
> patch (to wherever the original went - including cc'ing Andrew).  If
> you send a v2, he will probably turn it into an incremental patch and
> then squash it back before sending it to Linus.

And if you cc me as well, I will add it to the copy of Andrew's series
that I have in linux-next (so I won't have to worry about the warning
until Andrew gets around to sending out a new version of his quilt
series).
-- 
Cheers,
Stephen Rothwell


pgpA7KLhkbo0N.pgp
Description: OpenPGP digital signature

Re: linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi Anand,

On Thu, 5 Nov 2020 18:42:23 +1100 "Anand K. Mistry"  wrote:
>
> How would I go about fixing this? Send a new (v2), fixed patch to the
> mailing list? I'm not that familiar with how patches get merged
> through the branches.

Since this is in Andrew's quilt series, either a v2, or an incremental
patch (to wherever the original went - including cc'ing Andrew).  If
you send a v2, he will probably turn it into an incremental patch and
then squash it back before sending it to Linus.

-- 
Cheers,
Stephen Rothwell


pgpCM8nHbVhAM.pgp
Description: OpenPGP digital signature

Re: linux-next: build warning after merge of the akpm-current tree

[Anand K. Mistry]

SNIPPED

> >
> > Looks like left column became too wide, so rather than shift the right
> > column to the right, I'd suggest to drop underscores in Speculation*.
>
> Hm. That makes it inconsistent with Speculation_Store_Bypass. I guess
> it's the lesser of two evils.

Oh, do you mean renaming the existing Speculation_Store_Bypass? I
thought that was a big no-no for the kernel?

Re: linux-next: build warning after merge of the akpm-current tree

[Anand K. Mistry]

On Thu, 5 Nov 2020 at 18:03, Mike Rapoport  wrote:
>
> On Thu, Nov 05, 2020 at 05:45:49PM +1100, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the akpm-current tree, today's linux-next build (htmldocs)
> > produced this warning:
> >
> > Documentation/filesystems/proc.rst:296: WARNING: Malformed table.
> > Text in column margin in table line 61.
> >
> > ==  
> > ===
> > Field   Content
> > ==  
> > ===
>   ...
> > Speculation_Store_Bypassspeculative store bypass mitigation status
> > Speculation_Indirect_Branch indirect branch speculation mode
>   ...
> > ==  
> > ===
> > Documentation/filesystems/proc.rst:234: WARNING: Error parsing content 
> > block for the "table" directive: exactly one table expected.
>
> Looks like left column became too wide, so rather than shift the right
> column to the right, I'd suggest to drop underscores in Speculation*.

Hm. That makes it inconsistent with Speculation_Store_Bypass. I guess
it's the lesser of two evils.

How would I go about fixing this? Send a new (v2), fixed patch to the
mailing list? I'm not that familiar with how patches get merged
through the branches.

>
> >
> > .. table:: Table 1-2: Contents of the status files (as of 4.19)
> >
> >  ==  
> > ===
> >  Field   Content
> >  ==  
> > ===
>...
> >  Speculation_Store_Bypassspeculative store bypass mitigation status
> >  Speculation_Indirect_Branch indirect branch speculation mode
> >  Cpus_allowedmask of CPUs on which this process may run
> >  Cpus_allowed_list   Same as previous, but in "list format"
> >  Mems_allowedmask of memory nodes allowed to this process
> >  Mems_allowed_list   Same as previous, but in "list format"
> >  voluntary_ctxt_switches number of voluntary context switches
> >  nonvoluntary_ctxt_switches  number of non voluntary context switches
> >  ==  
> > ===
>
> Same here.
>
> > Introduced by commit
> >
> >   60b492d745d5 ("proc: provide details on indirect branch speculation")
> >
> > --
> > Cheers,
> > Stephen Rothwell
>
>
>
> --
> Sincerely yours,
> Mike.



-- 
Anand K. Mistry
Software Engineer
Google Australia

Re: linux-next: build warning after merge of the akpm-current tree

[Mike Rapoport]

On Thu, Nov 05, 2020 at 05:45:49PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the akpm-current tree, today's linux-next build (htmldocs)
> produced this warning:
> 
> Documentation/filesystems/proc.rst:296: WARNING: Malformed table.
> Text in column margin in table line 61.
> 
> ==  
> ===
> Field   Content
> ==  
> ===
  ...
> Speculation_Store_Bypassspeculative store bypass mitigation status
> Speculation_Indirect_Branch indirect branch speculation mode
  ...
> ==  
> ===
> Documentation/filesystems/proc.rst:234: WARNING: Error parsing content block 
> for the "table" directive: exactly one table expected.

Looks like left column became too wide, so rather than shift the right
column to the right, I'd suggest to drop underscores in Speculation*.

> 
> .. table:: Table 1-2: Contents of the status files (as of 4.19)
> 
>  ==  
> ===
>  Field   Content
>  ==  
> ===
   ...
>  Speculation_Store_Bypassspeculative store bypass mitigation status
>  Speculation_Indirect_Branch indirect branch speculation mode
>  Cpus_allowedmask of CPUs on which this process may run
>  Cpus_allowed_list   Same as previous, but in "list format"
>  Mems_allowedmask of memory nodes allowed to this process
>  Mems_allowed_list   Same as previous, but in "list format"
>  voluntary_ctxt_switches number of voluntary context switches
>  nonvoluntary_ctxt_switches  number of non voluntary context switches
>  ==  
> ===

Same here.
 
> Introduced by commit
> 
>   60b492d745d5 ("proc: provide details on indirect branch speculation")
> 
> -- 
> Cheers,
> Stephen Rothwell



-- 
Sincerely yours,
Mike.

linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi all,

After merging the akpm-current tree, today's linux-next build (htmldocs)
produced this warning:

Documentation/filesystems/proc.rst:296: WARNING: Malformed table.
Text in column margin in table line 61.

==  ===
Field   Content
==  ===
Namefilename of the executable
Umask   file mode creation mask
State   state (R is running, S is sleeping, D is sleeping
in an uninterruptible wait, Z is zombie,
T is traced or stopped)
Tgidthread group ID
NgidNUMA group ID (0 if none)
Pid process id
PPidprocess id of the parent process
TracerPid   PID of process tracing this process (0 if not)
Uid Real, effective, saved set, and  file system UIDs
Gid Real, effective, saved set, and  file system GIDs
FDSize  number of file descriptor slots currently allocated
Groups  supplementary group list
NStgid  descendant namespace thread group ID hierarchy
NSpid   descendant namespace process ID hierarchy
NSpgid  descendant namespace process group ID hierarchy
NSsid   descendant namespace session ID hierarchy
VmPeak  peak virtual memory size
VmSize  total program size
VmLck   locked memory size
VmPin   pinned memory size
VmHWM   peak resident set size ("high water mark")
VmRSS   size of memory portions. It contains the three
following parts
(VmRSS = RssAnon + RssFile + RssShmem)
RssAnon size of resident anonymous memory
RssFile size of resident file mappings
RssShmemsize of resident shmem memory (includes SysV shm,
mapping of tmpfs and shared anonymous mappings)
VmData  size of private data segments
VmStk   size of stack segments
VmExe   size of text segment
VmLib   size of shared library code
VmPTE   size of page table entries
VmSwap  amount of swap used by anonymous private data
(shmem swap usage is not included)
HugetlbPagessize of hugetlb memory portions
CoreDumping process's memory is currently being dumped
(killing the process may lead to a corrupted core)
THP_enabled process is allowed to use THP (returns 0 when
PR_SET_THP_DISABLE is set on the process
Threads number of threads
SigQnumber of signals queued/max. number for queue
SigPnd  bitmap of pending signals for the thread
ShdPnd  bitmap of shared pending signals for the process
SigBlk  bitmap of blocked signals
SigIgn  bitmap of ignored signals
SigCgt  bitmap of caught signals
CapInh  bitmap of inheritable capabilities
CapPrm  bitmap of permitted capabilities
CapEff  bitmap of effective capabilities
CapBnd  bitmap of capabilities bounding set
CapAmb  bitmap of ambient capabilities
NoNewPrivs  no_new_privs, like prctl(PR_GET_NO_NEW_PRIV, ...)
Seccomp seccomp mode, like prctl(PR_GET_SECCOMP, ...)
Speculation_Store_Bypassspeculative store bypass mitigation status
Speculation_Indirect_Branch indirect branch speculation mode
Cpus_allowedmask of CPUs on which this process may run
Cpus_allowed_list   Same as previous, but in "list format"
Mems_allowedmask of memory nodes allowed to this process
Mems_allowed_list   Same as previous, but in "list format"
voluntary_ctxt_switches number of voluntary context switches
nonvoluntary_ctxt_switches  number of non voluntary context switches
==  ===
Documentation/filesystems/proc.rst:234: WARNING: Error parsing content block 
for the "table" directive: exactly one table expected.

.. table:: Table 1-2: Contents of the status files (as of 4.19)

 ==  ===
 Field   Content
 ==  ===
 Name

Re: linux-next: build warning after merge of the akpm-current tree

[Marco Elver]

On Tue, 15 Sep 2020 at 06:03, 'David Gow' via kasan-dev
 wrote:
>
> [+kasan-dev, +kunit-dev]
>
> On Mon, Sep 14, 2020 at 3:01 PM Stephen Rothwell  
> wrote:
> >
> > Hi all,
> >
> > After merging the akpm-current tree, today's linux-next build (x86_64
> > allmodconfig) produced this warning:
> >
> > In file included from lib/test_kasan_module.c:16:
> > lib/../mm/kasan/kasan.h:232:6: warning: conflicting types for built-in 
> > function '__asan_register_globals'; expected 'void(void *, long int)' 
> > [-Wbuiltin-declaration-mismatch]
> >   232 | void __asan_register_globals(struct kasan_global *globals, size_t 
> > size);
> >   |  ^~~
> > lib/../mm/kasan/kasan.h:233:6: warning: conflicting types for built-in 
> > function '__asan_unregister_globals'; expected 'void(void *, long int)' 
> > [-Wbuiltin-declaration-mismatch]
> >   233 | void __asan_unregister_globals(struct kasan_global *globals, size_t 
> > size);
> >   |  ^
> > lib/../mm/kasan/kasan.h:235:6: warning: conflicting types for built-in 
> > function '__asan_alloca_poison'; expected 'void(void *, long int)' 
> > [-Wbuiltin-declaration-mismatch]
> >   235 | void __asan_alloca_poison(unsigned long addr, size_t size);
> >   |  ^~~~
> > lib/../mm/kasan/kasan.h:236:6: warning: conflicting types for built-in 
> > function '__asan_allocas_unpoison'; expected 'void(void *, long int)' 
> > [-Wbuiltin-declaration-mismatch]
> >   236 | void __asan_allocas_unpoison(const void *stack_top, const void 
> > *stack_bottom);
> >   |  ^~~
> > lib/../mm/kasan/kasan.h:238:6: warning: conflicting types for built-in 
> > function '__asan_load1'; expected 'void(void *)' 
> > [-Wbuiltin-declaration-mismatch]
> >   238 | void __asan_load1(unsigned long addr);
> >   |  ^~~~
> [...some more similar warnings truncated...]
>
> Whoops -- these are an issue with the patch: the test_kasan_module.c
> file should be built with -fno-builtin. I've out a new version of the
> series which fixes this:
> https://lore.kernel.org/linux-mm/20200915035828.570483-1-david...@google.com/T/#t
>
> Basically, the fix is just:
>
> diff --git a/lib/Makefile b/lib/Makefile
> index 8c94cad26db7..d4af75136c54 100644
> --- a/lib/Makefile
> +++ b/lib/Makefile
> @@ -69,6 +69,7 @@ obj-$(CONFIG_KASAN_KUNIT_TEST) += test_kasan.o
>  CFLAGS_test_kasan.o += -fno-builtin
>  CFLAGS_test_kasan.o += $(call cc-disable-warning, vla)
>  obj-$(CONFIG_TEST_KASAN_MODULE) += test_kasan_module.o
> +CFLAGS_test_kasan_module.o += -fno-builtin
>  obj-$(CONFIG_TEST_UBSAN) += test_ubsan.o
>  CFLAGS_test_ubsan.o += $(call cc-disable-warning, vla)
>  UBSAN_SANITIZE_test_ubsan.o := y

That's reasonable, given it's already done for test_kasan.o.

Although the warnings only occur because it's including
"../mm/kasan/kasan.h", which include declarations for the
instrumentation functions. AFAIK, those declarations only exist to
avoid missing-declaration warnings; in which case all of them could
just be moved above their definitions in generic.c (which would also
avoid some repetition for the ones defined with macros). But given the
various other KASAN patches in-flight, to avoid conflicts let's leave
this as-is, but it's something to improve in case we wanted to get rid
of the fno-builtin.

Thanks,
-- Marco

Re: linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi David,

On Tue, 15 Sep 2020 12:03:08 +0800 David Gow  wrote:
>
> > drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c: In function 
> > 'common_nfc_set_geometry':
> > drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c:514:3: warning: initialization 
> > discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
> >   514 |   nanddev_get_ecc_requirements(>base);
> >   |   ^~~~
> >  
> 
> I was unable to reproduce this warning: it looks unrelated, so I'm
> assuming it was attributed.

Yeah, sorry, that was included by accident.

-- 
Cheers,
Stephen Rothwell


pgp69D8trCJ15.pgp
Description: OpenPGP digital signature

Re: linux-next: build warning after merge of the akpm-current tree

[David Gow]

[+kasan-dev, +kunit-dev]

On Mon, Sep 14, 2020 at 3:01 PM Stephen Rothwell  wrote:
>
> Hi all,
>
> After merging the akpm-current tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
>
> In file included from lib/test_kasan_module.c:16:
> lib/../mm/kasan/kasan.h:232:6: warning: conflicting types for built-in 
> function '__asan_register_globals'; expected 'void(void *, long int)' 
> [-Wbuiltin-declaration-mismatch]
>   232 | void __asan_register_globals(struct kasan_global *globals, size_t 
> size);
>   |  ^~~
> lib/../mm/kasan/kasan.h:233:6: warning: conflicting types for built-in 
> function '__asan_unregister_globals'; expected 'void(void *, long int)' 
> [-Wbuiltin-declaration-mismatch]
>   233 | void __asan_unregister_globals(struct kasan_global *globals, size_t 
> size);
>   |  ^
> lib/../mm/kasan/kasan.h:235:6: warning: conflicting types for built-in 
> function '__asan_alloca_poison'; expected 'void(void *, long int)' 
> [-Wbuiltin-declaration-mismatch]
>   235 | void __asan_alloca_poison(unsigned long addr, size_t size);
>   |  ^~~~
> lib/../mm/kasan/kasan.h:236:6: warning: conflicting types for built-in 
> function '__asan_allocas_unpoison'; expected 'void(void *, long int)' 
> [-Wbuiltin-declaration-mismatch]
>   236 | void __asan_allocas_unpoison(const void *stack_top, const void 
> *stack_bottom);
>   |  ^~~
> lib/../mm/kasan/kasan.h:238:6: warning: conflicting types for built-in 
> function '__asan_load1'; expected 'void(void *)' 
> [-Wbuiltin-declaration-mismatch]
>   238 | void __asan_load1(unsigned long addr);
>   |  ^~~~
[...some more similar warnings truncated...]

Whoops -- these are an issue with the patch: the test_kasan_module.c
file should be built with -fno-builtin. I've out a new version of the
series which fixes this:
https://lore.kernel.org/linux-mm/20200915035828.570483-1-david...@google.com/T/#t

Basically, the fix is just:

diff --git a/lib/Makefile b/lib/Makefile
index 8c94cad26db7..d4af75136c54 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -69,6 +69,7 @@ obj-$(CONFIG_KASAN_KUNIT_TEST) += test_kasan.o
 CFLAGS_test_kasan.o += -fno-builtin
 CFLAGS_test_kasan.o += $(call cc-disable-warning, vla)
 obj-$(CONFIG_TEST_KASAN_MODULE) += test_kasan_module.o
+CFLAGS_test_kasan_module.o += -fno-builtin
 obj-$(CONFIG_TEST_UBSAN) += test_ubsan.o
 CFLAGS_test_ubsan.o += $(call cc-disable-warning, vla)
 UBSAN_SANITIZE_test_ubsan.o := y
-- 
2.28.0.618.gf4bc123cb7-goog


> drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c: In function 
> 'common_nfc_set_geometry':
> drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c:514:3: warning: initialization 
> discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
>   514 |   nanddev_get_ecc_requirements(>base);
>   |   ^~~~
>

I was unable to reproduce this warning: it looks unrelated, so I'm
assuming it was attributed.

> Introduced by commit
>
>   77e7d1c8c356 ("KASAN: Port KASAN Tests to KUnit")
>
> --
> Cheers,
> Stephen Rothwell

Sorry for the mess,
-- David

linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi all,

After merging the akpm-current tree, today's linux-next build (x86_64
allmodconfig) produced this warning:

In file included from lib/test_kasan_module.c:16:
lib/../mm/kasan/kasan.h:232:6: warning: conflicting types for built-in function 
'__asan_register_globals'; expected 'void(void *, long int)' 
[-Wbuiltin-declaration-mismatch]
  232 | void __asan_register_globals(struct kasan_global *globals, size_t size);
  |  ^~~
lib/../mm/kasan/kasan.h:233:6: warning: conflicting types for built-in function 
'__asan_unregister_globals'; expected 'void(void *, long int)' 
[-Wbuiltin-declaration-mismatch]
  233 | void __asan_unregister_globals(struct kasan_global *globals, size_t 
size);
  |  ^
lib/../mm/kasan/kasan.h:235:6: warning: conflicting types for built-in function 
'__asan_alloca_poison'; expected 'void(void *, long int)' 
[-Wbuiltin-declaration-mismatch]
  235 | void __asan_alloca_poison(unsigned long addr, size_t size);
  |  ^~~~
lib/../mm/kasan/kasan.h:236:6: warning: conflicting types for built-in function 
'__asan_allocas_unpoison'; expected 'void(void *, long int)' 
[-Wbuiltin-declaration-mismatch]
  236 | void __asan_allocas_unpoison(const void *stack_top, const void 
*stack_bottom);
  |  ^~~
lib/../mm/kasan/kasan.h:238:6: warning: conflicting types for built-in function 
'__asan_load1'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch]
  238 | void __asan_load1(unsigned long addr);
  |  ^~~~
lib/../mm/kasan/kasan.h:239:6: warning: conflicting types for built-in function 
'__asan_store1'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch]
  239 | void __asan_store1(unsigned long addr);
  |  ^
lib/../mm/kasan/kasan.h:240:6: warning: conflicting types for built-in function 
'__asan_load2'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch]
  240 | void __asan_load2(unsigned long addr);
  |  ^~~~
lib/../mm/kasan/kasan.h:241:6: warning: conflicting types for built-in function 
'__asan_store2'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch]
  241 | void __asan_store2(unsigned long addr);
  |  ^
lib/../mm/kasan/kasan.h:242:6: warning: conflicting types for built-in function 
'__asan_load4'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch]
  242 | void __asan_load4(unsigned long addr);
  |  ^~~~
lib/../mm/kasan/kasan.h:243:6: warning: conflicting types for built-in function 
'__asan_store4'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch]
  243 | void __asan_store4(unsigned long addr);
  |  ^
lib/../mm/kasan/kasan.h:244:6: warning: conflicting types for built-in function 
'__asan_load8'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch]
  244 | void __asan_load8(unsigned long addr);
  |  ^~~~
lib/../mm/kasan/kasan.h:245:6: warning: conflicting types for built-in function 
'__asan_store8'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch]
  245 | void __asan_store8(unsigned long addr);
  |  ^
lib/../mm/kasan/kasan.h:246:6: warning: conflicting types for built-in function 
'__asan_load16'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch]
  246 | void __asan_load16(unsigned long addr);
  |  ^
lib/../mm/kasan/kasan.h:247:6: warning: conflicting types for built-in function 
'__asan_store16'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch]
  247 | void __asan_store16(unsigned long addr);
  |  ^~
lib/../mm/kasan/kasan.h:248:6: warning: conflicting types for built-in function 
'__asan_loadN'; expected 'void(void *, long int)' 
[-Wbuiltin-declaration-mismatch]
  248 | void __asan_loadN(unsigned long addr, size_t size);
  |  ^~~~
lib/../mm/kasan/kasan.h:249:6: warning: conflicting types for built-in function 
'__asan_storeN'; expected 'void(void *, long int)' 
[-Wbuiltin-declaration-mismatch]
  249 | void __asan_storeN(unsigned long addr, size_t size);
  |  ^
lib/../mm/kasan/kasan.h:251:6: warning: conflicting types for built-in function 
'__asan_load1_noabort'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch]
  251 | void __asan_load1_noabort(unsigned long addr);
  |  ^~~~
lib/../mm/kasan/kasan.h:252:6: warning: conflicting types for built-in function 
'__asan_store1_noabort'; expected 'void(void *)' 
[-Wbuiltin-declaration-mismatch]
  252 | void __asan_store1_noabort(unsigned long addr);
  |  ^
lib/../mm/kasan/kasan.h:253:6: warning: conflicting types for built-in function 
'__asan_load2_noabort'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch]
  253 | void __asan_load2_noabort(unsigned long addr);
  |  ^~~~
lib/../mm/kasan/kasan.h:254:6: warning: conflicting types for built-in function 
'__asan_store2_noabort'; 

linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi all,

After merging the akpm-current tree, today's linux-next build (x86_64
allmodconfig) produced this warning:

mm/madvise.c: In function 'madvise_inject_error':
mm/madvise.c:875:15: warning: unused variable 'zone' [-Wunused-variable]
  875 |  struct zone *zone;
  |   ^~~~

Introduced by commit

  51fe27319785 ("mm,hwpoison: drop unneeded pcplist draining")

-- 
Cheers,
Stephen Rothwell


pgpomenuRD9TA.pgp
Description: OpenPGP digital signature

Re: linux-next: build warning after merge of the akpm-current tree

[Roman Gushchin]

On Fri, Jul 17, 2020 at 08:31:27PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the akpm-current tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
> 
> mm/vmstat.c:614: warning: "MAX_THRESHOLD" redefined
>   614 | #define MAX_THRESHOLD 0
>   | 
> mm/vmstat.c:172: note: this is the location of the previous definition
>   172 | #define MAX_THRESHOLD 125
>   | 
> mm/vmstat.c:614: warning: "MAX_THRESHOLD" redefined
>   614 | #define MAX_THRESHOLD 0
>   | 
> mm/vmstat.c:172: note: this is the location of the previous definition
>   172 | #define MAX_THRESHOLD 125
>   | 
> 
> Introduced by commit
> 
>   5f6bac149e10 ("mm: vmstat: fix /proc/sys/vm/stat_refresh generating false 
> warnings")
> 
> The preproccesor directives look like this:
> 
> #ifdef CONFIG_SMP
> #define MAX_THRESHOLD 125
> #ifdef CONFIG_HAVE_CMPXCHG_LOCAL
> #else
> #define MAX_THRESHOLD 0
> 
> So I guess the second MAX_THRESHOLD was put after the wrong #else?

Right, I missed it. Sorry for the inconvenience!
And thank you for pointing at it!

The following diff fixes it.

Andrew, can you, please, squash it into the
"mm: vmstat: fix /proc/sys/vm/stat_refresh generating false warnings" ?

Thank you!

--

diff --git a/mm/vmstat.c b/mm/vmstat.c
index 8f0ef8aaf8ee..08e415e0a15d 100644
--- a/mm/vmstat.c
+++ b/mm/vmstat.c
@@ -168,9 +168,12 @@ EXPORT_SYMBOL(vm_numa_stat);
 EXPORT_SYMBOL(vm_node_stat);
 
 #ifdef CONFIG_SMP
-
 #define MAX_THRESHOLD 125
+#else
+#define MAX_THRESHOLD 0
+#endif
 
+#ifdef CONFIG_SMP
 int calculate_pressure_threshold(struct zone *zone)
 {
int threshold;
@@ -611,8 +614,6 @@ void dec_node_page_state(struct page *page, enum 
node_stat_item item)
 EXPORT_SYMBOL(dec_node_page_state);
 #else
 
-#define MAX_THRESHOLD 0
-
 /*
  * Use interrupt disable to serialize counter updates
  */
-- 
2.26.2

linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi all,

After merging the akpm-current tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:

mm/vmstat.c:614: warning: "MAX_THRESHOLD" redefined
  614 | #define MAX_THRESHOLD 0
  | 
mm/vmstat.c:172: note: this is the location of the previous definition
  172 | #define MAX_THRESHOLD 125
  | 
mm/vmstat.c:614: warning: "MAX_THRESHOLD" redefined
  614 | #define MAX_THRESHOLD 0
  | 
mm/vmstat.c:172: note: this is the location of the previous definition
  172 | #define MAX_THRESHOLD 125
  | 

Introduced by commit

  5f6bac149e10 ("mm: vmstat: fix /proc/sys/vm/stat_refresh generating false 
warnings")

The preproccesor directives look like this:

#ifdef CONFIG_SMP
#define MAX_THRESHOLD 125
#ifdef CONFIG_HAVE_CMPXCHG_LOCAL
#else
#define MAX_THRESHOLD 0

So I guess the second MAX_THRESHOLD was put after the wrong #else?

-- 
Cheers,
Stephen Rothwell


pgpngSTn_nshU.pgp
Description: OpenPGP digital signature

linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi all,

After merging the akpm-current tree, today's linux-next build (i386
defconfig) produced this warning:

mm/hugetlb.c:49:20: warning: 'hugetlb_cma' defined but not used 
[-Wunused-variable]
   49 | static struct cma *hugetlb_cma[MAX_NUMNODES];
  |^~~

Maybe introduced by commit

  c70205bf186e ("mm/hugetlb: avoid hardcoding while checking if cma is enable")

-- 
Cheers,
Stephen Rothwell


pgpOeyrhaSCgm.pgp
Description: OpenPGP digital signature

linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi all,

After merging the akpm-current tree, today's linux-next build (x86_64
allmodconfig) produced this warning:

WARNING: modpost: missing MODULE_LICENSE() in lib/test_bits.o

Introduced by commit

  37f7d07028d1 ("lib/test_bits.c: add tests of GENMASK")

-- 
Cheers,
Stephen Rothwell


pgpOfpIs8XAeA.pgp
Description: OpenPGP digital signature

Re: linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi Rikard,

On Wed, 7 Aug 2019 13:29:17 +0200 Rikard Falkeborn  
wrote:
>
> Hi Stephen, Andrew
> 
> On Wed, Aug 07, 2019 at 06:00:41PM +1000, Stephen Rothwell wrote:
> > Hi all,
> > 
> > After merging the akpm-current tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> > 
> > In file included from include/linux/bits.h:22,
> >  from arch/x86/include/asm/msr-index.h:5,
> >  from arch/x86/boot/cpucheck.c:28:
> > include/linux/build_bug.h:49: warning: "BUILD_BUG_ON" redefined
> >  #define BUILD_BUG_ON(condition) \
> >  
> > In file included from arch/x86/boot/cpucheck.c:22:
> > arch/x86/boot/boot.h:31: note: this is the location of the previous 
> > definition
> >  #define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
> > 
> > Caused by commit
> > 
> >   d72f2a993607 ("linux/bits.h: add compile time sanity check of GENMASK 
> > inputs")
> > 
> > -- 
> > Cheers,
> > Stephen Rothwell  
> 
> Please drop this patch, it has additional issues that needs to be fixed
> in another revision.

I have removed it from linux-next for today.
-- 
Cheers,
Stephen Rothwell


pgplmtVQozSyP.pgp
Description: OpenPGP digital signature

Re: linux-next: build warning after merge of the akpm-current tree

[Rikard Falkeborn]

Hi Stephen, Andrew

On Wed, Aug 07, 2019 at 06:00:41PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the akpm-current tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> In file included from include/linux/bits.h:22,
>  from arch/x86/include/asm/msr-index.h:5,
>  from arch/x86/boot/cpucheck.c:28:
> include/linux/build_bug.h:49: warning: "BUILD_BUG_ON" redefined
>  #define BUILD_BUG_ON(condition) \
>  
> In file included from arch/x86/boot/cpucheck.c:22:
> arch/x86/boot/boot.h:31: note: this is the location of the previous definition
>  #define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
> 
> Caused by commit
> 
>   d72f2a993607 ("linux/bits.h: add compile time sanity check of GENMASK 
> inputs")
> 
> -- 
> Cheers,
> Stephen Rothwell

Please drop this patch, it has additional issues that needs to be fixed
in another revision.

Rikard

linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi all,

After merging the akpm-current tree, today's linux-next build (x86_64
allmodconfig) failed like this:

In file included from include/linux/bits.h:22,
 from arch/x86/include/asm/msr-index.h:5,
 from arch/x86/boot/cpucheck.c:28:
include/linux/build_bug.h:49: warning: "BUILD_BUG_ON" redefined
 #define BUILD_BUG_ON(condition) \
 
In file included from arch/x86/boot/cpucheck.c:22:
arch/x86/boot/boot.h:31: note: this is the location of the previous definition
 #define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))

Caused by commit

  d72f2a993607 ("linux/bits.h: add compile time sanity check of GENMASK inputs")

-- 
Cheers,
Stephen Rothwell


pgplHaF4AYS3z.pgp
Description: OpenPGP digital signature

Re: linux-next: build warning after merge of the akpm-current tree

[Miles Chen]

On Thu, 2019-08-01 at 16:39 +1000, Stephen Rothwell wrote:
> Hi Miles,
> 
> On Thu, 1 Aug 2019 14:30:03 +0800 Miles Chen  wrote:
> >
> > It's the first time that I receive a build warning after the patch has
> > been merged to -mm tree. The build warning had been fixed by Qian,
> > should I send another change for this?
> 
> No, that will do.

got it. thanks

Re: linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi Miles,

On Thu, 1 Aug 2019 14:30:03 +0800 Miles Chen  wrote:
>
> It's the first time that I receive a build warning after the patch has
> been merged to -mm tree. The build warning had been fixed by Qian,
> should I send another change for this?

No, that will do.

-- 
Cheers,
Stephen Rothwell


pgpvLVUI9YtuD.pgp
Description: OpenPGP digital signature

Re: linux-next: build warning after merge of the akpm-current tree

[Michal Hocko]

On Thu 01-08-19 14:30:03, Miles Chen wrote:
[...]
> It's the first time that I receive a build warning after the patch has
> been merged to -mm tree. The build warning had been fixed by Qian,
> should I send another change for this?
 
No need. Andrew has already picked up the fix for mmotm tree and it
should show up in linux-next soon.

Thanks!
-- 
Michal Hocko
SUSE Labs

Re: linux-next: build warning after merge of the akpm-current tree

[Miles Chen]

On Thu, 2019-08-01 at 08:15 +0200, Michal Hocko wrote:
> On Thu 01-08-19 15:51:30, Stephen Rothwell wrote:
> > Hi Miles,
> > 
> > On Wed, 31 Jul 2019 14:28:04 +0800 Miles Chen  
> > wrote:
> > >
> > > On Wed, 2019-07-31 at 16:11 +1000, Stephen Rothwell wrote:
> > > > 
> > > > After merging the akpm-current tree, today's linux-next build (powerpc
> > > > ppc64_defconfig) produced this warning:
> > > > 
> > > > mm/memcontrol.c: In function 'invalidate_reclaim_iterators':
> > > > mm/memcontrol.c:1160:11: warning: suggest parentheses around assignment 
> > > > used as truth value [-Wparentheses]
> > > >   } while (memcg = parent_mem_cgroup(memcg));
> > > >^
> > > >   
> > > 
> > > Hi Stephen,
> > > 
> > > Thanks for the telling me this. Sorry for the build warning. 
> > > Should I send patch v5 to the mailing list to fix this? 
> > 
> > You might as well (cc'ing Andrew, of course).
> > 
> > I would suggest finishing that loop like this:
> > 
> > memcg = parent_mem_cgroup(memcg);
> > } while (memcg);
> > 
> > rather than adding a set of parentheses.

thanks for the advise
> 
> Qian has already posted a patch 
> http://lkml.kernel.org/r/1564580753-17531-1-git-send-email-...@lca.pw

Thanks Qian's quick fix.

It's the first time that I receive a build warning after the patch has
been merged to -mm tree. The build warning had been fixed by Qian,
should I send another change for this?

Re: linux-next: build warning after merge of the akpm-current tree

[Michal Hocko]

On Thu 01-08-19 15:51:30, Stephen Rothwell wrote:
> Hi Miles,
> 
> On Wed, 31 Jul 2019 14:28:04 +0800 Miles Chen  wrote:
> >
> > On Wed, 2019-07-31 at 16:11 +1000, Stephen Rothwell wrote:
> > > 
> > > After merging the akpm-current tree, today's linux-next build (powerpc
> > > ppc64_defconfig) produced this warning:
> > > 
> > > mm/memcontrol.c: In function 'invalidate_reclaim_iterators':
> > > mm/memcontrol.c:1160:11: warning: suggest parentheses around assignment 
> > > used as truth value [-Wparentheses]
> > >   } while (memcg = parent_mem_cgroup(memcg));
> > >^
> > >   
> > 
> > Hi Stephen,
> > 
> > Thanks for the telling me this. Sorry for the build warning. 
> > Should I send patch v5 to the mailing list to fix this? 
> 
> You might as well (cc'ing Andrew, of course).
> 
> I would suggest finishing that loop like this:
> 
>   memcg = parent_mem_cgroup(memcg);
>   } while (memcg);
> 
> rather than adding a set of parentheses.

Qian has already posted a patch 
http://lkml.kernel.org/r/1564580753-17531-1-git-send-email-...@lca.pw
-- 
Michal Hocko
SUSE Labs

Re: linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi Miles,

On Wed, 31 Jul 2019 14:28:04 +0800 Miles Chen  wrote:
>
> On Wed, 2019-07-31 at 16:11 +1000, Stephen Rothwell wrote:
> > 
> > After merging the akpm-current tree, today's linux-next build (powerpc
> > ppc64_defconfig) produced this warning:
> > 
> > mm/memcontrol.c: In function 'invalidate_reclaim_iterators':
> > mm/memcontrol.c:1160:11: warning: suggest parentheses around assignment 
> > used as truth value [-Wparentheses]
> >   } while (memcg = parent_mem_cgroup(memcg));
> >^
> >   
> 
> Hi Stephen,
> 
> Thanks for the telling me this. Sorry for the build warning. 
> Should I send patch v5 to the mailing list to fix this? 

You might as well (cc'ing Andrew, of course).

I would suggest finishing that loop like this:

memcg = parent_mem_cgroup(memcg);
} while (memcg);

rather than adding a set of parentheses.

-- 
Cheers,
Stephen Rothwell


pgps4vx1GblfD.pgp
Description: OpenPGP digital signature

Re: linux-next: build warning after merge of the akpm-current tree

[Jia-Ju Bai]

On 2019/7/31 14:16, Stephen Rothwell wrote:

Hi all,

After merging the akpm-current tree, today's linux-next build (x86_64
allmodconfig) produced this warning:

fs/ocfs2/xattr.c:1493:13: warning: 'ocfs2_xa_add_entry' defined but not used 
[-Wunused-function]
  static void ocfs2_xa_add_entry(struct ocfs2_xa_loc *loc, u32 name_hash)
  ^~

Introduced by commit

   45d9aa3d263d ("fs: ocfs2: fix possible null-pointer dereferences in 
ocfs2_xa_prepare_entry()")



I look at the code again.
The function ocfs2_xa_add_entry() is never called when using this patch.
Thus, I think the definition of ocfs2_xa_add_entry() could be removed.
If it is okay, I can send a new patch (v3).


Best wishes,
Jia-Ju Bai

Re: linux-next: build warning after merge of the akpm-current tree

[Miles Chen]

On Wed, 2019-07-31 at 16:11 +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the akpm-current tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
> 
> mm/memcontrol.c: In function 'invalidate_reclaim_iterators':
> mm/memcontrol.c:1160:11: warning: suggest parentheses around assignment used 
> as truth value [-Wparentheses]
>   } while (memcg = parent_mem_cgroup(memcg));
>^
> 

Hi Stephen,

Thanks for the telling me this. Sorry for the build warning. 
Should I send patch v5 to the mailing list to fix this? 


Miles

> Introduced by commit
> 
>   c48a2f5ce935 ("mm/memcontrol.c: fix use after free in mem_cgroup_iter()")
> 

linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi all,

After merging the akpm-current tree, today's linux-next build (x86_64
allmodconfig) produced this warning:

fs/ocfs2/xattr.c:1493:13: warning: 'ocfs2_xa_add_entry' defined but not used 
[-Wunused-function]
 static void ocfs2_xa_add_entry(struct ocfs2_xa_loc *loc, u32 name_hash)
 ^~

Introduced by commit

  45d9aa3d263d ("fs: ocfs2: fix possible null-pointer dereferences in 
ocfs2_xa_prepare_entry()")

-- 
Cheers,
Stephen Rothwell


pgpQVtpKg7T7A.pgp
Description: OpenPGP digital signature

linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi all,

After merging the akpm-current tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:

mm/memcontrol.c: In function 'invalidate_reclaim_iterators':
mm/memcontrol.c:1160:11: warning: suggest parentheses around assignment used as 
truth value [-Wparentheses]
  } while (memcg = parent_mem_cgroup(memcg));
   ^

Introduced by commit

  c48a2f5ce935 ("mm/memcontrol.c: fix use after free in mem_cgroup_iter()")

-- 
Cheers,
Stephen Rothwell


pgpC2A5wwHSmS.pgp
Description: OpenPGP digital signature

linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi all,

After merging the akpm-current tree, today's linux-next build (x86_64
allmodconfig) produced this warning:

drivers/infiniband/sw/siw/siw_mem.c: In function 'siw_free_plist':
drivers/infiniband/sw/siw/siw_mem.c:66:16: warning: unused variable 'p' 
[-Wunused-variable]
  struct page **p = chunk->plist;
^

Introduced by commit

  63630f9a8d72 ("mm/gup: add make_dirty arg to put_user_pages_dirty_lock()")

-- 
Cheers,
Stephen Rothwell


pgpyDzupnONUj.pgp
Description: OpenPGP digital signature

linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi all,

After merging the akpm-current tree, today's linux-next build (x86_64
allmodconfig) produced this warning:

lib/rbtree_test.c: In function 'check_augmented':
lib/rbtree_test.c:220:18: warning: unused variable 'rb' [-Wunused-variable]
  struct rb_node *rb;
  ^~

Introduced by commit

  33a64f781816 ("augmented-rbtree-add-new-rb_declare_callbacks_max-macro-fix-2")

-- 
Cheers,
Stephen Rothwell


pgpTauRTgVPnB.pgp
Description: OpenPGP digital signature

Re: linux-next: build warning after merge of the akpm-current tree

[Matteo Croce]

On Thu, May 30, 2019 at 6:55 AM Stephen Rothwell  wrote:
>
> Hi all,
>
> After merging the akpm-current tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
>
> net/tipc/sysctl.c:42:12: warning: 'one' defined but not used 
> [-Wunused-variable]
>  static int one = 1;
> ^~~
> net/tipc/sysctl.c:41:12: warning: 'zero' defined but not used 
> [-Wunused-variable]
>  static int zero;
> ^~~~
>
> Introduced by commit
>
>   6a33853c5773 ("proc/sysctl: add shared variables for range check")
>
> --
> Cheers,
> Stephen Rothwell

Hi,

this is due the merge of:

commit 4bcd4ec1017205644a2697bccbc3b5143f522f5f
Author: Jie Liu 
Date:   Tue Apr 16 13:10:09 2019 +0800

tipc: set sysctl_tipc_rmem and named_timeout right range

I'm making a patch to suppress the warning.

Regards,
-- 
Matteo Croce
per aspera ad upstream

linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi all,

After merging the akpm-current tree, today's linux-next build (x86_64
allmodconfig) produced this warning:

net/tipc/sysctl.c:42:12: warning: 'one' defined but not used [-Wunused-variable]
 static int one = 1;
^~~
net/tipc/sysctl.c:41:12: warning: 'zero' defined but not used 
[-Wunused-variable]
 static int zero;
^~~~

Introduced by commit

  6a33853c5773 ("proc/sysctl: add shared variables for range check")

-- 
Cheers,
Stephen Rothwell


pgpzBtms8ZaMe.pgp
Description: OpenPGP digital signature

Re: linux-next: build warning after merge of the akpm-current tree

[Andrew Morton]

On Tue, 16 Apr 2019 16:52:56 +1000 Stephen Rothwell  
wrote:

> Hi all,
> 
> On Fri, 29 Mar 2019 13:39:14 +1100 Stephen Rothwell  
> wrote:
> >
> > After merging the akpm-current tree, today's linux-next build (arm
> > multi_v7_defconfig) produced this warning:
> > 
> > lib/list_sort.c:17:36: warning: 'pure' attribute ignored [-Wattributes]
> >struct list_head const *, struct list_head const *);
> > ^
> > 
> > Introduced by commit
> > 
> >   820c81be5237 ("lib/list_sort: simplify and remove MAX_LIST_LENGTH_BITS")
> 
> I am still getting that warning :-(

Me too and I can't figure it out.

Shrug, I guess we take a pass on it until someone has time/inclination
to revisit it.

--- a/lib/list_sort.c~lib-list_sort-simplify-and-remove-max_list_length_bits-fix
+++ a/lib/list_sort.c
@@ -7,13 +7,7 @@
 #include 
 #include 
 
-/*
- * By declaring the compare function with the __pure attribute, we give
- * the compiler more opportunity to optimize.  Ideally, we'd use this in
- * the prototype of list_sort(), but that would involve a lot of churn
- * at all call sites, so just cast the function pointer passed in.
- */
-typedef int __pure __attribute__((nonnull(2,3))) (*cmp_func)(void *,
+typedef int __attribute__((nonnull(2,3))) (*cmp_func)(void *,
struct list_head const *, struct list_head const *);
 
 /*
_

Re: linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi all,

On Fri, 29 Mar 2019 13:39:14 +1100 Stephen Rothwell  
wrote:
>
> After merging the akpm-current tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning:
> 
> lib/list_sort.c:17:36: warning: 'pure' attribute ignored [-Wattributes]
>struct list_head const *, struct list_head const *);
> ^
> 
> Introduced by commit
> 
>   820c81be5237 ("lib/list_sort: simplify and remove MAX_LIST_LENGTH_BITS")

I am still getting that warning :-(

-- 
Cheers,
Stephen Rothwell


pgpXtISy0mKZY.pgp
Description: OpenPGP digital signature

linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi all,

After merging the akpm-current tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:

lib/list_sort.c:17:36: warning: 'pure' attribute ignored [-Wattributes]
   struct list_head const *, struct list_head const *);
^

Introduced by commit

  820c81be5237 ("lib/list_sort: simplify and remove MAX_LIST_LENGTH_BITS")

-- 
Cheers,
Stephen Rothwell


pgpTpvx7K6CxJ.pgp
Description: OpenPGP digital signature

linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi all,

After merging the akpm-current tree, today's linux-next build (x86_64
allmodconfig) produced this warning:

In file included from arch/x86/include/asm/percpu.h:45,
 from arch/x86/include/asm/current.h:6,
 from include/linux/sched.h:12,
 from include/linux/uaccess.h:5,
 from fs/proc/base.c:51:
fs/proc/base.c: In function 'proc_smack_attr_dir_lookup':
include/linux/kernel.h:73:25: warning: passing argument 4 of 
'proc_pident_lookup' makes pointer from integer without a cast 
[-Wint-conversion]
 #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
 ^~~
fs/proc/base.c:2602:7: note: in expansion of macro 'ARRAY_SIZE'
   ARRAY_SIZE(LSM##_attr_dir_stuff)); \
   ^~
fs/proc/base.c:2615:1: note: in expansion of macro 'LSM_DIR_OPS'
 LSM_DIR_OPS(smack);
 ^~~
fs/proc/base.c:2454:31: note: expected 'const struct pid_entry *' but argument 
is of type 'long unsigned int'
   const struct pid_entry *end)
   ^~~

Introduced by commit

  f6e3521a4c5b ("proc: calculate end pointer for /proc/*/* lookup at compile 
time")

interacting with commit

  6d9c939dbe4d ("procfs: add smack subdir to attrs")

from the security tree.

I have applied the following merge fix patch

From: Stephen Rothwell 
Date: Thu, 31 Jan 2019 15:56:56 +1100
Subject: [PATCH] proc: merge fix for proc_pident_lookup() API change

Signed-off-by: Stephen Rothwell 
---
 fs/proc/base.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/proc/base.c b/fs/proc/base.c
index 4ac7f32c1929..3daca4367d29 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -2599,7 +2599,7 @@ static struct dentry *proc_##LSM##_attr_dir_lookup(struct 
inode *dir, \
 { \
return proc_pident_lookup(dir, dentry, \
  LSM##_attr_dir_stuff, \
- ARRAY_SIZE(LSM##_attr_dir_stuff)); \
+ LSM##_attr_dir_stuff + 
ARRAY_SIZE(LSM##_attr_dir_stuff)); \
 } \
 \
 static const struct inode_operations proc_##LSM##_attr_dir_inode_ops = { \
-- 
2.20.1

---
Cheers,
Stephen Rothwell


pgpzYnqToccFd.pgp
Description: OpenPGP digital signature

linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:

In file included from fs/fat/inode.c:24:0:
fs/fat/inode.c: In function '__fat_get_block':
fs/fat/inode.c:163:9: warning: format '%ld' expects argument of type 'long 
int', but argument 5 has type 'sector_t {aka long long unsigned int}' 
[-Wformat=]
 "invalid FAT chain (i_pos %lld, last_block %ld)",
 ^
fs/fat/fat.h:397:24: note: in definition of macro 'fat_fs_error'
  __fat_fs_error(sb, 1, fmt , ## args)
^~~

Introduced by commit

  3bdac70a1921 ("fat: use fat_fs_error() instead of BUG_ON() in 
__fat_get_block()")

-- 
Cheers,
Stephen Rothwell


pgpZZNY9AlJz2.pgp
Description: OpenPGP digital signature

linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:

In file included from fs/fat/inode.c:24:0:
fs/fat/inode.c: In function '__fat_get_block':
fs/fat/inode.c:163:9: warning: format '%ld' expects argument of type 'long 
int', but argument 5 has type 'sector_t {aka long long unsigned int}' 
[-Wformat=]
 "invalid FAT chain (i_pos %lld, last_block %ld)",
 ^
fs/fat/fat.h:397:24: note: in definition of macro 'fat_fs_error'
  __fat_fs_error(sb, 1, fmt , ## args)
^~~

Introduced by commit

  3bdac70a1921 ("fat: use fat_fs_error() instead of BUG_ON() in 
__fat_get_block()")

-- 
Cheers,
Stephen Rothwell


pgpZZNY9AlJz2.pgp
Description: OpenPGP digital signature

Re: linux-next: build warning after merge of the akpm-current tree

[Minchan Kim]

On Mon, May 07, 2018 at 09:47:54AM -0700, Randy Dunlap wrote:
> On 05/07/2018 07:10 AM, Minchan Kim wrote:
> > On Fri, May 04, 2018 at 08:39:43AM -0700, Randy Dunlap wrote:
> >> On 05/03/2018 09:17 PM, Stephen Rothwell wrote:
> >>> Hi Andrew,
> >>>
> >>> After merging the akpm-current tree, today's linux-next build
> >>> (x86_64_allmodconfig) produced this warning:
> >>>
> >>> drivers/block/zram/zram_drv.c: In function 'read_block_state':
> >>> drivers/block/zram/zram_drv.c:674:16: warning: format '%llu' expects 
> >>> argument of type 'long long unsigned int', but argument 5 has type 
> >>> '__kernel_time_t {aka long int}' [-Wformat=]
> >>> "%12lu %12llu.%06lu %c%c%c\n",
> >>>~^
> >>>%12lu
> >>> (unsigned long)index, ts.tv_sec,
> >>>   ~
> >>>
> >>> Introduced by commit
> >>>
> >>>   827c7dbda8eb ("zram-introduce-zram-memory-tracking-update-fix-fix")
> >>>
> >>
> >> typedef __s64 time64_t;
> >>
> >> struct timespec64 {
> >>time64_ttv_sec; /* seconds */
> >>longtv_nsec;/* nanoseconds */
> >> };
> >>
> >> time64_t is signed. Also, %lu on i386 et al is for 32-bit longs.
> >> I guess that "we" will need to cast ts.tv_sec to (s64) and use %lld to 
> >> print it
> >> in order to satisfy other $arch.
> >>
> >> Andrew, want to add a fix-fix-fix patch?
> > 
> > Thanks for the fix during I am absent, Andrew and Randy.
> > Here goes fix.
> > Andrew please fold this patchset.
> > 
> > From 16569c7abb641930b4e4ec66b4dc2005e6c87be8 Mon Sep 17 00:00:00 2001
> > From: Minchan Kim 
> > Date: Mon, 7 May 2018 23:00:16 +0900
> > Subject: [PATCH] zram-introduce-zram-memory-tracking-update-fix-fix-fix
> > 
> > fix compile warning
> > 
> > drivers/block/zram/zram_drv.c: In function 'read_block_state':
> > drivers/block/zram/zram_drv.c:674:16: warning: format '%llu' expects 
> > argument of type 'long long unsigned int', but argument 5 has type 
> > '__kernel_time_t {aka long int}' [-Wformat=]
> > "%12lu %12llu.%06lu %c%c%c\n",
> >~^
> >%12lu
> > (unsigned long)index, ts.tv_sec,
> >   ~
> > Cc: Greg Kroah-Hartman 
> > Cc: Randy Dunlap 
> > Cc: Sergey Senozhatsky 
> > Cc: Andrew Morton 
> > Cc: Stephen Rothwell 
> > Signed-off-by: Minchan Kim 
> > ---
> >  drivers/block/zram/zram_drv.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> > index f2f3104b2b48..635307e3238b 100644
> > --- a/drivers/block/zram/zram_drv.c
> > +++ b/drivers/block/zram/zram_drv.c
> > @@ -671,8 +671,8 @@ static ssize_t read_block_state(struct file *file, char 
> > __user *buf,
> >  
> > ts = ktime_to_timespec64(zram->table[index].ac_time);
> > copied = snprintf(kbuf + written, count,
> > -   "%12lu %12llu.%06lu %c%c%c\n",
> > -   (unsigned long)index, ts.tv_sec,
> > +   "%12lu %12lld.%06ld %c%c%c\n",
> > +   (unsigned long)index, (s64)ts.tv_sec,
> > ts.tv_nsec / NSEC_PER_USEC,
> > zram_test_flag(zram, index, ZRAM_SAME) ? 's' : '.',
> > zram_test_flag(zram, index, ZRAM_WB) ? 'w' : '.',
> > 
> 
>   ssize_t index,
> 
>   so why not print it with %zd (or %12zd) and skip the cast?

Thanks for the suggestion.
Resend.

Andrew, Could you pick up this?

>From 8af033804a8a7a0538629545957728c48d14d261 Mon Sep 17 00:00:00 2001
From: Minchan Kim 
Date: Mon, 7 May 2018 23:00:16 +0900
Subject: [PATCH] zram-introduce-zram-memory-tracking-update-fix-fix-fix

fix compile warning and use zd for ssize_t by Randy's suggestion.

drivers/block/zram/zram_drv.c: In function 'read_block_state':
drivers/block/zram/zram_drv.c:674:16: warning: format '%llu' expects argument 
of type 'long long unsigned int', but argument 5 has type '__kernel_time_t {aka 
long int}' [-Wformat=]
"%12lu %12llu.%06lu %c%c%c\n",
   ~^
   %12lu
(unsigned long)index, ts.tv_sec,
  ~
Cc: Greg Kroah-Hartman 
Cc: Randy Dunlap 
Cc: Sergey Senozhatsky 
Cc: Andrew Morton 
Cc: Stephen Rothwell 
Signed-off-by: Minchan Kim 
---
 drivers/block/zram/zram_drv.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index f2f3104b2b48..ceadcd1245b3 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -671,8 +671,8 @@ static ssize_t read_block_state(struct file *file, char 
__user 

Re: linux-next: build warning after merge of the akpm-current tree

[Minchan Kim]

On Mon, May 07, 2018 at 09:47:54AM -0700, Randy Dunlap wrote:
> On 05/07/2018 07:10 AM, Minchan Kim wrote:
> > On Fri, May 04, 2018 at 08:39:43AM -0700, Randy Dunlap wrote:
> >> On 05/03/2018 09:17 PM, Stephen Rothwell wrote:
> >>> Hi Andrew,
> >>>
> >>> After merging the akpm-current tree, today's linux-next build
> >>> (x86_64_allmodconfig) produced this warning:
> >>>
> >>> drivers/block/zram/zram_drv.c: In function 'read_block_state':
> >>> drivers/block/zram/zram_drv.c:674:16: warning: format '%llu' expects 
> >>> argument of type 'long long unsigned int', but argument 5 has type 
> >>> '__kernel_time_t {aka long int}' [-Wformat=]
> >>> "%12lu %12llu.%06lu %c%c%c\n",
> >>>~^
> >>>%12lu
> >>> (unsigned long)index, ts.tv_sec,
> >>>   ~
> >>>
> >>> Introduced by commit
> >>>
> >>>   827c7dbda8eb ("zram-introduce-zram-memory-tracking-update-fix-fix")
> >>>
> >>
> >> typedef __s64 time64_t;
> >>
> >> struct timespec64 {
> >>time64_ttv_sec; /* seconds */
> >>longtv_nsec;/* nanoseconds */
> >> };
> >>
> >> time64_t is signed. Also, %lu on i386 et al is for 32-bit longs.
> >> I guess that "we" will need to cast ts.tv_sec to (s64) and use %lld to 
> >> print it
> >> in order to satisfy other $arch.
> >>
> >> Andrew, want to add a fix-fix-fix patch?
> > 
> > Thanks for the fix during I am absent, Andrew and Randy.
> > Here goes fix.
> > Andrew please fold this patchset.
> > 
> > From 16569c7abb641930b4e4ec66b4dc2005e6c87be8 Mon Sep 17 00:00:00 2001
> > From: Minchan Kim 
> > Date: Mon, 7 May 2018 23:00:16 +0900
> > Subject: [PATCH] zram-introduce-zram-memory-tracking-update-fix-fix-fix
> > 
> > fix compile warning
> > 
> > drivers/block/zram/zram_drv.c: In function 'read_block_state':
> > drivers/block/zram/zram_drv.c:674:16: warning: format '%llu' expects 
> > argument of type 'long long unsigned int', but argument 5 has type 
> > '__kernel_time_t {aka long int}' [-Wformat=]
> > "%12lu %12llu.%06lu %c%c%c\n",
> >~^
> >%12lu
> > (unsigned long)index, ts.tv_sec,
> >   ~
> > Cc: Greg Kroah-Hartman 
> > Cc: Randy Dunlap 
> > Cc: Sergey Senozhatsky 
> > Cc: Andrew Morton 
> > Cc: Stephen Rothwell 
> > Signed-off-by: Minchan Kim 
> > ---
> >  drivers/block/zram/zram_drv.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> > index f2f3104b2b48..635307e3238b 100644
> > --- a/drivers/block/zram/zram_drv.c
> > +++ b/drivers/block/zram/zram_drv.c
> > @@ -671,8 +671,8 @@ static ssize_t read_block_state(struct file *file, char 
> > __user *buf,
> >  
> > ts = ktime_to_timespec64(zram->table[index].ac_time);
> > copied = snprintf(kbuf + written, count,
> > -   "%12lu %12llu.%06lu %c%c%c\n",
> > -   (unsigned long)index, ts.tv_sec,
> > +   "%12lu %12lld.%06ld %c%c%c\n",
> > +   (unsigned long)index, (s64)ts.tv_sec,
> > ts.tv_nsec / NSEC_PER_USEC,
> > zram_test_flag(zram, index, ZRAM_SAME) ? 's' : '.',
> > zram_test_flag(zram, index, ZRAM_WB) ? 'w' : '.',
> > 
> 
>   ssize_t index,
> 
>   so why not print it with %zd (or %12zd) and skip the cast?

Thanks for the suggestion.
Resend.

Andrew, Could you pick up this?

>From 8af033804a8a7a0538629545957728c48d14d261 Mon Sep 17 00:00:00 2001
From: Minchan Kim 
Date: Mon, 7 May 2018 23:00:16 +0900
Subject: [PATCH] zram-introduce-zram-memory-tracking-update-fix-fix-fix

fix compile warning and use zd for ssize_t by Randy's suggestion.

drivers/block/zram/zram_drv.c: In function 'read_block_state':
drivers/block/zram/zram_drv.c:674:16: warning: format '%llu' expects argument 
of type 'long long unsigned int', but argument 5 has type '__kernel_time_t {aka 
long int}' [-Wformat=]
"%12lu %12llu.%06lu %c%c%c\n",
   ~^
   %12lu
(unsigned long)index, ts.tv_sec,
  ~
Cc: Greg Kroah-Hartman 
Cc: Randy Dunlap 
Cc: Sergey Senozhatsky 
Cc: Andrew Morton 
Cc: Stephen Rothwell 
Signed-off-by: Minchan Kim 
---
 drivers/block/zram/zram_drv.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index f2f3104b2b48..ceadcd1245b3 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -671,8 +671,8 @@ static ssize_t read_block_state(struct file *file, char 
__user *buf,
 
ts = ktime_to_timespec64(zram->table[index].ac_time);
copied = snprintf(kbuf + written, count,
-   "%12lu %12llu.%06lu %c%c%c\n",
-   (unsigned long)index, ts.tv_sec,
+   "%12zd %12lld.%06ld %c%c%c\n",
+   index, 

linux-next: build warning after merge of the akpm-current tree

[Randy Dunlap]

On 05/07/2018 07:10 AM, Minchan Kim wrote:
> On Fri, May 04, 2018 at 08:39:43AM -0700, Randy Dunlap wrote:
>> On 05/03/2018 09:17 PM, Stephen Rothwell wrote:
>>> Hi Andrew,
>>>
>>> After merging the akpm-current tree, today's linux-next build
>>> (x86_64_allmodconfig) produced this warning:
>>>
>>> drivers/block/zram/zram_drv.c: In function 'read_block_state':
>>> drivers/block/zram/zram_drv.c:674:16: warning: format '%llu' expects 
>>> argument of type 'long long unsigned int', but argument 5 has type 
>>> '__kernel_time_t {aka long int}' [-Wformat=]
>>> "%12lu %12llu.%06lu %c%c%c\n",
>>>~^
>>>%12lu
>>> (unsigned long)index, ts.tv_sec,
>>>   ~
>>>
>>> Introduced by commit
>>>
>>>   827c7dbda8eb ("zram-introduce-zram-memory-tracking-update-fix-fix")
>>>
>>
>> typedef __s64 time64_t;
>>
>> struct timespec64 {
>>  time64_ttv_sec; /* seconds */
>>  longtv_nsec;/* nanoseconds */
>> };
>>
>> time64_t is signed. Also, %lu on i386 et al is for 32-bit longs.
>> I guess that "we" will need to cast ts.tv_sec to (s64) and use %lld to print 
>> it
>> in order to satisfy other $arch.
>>
>> Andrew, want to add a fix-fix-fix patch?
> 
> Thanks for the fix during I am absent, Andrew and Randy.
> Here goes fix.
> Andrew please fold this patchset.
> 
> From 16569c7abb641930b4e4ec66b4dc2005e6c87be8 Mon Sep 17 00:00:00 2001
> From: Minchan Kim 
> Date: Mon, 7 May 2018 23:00:16 +0900
> Subject: [PATCH] zram-introduce-zram-memory-tracking-update-fix-fix-fix
> 
> fix compile warning
> 
> drivers/block/zram/zram_drv.c: In function 'read_block_state':
> drivers/block/zram/zram_drv.c:674:16: warning: format '%llu' expects argument 
> of type 'long long unsigned int', but argument 5 has type '__kernel_time_t 
> {aka long int}' [-Wformat=]
> "%12lu %12llu.%06lu %c%c%c\n",
>~^
>%12lu
> (unsigned long)index, ts.tv_sec,
>   ~
> Cc: Greg Kroah-Hartman 
> Cc: Randy Dunlap 
> Cc: Sergey Senozhatsky 
> Cc: Andrew Morton 
> Cc: Stephen Rothwell 
> Signed-off-by: Minchan Kim 
> ---
>  drivers/block/zram/zram_drv.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> index f2f3104b2b48..635307e3238b 100644
> --- a/drivers/block/zram/zram_drv.c
> +++ b/drivers/block/zram/zram_drv.c
> @@ -671,8 +671,8 @@ static ssize_t read_block_state(struct file *file, char 
> __user *buf,
>  
>   ts = ktime_to_timespec64(zram->table[index].ac_time);
>   copied = snprintf(kbuf + written, count,
> - "%12lu %12llu.%06lu %c%c%c\n",
> - (unsigned long)index, ts.tv_sec,
> + "%12lu %12lld.%06ld %c%c%c\n",
> + (unsigned long)index, (s64)ts.tv_sec,
>   ts.tv_nsec / NSEC_PER_USEC,
>   zram_test_flag(zram, index, ZRAM_SAME) ? 's' : '.',
>   zram_test_flag(zram, index, ZRAM_WB) ? 'w' : '.',
> 

ssize_t index,

so why not print it with %zd (or %12zd) and skip the cast?

-- 
~Randy

linux-next: build warning after merge of the akpm-current tree

[Randy Dunlap]

On 05/07/2018 07:10 AM, Minchan Kim wrote:
> On Fri, May 04, 2018 at 08:39:43AM -0700, Randy Dunlap wrote:
>> On 05/03/2018 09:17 PM, Stephen Rothwell wrote:
>>> Hi Andrew,
>>>
>>> After merging the akpm-current tree, today's linux-next build
>>> (x86_64_allmodconfig) produced this warning:
>>>
>>> drivers/block/zram/zram_drv.c: In function 'read_block_state':
>>> drivers/block/zram/zram_drv.c:674:16: warning: format '%llu' expects 
>>> argument of type 'long long unsigned int', but argument 5 has type 
>>> '__kernel_time_t {aka long int}' [-Wformat=]
>>> "%12lu %12llu.%06lu %c%c%c\n",
>>>~^
>>>%12lu
>>> (unsigned long)index, ts.tv_sec,
>>>   ~
>>>
>>> Introduced by commit
>>>
>>>   827c7dbda8eb ("zram-introduce-zram-memory-tracking-update-fix-fix")
>>>
>>
>> typedef __s64 time64_t;
>>
>> struct timespec64 {
>>  time64_ttv_sec; /* seconds */
>>  longtv_nsec;/* nanoseconds */
>> };
>>
>> time64_t is signed. Also, %lu on i386 et al is for 32-bit longs.
>> I guess that "we" will need to cast ts.tv_sec to (s64) and use %lld to print 
>> it
>> in order to satisfy other $arch.
>>
>> Andrew, want to add a fix-fix-fix patch?
> 
> Thanks for the fix during I am absent, Andrew and Randy.
> Here goes fix.
> Andrew please fold this patchset.
> 
> From 16569c7abb641930b4e4ec66b4dc2005e6c87be8 Mon Sep 17 00:00:00 2001
> From: Minchan Kim 
> Date: Mon, 7 May 2018 23:00:16 +0900
> Subject: [PATCH] zram-introduce-zram-memory-tracking-update-fix-fix-fix
> 
> fix compile warning
> 
> drivers/block/zram/zram_drv.c: In function 'read_block_state':
> drivers/block/zram/zram_drv.c:674:16: warning: format '%llu' expects argument 
> of type 'long long unsigned int', but argument 5 has type '__kernel_time_t 
> {aka long int}' [-Wformat=]
> "%12lu %12llu.%06lu %c%c%c\n",
>~^
>%12lu
> (unsigned long)index, ts.tv_sec,
>   ~
> Cc: Greg Kroah-Hartman 
> Cc: Randy Dunlap 
> Cc: Sergey Senozhatsky 
> Cc: Andrew Morton 
> Cc: Stephen Rothwell 
> Signed-off-by: Minchan Kim 
> ---
>  drivers/block/zram/zram_drv.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> index f2f3104b2b48..635307e3238b 100644
> --- a/drivers/block/zram/zram_drv.c
> +++ b/drivers/block/zram/zram_drv.c
> @@ -671,8 +671,8 @@ static ssize_t read_block_state(struct file *file, char 
> __user *buf,
>  
>   ts = ktime_to_timespec64(zram->table[index].ac_time);
>   copied = snprintf(kbuf + written, count,
> - "%12lu %12llu.%06lu %c%c%c\n",
> - (unsigned long)index, ts.tv_sec,
> + "%12lu %12lld.%06ld %c%c%c\n",
> + (unsigned long)index, (s64)ts.tv_sec,
>   ts.tv_nsec / NSEC_PER_USEC,
>   zram_test_flag(zram, index, ZRAM_SAME) ? 's' : '.',
>   zram_test_flag(zram, index, ZRAM_WB) ? 'w' : '.',
> 

ssize_t index,

so why not print it with %zd (or %12zd) and skip the cast?

-- 
~Randy

Re: linux-next: build warning after merge of the akpm-current tree

[Minchan Kim]

On Fri, May 04, 2018 at 08:39:43AM -0700, Randy Dunlap wrote:
> On 05/03/2018 09:17 PM, Stephen Rothwell wrote:
> > Hi Andrew,
> > 
> > After merging the akpm-current tree, today's linux-next build
> > (x86_64_allmodconfig) produced this warning:
> > 
> > drivers/block/zram/zram_drv.c: In function 'read_block_state':
> > drivers/block/zram/zram_drv.c:674:16: warning: format '%llu' expects 
> > argument of type 'long long unsigned int', but argument 5 has type 
> > '__kernel_time_t {aka long int}' [-Wformat=]
> > "%12lu %12llu.%06lu %c%c%c\n",
> >~^
> >%12lu
> > (unsigned long)index, ts.tv_sec,
> >   ~
> > 
> > Introduced by commit
> > 
> >   827c7dbda8eb ("zram-introduce-zram-memory-tracking-update-fix-fix")
> > 
> 
> typedef __s64 time64_t;
> 
> struct timespec64 {
>   time64_ttv_sec; /* seconds */
>   longtv_nsec;/* nanoseconds */
> };
> 
> time64_t is signed. Also, %lu on i386 et al is for 32-bit longs.
> I guess that "we" will need to cast ts.tv_sec to (s64) and use %lld to print 
> it
> in order to satisfy other $arch.
> 
> Andrew, want to add a fix-fix-fix patch?

Thanks for the fix during I am absent, Andrew and Randy.
Here goes fix.
Andrew please fold this patchset.

>From 16569c7abb641930b4e4ec66b4dc2005e6c87be8 Mon Sep 17 00:00:00 2001
From: Minchan Kim 
Date: Mon, 7 May 2018 23:00:16 +0900
Subject: [PATCH] zram-introduce-zram-memory-tracking-update-fix-fix-fix

fix compile warning

drivers/block/zram/zram_drv.c: In function 'read_block_state':
drivers/block/zram/zram_drv.c:674:16: warning: format '%llu' expects argument 
of type 'long long unsigned int', but argument 5 has type '__kernel_time_t {aka 
long int}' [-Wformat=]
"%12lu %12llu.%06lu %c%c%c\n",
   ~^
   %12lu
(unsigned long)index, ts.tv_sec,
  ~
Cc: Greg Kroah-Hartman 
Cc: Randy Dunlap 
Cc: Sergey Senozhatsky 
Cc: Andrew Morton 
Cc: Stephen Rothwell 
Signed-off-by: Minchan Kim 
---
 drivers/block/zram/zram_drv.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index f2f3104b2b48..635307e3238b 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -671,8 +671,8 @@ static ssize_t read_block_state(struct file *file, char 
__user *buf,
 
ts = ktime_to_timespec64(zram->table[index].ac_time);
copied = snprintf(kbuf + written, count,
-   "%12lu %12llu.%06lu %c%c%c\n",
-   (unsigned long)index, ts.tv_sec,
+   "%12lu %12lld.%06ld %c%c%c\n",
+   (unsigned long)index, (s64)ts.tv_sec,
ts.tv_nsec / NSEC_PER_USEC,
zram_test_flag(zram, index, ZRAM_SAME) ? 's' : '.',
zram_test_flag(zram, index, ZRAM_WB) ? 'w' : '.',
-- 
2.17.0.441.gb46fe60e1d-goog

Re: linux-next: build warning after merge of the akpm-current tree

[Minchan Kim]

On Fri, May 04, 2018 at 08:39:43AM -0700, Randy Dunlap wrote:
> On 05/03/2018 09:17 PM, Stephen Rothwell wrote:
> > Hi Andrew,
> > 
> > After merging the akpm-current tree, today's linux-next build
> > (x86_64_allmodconfig) produced this warning:
> > 
> > drivers/block/zram/zram_drv.c: In function 'read_block_state':
> > drivers/block/zram/zram_drv.c:674:16: warning: format '%llu' expects 
> > argument of type 'long long unsigned int', but argument 5 has type 
> > '__kernel_time_t {aka long int}' [-Wformat=]
> > "%12lu %12llu.%06lu %c%c%c\n",
> >~^
> >%12lu
> > (unsigned long)index, ts.tv_sec,
> >   ~
> > 
> > Introduced by commit
> > 
> >   827c7dbda8eb ("zram-introduce-zram-memory-tracking-update-fix-fix")
> > 
> 
> typedef __s64 time64_t;
> 
> struct timespec64 {
>   time64_ttv_sec; /* seconds */
>   longtv_nsec;/* nanoseconds */
> };
> 
> time64_t is signed. Also, %lu on i386 et al is for 32-bit longs.
> I guess that "we" will need to cast ts.tv_sec to (s64) and use %lld to print 
> it
> in order to satisfy other $arch.
> 
> Andrew, want to add a fix-fix-fix patch?

Thanks for the fix during I am absent, Andrew and Randy.
Here goes fix.
Andrew please fold this patchset.

>From 16569c7abb641930b4e4ec66b4dc2005e6c87be8 Mon Sep 17 00:00:00 2001
From: Minchan Kim 
Date: Mon, 7 May 2018 23:00:16 +0900
Subject: [PATCH] zram-introduce-zram-memory-tracking-update-fix-fix-fix

fix compile warning

drivers/block/zram/zram_drv.c: In function 'read_block_state':
drivers/block/zram/zram_drv.c:674:16: warning: format '%llu' expects argument 
of type 'long long unsigned int', but argument 5 has type '__kernel_time_t {aka 
long int}' [-Wformat=]
"%12lu %12llu.%06lu %c%c%c\n",
   ~^
   %12lu
(unsigned long)index, ts.tv_sec,
  ~
Cc: Greg Kroah-Hartman 
Cc: Randy Dunlap 
Cc: Sergey Senozhatsky 
Cc: Andrew Morton 
Cc: Stephen Rothwell 
Signed-off-by: Minchan Kim 
---
 drivers/block/zram/zram_drv.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index f2f3104b2b48..635307e3238b 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -671,8 +671,8 @@ static ssize_t read_block_state(struct file *file, char 
__user *buf,
 
ts = ktime_to_timespec64(zram->table[index].ac_time);
copied = snprintf(kbuf + written, count,
-   "%12lu %12llu.%06lu %c%c%c\n",
-   (unsigned long)index, ts.tv_sec,
+   "%12lu %12lld.%06ld %c%c%c\n",
+   (unsigned long)index, (s64)ts.tv_sec,
ts.tv_nsec / NSEC_PER_USEC,
zram_test_flag(zram, index, ZRAM_SAME) ? 's' : '.',
zram_test_flag(zram, index, ZRAM_WB) ? 'w' : '.',
-- 
2.17.0.441.gb46fe60e1d-goog

Re: linux-next: build warning after merge of the akpm-current tree

[Randy Dunlap]

On 05/03/2018 09:17 PM, Stephen Rothwell wrote:
> Hi Andrew,
> 
> After merging the akpm-current tree, today's linux-next build
> (x86_64_allmodconfig) produced this warning:
> 
> drivers/block/zram/zram_drv.c: In function 'read_block_state':
> drivers/block/zram/zram_drv.c:674:16: warning: format '%llu' expects argument 
> of type 'long long unsigned int', but argument 5 has type '__kernel_time_t 
> {aka long int}' [-Wformat=]
> "%12lu %12llu.%06lu %c%c%c\n",
>~^
>%12lu
> (unsigned long)index, ts.tv_sec,
>   ~
> 
> Introduced by commit
> 
>   827c7dbda8eb ("zram-introduce-zram-memory-tracking-update-fix-fix")
> 

typedef __s64 time64_t;

struct timespec64 {
time64_ttv_sec; /* seconds */
longtv_nsec;/* nanoseconds */
};

time64_t is signed. Also, %lu on i386 et al is for 32-bit longs.
I guess that "we" will need to cast ts.tv_sec to (s64) and use %lld to print it
in order to satisfy other $arch.

Andrew, want to add a fix-fix-fix patch?

-- 
~Randy

Re: linux-next: build warning after merge of the akpm-current tree

[Randy Dunlap]

On 05/03/2018 09:17 PM, Stephen Rothwell wrote:
> Hi Andrew,
> 
> After merging the akpm-current tree, today's linux-next build
> (x86_64_allmodconfig) produced this warning:
> 
> drivers/block/zram/zram_drv.c: In function 'read_block_state':
> drivers/block/zram/zram_drv.c:674:16: warning: format '%llu' expects argument 
> of type 'long long unsigned int', but argument 5 has type '__kernel_time_t 
> {aka long int}' [-Wformat=]
> "%12lu %12llu.%06lu %c%c%c\n",
>~^
>%12lu
> (unsigned long)index, ts.tv_sec,
>   ~
> 
> Introduced by commit
> 
>   827c7dbda8eb ("zram-introduce-zram-memory-tracking-update-fix-fix")
> 

typedef __s64 time64_t;

struct timespec64 {
time64_ttv_sec; /* seconds */
longtv_nsec;/* nanoseconds */
};

time64_t is signed. Also, %lu on i386 et al is for 32-bit longs.
I guess that "we" will need to cast ts.tv_sec to (s64) and use %lld to print it
in order to satisfy other $arch.

Andrew, want to add a fix-fix-fix patch?

-- 
~Randy

linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build
(x86_64_allmodconfig) produced this warning:

drivers/block/zram/zram_drv.c: In function 'read_block_state':
drivers/block/zram/zram_drv.c:674:16: warning: format '%llu' expects argument 
of type 'long long unsigned int', but argument 5 has type '__kernel_time_t {aka 
long int}' [-Wformat=]
"%12lu %12llu.%06lu %c%c%c\n",
   ~^
   %12lu
(unsigned long)index, ts.tv_sec,
  ~

Introduced by commit

  827c7dbda8eb ("zram-introduce-zram-memory-tracking-update-fix-fix")

-- 
Cheers,
Stephen Rothwell


pgplpA3CAuW9d.pgp
Description: OpenPGP digital signature

linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build
(x86_64_allmodconfig) produced this warning:

drivers/block/zram/zram_drv.c: In function 'read_block_state':
drivers/block/zram/zram_drv.c:674:16: warning: format '%llu' expects argument 
of type 'long long unsigned int', but argument 5 has type '__kernel_time_t {aka 
long int}' [-Wformat=]
"%12lu %12llu.%06lu %c%c%c\n",
   ~^
   %12lu
(unsigned long)index, ts.tv_sec,
  ~

Introduced by commit

  827c7dbda8eb ("zram-introduce-zram-memory-tracking-update-fix-fix")

-- 
Cheers,
Stephen Rothwell


pgplpA3CAuW9d.pgp
Description: OpenPGP digital signature

linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (x86_64
allmodconfig) produced this warning:

mm/memcontrol.c: In function 'memory_events_show':
mm/memcontrol.c:5453:23: warning: array subscript is above array bounds 
[-Warray-bounds]
  atomic_long_read(>memory_events[OOM_KILL]));
   ^~~

Introduced by commit

  725844c87a0d ("mm: memcg: make sure memory.events is uptodate when waking 
pollers")

-- 
Cheers,
Stephen Rothwell


pgpryi2jbrxNP.pgp
Description: OpenPGP digital signature

linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (x86_64
allmodconfig) produced this warning:

mm/memcontrol.c: In function 'memory_events_show':
mm/memcontrol.c:5453:23: warning: array subscript is above array bounds 
[-Warray-bounds]
  atomic_long_read(>memory_events[OOM_KILL]));
   ^~~

Introduced by commit

  725844c87a0d ("mm: memcg: make sure memory.events is uptodate when waking 
pollers")

-- 
Cheers,
Stephen Rothwell


pgpryi2jbrxNP.pgp
Description: OpenPGP digital signature

linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:

WARNING: vmlinux: 'abort' exported twice. Previous export was in vmlinux
WARNING: vmlinux: 'abort' exported twice. Previous export was in vmlinux

Introduced by commit

  3ff677e9abdf ("kernel/exit.c: export abort() to modules")

EXPORT_SYMBOL(abort) already exists in

arch/arc/kernel/traps.c
arch/arm/kernel/traps.c
arch/m32r/kernel/traps.c
arch/unicore32/kernel/traps.c

-- 
Cheers,
Stephen Rothwell

linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:

WARNING: vmlinux: 'abort' exported twice. Previous export was in vmlinux
WARNING: vmlinux: 'abort' exported twice. Previous export was in vmlinux

Introduced by commit

  3ff677e9abdf ("kernel/exit.c: export abort() to modules")

EXPORT_SYMBOL(abort) already exists in

arch/arc/kernel/traps.c
arch/arm/kernel/traps.c
arch/m32r/kernel/traps.c
arch/unicore32/kernel/traps.c

-- 
Cheers,
Stephen Rothwell

linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:

mm/khugepaged.c: In function 'khugepaged':
mm/khugepaged.c:1757:31: warning: 'vma' may be used uninitialized in this 
function [-Wmaybe-uninitialized]
  if (khugepaged_test_exit(mm) || !vma) {
   ^
mm/khugepaged.c:1659:25: note: 'vma' was declared here
  struct vm_area_struct *vma;
 ^

Introduced by commit

  0951b59acf3a ("mm: thp: use down_read_trylock() in khugepaged to avoid long 
block")

-- 
Cheers,
Stephen Rothwell

linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:

mm/khugepaged.c: In function 'khugepaged':
mm/khugepaged.c:1757:31: warning: 'vma' may be used uninitialized in this 
function [-Wmaybe-uninitialized]
  if (khugepaged_test_exit(mm) || !vma) {
   ^
mm/khugepaged.c:1659:25: note: 'vma' was declared here
  struct vm_area_struct *vma;
 ^

Introduced by commit

  0951b59acf3a ("mm: thp: use down_read_trylock() in khugepaged to avoid long 
block")

-- 
Cheers,
Stephen Rothwell

linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:

fs/super.c: In function 'sget_userns':
fs/super.c:521:2: warning: ignoring return value of 'register_shrinker', 
declared with attribute warn_unused_result [-Wunused-result]
  register_shrinker(>s_shrink);
  ^
drivers/gpu/drm/ttm/ttm_page_alloc.c: In function 'ttm_pool_mm_shrink_init':
drivers/gpu/drm/ttm/ttm_page_alloc.c:451:2: warning: ignoring return value of 
'register_shrinker', declared with attribute warn_unused_result 
[-Wunused-result]
  register_shrinker(>mm_shrink);
  ^
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c: In function 
'ttm_dma_pool_mm_shrink_init':
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c:1185:2: warning: ignoring return value 
of 'register_shrinker', declared with attribute warn_unused_result 
[-Wunused-result]
  register_shrinker(>mm_shrink);
  ^

Introduced by commit

  488251e1e892 ("mm,vmscan: mark register_shrinker() as __must_check")

Yes, I realise that it is meant to flush the users out ...

-- 
Cheers,
Stephen Rothwell

linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:

fs/super.c: In function 'sget_userns':
fs/super.c:521:2: warning: ignoring return value of 'register_shrinker', 
declared with attribute warn_unused_result [-Wunused-result]
  register_shrinker(>s_shrink);
  ^
drivers/gpu/drm/ttm/ttm_page_alloc.c: In function 'ttm_pool_mm_shrink_init':
drivers/gpu/drm/ttm/ttm_page_alloc.c:451:2: warning: ignoring return value of 
'register_shrinker', declared with attribute warn_unused_result 
[-Wunused-result]
  register_shrinker(>mm_shrink);
  ^
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c: In function 
'ttm_dma_pool_mm_shrink_init':
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c:1185:2: warning: ignoring return value 
of 'register_shrinker', declared with attribute warn_unused_result 
[-Wunused-result]
  register_shrinker(>mm_shrink);
  ^

Introduced by commit

  488251e1e892 ("mm,vmscan: mark register_shrinker() as __must_check")

Yes, I realise that it is meant to flush the users out ...

-- 
Cheers,
Stephen Rothwell

Re: linux-next: build warning after merge of the akpm-current tree

[Arnd Bergmann]

On Fri, Nov 17, 2017 at 4:53 AM, Stephen Rothwell  wrote:
> Hi all,
>
> On Fri, 17 Nov 2017 09:44:39 +1100 Stephen Rothwell  
> wrote:
>>
>> On Mon, 13 Nov 2017 12:43:08 +0100 Arnd Bergmann  wrote:
>> >
>> > On Mon, Nov 13, 2017 at 9:09 AM, Michal Hocko  wrote:
>> > > On Mon 13-11-17 16:42:06, Stephen Rothwell wrote:
>> > >>
>> > >> After merging the akpm-current tree, today's linux-next build (powerpc
>> > >> ppc64_defconfig) produced this warning:
>> > >>
>> > >> In file included from include/linux/mmzone.h:17:0,
>> > >>  from include/linux/mempolicy.h:10,
>> > >>  from mm/mempolicy.c:70:
>> > >> mm/mempolicy.c: In function 'mpol_to_str':
>> > >> include/linux/nodemask.h:107:41: warning: the address of 'nodes' will 
>> > >> always evaluate as 'true' [-Waddress]
>> > >>  #define nodemask_pr_args(maskp) (maskp) ? MAX_NUMNODES : 0, (maskp) ? 
>> > >> (maskp)->bits : NULL
>> > >>  ^
>> > >> mm/mempolicy.c:2817:11: note: in expansion of macro 'nodemask_pr_args'
>> > >>nodemask_pr_args());
>> > >>^
>> > >
>> > > Hmm, this warning is quite surprising to me. Sure in this particular
>> > > case maskp will always be non-NULL so we always expand to
>> > > MAX_NUMNODES, maskp->bits
>> > > which is what we want. But we have other users which may be NULL. Does
>> > > anybody understan why this warns at all?
>> >
>> > As I understand it, the warning tries to address a common typo of 
>> > accidentally
>> > testing the pointer to a stack object for being non-NULL, rather than the 
>> > object
>> > pointed to for being non-zero.
>> >
>> > Adding an extra '!= NULL' comparison gets rid of the warning for me:
>> >
>> > #define nodemask_pr_args(maskp)  \
>> >((maskp) != NULL) ? MAX_NUMNODES : 0, \
>> >((maskp) != NULL) ?(maskp)->bits : NULL
>> >
>> >Arnd
>>
>> This warning now exists in Linus' tree :-(
>
> Looking closer, it seems that the above workaround doesn't work for my
> compiler (gcc v5.2.0):

Right, I see now that all versions from gcc-4.6 to gcc-6 are affected
by this, while 4.5 and
earlier as well as 7 and 8 are not.

I'll try to come up with an alternative workaround, it will probably
be even uglier.

   Arnd

Re: linux-next: build warning after merge of the akpm-current tree

[Arnd Bergmann]

On Fri, Nov 17, 2017 at 4:53 AM, Stephen Rothwell  wrote:
> Hi all,
>
> On Fri, 17 Nov 2017 09:44:39 +1100 Stephen Rothwell  
> wrote:
>>
>> On Mon, 13 Nov 2017 12:43:08 +0100 Arnd Bergmann  wrote:
>> >
>> > On Mon, Nov 13, 2017 at 9:09 AM, Michal Hocko  wrote:
>> > > On Mon 13-11-17 16:42:06, Stephen Rothwell wrote:
>> > >>
>> > >> After merging the akpm-current tree, today's linux-next build (powerpc
>> > >> ppc64_defconfig) produced this warning:
>> > >>
>> > >> In file included from include/linux/mmzone.h:17:0,
>> > >>  from include/linux/mempolicy.h:10,
>> > >>  from mm/mempolicy.c:70:
>> > >> mm/mempolicy.c: In function 'mpol_to_str':
>> > >> include/linux/nodemask.h:107:41: warning: the address of 'nodes' will 
>> > >> always evaluate as 'true' [-Waddress]
>> > >>  #define nodemask_pr_args(maskp) (maskp) ? MAX_NUMNODES : 0, (maskp) ? 
>> > >> (maskp)->bits : NULL
>> > >>  ^
>> > >> mm/mempolicy.c:2817:11: note: in expansion of macro 'nodemask_pr_args'
>> > >>nodemask_pr_args());
>> > >>^
>> > >
>> > > Hmm, this warning is quite surprising to me. Sure in this particular
>> > > case maskp will always be non-NULL so we always expand to
>> > > MAX_NUMNODES, maskp->bits
>> > > which is what we want. But we have other users which may be NULL. Does
>> > > anybody understan why this warns at all?
>> >
>> > As I understand it, the warning tries to address a common typo of 
>> > accidentally
>> > testing the pointer to a stack object for being non-NULL, rather than the 
>> > object
>> > pointed to for being non-zero.
>> >
>> > Adding an extra '!= NULL' comparison gets rid of the warning for me:
>> >
>> > #define nodemask_pr_args(maskp)  \
>> >((maskp) != NULL) ? MAX_NUMNODES : 0, \
>> >((maskp) != NULL) ?(maskp)->bits : NULL
>> >
>> >Arnd
>>
>> This warning now exists in Linus' tree :-(
>
> Looking closer, it seems that the above workaround doesn't work for my
> compiler (gcc v5.2.0):

Right, I see now that all versions from gcc-4.6 to gcc-6 are affected
by this, while 4.5 and
earlier as well as 7 and 8 are not.

I'll try to come up with an alternative workaround, it will probably
be even uglier.

   Arnd

Re: linux-next: build warning after merge of the akpm-current tree

[Zhangshaokun]

Hi,

On 2017/11/17 11:53, Stephen Rothwell wrote:
> Hi all,
> 
> On Fri, 17 Nov 2017 09:44:39 +1100 Stephen Rothwell  
> wrote:
>>
>> On Mon, 13 Nov 2017 12:43:08 +0100 Arnd Bergmann  wrote:
>>>
>>> On Mon, Nov 13, 2017 at 9:09 AM, Michal Hocko  wrote:  
 On Mon 13-11-17 16:42:06, Stephen Rothwell wrote:
>
> After merging the akpm-current tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
>
> In file included from include/linux/mmzone.h:17:0,
>  from include/linux/mempolicy.h:10,
>  from mm/mempolicy.c:70:
> mm/mempolicy.c: In function 'mpol_to_str':
> include/linux/nodemask.h:107:41: warning: the address of 'nodes' will 
> always evaluate as 'true' [-Waddress]
>  #define nodemask_pr_args(maskp) (maskp) ? MAX_NUMNODES : 0, (maskp) ? 
> (maskp)->bits : NULL
>  ^
> mm/mempolicy.c:2817:11: note: in expansion of macro 'nodemask_pr_args'
>nodemask_pr_args());
>^

 Hmm, this warning is quite surprising to me. Sure in this particular
 case maskp will always be non-NULL so we always expand to
 MAX_NUMNODES, maskp->bits
 which is what we want. But we have other users which may be NULL. Does
 anybody understan why this warns at all?
>>>
>>> As I understand it, the warning tries to address a common typo of 
>>> accidentally
>>> testing the pointer to a stack object for being non-NULL, rather than the 
>>> object
>>> pointed to for being non-zero.
>>>
>>> Adding an extra '!= NULL' comparison gets rid of the warning for me:
>>>
>>> #define nodemask_pr_args(maskp)  \
>>>((maskp) != NULL) ? MAX_NUMNODES : 0, \
>>>((maskp) != NULL) ?(maskp)->bits : NULL
>>>
>>>Arnd  
>>
>> This warning now exists in Linus' tree :-(
> 
> Looking closer, it seems that the above workaround doesn't work for my
> compiler (gcc v5.2.0):
> 

I also came across this issue using Linus' tree and my gcc is gcc version 5.4.0 
20160609
 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.5).

  CC  drivers/clk/renesas/rcar-gen3-cpg.o
In file included from ./include/linux/mmzone.h:17:0,
 from ./include/linux/mempolicy.h:10,
 from mm/mempolicy.c:70:
mm/mempolicy.c: In function ‘mpol_to_str’:
./include/linux/nodemask.h:108:11: warning: the comparison will always evaluate 
as ‘true’ for the address of ‘nodes’ will never be NULL [-Waddress]
  ((maskp) != NULL) ? MAX_NUMNODES : 0,  \
   ^
mm/mempolicy.c:2817:11: note: in expansion of macro ‘nodemask_pr_args’
   nodemask_pr_args());
   ^
./include/linux/nodemask.h:109:11: warning: the comparison will always evaluate 
as ‘true’ for the address of ‘nodes’ will never be NULL [-Waddress]
  ((maskp) != NULL) ? (maskp)->bits : NULL
   ^
mm/mempolicy.c:2817:11: note: in expansion of macro ‘nodemask_pr_args’
   nodemask_pr_args());
   ^
  CC  drivers/clk/renesas/renesas-cpg-mssr.o

Thanks,
Shaokun

> In file included from include/linux/mmzone.h:17:0,
>  from include/linux/mempolicy.h:10,
>  from mm/mempolicy.c:70:
> mm/mempolicy.c: In function 'mpol_to_str':
> include/linux/nodemask.h:108:11: warning: the comparison will always evaluate 
> as 'true' for the address of 'nodes' will never be NULL [-Waddress]
>   ((maskp) != NULL) ? MAX_NUMNODES : 0,  \
>^
> mm/mempolicy.c:2817:11: note: in expansion of macro 'nodemask_pr_args'
>nodemask_pr_args());
>^
> include/linux/nodemask.h:109:11: warning: the comparison will always evaluate 
> as 'true' for the address of 'nodes' will never be NULL [-Waddress]
>   ((maskp) != NULL) ? (maskp)->bits : NULL
>^
> mm/mempolicy.c:2817:11: note: in expansion of macro 'nodemask_pr_args'
>nodemask_pr_args());
>^
> 

Re: linux-next: build warning after merge of the akpm-current tree

[Zhangshaokun]

Hi,

On 2017/11/17 11:53, Stephen Rothwell wrote:
> Hi all,
> 
> On Fri, 17 Nov 2017 09:44:39 +1100 Stephen Rothwell  
> wrote:
>>
>> On Mon, 13 Nov 2017 12:43:08 +0100 Arnd Bergmann  wrote:
>>>
>>> On Mon, Nov 13, 2017 at 9:09 AM, Michal Hocko  wrote:  
 On Mon 13-11-17 16:42:06, Stephen Rothwell wrote:
>
> After merging the akpm-current tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
>
> In file included from include/linux/mmzone.h:17:0,
>  from include/linux/mempolicy.h:10,
>  from mm/mempolicy.c:70:
> mm/mempolicy.c: In function 'mpol_to_str':
> include/linux/nodemask.h:107:41: warning: the address of 'nodes' will 
> always evaluate as 'true' [-Waddress]
>  #define nodemask_pr_args(maskp) (maskp) ? MAX_NUMNODES : 0, (maskp) ? 
> (maskp)->bits : NULL
>  ^
> mm/mempolicy.c:2817:11: note: in expansion of macro 'nodemask_pr_args'
>nodemask_pr_args());
>^

 Hmm, this warning is quite surprising to me. Sure in this particular
 case maskp will always be non-NULL so we always expand to
 MAX_NUMNODES, maskp->bits
 which is what we want. But we have other users which may be NULL. Does
 anybody understan why this warns at all?
>>>
>>> As I understand it, the warning tries to address a common typo of 
>>> accidentally
>>> testing the pointer to a stack object for being non-NULL, rather than the 
>>> object
>>> pointed to for being non-zero.
>>>
>>> Adding an extra '!= NULL' comparison gets rid of the warning for me:
>>>
>>> #define nodemask_pr_args(maskp)  \
>>>((maskp) != NULL) ? MAX_NUMNODES : 0, \
>>>((maskp) != NULL) ?(maskp)->bits : NULL
>>>
>>>Arnd  
>>
>> This warning now exists in Linus' tree :-(
> 
> Looking closer, it seems that the above workaround doesn't work for my
> compiler (gcc v5.2.0):
> 

I also came across this issue using Linus' tree and my gcc is gcc version 5.4.0 
20160609
 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.5).

  CC  drivers/clk/renesas/rcar-gen3-cpg.o
In file included from ./include/linux/mmzone.h:17:0,
 from ./include/linux/mempolicy.h:10,
 from mm/mempolicy.c:70:
mm/mempolicy.c: In function ‘mpol_to_str’:
./include/linux/nodemask.h:108:11: warning: the comparison will always evaluate 
as ‘true’ for the address of ‘nodes’ will never be NULL [-Waddress]
  ((maskp) != NULL) ? MAX_NUMNODES : 0,  \
   ^
mm/mempolicy.c:2817:11: note: in expansion of macro ‘nodemask_pr_args’
   nodemask_pr_args());
   ^
./include/linux/nodemask.h:109:11: warning: the comparison will always evaluate 
as ‘true’ for the address of ‘nodes’ will never be NULL [-Waddress]
  ((maskp) != NULL) ? (maskp)->bits : NULL
   ^
mm/mempolicy.c:2817:11: note: in expansion of macro ‘nodemask_pr_args’
   nodemask_pr_args());
   ^
  CC  drivers/clk/renesas/renesas-cpg-mssr.o

Thanks,
Shaokun

> In file included from include/linux/mmzone.h:17:0,
>  from include/linux/mempolicy.h:10,
>  from mm/mempolicy.c:70:
> mm/mempolicy.c: In function 'mpol_to_str':
> include/linux/nodemask.h:108:11: warning: the comparison will always evaluate 
> as 'true' for the address of 'nodes' will never be NULL [-Waddress]
>   ((maskp) != NULL) ? MAX_NUMNODES : 0,  \
>^
> mm/mempolicy.c:2817:11: note: in expansion of macro 'nodemask_pr_args'
>nodemask_pr_args());
>^
> include/linux/nodemask.h:109:11: warning: the comparison will always evaluate 
> as 'true' for the address of 'nodes' will never be NULL [-Waddress]
>   ((maskp) != NULL) ? (maskp)->bits : NULL
>^
> mm/mempolicy.c:2817:11: note: in expansion of macro 'nodemask_pr_args'
>nodemask_pr_args());
>^
> 

Re: linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi all,

On Fri, 17 Nov 2017 09:44:39 +1100 Stephen Rothwell  
wrote:
>
> On Mon, 13 Nov 2017 12:43:08 +0100 Arnd Bergmann  wrote:
> >
> > On Mon, Nov 13, 2017 at 9:09 AM, Michal Hocko  wrote:  
> > > On Mon 13-11-17 16:42:06, Stephen Rothwell wrote:
> > >>
> > >> After merging the akpm-current tree, today's linux-next build (powerpc
> > >> ppc64_defconfig) produced this warning:
> > >>
> > >> In file included from include/linux/mmzone.h:17:0,
> > >>  from include/linux/mempolicy.h:10,
> > >>  from mm/mempolicy.c:70:
> > >> mm/mempolicy.c: In function 'mpol_to_str':
> > >> include/linux/nodemask.h:107:41: warning: the address of 'nodes' will 
> > >> always evaluate as 'true' [-Waddress]
> > >>  #define nodemask_pr_args(maskp) (maskp) ? MAX_NUMNODES : 0, (maskp) ? 
> > >> (maskp)->bits : NULL
> > >>  ^
> > >> mm/mempolicy.c:2817:11: note: in expansion of macro 'nodemask_pr_args'
> > >>nodemask_pr_args());
> > >>^
> > >
> > > Hmm, this warning is quite surprising to me. Sure in this particular
> > > case maskp will always be non-NULL so we always expand to
> > > MAX_NUMNODES, maskp->bits
> > > which is what we want. But we have other users which may be NULL. Does
> > > anybody understan why this warns at all?
> > 
> > As I understand it, the warning tries to address a common typo of 
> > accidentally
> > testing the pointer to a stack object for being non-NULL, rather than the 
> > object
> > pointed to for being non-zero.
> > 
> > Adding an extra '!= NULL' comparison gets rid of the warning for me:
> > 
> > #define nodemask_pr_args(maskp)  \
> >((maskp) != NULL) ? MAX_NUMNODES : 0, \
> >((maskp) != NULL) ?(maskp)->bits : NULL
> > 
> >Arnd  
> 
> This warning now exists in Linus' tree :-(

Looking closer, it seems that the above workaround doesn't work for my
compiler (gcc v5.2.0):

In file included from include/linux/mmzone.h:17:0,
 from include/linux/mempolicy.h:10,
 from mm/mempolicy.c:70:
mm/mempolicy.c: In function 'mpol_to_str':
include/linux/nodemask.h:108:11: warning: the comparison will always evaluate 
as 'true' for the address of 'nodes' will never be NULL [-Waddress]
  ((maskp) != NULL) ? MAX_NUMNODES : 0,  \
   ^
mm/mempolicy.c:2817:11: note: in expansion of macro 'nodemask_pr_args'
   nodemask_pr_args());
   ^
include/linux/nodemask.h:109:11: warning: the comparison will always evaluate 
as 'true' for the address of 'nodes' will never be NULL [-Waddress]
  ((maskp) != NULL) ? (maskp)->bits : NULL
   ^
mm/mempolicy.c:2817:11: note: in expansion of macro 'nodemask_pr_args'
   nodemask_pr_args());
   ^

-- 
Cheers,
Stephen Rothwell

Re: linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi all,

On Fri, 17 Nov 2017 09:44:39 +1100 Stephen Rothwell  
wrote:
>
> On Mon, 13 Nov 2017 12:43:08 +0100 Arnd Bergmann  wrote:
> >
> > On Mon, Nov 13, 2017 at 9:09 AM, Michal Hocko  wrote:  
> > > On Mon 13-11-17 16:42:06, Stephen Rothwell wrote:
> > >>
> > >> After merging the akpm-current tree, today's linux-next build (powerpc
> > >> ppc64_defconfig) produced this warning:
> > >>
> > >> In file included from include/linux/mmzone.h:17:0,
> > >>  from include/linux/mempolicy.h:10,
> > >>  from mm/mempolicy.c:70:
> > >> mm/mempolicy.c: In function 'mpol_to_str':
> > >> include/linux/nodemask.h:107:41: warning: the address of 'nodes' will 
> > >> always evaluate as 'true' [-Waddress]
> > >>  #define nodemask_pr_args(maskp) (maskp) ? MAX_NUMNODES : 0, (maskp) ? 
> > >> (maskp)->bits : NULL
> > >>  ^
> > >> mm/mempolicy.c:2817:11: note: in expansion of macro 'nodemask_pr_args'
> > >>nodemask_pr_args());
> > >>^
> > >
> > > Hmm, this warning is quite surprising to me. Sure in this particular
> > > case maskp will always be non-NULL so we always expand to
> > > MAX_NUMNODES, maskp->bits
> > > which is what we want. But we have other users which may be NULL. Does
> > > anybody understan why this warns at all?
> > 
> > As I understand it, the warning tries to address a common typo of 
> > accidentally
> > testing the pointer to a stack object for being non-NULL, rather than the 
> > object
> > pointed to for being non-zero.
> > 
> > Adding an extra '!= NULL' comparison gets rid of the warning for me:
> > 
> > #define nodemask_pr_args(maskp)  \
> >((maskp) != NULL) ? MAX_NUMNODES : 0, \
> >((maskp) != NULL) ?(maskp)->bits : NULL
> > 
> >Arnd  
> 
> This warning now exists in Linus' tree :-(

Looking closer, it seems that the above workaround doesn't work for my
compiler (gcc v5.2.0):

In file included from include/linux/mmzone.h:17:0,
 from include/linux/mempolicy.h:10,
 from mm/mempolicy.c:70:
mm/mempolicy.c: In function 'mpol_to_str':
include/linux/nodemask.h:108:11: warning: the comparison will always evaluate 
as 'true' for the address of 'nodes' will never be NULL [-Waddress]
  ((maskp) != NULL) ? MAX_NUMNODES : 0,  \
   ^
mm/mempolicy.c:2817:11: note: in expansion of macro 'nodemask_pr_args'
   nodemask_pr_args());
   ^
include/linux/nodemask.h:109:11: warning: the comparison will always evaluate 
as 'true' for the address of 'nodes' will never be NULL [-Waddress]
  ((maskp) != NULL) ? (maskp)->bits : NULL
   ^
mm/mempolicy.c:2817:11: note: in expansion of macro 'nodemask_pr_args'
   nodemask_pr_args());
   ^

-- 
Cheers,
Stephen Rothwell

Re: linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi all,

On Mon, 13 Nov 2017 12:43:08 +0100 Arnd Bergmann  wrote:
>
> On Mon, Nov 13, 2017 at 9:09 AM, Michal Hocko  wrote:
> > On Mon 13-11-17 16:42:06, Stephen Rothwell wrote:  
> >>
> >> After merging the akpm-current tree, today's linux-next build (powerpc
> >> ppc64_defconfig) produced this warning:
> >>
> >> In file included from include/linux/mmzone.h:17:0,
> >>  from include/linux/mempolicy.h:10,
> >>  from mm/mempolicy.c:70:
> >> mm/mempolicy.c: In function 'mpol_to_str':
> >> include/linux/nodemask.h:107:41: warning: the address of 'nodes' will 
> >> always evaluate as 'true' [-Waddress]
> >>  #define nodemask_pr_args(maskp) (maskp) ? MAX_NUMNODES : 0, (maskp) ? 
> >> (maskp)->bits : NULL
> >>  ^
> >> mm/mempolicy.c:2817:11: note: in expansion of macro 'nodemask_pr_args'
> >>nodemask_pr_args());
> >>^  
> >
> > Hmm, this warning is quite surprising to me. Sure in this particular
> > case maskp will always be non-NULL so we always expand to
> > MAX_NUMNODES, maskp->bits
> > which is what we want. But we have other users which may be NULL. Does
> > anybody understan why this warns at all?  
> 
> As I understand it, the warning tries to address a common typo of accidentally
> testing the pointer to a stack object for being non-NULL, rather than the 
> object
> pointed to for being non-zero.
> 
> Adding an extra '!= NULL' comparison gets rid of the warning for me:
> 
> #define nodemask_pr_args(maskp)  \
>((maskp) != NULL) ? MAX_NUMNODES : 0, \
>((maskp) != NULL) ?(maskp)->bits : NULL
> 
>Arnd

This warning now exists in Linus' tree :-(

-- 
Cheers,
Stephen Rothwell

Re: linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi all,

On Mon, 13 Nov 2017 12:43:08 +0100 Arnd Bergmann  wrote:
>
> On Mon, Nov 13, 2017 at 9:09 AM, Michal Hocko  wrote:
> > On Mon 13-11-17 16:42:06, Stephen Rothwell wrote:  
> >>
> >> After merging the akpm-current tree, today's linux-next build (powerpc
> >> ppc64_defconfig) produced this warning:
> >>
> >> In file included from include/linux/mmzone.h:17:0,
> >>  from include/linux/mempolicy.h:10,
> >>  from mm/mempolicy.c:70:
> >> mm/mempolicy.c: In function 'mpol_to_str':
> >> include/linux/nodemask.h:107:41: warning: the address of 'nodes' will 
> >> always evaluate as 'true' [-Waddress]
> >>  #define nodemask_pr_args(maskp) (maskp) ? MAX_NUMNODES : 0, (maskp) ? 
> >> (maskp)->bits : NULL
> >>  ^
> >> mm/mempolicy.c:2817:11: note: in expansion of macro 'nodemask_pr_args'
> >>nodemask_pr_args());
> >>^  
> >
> > Hmm, this warning is quite surprising to me. Sure in this particular
> > case maskp will always be non-NULL so we always expand to
> > MAX_NUMNODES, maskp->bits
> > which is what we want. But we have other users which may be NULL. Does
> > anybody understan why this warns at all?  
> 
> As I understand it, the warning tries to address a common typo of accidentally
> testing the pointer to a stack object for being non-NULL, rather than the 
> object
> pointed to for being non-zero.
> 
> Adding an extra '!= NULL' comparison gets rid of the warning for me:
> 
> #define nodemask_pr_args(maskp)  \
>((maskp) != NULL) ? MAX_NUMNODES : 0, \
>((maskp) != NULL) ?(maskp)->bits : NULL
> 
>Arnd

This warning now exists in Linus' tree :-(

-- 
Cheers,
Stephen Rothwell

Re: linux-next: build warning after merge of the akpm-current tree

[Michal Hocko]

On Mon 13-11-17 12:54:30, Michal Hocko wrote:
> On Mon 13-11-17 12:43:08, Arnd Bergmann wrote:
> > On Mon, Nov 13, 2017 at 9:09 AM, Michal Hocko  wrote:
> > > On Mon 13-11-17 16:42:06, Stephen Rothwell wrote:
> > >> Hi Andrew,
> > >>
> > >> After merging the akpm-current tree, today's linux-next build (powerpc
> > >> ppc64_defconfig) produced this warning:
> > >>
> > >> In file included from include/linux/mmzone.h:17:0,
> > >>  from include/linux/mempolicy.h:10,
> > >>  from mm/mempolicy.c:70:
> > >> mm/mempolicy.c: In function 'mpol_to_str':
> > >> include/linux/nodemask.h:107:41: warning: the address of 'nodes' will 
> > >> always evaluate as 'true' [-Waddress]
> > >>  #define nodemask_pr_args(maskp) (maskp) ? MAX_NUMNODES : 0, (maskp) ? 
> > >> (maskp)->bits : NULL
> > >>  ^
> > >> mm/mempolicy.c:2817:11: note: in expansion of macro 'nodemask_pr_args'
> > >>nodemask_pr_args());
> > >>^
> > >
> > > Hmm, this warning is quite surprising to me. Sure in this particular
> > > case maskp will always be non-NULL so we always expand to
> > > MAX_NUMNODES, maskp->bits
> > > which is what we want. But we have other users which may be NULL. Does
> > > anybody understan why this warns at all?
> > 
> > As I understand it, the warning tries to address a common typo of 
> > accidentally
> > testing the pointer to a stack object for being non-NULL, rather than the 
> > object
> > pointed to for being non-zero.
> > 
> > Adding an extra '!= NULL' comparison gets rid of the warning for me:
> > 
> > #define nodemask_pr_args(maskp)  \
> >((maskp) != NULL) ? MAX_NUMNODES : 0, \
> >((maskp) != NULL) ?(maskp)->bits : NULL
> 
> OK, that is a reasonable workaround. I was talking to our gcc guy and
> he suggested to report a bug for this.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82963

-- 
Michal Hocko
SUSE Labs

Re: linux-next: build warning after merge of the akpm-current tree

[Michal Hocko]

On Mon 13-11-17 12:54:30, Michal Hocko wrote:
> On Mon 13-11-17 12:43:08, Arnd Bergmann wrote:
> > On Mon, Nov 13, 2017 at 9:09 AM, Michal Hocko  wrote:
> > > On Mon 13-11-17 16:42:06, Stephen Rothwell wrote:
> > >> Hi Andrew,
> > >>
> > >> After merging the akpm-current tree, today's linux-next build (powerpc
> > >> ppc64_defconfig) produced this warning:
> > >>
> > >> In file included from include/linux/mmzone.h:17:0,
> > >>  from include/linux/mempolicy.h:10,
> > >>  from mm/mempolicy.c:70:
> > >> mm/mempolicy.c: In function 'mpol_to_str':
> > >> include/linux/nodemask.h:107:41: warning: the address of 'nodes' will 
> > >> always evaluate as 'true' [-Waddress]
> > >>  #define nodemask_pr_args(maskp) (maskp) ? MAX_NUMNODES : 0, (maskp) ? 
> > >> (maskp)->bits : NULL
> > >>  ^
> > >> mm/mempolicy.c:2817:11: note: in expansion of macro 'nodemask_pr_args'
> > >>nodemask_pr_args());
> > >>^
> > >
> > > Hmm, this warning is quite surprising to me. Sure in this particular
> > > case maskp will always be non-NULL so we always expand to
> > > MAX_NUMNODES, maskp->bits
> > > which is what we want. But we have other users which may be NULL. Does
> > > anybody understan why this warns at all?
> > 
> > As I understand it, the warning tries to address a common typo of 
> > accidentally
> > testing the pointer to a stack object for being non-NULL, rather than the 
> > object
> > pointed to for being non-zero.
> > 
> > Adding an extra '!= NULL' comparison gets rid of the warning for me:
> > 
> > #define nodemask_pr_args(maskp)  \
> >((maskp) != NULL) ? MAX_NUMNODES : 0, \
> >((maskp) != NULL) ?(maskp)->bits : NULL
> 
> OK, that is a reasonable workaround. I was talking to our gcc guy and
> he suggested to report a bug for this.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82963

-- 
Michal Hocko
SUSE Labs

Re: linux-next: build warning after merge of the akpm-current tree

[Arnd Bergmann]

On Mon, Nov 13, 2017 at 12:54 PM, Michal Hocko  wrote:
> On Mon 13-11-17 12:43:08, Arnd Bergmann wrote:
>> On Mon, Nov 13, 2017 at 9:09 AM, Michal Hocko  wrote:
>> > On Mon 13-11-17 16:42:06, Stephen Rothwell wrote:
>> >> Hi Andrew,
>> >>
>> >> After merging the akpm-current tree, today's linux-next build (powerpc
>> >> ppc64_defconfig) produced this warning:
>> >>
>> >> In file included from include/linux/mmzone.h:17:0,
>> >>  from include/linux/mempolicy.h:10,
>> >>  from mm/mempolicy.c:70:
>> >> mm/mempolicy.c: In function 'mpol_to_str':
>> >> include/linux/nodemask.h:107:41: warning: the address of 'nodes' will 
>> >> always evaluate as 'true' [-Waddress]
>> >>  #define nodemask_pr_args(maskp) (maskp) ? MAX_NUMNODES : 0, (maskp) ? 
>> >> (maskp)->bits : NULL
>> >>  ^
>> >> mm/mempolicy.c:2817:11: note: in expansion of macro 'nodemask_pr_args'
>> >>nodemask_pr_args());
>> >>^
>> >
>> > Hmm, this warning is quite surprising to me. Sure in this particular
>> > case maskp will always be non-NULL so we always expand to
>> > MAX_NUMNODES, maskp->bits
>> > which is what we want. But we have other users which may be NULL. Does
>> > anybody understan why this warns at all?
>>
>> As I understand it, the warning tries to address a common typo of 
>> accidentally
>> testing the pointer to a stack object for being non-NULL, rather than the 
>> object
>> pointed to for being non-zero.
>>
>> Adding an extra '!= NULL' comparison gets rid of the warning for me:
>>
>> #define nodemask_pr_args(maskp)  \
>>((maskp) != NULL) ? MAX_NUMNODES : 0, \
>>((maskp) != NULL) ?(maskp)->bits : NULL
>
> OK, that is a reasonable workaround. I was talking to our gcc guy and
> he suggested to report a bug for this.

That might also be useful. Some warnings in gcc get disabled when
they show up inside of a macro, and that could presumably be done
here too.

  Arnd

Re: linux-next: build warning after merge of the akpm-current tree

[Arnd Bergmann]

On Mon, Nov 13, 2017 at 12:54 PM, Michal Hocko  wrote:
> On Mon 13-11-17 12:43:08, Arnd Bergmann wrote:
>> On Mon, Nov 13, 2017 at 9:09 AM, Michal Hocko  wrote:
>> > On Mon 13-11-17 16:42:06, Stephen Rothwell wrote:
>> >> Hi Andrew,
>> >>
>> >> After merging the akpm-current tree, today's linux-next build (powerpc
>> >> ppc64_defconfig) produced this warning:
>> >>
>> >> In file included from include/linux/mmzone.h:17:0,
>> >>  from include/linux/mempolicy.h:10,
>> >>  from mm/mempolicy.c:70:
>> >> mm/mempolicy.c: In function 'mpol_to_str':
>> >> include/linux/nodemask.h:107:41: warning: the address of 'nodes' will 
>> >> always evaluate as 'true' [-Waddress]
>> >>  #define nodemask_pr_args(maskp) (maskp) ? MAX_NUMNODES : 0, (maskp) ? 
>> >> (maskp)->bits : NULL
>> >>  ^
>> >> mm/mempolicy.c:2817:11: note: in expansion of macro 'nodemask_pr_args'
>> >>nodemask_pr_args());
>> >>^
>> >
>> > Hmm, this warning is quite surprising to me. Sure in this particular
>> > case maskp will always be non-NULL so we always expand to
>> > MAX_NUMNODES, maskp->bits
>> > which is what we want. But we have other users which may be NULL. Does
>> > anybody understan why this warns at all?
>>
>> As I understand it, the warning tries to address a common typo of 
>> accidentally
>> testing the pointer to a stack object for being non-NULL, rather than the 
>> object
>> pointed to for being non-zero.
>>
>> Adding an extra '!= NULL' comparison gets rid of the warning for me:
>>
>> #define nodemask_pr_args(maskp)  \
>>((maskp) != NULL) ? MAX_NUMNODES : 0, \
>>((maskp) != NULL) ?(maskp)->bits : NULL
>
> OK, that is a reasonable workaround. I was talking to our gcc guy and
> he suggested to report a bug for this.

That might also be useful. Some warnings in gcc get disabled when
they show up inside of a macro, and that could presumably be done
here too.

  Arnd

Re: linux-next: build warning after merge of the akpm-current tree

[Michal Hocko]

On Mon 13-11-17 12:43:08, Arnd Bergmann wrote:
> On Mon, Nov 13, 2017 at 9:09 AM, Michal Hocko  wrote:
> > On Mon 13-11-17 16:42:06, Stephen Rothwell wrote:
> >> Hi Andrew,
> >>
> >> After merging the akpm-current tree, today's linux-next build (powerpc
> >> ppc64_defconfig) produced this warning:
> >>
> >> In file included from include/linux/mmzone.h:17:0,
> >>  from include/linux/mempolicy.h:10,
> >>  from mm/mempolicy.c:70:
> >> mm/mempolicy.c: In function 'mpol_to_str':
> >> include/linux/nodemask.h:107:41: warning: the address of 'nodes' will 
> >> always evaluate as 'true' [-Waddress]
> >>  #define nodemask_pr_args(maskp) (maskp) ? MAX_NUMNODES : 0, (maskp) ? 
> >> (maskp)->bits : NULL
> >>  ^
> >> mm/mempolicy.c:2817:11: note: in expansion of macro 'nodemask_pr_args'
> >>nodemask_pr_args());
> >>^
> >
> > Hmm, this warning is quite surprising to me. Sure in this particular
> > case maskp will always be non-NULL so we always expand to
> > MAX_NUMNODES, maskp->bits
> > which is what we want. But we have other users which may be NULL. Does
> > anybody understan why this warns at all?
> 
> As I understand it, the warning tries to address a common typo of accidentally
> testing the pointer to a stack object for being non-NULL, rather than the 
> object
> pointed to for being non-zero.
> 
> Adding an extra '!= NULL' comparison gets rid of the warning for me:
> 
> #define nodemask_pr_args(maskp)  \
>((maskp) != NULL) ? MAX_NUMNODES : 0, \
>((maskp) != NULL) ?(maskp)->bits : NULL

OK, that is a reasonable workaround. I was talking to our gcc guy and
he suggested to report a bug for this. Andrew, could you fold the
explicit != NULL check into the patch please?

-- 
Michal Hocko
SUSE Labs

Re: linux-next: build warning after merge of the akpm-current tree

[Michal Hocko]

On Mon 13-11-17 12:43:08, Arnd Bergmann wrote:
> On Mon, Nov 13, 2017 at 9:09 AM, Michal Hocko  wrote:
> > On Mon 13-11-17 16:42:06, Stephen Rothwell wrote:
> >> Hi Andrew,
> >>
> >> After merging the akpm-current tree, today's linux-next build (powerpc
> >> ppc64_defconfig) produced this warning:
> >>
> >> In file included from include/linux/mmzone.h:17:0,
> >>  from include/linux/mempolicy.h:10,
> >>  from mm/mempolicy.c:70:
> >> mm/mempolicy.c: In function 'mpol_to_str':
> >> include/linux/nodemask.h:107:41: warning: the address of 'nodes' will 
> >> always evaluate as 'true' [-Waddress]
> >>  #define nodemask_pr_args(maskp) (maskp) ? MAX_NUMNODES : 0, (maskp) ? 
> >> (maskp)->bits : NULL
> >>  ^
> >> mm/mempolicy.c:2817:11: note: in expansion of macro 'nodemask_pr_args'
> >>nodemask_pr_args());
> >>^
> >
> > Hmm, this warning is quite surprising to me. Sure in this particular
> > case maskp will always be non-NULL so we always expand to
> > MAX_NUMNODES, maskp->bits
> > which is what we want. But we have other users which may be NULL. Does
> > anybody understan why this warns at all?
> 
> As I understand it, the warning tries to address a common typo of accidentally
> testing the pointer to a stack object for being non-NULL, rather than the 
> object
> pointed to for being non-zero.
> 
> Adding an extra '!= NULL' comparison gets rid of the warning for me:
> 
> #define nodemask_pr_args(maskp)  \
>((maskp) != NULL) ? MAX_NUMNODES : 0, \
>((maskp) != NULL) ?(maskp)->bits : NULL

OK, that is a reasonable workaround. I was talking to our gcc guy and
he suggested to report a bug for this. Andrew, could you fold the
explicit != NULL check into the patch please?

-- 
Michal Hocko
SUSE Labs

Re: linux-next: build warning after merge of the akpm-current tree

[Arnd Bergmann]

On Mon, Nov 13, 2017 at 9:09 AM, Michal Hocko  wrote:
> On Mon 13-11-17 16:42:06, Stephen Rothwell wrote:
>> Hi Andrew,
>>
>> After merging the akpm-current tree, today's linux-next build (powerpc
>> ppc64_defconfig) produced this warning:
>>
>> In file included from include/linux/mmzone.h:17:0,
>>  from include/linux/mempolicy.h:10,
>>  from mm/mempolicy.c:70:
>> mm/mempolicy.c: In function 'mpol_to_str':
>> include/linux/nodemask.h:107:41: warning: the address of 'nodes' will always 
>> evaluate as 'true' [-Waddress]
>>  #define nodemask_pr_args(maskp) (maskp) ? MAX_NUMNODES : 0, (maskp) ? 
>> (maskp)->bits : NULL
>>  ^
>> mm/mempolicy.c:2817:11: note: in expansion of macro 'nodemask_pr_args'
>>nodemask_pr_args());
>>^
>
> Hmm, this warning is quite surprising to me. Sure in this particular
> case maskp will always be non-NULL so we always expand to
> MAX_NUMNODES, maskp->bits
> which is what we want. But we have other users which may be NULL. Does
> anybody understan why this warns at all?

As I understand it, the warning tries to address a common typo of accidentally
testing the pointer to a stack object for being non-NULL, rather than the object
pointed to for being non-zero.

Adding an extra '!= NULL' comparison gets rid of the warning for me:

#define nodemask_pr_args(maskp)  \
   ((maskp) != NULL) ? MAX_NUMNODES : 0, \
   ((maskp) != NULL) ?(maskp)->bits : NULL

   Arnd

Re: linux-next: build warning after merge of the akpm-current tree

[Arnd Bergmann]

On Mon, Nov 13, 2017 at 9:09 AM, Michal Hocko  wrote:
> On Mon 13-11-17 16:42:06, Stephen Rothwell wrote:
>> Hi Andrew,
>>
>> After merging the akpm-current tree, today's linux-next build (powerpc
>> ppc64_defconfig) produced this warning:
>>
>> In file included from include/linux/mmzone.h:17:0,
>>  from include/linux/mempolicy.h:10,
>>  from mm/mempolicy.c:70:
>> mm/mempolicy.c: In function 'mpol_to_str':
>> include/linux/nodemask.h:107:41: warning: the address of 'nodes' will always 
>> evaluate as 'true' [-Waddress]
>>  #define nodemask_pr_args(maskp) (maskp) ? MAX_NUMNODES : 0, (maskp) ? 
>> (maskp)->bits : NULL
>>  ^
>> mm/mempolicy.c:2817:11: note: in expansion of macro 'nodemask_pr_args'
>>nodemask_pr_args());
>>^
>
> Hmm, this warning is quite surprising to me. Sure in this particular
> case maskp will always be non-NULL so we always expand to
> MAX_NUMNODES, maskp->bits
> which is what we want. But we have other users which may be NULL. Does
> anybody understan why this warns at all?

As I understand it, the warning tries to address a common typo of accidentally
testing the pointer to a stack object for being non-NULL, rather than the object
pointed to for being non-zero.

Adding an extra '!= NULL' comparison gets rid of the warning for me:

#define nodemask_pr_args(maskp)  \
   ((maskp) != NULL) ? MAX_NUMNODES : 0, \
   ((maskp) != NULL) ?(maskp)->bits : NULL

   Arnd

Re: linux-next: build warning after merge of the akpm-current tree

[Michal Hocko]

On Mon 13-11-17 09:09:55, Michal Hocko wrote:
> On Mon 13-11-17 16:42:06, Stephen Rothwell wrote:
> > Hi Andrew,
> > 
> > After merging the akpm-current tree, today's linux-next build (powerpc
> > ppc64_defconfig) produced this warning:
> > 
> > In file included from include/linux/mmzone.h:17:0,
> >  from include/linux/mempolicy.h:10,
> >  from mm/mempolicy.c:70:
> > mm/mempolicy.c: In function 'mpol_to_str':
> > include/linux/nodemask.h:107:41: warning: the address of 'nodes' will 
> > always evaluate as 'true' [-Waddress]
> >  #define nodemask_pr_args(maskp) (maskp) ? MAX_NUMNODES : 0, (maskp) ? 
> > (maskp)->bits : NULL
> >  ^
> > mm/mempolicy.c:2817:11: note: in expansion of macro 'nodemask_pr_args'
> >nodemask_pr_args());
> >^
> 
> Hmm, this warning is quite surprising to me. Sure in this particular
> case maskp will always be non-NULL so we always expand to
>   MAX_NUMNODES, maskp->bits
> which is what we want. But we have other users which may be NULL. Does
> anybody understan why this warns at all?

Strange I played with the following minimal test case and it warns only
for the explicit  use while n is clearly never null as well. This all
smells like -Waddress is just confused (at least with my gcc 7.2.0-12

#include 

#define MAX_NUMNODES 10
struct mask {
void *bits;
};
#define nodemask_pr_args(maskp) (maskp) ? MAX_NUMNODES : 0, (maskp) ? 
(maskp)->bits : NULL

int foo(void)
{
struct mask m;
struct mask *n = 

printf("%*p\n", nodemask_pr_args());
printf("%*p\n", nodemask_pr_args(n));

return 0;
}
-- 
Michal Hocko
SUSE Labs

Re: linux-next: build warning after merge of the akpm-current tree

[Michal Hocko]

On Mon 13-11-17 09:09:55, Michal Hocko wrote:
> On Mon 13-11-17 16:42:06, Stephen Rothwell wrote:
> > Hi Andrew,
> > 
> > After merging the akpm-current tree, today's linux-next build (powerpc
> > ppc64_defconfig) produced this warning:
> > 
> > In file included from include/linux/mmzone.h:17:0,
> >  from include/linux/mempolicy.h:10,
> >  from mm/mempolicy.c:70:
> > mm/mempolicy.c: In function 'mpol_to_str':
> > include/linux/nodemask.h:107:41: warning: the address of 'nodes' will 
> > always evaluate as 'true' [-Waddress]
> >  #define nodemask_pr_args(maskp) (maskp) ? MAX_NUMNODES : 0, (maskp) ? 
> > (maskp)->bits : NULL
> >  ^
> > mm/mempolicy.c:2817:11: note: in expansion of macro 'nodemask_pr_args'
> >nodemask_pr_args());
> >^
> 
> Hmm, this warning is quite surprising to me. Sure in this particular
> case maskp will always be non-NULL so we always expand to
>   MAX_NUMNODES, maskp->bits
> which is what we want. But we have other users which may be NULL. Does
> anybody understan why this warns at all?

Strange I played with the following minimal test case and it warns only
for the explicit  use while n is clearly never null as well. This all
smells like -Waddress is just confused (at least with my gcc 7.2.0-12

#include 

#define MAX_NUMNODES 10
struct mask {
void *bits;
};
#define nodemask_pr_args(maskp) (maskp) ? MAX_NUMNODES : 0, (maskp) ? 
(maskp)->bits : NULL

int foo(void)
{
struct mask m;
struct mask *n = 

printf("%*p\n", nodemask_pr_args());
printf("%*p\n", nodemask_pr_args(n));

return 0;
}
-- 
Michal Hocko
SUSE Labs

Re: linux-next: build warning after merge of the akpm-current tree

[Michal Hocko]

On Mon 13-11-17 16:42:06, Stephen Rothwell wrote:
> Hi Andrew,
> 
> After merging the akpm-current tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
> 
> In file included from include/linux/mmzone.h:17:0,
>  from include/linux/mempolicy.h:10,
>  from mm/mempolicy.c:70:
> mm/mempolicy.c: In function 'mpol_to_str':
> include/linux/nodemask.h:107:41: warning: the address of 'nodes' will always 
> evaluate as 'true' [-Waddress]
>  #define nodemask_pr_args(maskp) (maskp) ? MAX_NUMNODES : 0, (maskp) ? 
> (maskp)->bits : NULL
>  ^
> mm/mempolicy.c:2817:11: note: in expansion of macro 'nodemask_pr_args'
>nodemask_pr_args());
>^

Hmm, this warning is quite surprising to me. Sure in this particular
case maskp will always be non-NULL so we always expand to
MAX_NUMNODES, maskp->bits
which is what we want. But we have other users which may be NULL. Does
anybody understan why this warns at all?
-- 
Michal Hocko
SUSE Labs

Re: linux-next: build warning after merge of the akpm-current tree

[Michal Hocko]

On Mon 13-11-17 16:42:06, Stephen Rothwell wrote:
> Hi Andrew,
> 
> After merging the akpm-current tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
> 
> In file included from include/linux/mmzone.h:17:0,
>  from include/linux/mempolicy.h:10,
>  from mm/mempolicy.c:70:
> mm/mempolicy.c: In function 'mpol_to_str':
> include/linux/nodemask.h:107:41: warning: the address of 'nodes' will always 
> evaluate as 'true' [-Waddress]
>  #define nodemask_pr_args(maskp) (maskp) ? MAX_NUMNODES : 0, (maskp) ? 
> (maskp)->bits : NULL
>  ^
> mm/mempolicy.c:2817:11: note: in expansion of macro 'nodemask_pr_args'
>nodemask_pr_args());
>^

Hmm, this warning is quite surprising to me. Sure in this particular
case maskp will always be non-NULL so we always expand to
MAX_NUMNODES, maskp->bits
which is what we want. But we have other users which may be NULL. Does
anybody understan why this warns at all?
-- 
Michal Hocko
SUSE Labs

linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (x86_64
allmodconfig) produced this warning:

In file included from include/linux/printk.h:7:0,
 from include/linux/kernel.h:14,
 from lib/test_find_bit.c:28:
lib/test_find_bit.c: In function 'test_find_first_bit':
include/linux/kern_levels.h:5:18: warning: format '%ld' expects argument of 
type 'long int', but argument 2 has type 'cycles_t {aka long long unsigned 
int}' [-Wformat=]
 #define KERN_SOH "\001"  /* ASCII Start Of Header */
  ^
include/linux/kern_levels.h:11:18: note: in expansion of macro 'KERN_SOH'
 #define KERN_ERR KERN_SOH "3" /* error conditions */
  ^
include/linux/printk.h:300:9: note: in expansion of macro 'KERN_ERR'
  printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
 ^
lib/test_find_bit.c:54:2: note: in expansion of macro 'pr_err'
  pr_err("find_first_bit:\t\t%ld cycles,\t%ld iterations\n", cycles, cnt);
  ^
lib/test_find_bit.c: In function 'test_find_next_bit':
include/linux/kern_levels.h:5:18: warning: format '%ld' expects argument of 
type 'long int', but argument 2 has type 'cycles_t {aka long long unsigned 
int}' [-Wformat=]
 #define KERN_SOH "\001"  /* ASCII Start Of Header */
  ^
include/linux/kern_levels.h:11:18: note: in expansion of macro 'KERN_SOH'
 #define KERN_ERR KERN_SOH "3" /* error conditions */
  ^
include/linux/printk.h:300:9: note: in expansion of macro 'KERN_ERR'
  printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
 ^
lib/test_find_bit.c:68:2: note: in expansion of macro 'pr_err'
  pr_err("find_next_bit:\t\t%ld cycles,\t%ld iterations\n", cycles, cnt);
  ^
lib/test_find_bit.c: In function 'test_find_next_zero_bit':
include/linux/kern_levels.h:5:18: warning: format '%ld' expects argument of 
type 'long int', but argument 2 has type 'cycles_t {aka long long unsigned 
int}' [-Wformat=]
 #define KERN_SOH "\001"  /* ASCII Start Of Header */
  ^
include/linux/kern_levels.h:11:18: note: in expansion of macro 'KERN_SOH'
 #define KERN_ERR KERN_SOH "3" /* error conditions */
  ^
include/linux/printk.h:300:9: note: in expansion of macro 'KERN_ERR'
  printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
 ^
lib/test_find_bit.c:82:2: note: in expansion of macro 'pr_err'
  pr_err("find_next_zero_bit:\t%ld cycles,\t%ld iterations\n",
  ^
lib/test_find_bit.c: In function 'test_find_last_bit':
include/linux/kern_levels.h:5:18: warning: format '%ld' expects argument of 
type 'long int', but argument 2 has type 'cycles_t {aka long long unsigned 
int}' [-Wformat=]
 #define KERN_SOH "\001"  /* ASCII Start Of Header */
  ^
include/linux/kern_levels.h:11:18: note: in expansion of macro 'KERN_SOH'
 #define KERN_ERR KERN_SOH "3" /* error conditions */
  ^
include/linux/printk.h:300:9: note: in expansion of macro 'KERN_ERR'
  printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
 ^
lib/test_find_bit.c:102:2: note: in expansion of macro 'pr_err'
  pr_err("find_last_bit:\t\t%ld cycles,\t%ld iterations\n", cycles, cnt);
  ^

Introduced by commit

  09588b1f1d58 ("lib: test module for find_*_bit() functions")

-- 
Cheers,
Stephen Rothwell

linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (x86_64
allmodconfig) produced this warning:

In file included from include/linux/printk.h:7:0,
 from include/linux/kernel.h:14,
 from lib/test_find_bit.c:28:
lib/test_find_bit.c: In function 'test_find_first_bit':
include/linux/kern_levels.h:5:18: warning: format '%ld' expects argument of 
type 'long int', but argument 2 has type 'cycles_t {aka long long unsigned 
int}' [-Wformat=]
 #define KERN_SOH "\001"  /* ASCII Start Of Header */
  ^
include/linux/kern_levels.h:11:18: note: in expansion of macro 'KERN_SOH'
 #define KERN_ERR KERN_SOH "3" /* error conditions */
  ^
include/linux/printk.h:300:9: note: in expansion of macro 'KERN_ERR'
  printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
 ^
lib/test_find_bit.c:54:2: note: in expansion of macro 'pr_err'
  pr_err("find_first_bit:\t\t%ld cycles,\t%ld iterations\n", cycles, cnt);
  ^
lib/test_find_bit.c: In function 'test_find_next_bit':
include/linux/kern_levels.h:5:18: warning: format '%ld' expects argument of 
type 'long int', but argument 2 has type 'cycles_t {aka long long unsigned 
int}' [-Wformat=]
 #define KERN_SOH "\001"  /* ASCII Start Of Header */
  ^
include/linux/kern_levels.h:11:18: note: in expansion of macro 'KERN_SOH'
 #define KERN_ERR KERN_SOH "3" /* error conditions */
  ^
include/linux/printk.h:300:9: note: in expansion of macro 'KERN_ERR'
  printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
 ^
lib/test_find_bit.c:68:2: note: in expansion of macro 'pr_err'
  pr_err("find_next_bit:\t\t%ld cycles,\t%ld iterations\n", cycles, cnt);
  ^
lib/test_find_bit.c: In function 'test_find_next_zero_bit':
include/linux/kern_levels.h:5:18: warning: format '%ld' expects argument of 
type 'long int', but argument 2 has type 'cycles_t {aka long long unsigned 
int}' [-Wformat=]
 #define KERN_SOH "\001"  /* ASCII Start Of Header */
  ^
include/linux/kern_levels.h:11:18: note: in expansion of macro 'KERN_SOH'
 #define KERN_ERR KERN_SOH "3" /* error conditions */
  ^
include/linux/printk.h:300:9: note: in expansion of macro 'KERN_ERR'
  printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
 ^
lib/test_find_bit.c:82:2: note: in expansion of macro 'pr_err'
  pr_err("find_next_zero_bit:\t%ld cycles,\t%ld iterations\n",
  ^
lib/test_find_bit.c: In function 'test_find_last_bit':
include/linux/kern_levels.h:5:18: warning: format '%ld' expects argument of 
type 'long int', but argument 2 has type 'cycles_t {aka long long unsigned 
int}' [-Wformat=]
 #define KERN_SOH "\001"  /* ASCII Start Of Header */
  ^
include/linux/kern_levels.h:11:18: note: in expansion of macro 'KERN_SOH'
 #define KERN_ERR KERN_SOH "3" /* error conditions */
  ^
include/linux/printk.h:300:9: note: in expansion of macro 'KERN_ERR'
  printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
 ^
lib/test_find_bit.c:102:2: note: in expansion of macro 'pr_err'
  pr_err("find_last_bit:\t\t%ld cycles,\t%ld iterations\n", cycles, cnt);
  ^

Introduced by commit

  09588b1f1d58 ("lib: test module for find_*_bit() functions")

-- 
Cheers,
Stephen Rothwell

linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:

In file included from include/linux/mmzone.h:17:0,
 from include/linux/mempolicy.h:10,
 from mm/mempolicy.c:70:
mm/mempolicy.c: In function 'mpol_to_str':
include/linux/nodemask.h:107:41: warning: the address of 'nodes' will always 
evaluate as 'true' [-Waddress]
 #define nodemask_pr_args(maskp) (maskp) ? MAX_NUMNODES : 0, (maskp) ? 
(maskp)->bits : NULL
 ^
mm/mempolicy.c:2817:11: note: in expansion of macro 'nodemask_pr_args'
   nodemask_pr_args());
   ^
include/linux/nodemask.h:107:69: warning: the address of 'nodes' will always 
evaluate as 'true' [-Waddress]
 #define nodemask_pr_args(maskp) (maskp) ? MAX_NUMNODES : 0, (maskp) ? 
(maskp)->bits : NULL
 ^
mm/mempolicy.c:2817:11: note: in expansion of macro 'nodemask_pr_args'
   nodemask_pr_args());
   ^

Introduced by commit

  b2c1ed23bdc1 ("mm: simplify nodemask printing")

-- 
Cheers,
Stephen Rothwell

linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:

In file included from include/linux/mmzone.h:17:0,
 from include/linux/mempolicy.h:10,
 from mm/mempolicy.c:70:
mm/mempolicy.c: In function 'mpol_to_str':
include/linux/nodemask.h:107:41: warning: the address of 'nodes' will always 
evaluate as 'true' [-Waddress]
 #define nodemask_pr_args(maskp) (maskp) ? MAX_NUMNODES : 0, (maskp) ? 
(maskp)->bits : NULL
 ^
mm/mempolicy.c:2817:11: note: in expansion of macro 'nodemask_pr_args'
   nodemask_pr_args());
   ^
include/linux/nodemask.h:107:69: warning: the address of 'nodes' will always 
evaluate as 'true' [-Waddress]
 #define nodemask_pr_args(maskp) (maskp) ? MAX_NUMNODES : 0, (maskp) ? 
(maskp)->bits : NULL
 ^
mm/mempolicy.c:2817:11: note: in expansion of macro 'nodemask_pr_args'
   nodemask_pr_args());
   ^

Introduced by commit

  b2c1ed23bdc1 ("mm: simplify nodemask printing")

-- 
Cheers,
Stephen Rothwell

linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:

fs/proc/task_mmu.c: In function 'show_map_vma':
fs/proc/task_mmu.c:285:28: warning: unused variable 'priv' [-Wunused-variable]
  struct proc_maps_private *priv = m->private;
^

Introduced by commit

  14ccc3193225 ("fs, proc: remove priv argument from is_stack")

-- 
Cheers,
Stephen Rothwell

linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:

fs/proc/task_mmu.c: In function 'show_map_vma':
fs/proc/task_mmu.c:285:28: warning: unused variable 'priv' [-Wunused-variable]
  struct proc_maps_private *priv = m->private;
^

Introduced by commit

  14ccc3193225 ("fs, proc: remove priv argument from is_stack")

-- 
Cheers,
Stephen Rothwell

Re: linux-next: build warning after merge of the akpm-current tree

[Dave Kleikamp]

On 05/26/2017 05:16 AM, Jeff Layton wrote:
> On Fri, 2017-05-26 at 12:43 +1000, Stephen Rothwell wrote:
>> Hi Andrew,
>>
>> After merging the akpm-current tree, today's linux-next build (powerpc
>> ppc64_defconfig) produced this warning:
>>
>> fs/jfs/jfs_metapage.c: In function 'force_metapage':
>> fs/jfs/jfs_metapage.c:714:2: warning: ignoring return value of 
>> 'write_one_page', declared with attribute warn_unused_result 
>> [-Wunused-result]
>>   write_one_page(page);
>>   ^
>> fs/jfs/jfs_metapage.c: In function 'release_metapage':
>> fs/jfs/jfs_metapage.c:759:4: warning: ignoring return value of 
>> 'write_one_page', declared with attribute warn_unused_result 
>> [-Wunused-result]
>> write_one_page(page);
>> ^
>>
>> Introduced by commit
>>
>>   f8652aebee02 ("mm: drop "wait" parameter from write_one_page()")
>>
>> These call sites were updated for the droppping of the argument, but
>> not for the addition of __must_check :-(
>>
> 
> (cc'ing Dave...)
> 
> Yeah, that's a known issue. When Willy reviewed the patch originally he
> asked me to add a __must_check there so that JFS would pick up some
> warnings for this.
> 
> JFS really ought to check the return code there and do something sane
> with it. Dave?

This is true. I promised to do something about it. I'll try to get a
patch out later today.

Dave

Re: linux-next: build warning after merge of the akpm-current tree

[Dave Kleikamp]

On 05/26/2017 05:16 AM, Jeff Layton wrote:
> On Fri, 2017-05-26 at 12:43 +1000, Stephen Rothwell wrote:
>> Hi Andrew,
>>
>> After merging the akpm-current tree, today's linux-next build (powerpc
>> ppc64_defconfig) produced this warning:
>>
>> fs/jfs/jfs_metapage.c: In function 'force_metapage':
>> fs/jfs/jfs_metapage.c:714:2: warning: ignoring return value of 
>> 'write_one_page', declared with attribute warn_unused_result 
>> [-Wunused-result]
>>   write_one_page(page);
>>   ^
>> fs/jfs/jfs_metapage.c: In function 'release_metapage':
>> fs/jfs/jfs_metapage.c:759:4: warning: ignoring return value of 
>> 'write_one_page', declared with attribute warn_unused_result 
>> [-Wunused-result]
>> write_one_page(page);
>> ^
>>
>> Introduced by commit
>>
>>   f8652aebee02 ("mm: drop "wait" parameter from write_one_page()")
>>
>> These call sites were updated for the droppping of the argument, but
>> not for the addition of __must_check :-(
>>
> 
> (cc'ing Dave...)
> 
> Yeah, that's a known issue. When Willy reviewed the patch originally he
> asked me to add a __must_check there so that JFS would pick up some
> warnings for this.
> 
> JFS really ought to check the return code there and do something sane
> with it. Dave?

This is true. I promised to do something about it. I'll try to get a
patch out later today.

Dave

Re: linux-next: build warning after merge of the akpm-current tree

[Jeff Layton]

On Fri, 2017-05-26 at 12:43 +1000, Stephen Rothwell wrote:
> Hi Andrew,
> 
> After merging the akpm-current tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
> 
> fs/jfs/jfs_metapage.c: In function 'force_metapage':
> fs/jfs/jfs_metapage.c:714:2: warning: ignoring return value of 
> 'write_one_page', declared with attribute warn_unused_result [-Wunused-result]
>   write_one_page(page);
>   ^
> fs/jfs/jfs_metapage.c: In function 'release_metapage':
> fs/jfs/jfs_metapage.c:759:4: warning: ignoring return value of 
> 'write_one_page', declared with attribute warn_unused_result [-Wunused-result]
> write_one_page(page);
> ^
> 
> Introduced by commit
> 
>   f8652aebee02 ("mm: drop "wait" parameter from write_one_page()")
> 
> These call sites were updated for the droppping of the argument, but
> not for the addition of __must_check :-(
> 

(cc'ing Dave...)

Yeah, that's a known issue. When Willy reviewed the patch originally he
asked me to add a __must_check there so that JFS would pick up some
warnings for this.

JFS really ought to check the return code there and do something sane
with it. Dave?

-- 
Jeff Layton 

Re: linux-next: build warning after merge of the akpm-current tree

[Jeff Layton]

On Fri, 2017-05-26 at 12:43 +1000, Stephen Rothwell wrote:
> Hi Andrew,
> 
> After merging the akpm-current tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
> 
> fs/jfs/jfs_metapage.c: In function 'force_metapage':
> fs/jfs/jfs_metapage.c:714:2: warning: ignoring return value of 
> 'write_one_page', declared with attribute warn_unused_result [-Wunused-result]
>   write_one_page(page);
>   ^
> fs/jfs/jfs_metapage.c: In function 'release_metapage':
> fs/jfs/jfs_metapage.c:759:4: warning: ignoring return value of 
> 'write_one_page', declared with attribute warn_unused_result [-Wunused-result]
> write_one_page(page);
> ^
> 
> Introduced by commit
> 
>   f8652aebee02 ("mm: drop "wait" parameter from write_one_page()")
> 
> These call sites were updated for the droppping of the argument, but
> not for the addition of __must_check :-(
> 

(cc'ing Dave...)

Yeah, that's a known issue. When Willy reviewed the patch originally he
asked me to add a __must_check there so that JFS would pick up some
warnings for this.

JFS really ought to check the return code there and do something sane
with it. Dave?

-- 
Jeff Layton 

linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:

fs/jfs/jfs_metapage.c: In function 'force_metapage':
fs/jfs/jfs_metapage.c:714:2: warning: ignoring return value of 
'write_one_page', declared with attribute warn_unused_result [-Wunused-result]
  write_one_page(page);
  ^
fs/jfs/jfs_metapage.c: In function 'release_metapage':
fs/jfs/jfs_metapage.c:759:4: warning: ignoring return value of 
'write_one_page', declared with attribute warn_unused_result [-Wunused-result]
write_one_page(page);
^

Introduced by commit

  f8652aebee02 ("mm: drop "wait" parameter from write_one_page()")

These call sites were updated for the droppping of the argument, but
not for the addition of __must_check :-(

-- 
Cheers,
Stephen Rothwell

linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:

fs/jfs/jfs_metapage.c: In function 'force_metapage':
fs/jfs/jfs_metapage.c:714:2: warning: ignoring return value of 
'write_one_page', declared with attribute warn_unused_result [-Wunused-result]
  write_one_page(page);
  ^
fs/jfs/jfs_metapage.c: In function 'release_metapage':
fs/jfs/jfs_metapage.c:759:4: warning: ignoring return value of 
'write_one_page', declared with attribute warn_unused_result [-Wunused-result]
write_one_page(page);
^

Introduced by commit

  f8652aebee02 ("mm: drop "wait" parameter from write_one_page()")

These call sites were updated for the droppping of the argument, but
not for the addition of __must_check :-(

-- 
Cheers,
Stephen Rothwell