linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* linux-next: build warning after merge of the akpm-current tree
@ 2019-07-31  6:11 Stephen Rothwell
  2019-07-31  6:28 ` Miles Chen
  0 siblings, 1 reply; 145+ messages in thread
From: Stephen Rothwell @ 2019-07-31  6:11 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Miles Chen

[-- Attachment #1: Type: text/plain, Size: 499 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2019-07-31  6:11 linux-next: build warning after merge of the akpm-current tree Stephen Rothwell
@ 2019-07-31  6:28 ` Miles Chen
  2019-08-01  5:51   ` Stephen Rothwell
  0 siblings, 1 reply; 145+ messages in thread
From: Miles Chen @ 2019-07-31  6:28 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Linux Next Mailing List, Linux Kernel Mailing List

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()")
> 



^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2019-07-31  6:28 ` Miles Chen
@ 2019-08-01  5:51   ` Stephen Rothwell
  2019-08-01  6:15     ` Michal Hocko
  0 siblings, 1 reply; 145+ messages in thread
From: Stephen Rothwell @ 2019-08-01  5:51 UTC (permalink / raw)
  To: Miles Chen
  Cc: Andrew Morton, Linux Next Mailing List, Linux Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 934 bytes --]

Hi Miles,

On Wed, 31 Jul 2019 14:28:04 +0800 Miles Chen <miles.chen@mediatek.com> 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2019-08-01  5:51   ` Stephen Rothwell
@ 2019-08-01  6:15     ` Michal Hocko
  2019-08-01  6:30       ` Miles Chen
  0 siblings, 1 reply; 145+ messages in thread
From: Michal Hocko @ 2019-08-01  6:15 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Miles Chen, Andrew Morton, Linux Next Mailing List,
	Linux Kernel Mailing List, Qian Cai

On Thu 01-08-19 15:51:30, Stephen Rothwell wrote:
> Hi Miles,
> 
> On Wed, 31 Jul 2019 14:28:04 +0800 Miles Chen <miles.chen@mediatek.com> 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-cai@lca.pw
-- 
Michal Hocko
SUSE Labs

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2019-08-01  6:15     ` Michal Hocko
@ 2019-08-01  6:30       ` Miles Chen
  2019-08-01  6:38         ` Michal Hocko
  2019-08-01  6:39         ` Stephen Rothwell
  0 siblings, 2 replies; 145+ messages in thread
From: Miles Chen @ 2019-08-01  6:30 UTC (permalink / raw)
  To: Michal Hocko
  Cc: Stephen Rothwell, Andrew Morton, Linux Next Mailing List,
	Linux Kernel Mailing List, Qian Cai

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 <miles.chen@mediatek.com> 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-cai@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?



^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2019-08-01  6:30       ` Miles Chen
@ 2019-08-01  6:38         ` Michal Hocko
  2019-08-01  6:39         ` Stephen Rothwell
  1 sibling, 0 replies; 145+ messages in thread
From: Michal Hocko @ 2019-08-01  6:38 UTC (permalink / raw)
  To: Miles Chen
  Cc: Stephen Rothwell, Andrew Morton, Linux Next Mailing List,
	Linux Kernel Mailing List, Qian Cai

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

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2019-08-01  6:30       ` Miles Chen
  2019-08-01  6:38         ` Michal Hocko
@ 2019-08-01  6:39         ` Stephen Rothwell
  2019-08-01  6:42           ` Miles Chen
  1 sibling, 1 reply; 145+ messages in thread
From: Stephen Rothwell @ 2019-08-01  6:39 UTC (permalink / raw)
  To: Miles Chen
  Cc: Michal Hocko, Andrew Morton, Linux Next Mailing List,
	Linux Kernel Mailing List, Qian Cai

[-- Attachment #1: Type: text/plain, Size: 336 bytes --]

Hi Miles,

On Thu, 1 Aug 2019 14:30:03 +0800 Miles Chen <miles.chen@mediatek.com> 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2019-08-01  6:39         ` Stephen Rothwell
@ 2019-08-01  6:42           ` Miles Chen
  0 siblings, 0 replies; 145+ messages in thread
From: Miles Chen @ 2019-08-01  6:42 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Michal Hocko, Andrew Morton, Linux Next Mailing List,
	Linux Kernel Mailing List, Qian Cai

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 <miles.chen@mediatek.com> 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


^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2021-11-23 22:26     ` Stephen Rothwell
@ 2021-11-23 22:30       ` Suren Baghdasaryan
  0 siblings, 0 replies; 145+ messages in thread
From: Suren Baghdasaryan @ 2021-11-23 22:30 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Colin Cross, Linux Kernel Mailing List,
	Linux Next Mailing List

On Tue, Nov 23, 2021 at 2:26 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi Suren,
>
> On Tue, 23 Nov 2021 11:03:47 -0800 Suren Baghdasaryan <surenb@google.com> wrote:
> >
> > I just posted a fix for the warning at
> > https://lore.kernel.org/linux-next/20211123185928.2513763-1-surenb@google.com/T/#u
> > One thing I'm not sure is that I used SHA from linux-next in the Fixes: field:
> >
> > Fixes: 2df148be9486 ("mm: add a field to store names for private
> > anonymous memory")
> >
> > Not sure if that's acceptable. Please let me know if you want me to
> > repost the fix without that line.
>
> It doesn't really matter as Andrew will most likely squash this fixup
> into the original patch.

Perfect! Please let me know if anything else is needed.
Thanks,
Suren.

>
> --
> Cheers,
> Stephen Rothwell

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2021-11-23 19:03   ` Suren Baghdasaryan
@ 2021-11-23 22:26     ` Stephen Rothwell
  2021-11-23 22:30       ` Suren Baghdasaryan
  0 siblings, 1 reply; 145+ messages in thread
From: Stephen Rothwell @ 2021-11-23 22:26 UTC (permalink / raw)
  To: Suren Baghdasaryan
  Cc: Andrew Morton, Colin Cross, Linux Kernel Mailing List,
	Linux Next Mailing List

[-- Attachment #1: Type: text/plain, Size: 647 bytes --]

Hi Suren,

On Tue, 23 Nov 2021 11:03:47 -0800 Suren Baghdasaryan <surenb@google.com> wrote:
>
> I just posted a fix for the warning at
> https://lore.kernel.org/linux-next/20211123185928.2513763-1-surenb@google.com/T/#u
> One thing I'm not sure is that I used SHA from linux-next in the Fixes: field:
> 
> Fixes: 2df148be9486 ("mm: add a field to store names for private
> anonymous memory")
> 
> Not sure if that's acceptable. Please let me know if you want me to
> repost the fix without that line.

It doesn't really matter as Andrew will most likely squash this fixup
into the original patch.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2021-11-23  8:38 ` Suren Baghdasaryan
@ 2021-11-23 19:03   ` Suren Baghdasaryan
  2021-11-23 22:26     ` Stephen Rothwell
  0 siblings, 1 reply; 145+ messages in thread
From: Suren Baghdasaryan @ 2021-11-23 19:03 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Colin Cross, Linux Kernel Mailing List,
	Linux Next Mailing List

On Tue, Nov 23, 2021 at 12:38 AM Suren Baghdasaryan <surenb@google.com> wrote:
>
> On Mon, Nov 22, 2021 at 9:26 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Hi all,
> >
> > After merging the akpm-current tree, today's linux-next build (htmldocs)
> > produced this warning:
> >
> > Documentation/filesystems/proc.rst:429: WARNING: Malformed table.
> > No bottom table border found.
> >
> > =======                    ====================================
> > [heap]                     the heap of the program
> > [stack]                    the stack of the main process
> > [vdso]                     the "virtual dynamic shared object",
> >                            the kernel system call handler
> > Documentation/filesystems/proc.rst:434: WARNING: Block quote ends without a blank line; unexpected unindent.
> > Documentation/filesystems/proc.rst:436: WARNING: Block quote ends without a blank line; unexpected unindent.
> > Documentation/filesystems/proc.rst:436: WARNING: Malformed table.
> > No bottom table border found.
> >
> > =======                    ====================================
> >
> > or if empty, the mapping is anonymous.
> >
> > Introduced by commit
> >
> >   2df148be9486 ("mm: add a field to store names for private anonymous memory")
>
> Thank you for reporting! I'll try to fix it first thing in the morning.

Hi Stephen,
I just posted a fix for the warning at
https://lore.kernel.org/linux-next/20211123185928.2513763-1-surenb@google.com/T/#u
One thing I'm not sure is that I used SHA from linux-next in the Fixes: field:

Fixes: 2df148be9486 ("mm: add a field to store names for private
anonymous memory")

Not sure if that's acceptable. Please let me know if you want me to
repost the fix without that line.
Thanks,
Suren.

> Thanks,
> Suren.
>
> >
> > --
> > Cheers,
> > Stephen Rothwell

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2021-11-23  5:26 Stephen Rothwell
@ 2021-11-23  8:38 ` Suren Baghdasaryan
  2021-11-23 19:03   ` Suren Baghdasaryan
  0 siblings, 1 reply; 145+ messages in thread
From: Suren Baghdasaryan @ 2021-11-23  8:38 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Colin Cross, Linux Kernel Mailing List,
	Linux Next Mailing List

On Mon, Nov 22, 2021 at 9:26 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> After merging the akpm-current tree, today's linux-next build (htmldocs)
> produced this warning:
>
> Documentation/filesystems/proc.rst:429: WARNING: Malformed table.
> No bottom table border found.
>
> =======                    ====================================
> [heap]                     the heap of the program
> [stack]                    the stack of the main process
> [vdso]                     the "virtual dynamic shared object",
>                            the kernel system call handler
> Documentation/filesystems/proc.rst:434: WARNING: Block quote ends without a blank line; unexpected unindent.
> Documentation/filesystems/proc.rst:436: WARNING: Block quote ends without a blank line; unexpected unindent.
> Documentation/filesystems/proc.rst:436: WARNING: Malformed table.
> No bottom table border found.
>
> =======                    ====================================
>
> or if empty, the mapping is anonymous.
>
> Introduced by commit
>
>   2df148be9486 ("mm: add a field to store names for private anonymous memory")

Thank you for reporting! I'll try to fix it first thing in the morning.
Thanks,
Suren.

>
> --
> Cheers,
> Stephen Rothwell

^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
@ 2021-11-23  5:26 Stephen Rothwell
  2021-11-23  8:38 ` Suren Baghdasaryan
  0 siblings, 1 reply; 145+ messages in thread
From: Stephen Rothwell @ 2021-11-23  5:26 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Colin Cross, Suren Baghdasaryan, Linux Kernel Mailing List,
	Linux Next Mailing List

[-- Attachment #1: Type: text/plain, Size: 1077 bytes --]

Hi all,

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

Documentation/filesystems/proc.rst:429: WARNING: Malformed table.
No bottom table border found.

=======                    ====================================
[heap]                     the heap of the program
[stack]                    the stack of the main process
[vdso]                     the "virtual dynamic shared object",
                           the kernel system call handler
Documentation/filesystems/proc.rst:434: WARNING: Block quote ends without a blank line; unexpected unindent.
Documentation/filesystems/proc.rst:436: WARNING: Block quote ends without a blank line; unexpected unindent.
Documentation/filesystems/proc.rst:436: WARNING: Malformed table.
No bottom table border found.

=======                    ====================================

or if empty, the mapping is anonymous.

Introduced by commit

  2df148be9486 ("mm: add a field to store names for private anonymous memory")

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2021-07-19  7:52 Stephen Rothwell
@ 2021-07-19  8:47 ` Feng Tang
  0 siblings, 0 replies; 145+ messages in thread
From: Feng Tang @ 2021-07-19  8:47 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Ben Widawsky, Linux Kernel Mailing List,
	Linux Next Mailing List

[-- Attachment #1: Type: text/plain, Size: 2029 bytes --]

Hi Stephen,

On Mon, Jul 19, 2021 at 05:52:03PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the akpm-current tree, today's linux-next build (i386
> defconfig) produced this warning:
> 
> mm/hugetlb.c: In function 'dequeue_huge_page_vma':
> mm/hugetlb.c:1180:1: warning: label 'check_reserve' defined but not used [-Wunused-label]
>  1180 | check_reserve:
>       | ^~~~~~~~~~~~~
> 
> Introduced by commit
> 
>   df178183cf05 ("mm/hugetlb: add support for mempolicy MPOL_PREFERRED_MANY")

Thanks for the report!

The below patch should fix it (Also attached).

Andrew,

Could you help to fold it to the 4/6 of patchset of "introducing
multi-preference memplicy":
  [PATCH v6 4/6] mm/hugetlb: add support for mempolicy MPOL_PREFERRED_MANY 

Thanks!

- Feng

--------------------------------8<-----------------------------------

From 4d3b4b0037bf4e1eacae4886387ffe4af90f5a1f Mon Sep 17 00:00:00 2001
From: Feng Tang <feng.tang@intel.com>
Date: Mon, 19 Jul 2021 16:24:23 +0800
Subject: [PATCH] mm/hugetlb: fix compile warning for !CONFIG_NUMA build

Stephen Rothwell reported the i386 build with CONFIG_NUMA=n
will have a warning:

mm/hugetlb.c: In function 'dequeue_huge_page_vma':
mm/hugetlb.c:1180:1: warning: label 'check_reserve' defined but not used [-Wunused-label]
 1180 | check_reserve:
       | ^~~~~~~~~~~~~

introduced by commit
    df178183cf05 ("mm/hugetlb: add support for mempolicy MPOL_PREFERRED_MANY")

Signed-off-by: Feng Tang <feng.tang@intel.com>
---
 mm/hugetlb.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index ae1a39e11bcf..528947da65c8 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1177,7 +1177,9 @@ static struct page *dequeue_huge_page_vma(struct hstate *h,
 #endif
 	page = dequeue_huge_page_nodemask(h, gfp_mask, nid, nodemask);
 
+#ifdef CONFIG_NUMA
 check_reserve:
+#endif
 	if (page && !avoid_reserve && vma_has_reserves(vma, chg)) {
 		SetHPageRestoreReserve(page);
 		h->resv_huge_pages--;
-- 
2.7.4


> -- 
> Cheers,
> Stephen Rothwell



[-- Attachment #2: 0001-mm-hugetlb-fix-compile-warning-for-CONFIG_NUMA-build.patch --]
[-- Type: text/x-diff, Size: 1148 bytes --]

From 4d3b4b0037bf4e1eacae4886387ffe4af90f5a1f Mon Sep 17 00:00:00 2001
From: Feng Tang <feng.tang@intel.com>
Date: Mon, 19 Jul 2021 16:24:23 +0800
Subject: [PATCH] mm/hugetlb: fix compile warning for !CONFIG_NUMA build

Stephen Rothwell reported the i386 build with CONFIG_NUMA=n
will have a warning:

mm/hugetlb.c: In function 'dequeue_huge_page_vma':
mm/hugetlb.c:1180:1: warning: label 'check_reserve' defined but not used [-Wunused-label]
 1180 | check_reserve:
       | ^~~~~~~~~~~~~

introduced by commit
    df178183cf05 ("mm/hugetlb: add support for mempolicy MPOL_PREFERRED_MANY")

Signed-off-by: Feng Tang <feng.tang@intel.com>
---
 mm/hugetlb.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index ae1a39e11bcf..528947da65c8 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1177,7 +1177,9 @@ static struct page *dequeue_huge_page_vma(struct hstate *h,
 #endif
 	page = dequeue_huge_page_nodemask(h, gfp_mask, nid, nodemask);
 
+#ifdef CONFIG_NUMA
 check_reserve:
+#endif
 	if (page && !avoid_reserve && vma_has_reserves(vma, chg)) {
 		SetHPageRestoreReserve(page);
 		h->resv_huge_pages--;
-- 
2.7.4


^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
@ 2021-07-19  7:52 Stephen Rothwell
  2021-07-19  8:47 ` Feng Tang
  0 siblings, 1 reply; 145+ messages in thread
From: Stephen Rothwell @ 2021-07-19  7:52 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Ben Widawsky, Feng Tang, Linux Kernel Mailing List,
	Linux Next Mailing List

[-- Attachment #1: Type: text/plain, Size: 445 bytes --]

Hi all,

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

mm/hugetlb.c: In function 'dequeue_huge_page_vma':
mm/hugetlb.c:1180:1: warning: label 'check_reserve' defined but not used [-Wunused-label]
 1180 | check_reserve:
      | ^~~~~~~~~~~~~

Introduced by commit

  df178183cf05 ("mm/hugetlb: add support for mempolicy MPOL_PREFERRED_MANY")

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2021-05-21  5:39 Stephen Rothwell
@ 2021-05-21  6:53 ` Miaohe Lin
  0 siblings, 0 replies; 145+ messages in thread
From: Miaohe Lin @ 2021-05-21  6:53 UTC (permalink / raw)
  To: Stephen Rothwell, Andrew Morton
  Cc: Linux Kernel Mailing List, Linux Next Mailing List

On 2021/5/21 13:39, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the akpm-current tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
> 
> mm/swapfile.c:1039:22: warning: 'scan_swap_map' defined but not used [-Wunused-function]
>  1039 | static unsigned long scan_swap_map(struct swap_info_struct *si,
>       |                      ^~~~~~~~~~~~~
> 
> Introduced by commit
> 
>   c9ea6b99df3c ("mm/swapfile: move get_swap_page_of_type() under CONFIG_HIBERNATION")
> 
> # CONFIG_HIBERNATION is not set

It seems that scan_swap_map is only used by get_swap_page_of_type(). I should have been more careful
and move it under CONFIG_HIBERNATION too. I will send a patch to fix this. Many thanks!

> 


^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
@ 2021-05-21  5:39 Stephen Rothwell
  2021-05-21  6:53 ` Miaohe Lin
  0 siblings, 1 reply; 145+ messages in thread
From: Stephen Rothwell @ 2021-05-21  5:39 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Miaohe Lin, Linux Kernel Mailing List, Linux Next Mailing List

[-- Attachment #1: Type: text/plain, Size: 515 bytes --]

Hi all,

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

mm/swapfile.c:1039:22: warning: 'scan_swap_map' defined but not used [-Wunused-function]
 1039 | static unsigned long scan_swap_map(struct swap_info_struct *si,
      |                      ^~~~~~~~~~~~~

Introduced by commit

  c9ea6b99df3c ("mm/swapfile: move get_swap_page_of_type() under CONFIG_HIBERNATION")

# CONFIG_HIBERNATION is not set

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
@ 2021-03-30 20:04 Stephen Rothwell
  0 siblings, 0 replies; 145+ messages in thread
From: Stephen Rothwell @ 2021-03-30 20:04 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Nicholas Piggin, Linux Kernel Mailing List, Linux Next Mailing List

[-- Attachment #1: Type: text/plain, Size: 350 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2021-03-16 23:09     ` Jonathan Corbet
@ 2021-03-17 13:22       ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 145+ messages in thread
From: Mauro Carvalho Chehab @ 2021-03-17 13:22 UTC (permalink / raw)
  To: Jonathan Corbet
  Cc: Stephen Rothwell, Minchan Kim, Andrew Morton,
	Linux Kernel Mailing List, Linux Next Mailing List

Em Tue, 16 Mar 2021 17:09:20 -0600
Jonathan Corbet <corbet@lwn.net> escreveu:

> Stephen Rothwell <sfr@canb.auug.org.au> writes:
> 
> [Adding Mauro]
> 
> > On Tue, 16 Mar 2021 11:18:11 -0700 Minchan Kim <minchan@kernel.org> 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/<cma-heap-name> 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
> <text in angle brackets> 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/ <abi_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 <abi_file_aa_sysfs_kernel_mm_cma>`
	
	:ref:`\/sys\/kernel\/mm\/cma\/ <abi_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\/ <abi_sys_kernel_mm_cma>`<cma-heap-name> 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/<cma\-heap\-name>/alloc\_pages\_fail** |
	+-------------------------------------------------------------+
	
	Defined on file :ref:`sysfs-kernel-mm-cma <abi_file_aa_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/<cma\-heap\-name>/alloc\_pages\_success** |
	+----------------------------------------------------------------+
	
	Defined on file :ref:`sysfs-kernel-mm-cma <abi_file_aa_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\/ <abi_sys_kernel_mm_cma>`
	
	- :ref:`\/sys\/kernel\/mm\/cma\/\<cma\-heap\-name\>\/alloc_pages_success <abi_sys_kernel_mm_cma_cma_heap_name_alloc_pages_success>`
	
	- :ref:`\/sys\/kernel\/mm\/cma\/\<cma\-heap\-name\>\/alloc_pages_fail <abi_sys_kernel_mm_cma_cma_heap_name_alloc_pages_fail>`
	
There are two separated issues here:

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

	What:           /sys/kernel/mm/cma/
	Date:           Feb 2021
	Contact:        Minchan Kim <minchan@kernel.org>
	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/<cma-heap-name>/alloc_pages_success
	                        /sys/kernel/mm/cma/<cma-heap-name>/alloc_pages_fail

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

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

  The enclosed patch should do the trick. Please notice that I didn't
  check if this won't cause side effects - I'm in vacations until next
  week... too lazy to do a full test those days ;-) 

Thanks,
Mauro

[PATCH] script: get_abi.pl: escape "<" and ">" characters

Those characters should be escaped on cross-references.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

diff --git a/scripts/get_abi.pl b/scripts/get_abi.pl
index 92d9aa6cc4f5..79d195b48652 100755
--- a/scripts/get_abi.pl
+++ b/scripts/get_abi.pl
@@ -305,7 +305,7 @@ sub output_rest {
 		}
 
 		my $w = $what;
-		$w =~ s/([\(\)\_\-\*\=\^\~\\])/\\$1/g;
+		$w =~ s/([\(\)\_\-\*\=\^\~\\\<\>])/\\$1/g;
 
 		if ($type ne "File") {
 			my $cur_part = $what;



^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2021-03-16 21:49   ` Stephen Rothwell
@ 2021-03-16 23:09     ` Jonathan Corbet
  2021-03-17 13:22       ` Mauro Carvalho Chehab
  0 siblings, 1 reply; 145+ messages in thread
From: Jonathan Corbet @ 2021-03-16 23:09 UTC (permalink / raw)
  To: Stephen Rothwell, Minchan Kim
  Cc: Andrew Morton, Linux Kernel Mailing List,
	Linux Next Mailing List, Mauro Carvalho Chehab

Stephen Rothwell <sfr@canb.auug.org.au> writes:

[Adding Mauro]

> On Tue, 16 Mar 2021 11:18:11 -0700 Minchan Kim <minchan@kernel.org> 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/<cma-heap-name> 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
<text in angle brackets> 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

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2021-03-16 18:18 ` Minchan Kim
@ 2021-03-16 21:49   ` Stephen Rothwell
  2021-03-16 23:09     ` Jonathan Corbet
  0 siblings, 1 reply; 145+ messages in thread
From: Stephen Rothwell @ 2021-03-16 21:49 UTC (permalink / raw)
  To: Minchan Kim
  Cc: Andrew Morton, Linux Kernel Mailing List,
	Linux Next Mailing List, Jonathan Corbet

[-- Attachment #1: Type: text/plain, Size: 732 bytes --]

Hi Minchan,

On Tue, 16 Mar 2021 11:18:11 -0700 Minchan Kim <minchan@kernel.org> 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2021-03-15  5:35 Stephen Rothwell
@ 2021-03-16 18:18 ` Minchan Kim
  2021-03-16 21:49   ` Stephen Rothwell
  0 siblings, 1 reply; 145+ messages in thread
From: Minchan Kim @ 2021-03-16 18:18 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Linux Kernel Mailing List, Linux Next Mailing List

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?

^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
@ 2021-03-15  5:35 Stephen Rothwell
  2021-03-16 18:18 ` Minchan Kim
  0 siblings, 1 reply; 145+ messages in thread
From: Stephen Rothwell @ 2021-03-15  5:35 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Minchan Kim, Linux Kernel Mailing List, Linux Next Mailing List

[-- Attachment #1: Type: text/plain, Size: 350 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2020-12-10  9:38 Stephen Rothwell
@ 2020-12-10 16:05 ` Georgi Djakov
  0 siblings, 0 replies; 145+ messages in thread
From: Georgi Djakov @ 2020-12-10 16:05 UTC (permalink / raw)
  To: Stephen Rothwell, Andrew Morton
  Cc: Liam Mark, Linux Kernel Mailing List, Linux Next Mailing List

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")
> 

^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
@ 2020-12-10  9:38 Stephen Rothwell
  2020-12-10 16:05 ` Georgi Djakov
  0 siblings, 1 reply; 145+ messages in thread
From: Stephen Rothwell @ 2020-12-10  9:38 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Georgi Djakov, Liam Mark, Linux Kernel Mailing List,
	Linux Next Mailing List

[-- Attachment #1: Type: text/plain, Size: 447 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2020-11-13  6:01 Stephen Rothwell
@ 2020-11-16 10:03 ` Andy Shevchenko
  0 siblings, 0 replies; 145+ messages in thread
From: Andy Shevchenko @ 2020-11-16 10:03 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Linux Kernel Mailing List, Linux Next Mailing List

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



^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
@ 2020-11-13  6:01 Stephen Rothwell
  2020-11-16 10:03 ` Andy Shevchenko
  0 siblings, 1 reply; 145+ messages in thread
From: Stephen Rothwell @ 2020-11-13  6:01 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Andy Shevchenko, Linux Kernel Mailing List, Linux Next Mailing List

[-- Attachment #1: Type: text/plain, Size: 325 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
@ 2020-11-06  6:26 Stephen Rothwell
  0 siblings, 0 replies; 145+ messages in thread
From: Stephen Rothwell @ 2020-11-06  6:26 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Alexander Potapenko, Marco Elver, Linux Kernel Mailing List,
	Linux Next Mailing List

[-- Attachment #1: Type: text/plain, Size: 331 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2020-11-05  7:45     ` Anand K. Mistry
@ 2020-11-05  9:17       ` Mike Rapoport
  0 siblings, 0 replies; 145+ messages in thread
From: Mike Rapoport @ 2020-11-05  9:17 UTC (permalink / raw)
  To: Anand K. Mistry
  Cc: Stephen Rothwell, Andrew Morton, Linux Kernel Mailing List,
	Linux Next Mailing List

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.

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2020-11-05  8:00     ` Stephen Rothwell
@ 2020-11-05  8:03       ` Stephen Rothwell
  0 siblings, 0 replies; 145+ messages in thread
From: Stephen Rothwell @ 2020-11-05  8:03 UTC (permalink / raw)
  To: Anand K. Mistry
  Cc: Mike Rapoport, Andrew Morton, Linux Kernel Mailing List,
	Linux Next Mailing List

[-- Attachment #1: Type: text/plain, Size: 888 bytes --]

Hi Anand,

On Thu, 5 Nov 2020 19:00:11 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Thu, 5 Nov 2020 18:42:23 +1100 "Anand K. Mistry" <amistry@google.com> 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2020-11-05  7:42   ` Anand K. Mistry
  2020-11-05  7:45     ` Anand K. Mistry
@ 2020-11-05  8:00     ` Stephen Rothwell
  2020-11-05  8:03       ` Stephen Rothwell
  1 sibling, 1 reply; 145+ messages in thread
From: Stephen Rothwell @ 2020-11-05  8:00 UTC (permalink / raw)
  To: Anand K. Mistry
  Cc: Mike Rapoport, Andrew Morton, Linux Kernel Mailing List,
	Linux Next Mailing List

[-- Attachment #1: Type: text/plain, Size: 560 bytes --]

Hi Anand,

On Thu, 5 Nov 2020 18:42:23 +1100 "Anand K. Mistry" <amistry@google.com> 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2020-11-05  7:42   ` Anand K. Mistry
@ 2020-11-05  7:45     ` Anand K. Mistry
  2020-11-05  9:17       ` Mike Rapoport
  2020-11-05  8:00     ` Stephen Rothwell
  1 sibling, 1 reply; 145+ messages in thread
From: Anand K. Mistry @ 2020-11-05  7:45 UTC (permalink / raw)
  To: Mike Rapoport
  Cc: Stephen Rothwell, Andrew Morton, Linux Kernel Mailing List,
	Linux Next Mailing List

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?

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2020-11-05  7:03 ` Mike Rapoport
@ 2020-11-05  7:42   ` Anand K. Mistry
  2020-11-05  7:45     ` Anand K. Mistry
  2020-11-05  8:00     ` Stephen Rothwell
  0 siblings, 2 replies; 145+ messages in thread
From: Anand K. Mistry @ 2020-11-05  7:42 UTC (permalink / raw)
  To: Mike Rapoport
  Cc: Stephen Rothwell, Andrew Morton, Linux Kernel Mailing List,
	Linux Next Mailing List

On Thu, 5 Nov 2020 at 18:03, Mike Rapoport <rppt@kernel.org> 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_Bypass    speculative 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_Bypass    speculative store bypass mitigation status
> >  Speculation_Indirect_Branch indirect branch speculation mode
> >  Cpus_allowed                mask of CPUs on which this process may run
> >  Cpus_allowed_list           Same as previous, but in "list format"
> >  Mems_allowed                mask 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

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2020-11-05  6:45 Stephen Rothwell
@ 2020-11-05  7:03 ` Mike Rapoport
  2020-11-05  7:42   ` Anand K. Mistry
  0 siblings, 1 reply; 145+ messages in thread
From: Mike Rapoport @ 2020-11-05  7:03 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Anand K Mistry, Linux Kernel Mailing List,
	Linux Next Mailing List

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_Bypass    speculative 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_Bypass    speculative store bypass mitigation status
>  Speculation_Indirect_Branch indirect branch speculation mode
>  Cpus_allowed                mask of CPUs on which this process may run
>  Cpus_allowed_list           Same as previous, but in "list format"
>  Mems_allowed                mask 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.

^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
@ 2020-11-05  6:45 Stephen Rothwell
  2020-11-05  7:03 ` Mike Rapoport
  0 siblings, 1 reply; 145+ messages in thread
From: Stephen Rothwell @ 2020-11-05  6:45 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Anand K Mistry, Linux Kernel Mailing List, Linux Next Mailing List

[-- Attachment #1: Type: text/plain, Size: 9464 bytes --]

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
==========================  ===================================================
Name                        filename 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)
Tgid                        thread group ID
Ngid                        NUMA group ID (0 if none)
Pid                         process id
PPid                        process 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
RssShmem                    size 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)
HugetlbPages                size 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
SigQ                        number 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_Bypass    speculative store bypass mitigation status
Speculation_Indirect_Branch indirect branch speculation mode
Cpus_allowed                mask of CPUs on which this process may run
Cpus_allowed_list           Same as previous, but in "list format"
Mems_allowed                mask 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                        filename 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)
 Tgid                        thread group ID
 Ngid                        NUMA group ID (0 if none)
 Pid                         process id
 PPid                        process 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
 RssShmem                    size 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)
 HugetlbPages                size 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
 SigQ                        number 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_Bypass    speculative store bypass mitigation status
 Speculation_Indirect_Branch indirect branch speculation mode
 Cpus_allowed                mask of CPUs on which this process may run
 Cpus_allowed_list           Same as previous, but in "list format"
 Mems_allowed                mask 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
 ==========================  ===================================================

Introduced by commit

  60b492d745d5 ("proc: provide details on indirect branch speculation")

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2020-09-15  4:03 ` David Gow
  2020-09-15  4:16   ` Stephen Rothwell
@ 2020-09-15  9:57   ` Marco Elver
  1 sibling, 0 replies; 145+ messages in thread
From: Marco Elver @ 2020-09-15  9:57 UTC (permalink / raw)
  To: David Gow
  Cc: Stephen Rothwell, Andrew Morton, Patricia Alfonso,
	Linux Next Mailing List, Linux Kernel Mailing List, kasan-dev,
	KUnit Development, Andrey Konovalov

On Tue, 15 Sep 2020 at 06:03, 'David Gow' via kasan-dev
<kasan-dev@googlegroups.com> wrote:
>
> [+kasan-dev, +kunit-dev]
>
> On Mon, Sep 14, 2020 at 3:01 PM Stephen Rothwell <sfr@canb.auug.org.au> 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-davidgow@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

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2020-09-15  4:03 ` David Gow
@ 2020-09-15  4:16   ` Stephen Rothwell
  2020-09-15  9:57   ` Marco Elver
  1 sibling, 0 replies; 145+ messages in thread
From: Stephen Rothwell @ 2020-09-15  4:16 UTC (permalink / raw)
  To: David Gow
  Cc: Andrew Morton, Patricia Alfonso, Linux Next Mailing List,
	Linux Kernel Mailing List, kasan-dev, KUnit Development

[-- Attachment #1: Type: text/plain, Size: 630 bytes --]

Hi David,

On Tue, 15 Sep 2020 12:03:08 +0800 David Gow <davidgow@google.com> 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(&chip->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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2020-09-14  7:00 Stephen Rothwell
@ 2020-09-15  4:03 ` David Gow
  2020-09-15  4:16   ` Stephen Rothwell
  2020-09-15  9:57   ` Marco Elver
  0 siblings, 2 replies; 145+ messages in thread
From: David Gow @ 2020-09-15  4:03 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Patricia Alfonso, Linux Next Mailing List,
	Linux Kernel Mailing List, kasan-dev, KUnit Development

[+kasan-dev, +kunit-dev]

On Mon, Sep 14, 2020 at 3:01 PM Stephen Rothwell <sfr@canb.auug.org.au> 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-davidgow@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(&chip->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

^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
@ 2020-09-14  7:00 Stephen Rothwell
  2020-09-15  4:03 ` David Gow
  0 siblings, 1 reply; 145+ messages in thread
From: Stephen Rothwell @ 2020-09-14  7:00 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Patricia Alfonso, Linux Next Mailing List,
	Linux Kernel Mailing List, David Gow

[-- Attachment #1: Type: text/plain, Size: 11077 bytes --]

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'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch]
  254 | void __asan_store2_noabort(unsigned long addr);
      |      ^~~~~~~~~~~~~~~~~~~~~
lib/../mm/kasan/kasan.h:255:6: warning: conflicting types for built-in function '__asan_load4_noabort'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch]
  255 | void __asan_load4_noabort(unsigned long addr);
      |      ^~~~~~~~~~~~~~~~~~~~
lib/../mm/kasan/kasan.h:256:6: warning: conflicting types for built-in function '__asan_store4_noabort'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch]
  256 | void __asan_store4_noabort(unsigned long addr);
      |      ^~~~~~~~~~~~~~~~~~~~~
lib/../mm/kasan/kasan.h:257:6: warning: conflicting types for built-in function '__asan_load8_noabort'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch]
  257 | void __asan_load8_noabort(unsigned long addr);
      |      ^~~~~~~~~~~~~~~~~~~~
lib/../mm/kasan/kasan.h:258:6: warning: conflicting types for built-in function '__asan_store8_noabort'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch]
  258 | void __asan_store8_noabort(unsigned long addr);
      |      ^~~~~~~~~~~~~~~~~~~~~
lib/../mm/kasan/kasan.h:259:6: warning: conflicting types for built-in function '__asan_load16_noabort'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch]
  259 | void __asan_load16_noabort(unsigned long addr);
      |      ^~~~~~~~~~~~~~~~~~~~~
lib/../mm/kasan/kasan.h:260:6: warning: conflicting types for built-in function '__asan_store16_noabort'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch]
  260 | void __asan_store16_noabort(unsigned long addr);
      |      ^~~~~~~~~~~~~~~~~~~~~~
lib/../mm/kasan/kasan.h:261:6: warning: conflicting types for built-in function '__asan_loadN_noabort'; expected 'void(void *, long int)' [-Wbuiltin-declaration-mismatch]
  261 | void __asan_loadN_noabort(unsigned long addr, size_t size);
      |      ^~~~~~~~~~~~~~~~~~~~
lib/../mm/kasan/kasan.h:262:6: warning: conflicting types for built-in function '__asan_storeN_noabort'; expected 'void(void *, long int)' [-Wbuiltin-declaration-mismatch]
  262 | void __asan_storeN_noabort(unsigned long addr, size_t size);
      |      ^~~~~~~~~~~~~~~~~~~~~
lib/../mm/kasan/kasan.h:264:6: warning: conflicting types for built-in function '__asan_report_load1_noabort'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch]
  264 | void __asan_report_load1_noabort(unsigned long addr);
      |      ^~~~~~~~~~~~~~~~~~~~~~~~~~~
lib/../mm/kasan/kasan.h:265:6: warning: conflicting types for built-in function '__asan_report_store1_noabort'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch]
  265 | void __asan_report_store1_noabort(unsigned long addr);
      |      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
lib/../mm/kasan/kasan.h:266:6: warning: conflicting types for built-in function '__asan_report_load2_noabort'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch]
  266 | void __asan_report_load2_noabort(unsigned long addr);
      |      ^~~~~~~~~~~~~~~~~~~~~~~~~~~
lib/../mm/kasan/kasan.h:267:6: warning: conflicting types for built-in function '__asan_report_store2_noabort'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch]
  267 | void __asan_report_store2_noabort(unsigned long addr);
      |      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
lib/../mm/kasan/kasan.h:268:6: warning: conflicting types for built-in function '__asan_report_load4_noabort'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch]
  268 | void __asan_report_load4_noabort(unsigned long addr);
      |      ^~~~~~~~~~~~~~~~~~~~~~~~~~~
lib/../mm/kasan/kasan.h:269:6: warning: conflicting types for built-in function '__asan_report_store4_noabort'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch]
  269 | void __asan_report_store4_noabort(unsigned long addr);
      |      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
lib/../mm/kasan/kasan.h:270:6: warning: conflicting types for built-in function '__asan_report_load8_noabort'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch]
  270 | void __asan_report_load8_noabort(unsigned long addr);
      |      ^~~~~~~~~~~~~~~~~~~~~~~~~~~
lib/../mm/kasan/kasan.h:271:6: warning: conflicting types for built-in function '__asan_report_store8_noabort'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch]
  271 | void __asan_report_store8_noabort(unsigned long addr);
      |      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
lib/../mm/kasan/kasan.h:272:6: warning: conflicting types for built-in function '__asan_report_load16_noabort'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch]
  272 | void __asan_report_load16_noabort(unsigned long addr);
      |      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
lib/../mm/kasan/kasan.h:273:6: warning: conflicting types for built-in function '__asan_report_store16_noabort'; expected 'void(void *)' [-Wbuiltin-declaration-mismatch]
  273 | void __asan_report_store16_noabort(unsigned long addr);
      |      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
lib/../mm/kasan/kasan.h:274:6: warning: conflicting types for built-in function '__asan_report_load_n_noabort'; expected 'void(void *, long int)' [-Wbuiltin-declaration-mismatch]
  274 | void __asan_report_load_n_noabort(unsigned long addr, size_t size);
      |      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
lib/../mm/kasan/kasan.h:275:6: warning: conflicting types for built-in function '__asan_report_store_n_noabort'; expected 'void(void *, long int)' [-Wbuiltin-declaration-mismatch]
  275 | void __asan_report_store_n_noabort(unsigned long addr, size_t size);
      |      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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(&chip->base);
      |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~

Introduced by commit

  77e7d1c8c356 ("KASAN: Port KASAN Tests to KUnit")

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
@ 2020-09-14  6:57 Stephen Rothwell
  0 siblings, 0 replies; 145+ messages in thread
From: Stephen Rothwell @ 2020-09-14  6:57 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Oscar Salvador, Linux Next Mailing List, Linux Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 428 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2020-07-17 10:31 Stephen Rothwell
@ 2020-07-17 17:47 ` Roman Gushchin
  0 siblings, 0 replies; 145+ messages in thread
From: Roman Gushchin @ 2020-07-17 17:47 UTC (permalink / raw)
  To: Stephen Rothwell, Andrew Morton
  Cc: Andrew Morton, Linux Next Mailing List, Linux Kernel Mailing List

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


^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
@ 2020-07-17 10:31 Stephen Rothwell
  2020-07-17 17:47 ` Roman Gushchin
  0 siblings, 1 reply; 145+ messages in thread
From: Stephen Rothwell @ 2020-07-17 10:31 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Roman Gushchin

[-- Attachment #1: Type: text/plain, Size: 931 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
@ 2020-07-09  9:11 Stephen Rothwell
  0 siblings, 0 replies; 145+ messages in thread
From: Stephen Rothwell @ 2020-07-09  9:11 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Barry Song

[-- Attachment #1: Type: text/plain, Size: 444 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
@ 2020-06-21 14:40 Stephen Rothwell
  0 siblings, 0 replies; 145+ messages in thread
From: Stephen Rothwell @ 2020-06-21 14:40 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Rikard Falkeborn, Andy Shevchenko

[-- Attachment #1: Type: text/plain, Size: 303 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2020-04-01 23:00   ` Jason Gunthorpe
@ 2020-04-01 23:06     ` Mike Kravetz
  0 siblings, 0 replies; 145+ messages in thread
From: Mike Kravetz @ 2020-04-01 23:06 UTC (permalink / raw)
  To: Jason Gunthorpe, Andrew Morton
  Cc: Stephen Rothwell, Linux Next Mailing List,
	Linux Kernel Mailing List, Longpeng, Matthew Wilcox,
	Sean Christopherson

On 4/1/20 4:00 PM, Jason Gunthorpe wrote:
> On Wed, Apr 01, 2020 at 03:58:31PM -0700, Andrew Morton wrote:
>> On Tue, 31 Mar 2020 19:56:12 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>>> Hi all,
>>>
>>> After merging the akpm-current tree, today's linux-next build (i386
>>> defconfig) produced this warning:
>>>
>>> mm/hugetlb.c: In function 'huge_pte_offset':
>>> cc1: warning: function may return address of local variable [-Wreturn-local-addr]
>>> mm/hugetlb.c:5361:14: note: declared here
>>>  5361 |  pud_t *pud, pud_entry;
>>>       |              ^~~~~~~~~
>>> cc1: warning: function may return address of local variable [-Wreturn-local-addr]
>>> mm/hugetlb.c:5360:14: note: declared here
>>>  5360 |  p4d_t *p4d, p4d_entry;
>>>       |              ^~~~~~~~~
>>>
>>> Introduced by commit
>>>
>>>   826ddc88e2cf ("mm/hugetlb: fix a addressing exception caused by huge_pte_offset")
>>
>> I can reproduce this (i386 defconfig, gcc-7.2.0).
>>
>> I can see no way in which this makes any sense.  Hopefully it's a gcc
>> bug but it's hard to see how it could have messed up this fairly simple
>> code.
> 
> It is a code bug, there was a little thread about this. It happens
> because the address of a stack variable is passed into the pXX_offset
> functions which return that address when the page levels are folded.
> 
> I recommend to drop this patch until it is adjusted..

Yes, this patch causes at least the BUG here,

https://lore.kernel.org/linux-mm/CA+G9fYsJgZhhWLMzUxu_ZQ+THdCcJmFbHQ2ETA_YPP8M6yxOYA@mail.gmail.com/

-- 
Mike Kravetz

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2020-04-01 22:58 ` Andrew Morton
@ 2020-04-01 23:00   ` Jason Gunthorpe
  2020-04-01 23:06     ` Mike Kravetz
  0 siblings, 1 reply; 145+ messages in thread
From: Jason Gunthorpe @ 2020-04-01 23:00 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Stephen Rothwell, Linux Next Mailing List,
	Linux Kernel Mailing List, Longpeng, Mike Kravetz,
	Matthew Wilcox, Sean Christopherson

On Wed, Apr 01, 2020 at 03:58:31PM -0700, Andrew Morton wrote:
> On Tue, 31 Mar 2020 19:56:12 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > Hi all,
> > 
> > After merging the akpm-current tree, today's linux-next build (i386
> > defconfig) produced this warning:
> > 
> > mm/hugetlb.c: In function 'huge_pte_offset':
> > cc1: warning: function may return address of local variable [-Wreturn-local-addr]
> > mm/hugetlb.c:5361:14: note: declared here
> >  5361 |  pud_t *pud, pud_entry;
> >       |              ^~~~~~~~~
> > cc1: warning: function may return address of local variable [-Wreturn-local-addr]
> > mm/hugetlb.c:5360:14: note: declared here
> >  5360 |  p4d_t *p4d, p4d_entry;
> >       |              ^~~~~~~~~
> > 
> > Introduced by commit
> > 
> >   826ddc88e2cf ("mm/hugetlb: fix a addressing exception caused by huge_pte_offset")
> 
> I can reproduce this (i386 defconfig, gcc-7.2.0).
> 
> I can see no way in which this makes any sense.  Hopefully it's a gcc
> bug but it's hard to see how it could have messed up this fairly simple
> code.

It is a code bug, there was a little thread about this. It happens
because the address of a stack variable is passed into the pXX_offset
functions which return that address when the page levels are folded.

I recommend to drop this patch until it is adjusted..

Jason

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2020-03-31  8:56 Stephen Rothwell
@ 2020-04-01 22:58 ` Andrew Morton
  2020-04-01 23:00   ` Jason Gunthorpe
  0 siblings, 1 reply; 145+ messages in thread
From: Andrew Morton @ 2020-04-01 22:58 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Longpeng,
	Jason Gunthorpe, Mike Kravetz, Jason Gunthorpe, Matthew Wilcox,
	Sean Christopherson

On Tue, 31 Mar 2020 19:56:12 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> After merging the akpm-current tree, today's linux-next build (i386
> defconfig) produced this warning:
> 
> mm/hugetlb.c: In function 'huge_pte_offset':
> cc1: warning: function may return address of local variable [-Wreturn-local-addr]
> mm/hugetlb.c:5361:14: note: declared here
>  5361 |  pud_t *pud, pud_entry;
>       |              ^~~~~~~~~
> cc1: warning: function may return address of local variable [-Wreturn-local-addr]
> mm/hugetlb.c:5360:14: note: declared here
>  5360 |  p4d_t *p4d, p4d_entry;
>       |              ^~~~~~~~~
> 
> Introduced by commit
> 
>   826ddc88e2cf ("mm/hugetlb: fix a addressing exception caused by huge_pte_offset")

I can reproduce this (i386 defconfig, gcc-7.2.0).

I can see no way in which this makes any sense.  Hopefully it's a gcc
bug but it's hard to see how it could have messed up this fairly simple
code.

^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
@ 2020-03-31  8:56 Stephen Rothwell
  2020-04-01 22:58 ` Andrew Morton
  0 siblings, 1 reply; 145+ messages in thread
From: Stephen Rothwell @ 2020-03-31  8:56 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Longpeng

[-- Attachment #1: Type: text/plain, Size: 690 bytes --]

Hi all,

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

mm/hugetlb.c: In function 'huge_pte_offset':
cc1: warning: function may return address of local variable [-Wreturn-local-addr]
mm/hugetlb.c:5361:14: note: declared here
 5361 |  pud_t *pud, pud_entry;
      |              ^~~~~~~~~
cc1: warning: function may return address of local variable [-Wreturn-local-addr]
mm/hugetlb.c:5360:14: note: declared here
 5360 |  p4d_t *p4d, p4d_entry;
      |              ^~~~~~~~~

Introduced by commit

  826ddc88e2cf ("mm/hugetlb: fix a addressing exception caused by huge_pte_offset")

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2020-03-16  6:13   ` Stephen Rothwell
  2020-03-16  6:51     ` Baoquan He
@ 2020-03-16  6:54     ` Stephen Rothwell
  1 sibling, 0 replies; 145+ messages in thread
From: Stephen Rothwell @ 2020-03-16  6:54 UTC (permalink / raw)
  To: Baoquan He
  Cc: Andrew Morton, Linux Next Mailing List, Linux Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 837 bytes --]

Hi all,

On Mon, 16 Mar 2020 17:13:26 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi Baoquan,
> 
> On Mon, 16 Mar 2020 12:58:04 +0800 Baoquan He <bhe@redhat.com> wrote:
> >
> > I made a patch to fix these warnings, the reason has been told in the
> > log. Or just drop below patch. Both is fine to me.
> > 
> > mm-sparsec-move-subsection_map-related-functions-together.patch
> > 
> > From 273196eeb7bbc4af93bef18f594af91541e3ce8a Mon Sep 17 00:00:00 2001
> > From: Baoquan He <bhe@redhat.com>
> > Date: Sat, 14 Mar 2020 17:01:01 +0800
> > Subject: [PATCH] mm/sparse.c: move functions into CONFIG_MEMORY_HOTPLUG
> >  ifdeffery scope  
> 
> I have applied this to linux-next today to see how it goes.

Tested-by: Stephen Rothwell <sfr@canb.auug.org.au> # compile tested

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2020-03-16  6:13   ` Stephen Rothwell
@ 2020-03-16  6:51     ` Baoquan He
  2020-03-16  6:54     ` Stephen Rothwell
  1 sibling, 0 replies; 145+ messages in thread
From: Baoquan He @ 2020-03-16  6:51 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Linux Next Mailing List, Linux Kernel Mailing List

On 03/16/20 at 05:13pm, Stephen Rothwell wrote:
> Hi Baoquan,
> 
> On Mon, 16 Mar 2020 12:58:04 +0800 Baoquan He <bhe@redhat.com> wrote:
> >
> > I made a patch to fix these warnings, the reason has been told in the
> > log. Or just drop below patch. Both is fine to me.
> > 
> > mm-sparsec-move-subsection_map-related-functions-together.patch
> > 
> > From 273196eeb7bbc4af93bef18f594af91541e3ce8a Mon Sep 17 00:00:00 2001
> > From: Baoquan He <bhe@redhat.com>
> > Date: Sat, 14 Mar 2020 17:01:01 +0800
> > Subject: [PATCH] mm/sparse.c: move functions into CONFIG_MEMORY_HOTPLUG
> >  ifdeffery scope
> 
> I have applied this to linux-next today to see how it goes.

Thanks.


^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2020-03-16  4:58 ` Baoquan He
@ 2020-03-16  6:13   ` Stephen Rothwell
  2020-03-16  6:51     ` Baoquan He
  2020-03-16  6:54     ` Stephen Rothwell
  0 siblings, 2 replies; 145+ messages in thread
From: Stephen Rothwell @ 2020-03-16  6:13 UTC (permalink / raw)
  To: Baoquan He
  Cc: Andrew Morton, Linux Next Mailing List, Linux Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 635 bytes --]

Hi Baoquan,

On Mon, 16 Mar 2020 12:58:04 +0800 Baoquan He <bhe@redhat.com> wrote:
>
> I made a patch to fix these warnings, the reason has been told in the
> log. Or just drop below patch. Both is fine to me.
> 
> mm-sparsec-move-subsection_map-related-functions-together.patch
> 
> From 273196eeb7bbc4af93bef18f594af91541e3ce8a Mon Sep 17 00:00:00 2001
> From: Baoquan He <bhe@redhat.com>
> Date: Sat, 14 Mar 2020 17:01:01 +0800
> Subject: [PATCH] mm/sparse.c: move functions into CONFIG_MEMORY_HOTPLUG
>  ifdeffery scope

I have applied this to linux-next today to see how it goes.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2020-03-13 10:42 Stephen Rothwell
  2020-03-13 10:55 ` Baoquan He
  2020-03-13 12:56 ` Baoquan He
@ 2020-03-16  4:58 ` Baoquan He
  2020-03-16  6:13   ` Stephen Rothwell
  2 siblings, 1 reply; 145+ messages in thread
From: Baoquan He @ 2020-03-16  4:58 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Linux Next Mailing List, Linux Kernel Mailing List

On 03/13/20 at 09:42pm, Stephen Rothwell wrote:
> After merging the akpm-current tree, today's linux-next build (x86_64
> allnoconfig) produced this warning:
> 
> mm/sparse.c:311:12: warning: 'fill_subsection_map' defined but not used [-Wunused-function]
>   311 | static int fill_subsection_map(unsigned long pfn, unsigned long nr_pages)
>       |            ^~~~~~~~~~~~~~~~~~~
> mm/sparse.c:306:13: warning: 'is_subsection_map_empty' defined but not used [-Wunused-function]
>   306 | static bool is_subsection_map_empty(struct mem_section *ms)
>       |             ^~~~~~~~~~~~~~~~~~~~~~~
> mm/sparse.c:301:12: warning: 'clear_subsection_map' defined but not used [-Wunused-function]
>   301 | static int clear_subsection_map(unsigned long pfn, unsigned long nr_pages)
>       |            ^~~~~~~~~~~~~~~~~~~~

Hi Stephen, Andrew,

I made a patch to fix these warnings, the reason has been told in the
log. Or just drop below patch. Both is fine to me.

mm-sparsec-move-subsection_map-related-functions-together.patch

From 273196eeb7bbc4af93bef18f594af91541e3ce8a Mon Sep 17 00:00:00 2001
From: Baoquan He <bhe@redhat.com>
Date: Sat, 14 Mar 2020 17:01:01 +0800
Subject: [PATCH] mm/sparse.c: move functions into CONFIG_MEMORY_HOTPLUG
 ifdeffery scope

Stephen reported warnings are seen with allnoconfig on x86_64:

mm/sparse.c:311:12: warning: 'fill_subsection_map' defined but not used [-Wunused-function]
  311 | static int fill_subsection_map(unsigned long pfn, unsigned long nr_pages)
      |            ^~~~~~~~~~~~~~~~~~~
mm/sparse.c:306:13: warning: 'is_subsection_map_empty' defined but not used [-Wunused-function]
  306 | static bool is_subsection_map_empty(struct mem_section *ms)
      |             ^~~~~~~~~~~~~~~~~~~~~~~
mm/sparse.c:301:12: warning: 'clear_subsection_map' defined but not used [-Wunused-function]
  301 | static int clear_subsection_map(unsigned long pfn, unsigned long nr_pages)
      |            ^~~~~~~~~~~~~~~~~~~~

This is because allnoconfig on x86_64 sets  CONFIG_SPARSEMEM=y and
CONFIG_MEMORY_HOTPLUG=n. Functions clear_subsection_map(),
is_subsection_map_empty() and fill_subsection_map() are all defined
outside CONFIG_MEMORY_HOTPLUG ifdeffery scope. However, their callers,
section_activate() and section_deactivate() are inside CONFIG_MEMORY_HOTPLUG
ifdeffery scope.

So let's move them into the CONFIG_MEMORY_HOTPLUG iddeffery scope which
includes their callers.

Signed-off-by: Baoquan He <bhe@redhat.com>
---
 mm/sparse.c | 128 ++++++++++++++++++++++++++--------------------------
 1 file changed, 64 insertions(+), 64 deletions(-)

diff --git a/mm/sparse.c b/mm/sparse.c
index bb99633575b5..9b845621b854 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -244,74 +244,10 @@ void __init subsection_map_init(unsigned long pfn, unsigned long nr_pages)
 		nr_pages -= pfns;
 	}
 }
-
-static int clear_subsection_map(unsigned long pfn, unsigned long nr_pages)
-{
-	DECLARE_BITMAP(map, SUBSECTIONS_PER_SECTION) = { 0 };
-	DECLARE_BITMAP(tmp, SUBSECTIONS_PER_SECTION) = { 0 };
-	struct mem_section *ms = __pfn_to_section(pfn);
-	unsigned long *subsection_map = ms->usage
-		? &ms->usage->subsection_map[0] : NULL;
-
-	subsection_mask_set(map, pfn, nr_pages);
-	if (subsection_map)
-		bitmap_and(tmp, map, subsection_map, SUBSECTIONS_PER_SECTION);
-
-	if (WARN(!subsection_map || !bitmap_equal(tmp, map, SUBSECTIONS_PER_SECTION),
-				"section already deactivated (%#lx + %ld)\n",
-				pfn, nr_pages))
-		return -EINVAL;
-
-	bitmap_xor(subsection_map, map, subsection_map, SUBSECTIONS_PER_SECTION);
-	return 0;
-}
-
-static bool is_subsection_map_empty(struct mem_section *ms)
-{
-	return bitmap_empty(&ms->usage->subsection_map[0],
-			    SUBSECTIONS_PER_SECTION);
-}
-
-static int fill_subsection_map(unsigned long pfn, unsigned long nr_pages)
-{
-	struct mem_section *ms = __pfn_to_section(pfn);
-	DECLARE_BITMAP(map, SUBSECTIONS_PER_SECTION) = { 0 };
-	unsigned long *subsection_map;
-	int rc = 0;
-
-	subsection_mask_set(map, pfn, nr_pages);
-
-	subsection_map = &ms->usage->subsection_map[0];
-
-	if (bitmap_empty(map, SUBSECTIONS_PER_SECTION))
-		rc = -EINVAL;
-	else if (bitmap_intersects(map, subsection_map, SUBSECTIONS_PER_SECTION))
-		rc = -EEXIST;
-	else
-		bitmap_or(subsection_map, map, subsection_map,
-				SUBSECTIONS_PER_SECTION);
-
-	return rc;
-}
 #else
 void __init subsection_map_init(unsigned long pfn, unsigned long nr_pages)
 {
 }
-
-static int clear_subsection_map(unsigned long pfn, unsigned long nr_pages)
-{
-	return 0;
-}
-
-static bool is_subsection_map_empty(struct mem_section *ms)
-{
-	return true;
-}
-
-static int fill_subsection_map(unsigned long pfn, unsigned long nr_pages)
-{
-	return 0;
-}
 #endif
 
 /* Record a memory area against a node. */
@@ -730,6 +666,55 @@ static void free_map_bootmem(struct page *memmap)
 
 	vmemmap_free(start, end, NULL);
 }
+
+static int clear_subsection_map(unsigned long pfn, unsigned long nr_pages)
+{
+	DECLARE_BITMAP(map, SUBSECTIONS_PER_SECTION) = { 0 };
+	DECLARE_BITMAP(tmp, SUBSECTIONS_PER_SECTION) = { 0 };
+	struct mem_section *ms = __pfn_to_section(pfn);
+	unsigned long *subsection_map = ms->usage
+		? &ms->usage->subsection_map[0] : NULL;
+
+	subsection_mask_set(map, pfn, nr_pages);
+	if (subsection_map)
+		bitmap_and(tmp, map, subsection_map, SUBSECTIONS_PER_SECTION);
+
+	if (WARN(!subsection_map || !bitmap_equal(tmp, map, SUBSECTIONS_PER_SECTION),
+				"section already deactivated (%#lx + %ld)\n",
+				pfn, nr_pages))
+		return -EINVAL;
+
+	bitmap_xor(subsection_map, map, subsection_map, SUBSECTIONS_PER_SECTION);
+	return 0;
+}
+
+static bool is_subsection_map_empty(struct mem_section *ms)
+{
+	return bitmap_empty(&ms->usage->subsection_map[0],
+			    SUBSECTIONS_PER_SECTION);
+}
+
+static int fill_subsection_map(unsigned long pfn, unsigned long nr_pages)
+{
+	struct mem_section *ms = __pfn_to_section(pfn);
+	DECLARE_BITMAP(map, SUBSECTIONS_PER_SECTION) = { 0 };
+	unsigned long *subsection_map;
+	int rc = 0;
+
+	subsection_mask_set(map, pfn, nr_pages);
+
+	subsection_map = &ms->usage->subsection_map[0];
+
+	if (bitmap_empty(map, SUBSECTIONS_PER_SECTION))
+		rc = -EINVAL;
+	else if (bitmap_intersects(map, subsection_map, SUBSECTIONS_PER_SECTION))
+		rc = -EEXIST;
+	else
+		bitmap_or(subsection_map, map, subsection_map,
+				SUBSECTIONS_PER_SECTION);
+
+	return rc;
+}
 #else
 struct page * __meminit populate_section_memmap(unsigned long pfn,
 		unsigned long nr_pages, int nid, struct vmem_altmap *altmap)
@@ -773,6 +758,21 @@ static void free_map_bootmem(struct page *memmap)
 			put_page_bootmem(page);
 	}
 }
+
+static int clear_subsection_map(unsigned long pfn, unsigned long nr_pages)
+{
+	return 0;
+}
+
+static bool is_subsection_map_empty(struct mem_section *ms)
+{
+	return true;
+}
+
+static int fill_subsection_map(unsigned long pfn, unsigned long nr_pages)
+{
+	return 0;
+}
 #endif /* CONFIG_SPARSEMEM_VMEMMAP */
 
 /*
-- 
2.17.2


^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2020-03-14  0:09   ` Stephen Rothwell
@ 2020-03-14  0:35     ` Baoquan He
  0 siblings, 0 replies; 145+ messages in thread
From: Baoquan He @ 2020-03-14  0:35 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Linux Next Mailing List, Linux Kernel Mailing List

On 03/14/20 at 11:09am, Stephen Rothwell wrote:
> Hi Baoquan,
> 
> On Fri, 13 Mar 2020 20:56:27 +0800 Baoquan He <bhe@redhat.com> wrote:
> >
> > I made below change, but I can't triger these warnings. Could you try
> > below patch, see if it's works?
> 
> I needed to add "ARCH=x86_64" to the "make allnoconfig" command line
> (and the subsequent "make") otherwise I get a 32 bit build.

Ok, I now see the warnings with 'allnoconfig ARCH=x86_64', thanks.

> 
> > From 9be668f1e30b6bb4ed5f4a07e7d3bb76d3f58f35 Mon Sep 17 00:00:00 2001
> > From: Baoquan He <bhe@redhat.com>
> > Date: Fri, 13 Mar 2020 20:25:54 +0800
> > Subject: [PATCH] mm/sparse.c: fix the building warning with !SPARSEMEM
> > 
> > Stephen reported below warnings are seen with allnoconfig on x86_64.
> > Fix it by making those dummy functions sub-section map handling visible
> > with CONFIG_SPARSEMEM enabled.
> > 
> > mm/sparse.c:311:12: warning: 'fill_subsection_map' defined but not used [-Wunused-function]
> >   311 | static int fill_subsection_map(unsigned long pfn, unsigned long nr_pages)
> >       |            ^~~~~~~~~~~~~~~~~~~
> > mm/sparse.c:306:13: warning: 'is_subsection_map_empty' defined but not used [-Wunused-function]
> >   306 | static bool is_subsection_map_empty(struct mem_section *ms)
> >       |             ^~~~~~~~~~~~~~~~~~~~~~~
> > mm/sparse.c:301:12: warning: 'clear_subsection_map' defined but not used [-Wunused-function]
> >   301 | static int clear_subsection_map(unsigned long pfn, unsigned long nr_pages)
> >       |            ^~~~~~~~~~~~~~~~~~~~
> > 
> > Signed-off-by: Baoquan He <bhe@redhat.com>
> > ---
> >  mm/sparse.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/mm/sparse.c b/mm/sparse.c
> > index 362018e82e22..9e08d118719f 100644
> > --- a/mm/sparse.c
> > +++ b/mm/sparse.c
> > @@ -293,7 +293,7 @@ static int fill_subsection_map(unsigned long pfn, unsigned long nr_pages)
> >  
> >  	return rc;
> >  }
> > -#else
> > +#elif defined(CONFIG_SPARSEMEM)
> >  void __init subsection_map_init(unsigned long pfn, unsigned long nr_pages)
> >  {
> >  }
> 
> This didn't make any difference as CONFIG_SPARSEMEM is set for the
> x86_64 allnoconfig build.

You are right, CONFIG_SPARSEMEM is set for x86_64. I will work out a
patch after testing. Thanks for these details.


^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2020-03-13 12:56 ` Baoquan He
@ 2020-03-14  0:09   ` Stephen Rothwell
  2020-03-14  0:35     ` Baoquan He
  0 siblings, 1 reply; 145+ messages in thread
From: Stephen Rothwell @ 2020-03-14  0:09 UTC (permalink / raw)
  To: Baoquan He
  Cc: Andrew Morton, Linux Next Mailing List, Linux Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 2064 bytes --]

Hi Baoquan,

On Fri, 13 Mar 2020 20:56:27 +0800 Baoquan He <bhe@redhat.com> wrote:
>
> I made below change, but I can't triger these warnings. Could you try
> below patch, see if it's works?

I needed to add "ARCH=x86_64" to the "make allnoconfig" command line
(and the subsequent "make") otherwise I get a 32 bit build.

> From 9be668f1e30b6bb4ed5f4a07e7d3bb76d3f58f35 Mon Sep 17 00:00:00 2001
> From: Baoquan He <bhe@redhat.com>
> Date: Fri, 13 Mar 2020 20:25:54 +0800
> Subject: [PATCH] mm/sparse.c: fix the building warning with !SPARSEMEM
> 
> Stephen reported below warnings are seen with allnoconfig on x86_64.
> Fix it by making those dummy functions sub-section map handling visible
> with CONFIG_SPARSEMEM enabled.
> 
> mm/sparse.c:311:12: warning: 'fill_subsection_map' defined but not used [-Wunused-function]
>   311 | static int fill_subsection_map(unsigned long pfn, unsigned long nr_pages)
>       |            ^~~~~~~~~~~~~~~~~~~
> mm/sparse.c:306:13: warning: 'is_subsection_map_empty' defined but not used [-Wunused-function]
>   306 | static bool is_subsection_map_empty(struct mem_section *ms)
>       |             ^~~~~~~~~~~~~~~~~~~~~~~
> mm/sparse.c:301:12: warning: 'clear_subsection_map' defined but not used [-Wunused-function]
>   301 | static int clear_subsection_map(unsigned long pfn, unsigned long nr_pages)
>       |            ^~~~~~~~~~~~~~~~~~~~
> 
> Signed-off-by: Baoquan He <bhe@redhat.com>
> ---
>  mm/sparse.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/sparse.c b/mm/sparse.c
> index 362018e82e22..9e08d118719f 100644
> --- a/mm/sparse.c
> +++ b/mm/sparse.c
> @@ -293,7 +293,7 @@ static int fill_subsection_map(unsigned long pfn, unsigned long nr_pages)
>  
>  	return rc;
>  }
> -#else
> +#elif defined(CONFIG_SPARSEMEM)
>  void __init subsection_map_init(unsigned long pfn, unsigned long nr_pages)
>  {
>  }

This didn't make any difference as CONFIG_SPARSEMEM is set for the
x86_64 allnoconfig build.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2020-03-13 10:42 Stephen Rothwell
  2020-03-13 10:55 ` Baoquan He
@ 2020-03-13 12:56 ` Baoquan He
  2020-03-14  0:09   ` Stephen Rothwell
  2020-03-16  4:58 ` Baoquan He
  2 siblings, 1 reply; 145+ messages in thread
From: Baoquan He @ 2020-03-13 12:56 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Linux Next Mailing List, Linux Kernel Mailing List

On 03/13/20 at 09:42pm, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the akpm-current tree, today's linux-next build (x86_64
> allnoconfig) produced this warning:
> 
> mm/sparse.c:311:12: warning: 'fill_subsection_map' defined but not used [-Wunused-function]
>   311 | static int fill_subsection_map(unsigned long pfn, unsigned long nr_pages)
>       |            ^~~~~~~~~~~~~~~~~~~
> mm/sparse.c:306:13: warning: 'is_subsection_map_empty' defined but not used [-Wunused-function]
>   306 | static bool is_subsection_map_empty(struct mem_section *ms)
>       |             ^~~~~~~~~~~~~~~~~~~~~~~
> mm/sparse.c:301:12: warning: 'clear_subsection_map' defined but not used [-Wunused-function]
>   301 | static int clear_subsection_map(unsigned long pfn, unsigned long nr_pages)
>       |            ^~~~~~~~~~~~~~~~~~~~
> 
> Introduced by commits
> 
>   38eb09ac7c29 ("mm/sparse.c: introduce new function fill_subsection_map()")
>   334411156ba6 ("mm/sparse.c: introduce a new function clear_subsection_map()")

Hi Stephen,

I made below change, but I can't triger these warnings. Could you try
below patch, see if it's works?


From 9be668f1e30b6bb4ed5f4a07e7d3bb76d3f58f35 Mon Sep 17 00:00:00 2001
From: Baoquan He <bhe@redhat.com>
Date: Fri, 13 Mar 2020 20:25:54 +0800
Subject: [PATCH] mm/sparse.c: fix the building warning with !SPARSEMEM

Stephen reported below warnings are seen with allnoconfig on x86_64.
Fix it by making those dummy functions sub-section map handling visible
with CONFIG_SPARSEMEM enabled.

mm/sparse.c:311:12: warning: 'fill_subsection_map' defined but not used [-Wunused-function]
  311 | static int fill_subsection_map(unsigned long pfn, unsigned long nr_pages)
      |            ^~~~~~~~~~~~~~~~~~~
mm/sparse.c:306:13: warning: 'is_subsection_map_empty' defined but not used [-Wunused-function]
  306 | static bool is_subsection_map_empty(struct mem_section *ms)
      |             ^~~~~~~~~~~~~~~~~~~~~~~
mm/sparse.c:301:12: warning: 'clear_subsection_map' defined but not used [-Wunused-function]
  301 | static int clear_subsection_map(unsigned long pfn, unsigned long nr_pages)
      |            ^~~~~~~~~~~~~~~~~~~~

Signed-off-by: Baoquan He <bhe@redhat.com>
---
 mm/sparse.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/sparse.c b/mm/sparse.c
index 362018e82e22..9e08d118719f 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -293,7 +293,7 @@ static int fill_subsection_map(unsigned long pfn, unsigned long nr_pages)
 
 	return rc;
 }
-#else
+#elif defined(CONFIG_SPARSEMEM)
 void __init subsection_map_init(unsigned long pfn, unsigned long nr_pages)
 {
 }
-- 
2.17.2


^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2020-03-13 10:42 Stephen Rothwell
@ 2020-03-13 10:55 ` Baoquan He
  2020-03-13 12:56 ` Baoquan He
  2020-03-16  4:58 ` Baoquan He
  2 siblings, 0 replies; 145+ messages in thread
From: Baoquan He @ 2020-03-13 10:55 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Linux Next Mailing List, Linux Kernel Mailing List

On 03/13/20 at 09:42pm, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the akpm-current tree, today's linux-next build (x86_64
> allnoconfig) produced this warning:

I tried with allnoconfig on x86_64, make doesn't trigger below warnings.

Hi Andrew,

Should we fix this kind of warning? If have to, I'll try to make several 
macro functions like subsection_map_init does for !CONFIG_SPARSEMEM.

> 
> mm/sparse.c:311:12: warning: 'fill_subsection_map' defined but not used [-Wunused-function]
>   311 | static int fill_subsection_map(unsigned long pfn, unsigned long nr_pages)
>       |            ^~~~~~~~~~~~~~~~~~~
> mm/sparse.c:306:13: warning: 'is_subsection_map_empty' defined but not used [-Wunused-function]
>   306 | static bool is_subsection_map_empty(struct mem_section *ms)
>       |             ^~~~~~~~~~~~~~~~~~~~~~~
> mm/sparse.c:301:12: warning: 'clear_subsection_map' defined but not used [-Wunused-function]
>   301 | static int clear_subsection_map(unsigned long pfn, unsigned long nr_pages)
>       |            ^~~~~~~~~~~~~~~~~~~~
> 
> Introduced by commits
> 
>   38eb09ac7c29 ("mm/sparse.c: introduce new function fill_subsection_map()")
>   334411156ba6 ("mm/sparse.c: introduce a new function clear_subsection_map()")
> 
> Or maybe laster patches.
> 
> -- 
> Cheers,
> Stephen Rothwell



^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
@ 2020-03-13 10:42 Stephen Rothwell
  2020-03-13 10:55 ` Baoquan He
                   ` (2 more replies)
  0 siblings, 3 replies; 145+ messages in thread
From: Stephen Rothwell @ 2020-03-13 10:42 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Baoquan He

[-- Attachment #1: Type: text/plain, Size: 1015 bytes --]

Hi all,

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

mm/sparse.c:311:12: warning: 'fill_subsection_map' defined but not used [-Wunused-function]
  311 | static int fill_subsection_map(unsigned long pfn, unsigned long nr_pages)
      |            ^~~~~~~~~~~~~~~~~~~
mm/sparse.c:306:13: warning: 'is_subsection_map_empty' defined but not used [-Wunused-function]
  306 | static bool is_subsection_map_empty(struct mem_section *ms)
      |             ^~~~~~~~~~~~~~~~~~~~~~~
mm/sparse.c:301:12: warning: 'clear_subsection_map' defined but not used [-Wunused-function]
  301 | static int clear_subsection_map(unsigned long pfn, unsigned long nr_pages)
      |            ^~~~~~~~~~~~~~~~~~~~

Introduced by commits

  38eb09ac7c29 ("mm/sparse.c: introduce new function fill_subsection_map()")
  334411156ba6 ("mm/sparse.c: introduce a new function clear_subsection_map()")

Or maybe laster patches.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2020-03-12  7:27 Stephen Rothwell
@ 2020-03-13  0:31 ` Andrew Morton
  0 siblings, 0 replies; 145+ messages in thread
From: Andrew Morton @ 2020-03-13  0:31 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Claudio Imbrenda

On Thu, 12 Mar 2020 18:27:25 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> After merging the akpm-current tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning:
> 
> mm/gup.c:119:13: warning: 'put_compound_head' defined but not used [-Wunused-function]
>   119 | static void put_compound_head(struct page *page, int refs, unsigned int flags)
>       |             ^~~~~~~~~~~~~~~~~
> 
> Introduced by commit
> 
>   6379e529ebe4 ("mm/gup: fixup for 9947ea2c1e608e32 "mm/gup: track FOLL_PIN pages"")
> 

Thanks.

I think this is right.  And I don't think it'll apply to most recent
-next.

--- a/mm/gup.c~mm-gup-track-foll_pin-pages-fix-2-fix
+++ a/mm/gup.c
@@ -78,21 +78,6 @@ static __maybe_unused struct page *try_g
 	return NULL;
 }
 
-static void put_compound_head(struct page *page, int refs, unsigned int flags)
-{
-	if (flags & FOLL_PIN)
-		refs *= GUP_PIN_COUNTING_BIAS;
-
-	VM_BUG_ON_PAGE(page_ref_count(page) < refs, page);
-	/*
-	 * Calling put_page() for each ref is unnecessarily slow. Only the last
-	 * ref needs a put_page().
-	 */
-	if (refs > 1)
-		page_ref_sub(page, refs - 1);
-	put_page(page);
-}
-
 /**
  * try_grab_page() - elevate a page's refcount by a flag-dependent amount
  *
@@ -1967,7 +1952,24 @@ EXPORT_SYMBOL(get_user_pages_unlocked);
  * This code is based heavily on the PowerPC implementation by Nick Piggin.
  */
 #ifdef CONFIG_HAVE_FAST_GUP
+
+static void put_compound_head(struct page *page, int refs, unsigned int flags)
+{
+	if (flags & FOLL_PIN)
+		refs *= GUP_PIN_COUNTING_BIAS;
+
+	VM_BUG_ON_PAGE(page_ref_count(page) < refs, page);
+	/*
+	 * Calling put_page() for each ref is unnecessarily slow. Only the last
+	 * ref needs a put_page().
+	 */
+	if (refs > 1)
+		page_ref_sub(page, refs - 1);
+	put_page(page);
+}
+
 #ifdef CONFIG_GUP_GET_PTE_LOW_HIGH
+
 /*
  * WARNING: only to be used in the get_user_pages_fast() implementation.
  *
_


^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2020-03-12  7:31 Stephen Rothwell
@ 2020-03-12 16:48 ` Mike Kravetz
  0 siblings, 0 replies; 145+ messages in thread
From: Mike Kravetz @ 2020-03-12 16:48 UTC (permalink / raw)
  To: Stephen Rothwell, Andrew Morton
  Cc: Linux Next Mailing List, Linux Kernel Mailing List

On 3/12/20 12:31 AM, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the akpm-current tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
> 
> fs/hugetlbfs/inode.c: In function 'remove_inode_hugepages':
> fs/hugetlbfs/inode.c:460:44: warning: 'hash' may be used uninitialized in this function [-Wmaybe-uninitialized]
>   460 |     mutex_unlock(&hugetlb_fault_mutex_table[hash]);
>       |                                            ^
> fs/hugetlbfs/inode.c:463:5: warning: 'index' may be used uninitialized in this function [-Wmaybe-uninitialized]
>   463 |     hugetlb_vmdelete_list(&mapping->i_mmap,
>       |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>   464 |      index * pages_per_huge_page(h),
>       |      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>   465 |      (index + 1) * pages_per_huge_page(h));
>       |      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> Introduced by commit
> 
>   6fdc8f8d1781 ("hugetlbfs: use i_mmap_rwsem to address page fault/truncate race")
> 

This is a false positive.  However, there are more serious issues with this
patch series as reported here:
https://lore.kernel.org/linux-mm/1584028670.7365.182.camel@lca.pw/

I'm working on the issue, but these may need to be reverted if I can not come
up with a solution quickly.  So, I am ignoring the false positive warning
until the more serious issue is resolved.
-- 
Mike Kravetz

^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
@ 2020-03-12  7:31 Stephen Rothwell
  2020-03-12 16:48 ` Mike Kravetz
  0 siblings, 1 reply; 145+ messages in thread
From: Stephen Rothwell @ 2020-03-12  7:31 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Mike Kravetz

[-- Attachment #1: Type: text/plain, Size: 975 bytes --]

Hi all,

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

fs/hugetlbfs/inode.c: In function 'remove_inode_hugepages':
fs/hugetlbfs/inode.c:460:44: warning: 'hash' may be used uninitialized in this function [-Wmaybe-uninitialized]
  460 |     mutex_unlock(&hugetlb_fault_mutex_table[hash]);
      |                                            ^
fs/hugetlbfs/inode.c:463:5: warning: 'index' may be used uninitialized in this function [-Wmaybe-uninitialized]
  463 |     hugetlb_vmdelete_list(&mapping->i_mmap,
      |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  464 |      index * pages_per_huge_page(h),
      |      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  465 |      (index + 1) * pages_per_huge_page(h));
      |      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Introduced by commit

  6fdc8f8d1781 ("hugetlbfs: use i_mmap_rwsem to address page fault/truncate race")

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
@ 2020-03-12  7:27 Stephen Rothwell
  2020-03-13  0:31 ` Andrew Morton
  0 siblings, 1 reply; 145+ messages in thread
From: Stephen Rothwell @ 2020-03-12  7:27 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Claudio Imbrenda

[-- Attachment #1: Type: text/plain, Size: 486 bytes --]

Hi all,

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

mm/gup.c:119:13: warning: 'put_compound_head' defined but not used [-Wunused-function]
  119 | static void put_compound_head(struct page *page, int refs, unsigned int flags)
      |             ^~~~~~~~~~~~~~~~~

Introduced by commit

  6379e529ebe4 ("mm/gup: fixup for 9947ea2c1e608e32 "mm/gup: track FOLL_PIN pages"")

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2020-03-05  5:54 ` Dmitry Vyukov
@ 2020-03-07  5:03   ` Walter Wu
  0 siblings, 0 replies; 145+ messages in thread
From: Walter Wu @ 2020-03-07  5:03 UTC (permalink / raw)
  To: Dmitry Vyukov
  Cc: Stephen Rothwell, Andrew Morton, Linux Next Mailing List,
	Linux Kernel Mailing List, Andrey Ryabinin, kasan-dev

On Thu, 2020-03-05 at 06:54 +0100, Dmitry Vyukov wrote:
> On Thu, Mar 5, 2020 at 6:37 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Hi all,
> >
> > After merging the akpm-current tree, today's linux-next build (x86_64
> > allmodconfig) produced this warning:
> >
> > mm/kasan/common.o: warning: objtool: kasan_report()+0x17: call to report_enabled() with UACCESS enabled
> > In file included from include/linux/bitmap.h:9,
> >                  from include/linux/cpumask.h:12,
> >                  from arch/x86/include/asm/paravirt.h:17,
> >                  from arch/x86/include/asm/irqflags.h:72,
> >                  from include/linux/irqflags.h:16,
> >                  from include/linux/rcupdate.h:26,
> >                  from include/linux/rculist.h:11,
> >                  from include/linux/pid.h:5,
> >                  from include/linux/sched.h:14,
> >                  from include/linux/uaccess.h:6,
> >                  from arch/x86/include/asm/fpu/xstate.h:5,
> >                  from arch/x86/include/asm/pgtable.h:26,
> >                  from include/linux/kasan.h:15,
> >                  from lib/test_kasan.c:12:
> > In function 'memmove',
> >     inlined from 'kmalloc_memmove_invalid_size' at lib/test_kasan.c:301:2:
> > include/linux/string.h:441:9: warning: '__builtin_memmove' specified bound 18446744073709551614 exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=]
> 
> +kasan-dev
> 
> We probably need to make this 18446744073709551614 constant "dynamic"
> so that compiler does not see it.
> 
> Walter, will you take a look? Thanks

Hi Dmitry,

Yes, I have fixed it. This warning need newer gcc enough to reproduce.
Maybe I should replace original gcc-7.4.0.

Thanks.


--- a/lib/test_kasan.c
+++ b/lib/test_kasan.c
@@ -286,17 +286,19 @@ static noinline void __init
kmalloc_oob_in_memset(void)
 static noinline void __init kmalloc_memmove_invalid_size(void)
 {
        char *ptr;
-       size_t size = 64;
+       size_t size1 = 64;
+       volatile size_t size2 = -2;

        pr_info("invalid size in memmove\n");
-       ptr = kmalloc(size, GFP_KERNEL);
+       ptr = kmalloc(size1, GFP_KERNEL);
        if (!ptr) {
                pr_err("Allocation failed\n");
                return;
        }

-       memset((char *)ptr, 0, 64);
-       memmove((char *)ptr, (char *)ptr + 4, -2);
+       memset((char *)ptr, 0, size1);
+       /* the size of memmove() is negative number */
+       memmove((char *)ptr, (char *)ptr + 4, size2);
        kfree(ptr);
 }

> 
> >   441 |  return __builtin_memmove(p, q, size);
> >       |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> > Introduced by commit
> >
> >   519e500fac64 ("kasan: add test for invalid size in memmove")
> >
> > That's a bit annoying during a normal x86_64 allmodconfig build ...
> >
> > --
> > Cheers,
> > Stephen Rothwell


^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2020-03-06 18:59     ` Walter Wu
@ 2020-03-06 20:45       ` Walter Wu
  0 siblings, 0 replies; 145+ messages in thread
From: Walter Wu @ 2020-03-06 20:45 UTC (permalink / raw)
  To: Stephen Rothwell, Dmitry Vyukov
  Cc: Andrew Morton, Linux Next Mailing List,
	Linux Kernel Mailing List, Andrey Ryabinin

On Sat, 2020-03-07 at 02:59 +0800, Walter Wu wrote:
> On Thu, 2020-03-05 at 20:33 +1100, Stephen Rothwell wrote:
> > Hi Walter,
> > 
> > On Thu, 5 Mar 2020 16:54:36 +0800 Walter Wu <walter-zh.wu@mediatek.com> wrote:
> > >
> > > I'm sorry for the build warning, it doesn't generate in our local
> > > environment(arm64/x86_64). Would you tell me what toolchains can
> > > reproduce it?
> > 
> > I am using a PowerPC LE hosted x86_64 gcc v9.2.1 (Debian cross compiler).
> > 
> > $ /usr/bin/x86_64-linux-gnu-gcc --version
> > x86_64-linux-gnu-gcc (Debian 9.2.1-21) 9.2.1 20191130
> > 
> Hi Stephen,
> 
> Thanks for your information, It doesn't generate warning message in
> gcc-8.3.0(Debian 8.3.0-6) after apply below patch.
> 
> 
> --- a/lib/test_kasan.c
> +++ b/lib/test_kasan.c
> @@ -286,17 +286,19 @@ static noinline void __init
> kmalloc_oob_in_memset(void)
>  static noinline void __init kmalloc_memmove_invalid_size(void)
>  {
>         char *ptr;
> -       size_t size = 64;
> +       size_t size1 = 64;
> +       size_t size2 = 62;
> 
>         pr_info("invalid size in memmove\n");
> -       ptr = kmalloc(size, GFP_KERNEL);
> +       ptr = kmalloc(size1, GFP_KERNEL);
>         if (!ptr) {
>                 pr_err("Allocation failed\n");
>                 return;
>         }
> 
> -       memset((char *)ptr, 0, 64);
> -       memmove((char *)ptr, (char *)ptr + 4, -2);
> +       memset((char *)ptr, 0, size1);
> +       /* the size of memmove() is negative numbers */
> +       memmove((char *)ptr, (char *)ptr + 4, size2 - size1);
>         kfree(ptr);
>  }
> 
Hi Stephen,

Please ignore previous mail, I miss the message. Below the patch will
fix the warning.


--- a/lib/test_kasan.c
+++ b/lib/test_kasan.c
@@ -286,17 +286,19 @@ static noinline void __init
kmalloc_oob_in_memset(void)
 static noinline void __init kmalloc_memmove_invalid_size(void)
 {
        char *ptr;
-       size_t size = 64;
+       size_t size1 = 64;
+       volatile size_t size2 = -2;

        pr_info("invalid size in memmove\n");
-       ptr = kmalloc(size, GFP_KERNEL);
+       ptr = kmalloc(size1, GFP_KERNEL);
        if (!ptr) {
                pr_err("Allocation failed\n");
                return;
        }

-       memset((char *)ptr, 0, 64);
-       memmove((char *)ptr, (char *)ptr + 4, -2);
+       memset((char *)ptr, 0, size1);
+       /* the size of memmove() is negative number */
+       memmove((char *)ptr, (char *)ptr + 4, size2);
        kfree(ptr);
 }

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2020-03-05  9:33   ` Stephen Rothwell
@ 2020-03-06 18:59     ` Walter Wu
  2020-03-06 20:45       ` Walter Wu
  0 siblings, 1 reply; 145+ messages in thread
From: Walter Wu @ 2020-03-06 18:59 UTC (permalink / raw)
  To: Stephen Rothwell, Dmitry Vyukov
  Cc: Andrew Morton, Linux Next Mailing List,
	Linux Kernel Mailing List, Andrey Ryabinin

On Thu, 2020-03-05 at 20:33 +1100, Stephen Rothwell wrote:
> Hi Walter,
> 
> On Thu, 5 Mar 2020 16:54:36 +0800 Walter Wu <walter-zh.wu@mediatek.com> wrote:
> >
> > I'm sorry for the build warning, it doesn't generate in our local
> > environment(arm64/x86_64). Would you tell me what toolchains can
> > reproduce it?
> 
> I am using a PowerPC LE hosted x86_64 gcc v9.2.1 (Debian cross compiler).
> 
> $ /usr/bin/x86_64-linux-gnu-gcc --version
> x86_64-linux-gnu-gcc (Debian 9.2.1-21) 9.2.1 20191130
> 
Hi Stephen,

Thanks for your information, It doesn't generate warning message in
gcc-8.3.0(Debian 8.3.0-6) after apply below patch.


--- a/lib/test_kasan.c
+++ b/lib/test_kasan.c
@@ -286,17 +286,19 @@ static noinline void __init
kmalloc_oob_in_memset(void)
 static noinline void __init kmalloc_memmove_invalid_size(void)
 {
        char *ptr;
-       size_t size = 64;
+       size_t size1 = 64;
+       size_t size2 = 62;

        pr_info("invalid size in memmove\n");
-       ptr = kmalloc(size, GFP_KERNEL);
+       ptr = kmalloc(size1, GFP_KERNEL);
        if (!ptr) {
                pr_err("Allocation failed\n");
                return;
        }

-       memset((char *)ptr, 0, 64);
-       memmove((char *)ptr, (char *)ptr + 4, -2);
+       memset((char *)ptr, 0, size1);
+       /* the size of memmove() is negative numbers */
+       memmove((char *)ptr, (char *)ptr + 4, size2 - size1);
        kfree(ptr);
 }


^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2020-03-05  8:54 ` Walter Wu
@ 2020-03-05  9:33   ` Stephen Rothwell
  2020-03-06 18:59     ` Walter Wu
  0 siblings, 1 reply; 145+ messages in thread
From: Stephen Rothwell @ 2020-03-05  9:33 UTC (permalink / raw)
  To: Walter Wu
  Cc: Dmitry Vyukov, Andrew Morton, Linux Next Mailing List,
	Linux Kernel Mailing List, Andrey Ryabinin

[-- Attachment #1: Type: text/plain, Size: 462 bytes --]

Hi Walter,

On Thu, 5 Mar 2020 16:54:36 +0800 Walter Wu <walter-zh.wu@mediatek.com> wrote:
>
> I'm sorry for the build warning, it doesn't generate in our local
> environment(arm64/x86_64). Would you tell me what toolchains can
> reproduce it?

I am using a PowerPC LE hosted x86_64 gcc v9.2.1 (Debian cross compiler).

$ /usr/bin/x86_64-linux-gnu-gcc --version
x86_64-linux-gnu-gcc (Debian 9.2.1-21) 9.2.1 20191130

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2020-03-05  5:37 Stephen Rothwell
  2020-03-05  5:54 ` Dmitry Vyukov
@ 2020-03-05  8:54 ` Walter Wu
  2020-03-05  9:33   ` Stephen Rothwell
  1 sibling, 1 reply; 145+ messages in thread
From: Walter Wu @ 2020-03-05  8:54 UTC (permalink / raw)
  To: Stephen Rothwell, Dmitry Vyukov
  Cc: Andrew Morton, Linux Next Mailing List,
	Linux Kernel Mailing List, Andrey Ryabinin

On Thu, 2020-03-05 at 16:37 +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the akpm-current tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
> 
> mm/kasan/common.o: warning: objtool: kasan_report()+0x17: call to report_enabled() with UACCESS enabled
> In file included from include/linux/bitmap.h:9,
>                  from include/linux/cpumask.h:12,
>                  from arch/x86/include/asm/paravirt.h:17,
>                  from arch/x86/include/asm/irqflags.h:72,
>                  from include/linux/irqflags.h:16,
>                  from include/linux/rcupdate.h:26,
>                  from include/linux/rculist.h:11,
>                  from include/linux/pid.h:5,
>                  from include/linux/sched.h:14,
>                  from include/linux/uaccess.h:6,
>                  from arch/x86/include/asm/fpu/xstate.h:5,
>                  from arch/x86/include/asm/pgtable.h:26,
>                  from include/linux/kasan.h:15,
>                  from lib/test_kasan.c:12:
> In function 'memmove',
>     inlined from 'kmalloc_memmove_invalid_size' at lib/test_kasan.c:301:2:
> include/linux/string.h:441:9: warning: '__builtin_memmove' specified bound 18446744073709551614 exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=]
>   441 |  return __builtin_memmove(p, q, size);
>       |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> Introduced by commit
> 
>   519e500fac64 ("kasan: add test for invalid size in memmove")
> 
> That's a bit annoying during a normal x86_64 allmodconfig build ...
> 

Hi Stephen and Dmitry,

I'm sorry for the build warning, it doesn't generate in our local
environment(arm64/x86_64). Would you tell me what toolchains can
reproduce it?

Dmitry, Thanks for your suggestion.


Thanks

Walter




^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2020-03-05  5:37 Stephen Rothwell
@ 2020-03-05  5:54 ` Dmitry Vyukov
  2020-03-07  5:03   ` Walter Wu
  2020-03-05  8:54 ` Walter Wu
  1 sibling, 1 reply; 145+ messages in thread
From: Dmitry Vyukov @ 2020-03-05  5:54 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Linux Next Mailing List,
	Linux Kernel Mailing List, Walter Wu, Andrey Ryabinin, kasan-dev

On Thu, Mar 5, 2020 at 6:37 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> After merging the akpm-current tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
>
> mm/kasan/common.o: warning: objtool: kasan_report()+0x17: call to report_enabled() with UACCESS enabled
> In file included from include/linux/bitmap.h:9,
>                  from include/linux/cpumask.h:12,
>                  from arch/x86/include/asm/paravirt.h:17,
>                  from arch/x86/include/asm/irqflags.h:72,
>                  from include/linux/irqflags.h:16,
>                  from include/linux/rcupdate.h:26,
>                  from include/linux/rculist.h:11,
>                  from include/linux/pid.h:5,
>                  from include/linux/sched.h:14,
>                  from include/linux/uaccess.h:6,
>                  from arch/x86/include/asm/fpu/xstate.h:5,
>                  from arch/x86/include/asm/pgtable.h:26,
>                  from include/linux/kasan.h:15,
>                  from lib/test_kasan.c:12:
> In function 'memmove',
>     inlined from 'kmalloc_memmove_invalid_size' at lib/test_kasan.c:301:2:
> include/linux/string.h:441:9: warning: '__builtin_memmove' specified bound 18446744073709551614 exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=]

+kasan-dev

We probably need to make this 18446744073709551614 constant "dynamic"
so that compiler does not see it.

Walter, will you take a look? Thanks

>   441 |  return __builtin_memmove(p, q, size);
>       |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Introduced by commit
>
>   519e500fac64 ("kasan: add test for invalid size in memmove")
>
> That's a bit annoying during a normal x86_64 allmodconfig build ...
>
> --
> Cheers,
> Stephen Rothwell

^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
@ 2020-03-05  5:37 Stephen Rothwell
  2020-03-05  5:54 ` Dmitry Vyukov
  2020-03-05  8:54 ` Walter Wu
  0 siblings, 2 replies; 145+ messages in thread
From: Stephen Rothwell @ 2020-03-05  5:37 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Walter Wu,
	Dmitry Vyukov, Andrey Ryabinin

[-- Attachment #1: Type: text/plain, Size: 1514 bytes --]

Hi all,

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

mm/kasan/common.o: warning: objtool: kasan_report()+0x17: call to report_enabled() with UACCESS enabled
In file included from include/linux/bitmap.h:9,
                 from include/linux/cpumask.h:12,
                 from arch/x86/include/asm/paravirt.h:17,
                 from arch/x86/include/asm/irqflags.h:72,
                 from include/linux/irqflags.h:16,
                 from include/linux/rcupdate.h:26,
                 from include/linux/rculist.h:11,
                 from include/linux/pid.h:5,
                 from include/linux/sched.h:14,
                 from include/linux/uaccess.h:6,
                 from arch/x86/include/asm/fpu/xstate.h:5,
                 from arch/x86/include/asm/pgtable.h:26,
                 from include/linux/kasan.h:15,
                 from lib/test_kasan.c:12:
In function 'memmove',
    inlined from 'kmalloc_memmove_invalid_size' at lib/test_kasan.c:301:2:
include/linux/string.h:441:9: warning: '__builtin_memmove' specified bound 18446744073709551614 exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=]
  441 |  return __builtin_memmove(p, q, size);
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Introduced by commit

  519e500fac64 ("kasan: add test for invalid size in memmove")

That's a bit annoying during a normal x86_64 allmodconfig build ...

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
@ 2020-02-17  2:00 Stephen Rothwell
  0 siblings, 0 replies; 145+ messages in thread
From: Stephen Rothwell @ 2020-02-17  2:00 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Randy Dunlap,
	Mina Almasry

[-- Attachment #1: Type: text/plain, Size: 1320 bytes --]

Hi all,

[Also earlier reported by Randy Dunlap]

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

In file included from mm/migrate.c:39:
include/linux/hugetlb_cgroup.h:146:21: warning: 'struct file_region' declared inside parameter list will not be visible outside of this definition or declaration
  146 |              struct file_region *rg,
      |                     ^~~~~~~~~~~
include/linux/hugetlb_cgroup.h:145:63: warning: 'struct resv_map' declared inside parameter list will not be visible outside of this definition or declaration
  145 | static inline void hugetlb_cgroup_uncharge_file_region(struct resv_map *resv,
      |                                                               ^~~~~~~~
include/linux/hugetlb_cgroup.h:233:59: warning: 'struct resv_map' declared inside parameter list will not be visible outside of this definition or declaration
  233 | static inline void hugetlb_cgroup_uncharge_counter(struct resv_map *resv,
      |                                                           ^~~~~~~~

Introduced by commits

  0b42cb2e47b6 ("hugetlb_cgroup: add reservation accounting for private mappings")
  881818698361 ("hugetlb_cgroup: add accounting for shared mappings")

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2019-11-06  7:05 Stephen Rothwell
@ 2019-11-06  7:52 ` Shaokun Zhang
  0 siblings, 0 replies; 145+ messages in thread
From: Shaokun Zhang @ 2019-11-06  7:52 UTC (permalink / raw)
  To: Stephen Rothwell, Andrew Morton
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, yuqi jin,
	Michal Hocko

Hi Stephen,

On 2019/11/6 15:05, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the akpm-current tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
> 
> lib/cpumask.c: In function 'cpumask_local_spread':
> lib/cpumask.c:302:1: warning: the frame size of 5472 bytes is larger than 2048 bytes [-Wframe-larger-than=]
>   302 | }
>       | ^
> 
> Introduced by commit
> 
>   3d591f2836cf ("lib: optimize cpumask_local_spread()")
> 
> MAX_NUMNODES == (1 << NODES_SHIFT) and NODES_SHIFT == CONFIG_NODES_SHIFT== 10,
> so MAX_NUMNODES == 1024 and there is an int array and a bool array of that
> size declared here :-(

Thanks for the report and sorry for the warning, Michal has pointed this[1].
We are preparing the new solution and will post it soon.

[1] https://lkml.org/lkml/2019/11/5/66

Thanks,
Shaokun

> 


^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
@ 2019-11-06  7:05 Stephen Rothwell
  2019-11-06  7:52 ` Shaokun Zhang
  0 siblings, 1 reply; 145+ messages in thread
From: Stephen Rothwell @ 2019-11-06  7:05 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, yuqi jin,
	Shaokun Zhang

[-- Attachment #1: Type: text/plain, Size: 604 bytes --]

Hi all,

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

lib/cpumask.c: In function 'cpumask_local_spread':
lib/cpumask.c:302:1: warning: the frame size of 5472 bytes is larger than 2048 bytes [-Wframe-larger-than=]
  302 | }
      | ^

Introduced by commit

  3d591f2836cf ("lib: optimize cpumask_local_spread()")

MAX_NUMNODES == (1 << NODES_SHIFT) and NODES_SHIFT == CONFIG_NODES_SHIFT== 10,
so MAX_NUMNODES == 1024 and there is an int array and a bool array of that
size declared here :-(

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
@ 2019-11-06  6:54 Stephen Rothwell
  0 siblings, 0 replies; 145+ messages in thread
From: Stephen Rothwell @ 2019-11-06  6:54 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Joel Fernandes (Google)

[-- Attachment #1: Type: text/plain, Size: 492 bytes --]

Hi all,

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

lib/vsprintf.c: In function 'ptr_to_hashval':
lib/vsprintf.c:766:14: warning: unused variable 'str' [-Wunused-variable]
  766 |  const char *str = sizeof(ptr) == 8 ? "(____ptrval____)" : "(ptrval)";
      |              ^~~

Introduced by commit

  aea87b9b95b9 ("rss_stat: add support to detect RSS updates of external mm")

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2019-08-07 11:29 ` Rikard Falkeborn
@ 2019-08-07 23:31   ` Stephen Rothwell
  0 siblings, 0 replies; 145+ messages in thread
From: Stephen Rothwell @ 2019-08-07 23:31 UTC (permalink / raw)
  To: Rikard Falkeborn
  Cc: Andrew Morton, Linux Next Mailing List, Linux Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 1199 bytes --]

Hi Rikard,

On Wed, 7 Aug 2019 13:29:17 +0200 Rikard Falkeborn <rikard.falkeborn@gmail.com> 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2019-08-07  8:00 Stephen Rothwell
@ 2019-08-07 11:29 ` Rikard Falkeborn
  2019-08-07 23:31   ` Stephen Rothwell
  0 siblings, 1 reply; 145+ messages in thread
From: Rikard Falkeborn @ 2019-08-07 11:29 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Linux Next Mailing List,
	Linux Kernel Mailing List, 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

^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
@ 2019-08-07  8:00 Stephen Rothwell
  2019-08-07 11:29 ` Rikard Falkeborn
  0 siblings, 1 reply; 145+ messages in thread
From: Stephen Rothwell @ 2019-08-07  8:00 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Rikard Falkeborn

[-- Attachment #1: Type: text/plain, Size: 726 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2019-07-31  6:16 Stephen Rothwell
@ 2019-07-31 12:01 ` Jia-Ju Bai
  0 siblings, 0 replies; 145+ messages in thread
From: Jia-Ju Bai @ 2019-07-31 12:01 UTC (permalink / raw)
  To: Stephen Rothwell, Andrew Morton
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Joseph Qi



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

^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
@ 2019-07-31  6:16 Stephen Rothwell
  2019-07-31 12:01 ` Jia-Ju Bai
  0 siblings, 1 reply; 145+ messages in thread
From: Stephen Rothwell @ 2019-07-31  6:16 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Jia-Ju Bai,
	Joseph Qi

[-- Attachment #1: Type: text/plain, Size: 485 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
@ 2019-07-29  3:48 Stephen Rothwell
  0 siblings, 0 replies; 145+ messages in thread
From: Stephen Rothwell @ 2019-07-29  3:48 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, John Hubbard

[-- Attachment #1: Type: text/plain, Size: 475 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
@ 2019-07-29  3:44 Stephen Rothwell
  0 siblings, 0 replies; 145+ messages in thread
From: Stephen Rothwell @ 2019-07-29  3:44 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Linux Next Mailing List, Linux Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 437 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2019-05-30  4:55 Stephen Rothwell
@ 2019-05-30  9:02 ` Matteo Croce
  0 siblings, 0 replies; 145+ messages in thread
From: Matteo Croce @ 2019-05-30  9:02 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Linux Next Mailing List, Linux Kernel Mailing List

On Thu, May 30, 2019 at 6:55 AM Stephen Rothwell <sfr@canb.auug.org.au> 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 <liujie165@huawei.com>
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

^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
@ 2019-05-30  4:55 Stephen Rothwell
  2019-05-30  9:02 ` Matteo Croce
  0 siblings, 1 reply; 145+ messages in thread
From: Stephen Rothwell @ 2019-05-30  4:55 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Matteo Croce

[-- Attachment #1: Type: text/plain, Size: 493 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2019-04-16  6:52 ` Stephen Rothwell
@ 2019-04-16 22:45   ` Andrew Morton
  0 siblings, 0 replies; 145+ messages in thread
From: Andrew Morton @ 2019-04-16 22:45 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: George Spelvin, Linux Next Mailing List, Linux Kernel Mailing List

On Tue, 16 Apr 2019 16:52:56 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> On Fri, 29 Mar 2019 13:39:14 +1100 Stephen Rothwell <sfr@canb.auug.org.au> 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 <linux/list_sort.h>
 #include <linux/list.h>
 
-/*
- * 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 *);
 
 /*
_


^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2019-03-29  2:39 Stephen Rothwell
@ 2019-04-16  6:52 ` Stephen Rothwell
  2019-04-16 22:45   ` Andrew Morton
  0 siblings, 1 reply; 145+ messages in thread
From: Stephen Rothwell @ 2019-04-16  6:52 UTC (permalink / raw)
  To: Andrew Morton, George Spelvin
  Cc: Linux Next Mailing List, Linux Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 583 bytes --]

Hi all,

On Fri, 29 Mar 2019 13:39:14 +1100 Stephen Rothwell <sfr@canb.auug.org.au> 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
@ 2019-03-29  2:39 Stephen Rothwell
  2019-04-16  6:52 ` Stephen Rothwell
  0 siblings, 1 reply; 145+ messages in thread
From: Stephen Rothwell @ 2019-03-29  2:39 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, George Spelvin

[-- Attachment #1: Type: text/plain, Size: 438 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
@ 2019-01-31  5:01 Stephen Rothwell
  0 siblings, 0 replies; 145+ messages in thread
From: Stephen Rothwell @ 2019-01-31  5:01 UTC (permalink / raw)
  To: Andrew Morton, James Morris
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Alexey Dobriyan, Casey Schaufler, Kees Cook

[-- Attachment #1: Type: text/plain, Size: 2278 bytes --]

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 <sfr@canb.auug.org.au>
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 <sfr@canb.auug.org.au>
---
 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
@ 2018-06-08  4:45 Stephen Rothwell
  0 siblings, 0 replies; 145+ messages in thread
From: Stephen Rothwell @ 2018-06-08  4:45 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, OGAWA Hirofumi

[-- Attachment #1: Type: text/plain, Size: 730 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2018-05-07 16:47     ` Randy Dunlap
@ 2018-05-08 10:48       ` Minchan Kim
  0 siblings, 0 replies; 145+ messages in thread
From: Minchan Kim @ 2018-05-08 10:48 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: Stephen Rothwell, Andrew Morton, Linux-Next Mailing List,
	Linux Kernel Mailing List, Greg Kroah-Hartman,
	Sergey Senozhatsky

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_t	tv_sec;			/* seconds */
> >> 	long		tv_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 <minchan@kernel.org>
> > 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 <gregkh@linuxfoundation.org>
> > Cc: Randy Dunlap <rdunlap@infradead.org>
> > Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
> > Cc: Andrew Morton <akpm@linux-foundation.org>
> > Cc: Stephen Rothwell <sfr@canb.auug.org.au>
> > Signed-off-by: Minchan Kim <minchan@kernel.org>
> > ---
> >  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 <minchan@kernel.org>
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 <gregkh@linuxfoundation.org>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Minchan Kim <minchan@kernel.org>
---
 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, (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

^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
  2018-05-07 14:10   ` Minchan Kim
@ 2018-05-07 16:47     ` Randy Dunlap
  2018-05-08 10:48       ` Minchan Kim
  0 siblings, 1 reply; 145+ messages in thread
From: Randy Dunlap @ 2018-05-07 16:47 UTC (permalink / raw)
  To: Minchan Kim
  Cc: Stephen Rothwell, Andrew Morton, Linux-Next Mailing List,
	Linux Kernel Mailing List, Greg Kroah-Hartman,
	Sergey Senozhatsky

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_t	tv_sec;			/* seconds */
>> 	long		tv_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 <minchan@kernel.org>
> 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 <gregkh@linuxfoundation.org>
> Cc: Randy Dunlap <rdunlap@infradead.org>
> Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Stephen Rothwell <sfr@canb.auug.org.au>
> Signed-off-by: Minchan Kim <minchan@kernel.org>
> ---
>  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

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2018-05-04 15:39 ` Randy Dunlap
@ 2018-05-07 14:10   ` Minchan Kim
  2018-05-07 16:47     ` Randy Dunlap
  0 siblings, 1 reply; 145+ messages in thread
From: Minchan Kim @ 2018-05-07 14:10 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: Stephen Rothwell, Andrew Morton, Linux-Next Mailing List,
	Linux Kernel Mailing List, Greg Kroah-Hartman,
	Sergey Senozhatsky

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_t	tv_sec;			/* seconds */
> 	long		tv_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 <minchan@kernel.org>
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 <gregkh@linuxfoundation.org>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Minchan Kim <minchan@kernel.org>
---
 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

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2018-05-04  4:17 Stephen Rothwell
@ 2018-05-04 15:39 ` Randy Dunlap
  2018-05-07 14:10   ` Minchan Kim
  0 siblings, 1 reply; 145+ messages in thread
From: Randy Dunlap @ 2018-05-04 15:39 UTC (permalink / raw)
  To: Stephen Rothwell, Andrew Morton
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Greg Kroah-Hartman, Minchan Kim, Sergey Senozhatsky

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_t	tv_sec;			/* seconds */
	long		tv_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

^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
@ 2018-05-04  4:17 Stephen Rothwell
  2018-05-04 15:39 ` Randy Dunlap
  0 siblings, 1 reply; 145+ messages in thread
From: Stephen Rothwell @ 2018-05-04  4:17 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Greg Kroah-Hartman, Minchan Kim, Randy Dunlap,
	Sergey Senozhatsky

[-- Attachment #1: Type: text/plain, Size: 650 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
@ 2018-04-06  4:53 Stephen Rothwell
  0 siblings, 0 replies; 145+ messages in thread
From: Stephen Rothwell @ 2018-04-06  4:53 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Johannes Weiner

[-- Attachment #1: Type: text/plain, Size: 529 bytes --]

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(&memcg->memory_events[OOM_KILL]));
                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Introduced by commit

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

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
@ 2018-01-02  7:04 Stephen Rothwell
  0 siblings, 0 replies; 145+ messages in thread
From: Stephen Rothwell @ 2018-01-02  7:04 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Linux-Next Mailing List, Linux Kernel Mailing List

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

^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
@ 2017-12-15  2:48 Stephen Rothwell
  0 siblings, 0 replies; 145+ messages in thread
From: Stephen Rothwell @ 2017-12-15  2:48 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Yang Shi

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

^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
@ 2017-11-23  2:01 Stephen Rothwell
  0 siblings, 0 replies; 145+ messages in thread
From: Stephen Rothwell @ 2017-11-23  2:01 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Tetsuo Handa

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->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(&manager->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(&manager->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

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2017-11-17  3:53       ` Stephen Rothwell
  2017-11-17  9:36         ` Zhangshaokun
@ 2017-11-17  9:56         ` Arnd Bergmann
  1 sibling, 0 replies; 145+ messages in thread
From: Arnd Bergmann @ 2017-11-17  9:56 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Michal Hocko, Andrew Morton, Linux-Next Mailing List,
	Linux Kernel Mailing List

On Fri, Nov 17, 2017 at 4:53 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> On Fri, 17 Nov 2017 09:44:39 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> On Mon, 13 Nov 2017 12:43:08 +0100 Arnd Bergmann <arnd@arndb.de> wrote:
>> >
>> > On Mon, Nov 13, 2017 at 9:09 AM, Michal Hocko <mhocko@kernel.org> 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(&nodes));
>> > >>            ^
>> > >
>> > > 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

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2017-11-17  3:53       ` Stephen Rothwell
@ 2017-11-17  9:36         ` Zhangshaokun
  2017-11-17  9:56         ` Arnd Bergmann
  1 sibling, 0 replies; 145+ messages in thread
From: Zhangshaokun @ 2017-11-17  9:36 UTC (permalink / raw)
  To: Stephen Rothwell, Michal Hocko, Andrew Morton
  Cc: Arnd Bergmann, Linux-Next Mailing List, Linux Kernel Mailing List

Hi,

On 2017/11/17 11:53, Stephen Rothwell wrote:
> Hi all,
> 
> On Fri, 17 Nov 2017 09:44:39 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> On Mon, 13 Nov 2017 12:43:08 +0100 Arnd Bergmann <arnd@arndb.de> wrote:
>>>
>>> On Mon, Nov 13, 2017 at 9:09 AM, Michal Hocko <mhocko@kernel.org> 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(&nodes));
>>>>>            ^    
>>>>
>>>> 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(&nodes));
           ^
./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(&nodes));
           ^
  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(&nodes));
>            ^
> 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(&nodes));
>            ^
> 

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2017-11-16 22:44     ` Stephen Rothwell
@ 2017-11-17  3:53       ` Stephen Rothwell
  2017-11-17  9:36         ` Zhangshaokun
  2017-11-17  9:56         ` Arnd Bergmann
  0 siblings, 2 replies; 145+ messages in thread
From: Stephen Rothwell @ 2017-11-17  3:53 UTC (permalink / raw)
  To: Michal Hocko, Andrew Morton
  Cc: Arnd Bergmann, Linux-Next Mailing List, Linux Kernel Mailing List

Hi all,

On Fri, 17 Nov 2017 09:44:39 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Mon, 13 Nov 2017 12:43:08 +0100 Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > On Mon, Nov 13, 2017 at 9:09 AM, Michal Hocko <mhocko@kernel.org> 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(&nodes));
> > >>            ^    
> > >
> > > 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(&nodes));
           ^
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(&nodes));
           ^

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2017-11-13 11:43   ` Arnd Bergmann
  2017-11-13 11:54     ` Michal Hocko
@ 2017-11-16 22:44     ` Stephen Rothwell
  2017-11-17  3:53       ` Stephen Rothwell
  1 sibling, 1 reply; 145+ messages in thread
From: Stephen Rothwell @ 2017-11-16 22:44 UTC (permalink / raw)
  To: Michal Hocko, Andrew Morton
  Cc: Arnd Bergmann, Linux-Next Mailing List, Linux Kernel Mailing List

Hi all,

On Mon, 13 Nov 2017 12:43:08 +0100 Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Mon, Nov 13, 2017 at 9:09 AM, Michal Hocko <mhocko@kernel.org> 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(&nodes));
> >>            ^  
> >
> > 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

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2017-11-13 11:54     ` Michal Hocko
  2017-11-13 12:24       ` Arnd Bergmann
@ 2017-11-13 12:29       ` Michal Hocko
  1 sibling, 0 replies; 145+ messages in thread
From: Michal Hocko @ 2017-11-13 12:29 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Stephen Rothwell, Andrew Morton, Linux-Next Mailing List,
	Linux Kernel Mailing List

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 <mhocko@kernel.org> 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(&nodes));
> > >>            ^
> > >
> > > 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

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2017-11-13 11:54     ` Michal Hocko
@ 2017-11-13 12:24       ` Arnd Bergmann
  2017-11-13 12:29       ` Michal Hocko
  1 sibling, 0 replies; 145+ messages in thread
From: Arnd Bergmann @ 2017-11-13 12:24 UTC (permalink / raw)
  To: Michal Hocko
  Cc: Stephen Rothwell, Andrew Morton, Linux-Next Mailing List,
	Linux Kernel Mailing List

On Mon, Nov 13, 2017 at 12:54 PM, Michal Hocko <mhocko@kernel.org> wrote:
> On Mon 13-11-17 12:43:08, Arnd Bergmann wrote:
>> On Mon, Nov 13, 2017 at 9:09 AM, Michal Hocko <mhocko@kernel.org> 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(&nodes));
>> >>            ^
>> >
>> > 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

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2017-11-13 11:43   ` Arnd Bergmann
@ 2017-11-13 11:54     ` Michal Hocko
  2017-11-13 12:24       ` Arnd Bergmann
  2017-11-13 12:29       ` Michal Hocko
  2017-11-16 22:44     ` Stephen Rothwell
  1 sibling, 2 replies; 145+ messages in thread
From: Michal Hocko @ 2017-11-13 11:54 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Stephen Rothwell, Andrew Morton, Linux-Next Mailing List,
	Linux Kernel Mailing List

On Mon 13-11-17 12:43:08, Arnd Bergmann wrote:
> On Mon, Nov 13, 2017 at 9:09 AM, Michal Hocko <mhocko@kernel.org> 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(&nodes));
> >>            ^
> >
> > 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

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2017-11-13  8:09 ` Michal Hocko
  2017-11-13  8:23   ` Michal Hocko
@ 2017-11-13 11:43   ` Arnd Bergmann
  2017-11-13 11:54     ` Michal Hocko
  2017-11-16 22:44     ` Stephen Rothwell
  1 sibling, 2 replies; 145+ messages in thread
From: Arnd Bergmann @ 2017-11-13 11:43 UTC (permalink / raw)
  To: Michal Hocko
  Cc: Stephen Rothwell, Andrew Morton, Linux-Next Mailing List,
	Linux Kernel Mailing List

On Mon, Nov 13, 2017 at 9:09 AM, Michal Hocko <mhocko@kernel.org> 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(&nodes));
>>            ^
>
> 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

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2017-11-13  8:09 ` Michal Hocko
@ 2017-11-13  8:23   ` Michal Hocko
  2017-11-13 11:43   ` Arnd Bergmann
  1 sibling, 0 replies; 145+ messages in thread
From: Michal Hocko @ 2017-11-13  8:23 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Linux-Next Mailing List, Linux Kernel Mailing List

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(&nodes));
> >            ^
> 
> 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 &m 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 <stdio.h>

#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 = &m;

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

	return 0;
}
-- 
Michal Hocko
SUSE Labs

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2017-11-13  5:42 Stephen Rothwell
@ 2017-11-13  8:09 ` Michal Hocko
  2017-11-13  8:23   ` Michal Hocko
  2017-11-13 11:43   ` Arnd Bergmann
  0 siblings, 2 replies; 145+ messages in thread
From: Michal Hocko @ 2017-11-13  8:09 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Linux-Next Mailing List, Linux Kernel Mailing List

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(&nodes));
>            ^

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

^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
@ 2017-11-13  5:54 Stephen Rothwell
  0 siblings, 0 replies; 145+ messages in thread
From: Stephen Rothwell @ 2017-11-13  5:54 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Yury Norov

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

^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
@ 2017-11-13  5:42 Stephen Rothwell
  2017-11-13  8:09 ` Michal Hocko
  0 siblings, 1 reply; 145+ messages in thread
From: Stephen Rothwell @ 2017-11-13  5:42 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Michal Hocko

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(&nodes));
           ^
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(&nodes));
           ^

Introduced by commit

  b2c1ed23bdc1 ("mm: simplify nodemask printing")

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
@ 2017-08-01  5:22 Stephen Rothwell
  0 siblings, 0 replies; 145+ messages in thread
From: Stephen Rothwell @ 2017-08-01  5:22 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Michal Hocko

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

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2017-05-26 10:16 ` Jeff Layton
@ 2017-05-26 11:28   ` Dave Kleikamp
  0 siblings, 0 replies; 145+ messages in thread
From: Dave Kleikamp @ 2017-05-26 11:28 UTC (permalink / raw)
  To: Jeff Layton, Stephen Rothwell, Andrew Morton
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Ross Zwisler,
	Jan Kara, Matthew Wilcox, Christoph Hellwig

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

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2017-05-26  2:43 Stephen Rothwell
@ 2017-05-26 10:16 ` Jeff Layton
  2017-05-26 11:28   ` Dave Kleikamp
  0 siblings, 1 reply; 145+ messages in thread
From: Jeff Layton @ 2017-05-26 10:16 UTC (permalink / raw)
  To: Stephen Rothwell, Andrew Morton, Dave Kleikamp
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Ross Zwisler,
	Jan Kara, Matthew Wilcox, Christoph Hellwig

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 <jlayton@redhat.com>

^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
@ 2017-05-26  2:43 Stephen Rothwell
  2017-05-26 10:16 ` Jeff Layton
  0 siblings, 1 reply; 145+ messages in thread
From: Stephen Rothwell @ 2017-05-26  2:43 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Jeff Layton,
	Ross Zwisler, Jan Kara, Matthew Wilcox, Christoph Hellwig

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

^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
@ 2017-05-19  4:44 Stephen Rothwell
  0 siblings, 0 replies; 145+ messages in thread
From: Stephen Rothwell @ 2017-05-19  4:44 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Michal Hocko

Hi Andrew,

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

mm/vmstat.c: In function 'pagetypeinfo_showblockcount_print':
mm/vmstat.c:1230:8: warning: 'page' may be used uninitialized in this function [-Wmaybe-uninitialized]
   if (!memmap_valid_within(pfn, page, zone))
        ^

Introduced by commit

  36c7473b3c85 ("mm, vmstat: skip reporting offline pages in pagetypeinfo")

That really doesn't look good.

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2017-05-15  4:02 ` Xunlei Pang
@ 2017-05-15  5:07   ` Stephen Rothwell
  0 siblings, 0 replies; 145+ messages in thread
From: Stephen Rothwell @ 2017-05-15  5:07 UTC (permalink / raw)
  To: Xunlei Pang
  Cc: xlpang, Andrew Morton, Linux-Next Mailing List,
	Linux Kernel Mailing List

Hi Xunlei,

On Mon, 15 May 2017 12:02:18 +0800 Xunlei Pang <xpang@redhat.com> wrote:
>
> The following patch will fix it, do you want to me to send it out separately? or help merge it into
> fc7d2b44367f ("powerpc/fadump: use the correct VMCOREINFO_NOTE_SIZE for phdr") directly?

Andrew normally takes these as separate patches and then merges them
before sending them on.

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2017-05-15  1:56 Stephen Rothwell
@ 2017-05-15  4:02 ` Xunlei Pang
  2017-05-15  5:07   ` Stephen Rothwell
  0 siblings, 1 reply; 145+ messages in thread
From: Xunlei Pang @ 2017-05-15  4:02 UTC (permalink / raw)
  To: Stephen Rothwell, Andrew Morton
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Xunlei Pang

On 05/15/2017 at 09:56 AM, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm-current tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning:
>
> In file included from include/asm-generic/bug.h:15:0,
>                  from arch/arm/include/asm/bug.h:59,
>                  from include/linux/bug.h:4,
>                  from include/linux/elfcore.h:5,
>                  from include/linux/crash_core.h:5,
>                  from kernel/crash_core.c:9:
> kernel/crash_core.c: In function 'vmcoreinfo_append_str':
> include/linux/kernel.h:757:16: warning: comparison of distinct pointer types lacks a cast
>   (void) (&min1 == &min2);   \
>                 ^
> include/linux/kernel.h:760:2: note: in expansion of macro '__min'
>   __min(typeof(x), typeof(y),   \
>   ^
> kernel/crash_core.c:360:6: note: in expansion of macro 'min'
>   r = min(r, VMCOREINFO_BYTES - vmcoreinfo_size);
>       ^
>
> Introduced by commit
>
>   fc7d2b44367f ("powerpc/fadump: use the correct VMCOREINFO_NOTE_SIZE for phdr")
>

Hi Stephen/Andrew,

Sorry for the trouble.

The following patch will fix it, do you want to me to send it out separately? or help merge it into
fc7d2b44367f ("powerpc/fadump: use the correct VMCOREINFO_NOTE_SIZE for phdr") directly?

Thanks,
Xunlei

===========================================

From: Xunlei Pang <xlpang@redhat.com>
Subject: [PATCH] crash: Fix build warning

linux-next build (arm multi_v7_defconfig) produced this warning:

In file included from include/asm-generic/bug.h:15:0,
                 from arch/arm/include/asm/bug.h:59,
                 from include/linux/bug.h:4,
                 from include/linux/elfcore.h:5,
                 from include/linux/crash_core.h:5,
                 from kernel/crash_core.c:9:
kernel/crash_core.c: In function 'vmcoreinfo_append_str':
include/linux/kernel.h:757:16: warning: comparison of distinct pointer
types lacks a cast
  (void) (&min1 == &min2);   \
                ^
include/linux/kernel.h:760:2: note: in expansion of macro '__min'
  __min(typeof(x), typeof(y),   \
  ^
kernel/crash_core.c:360:6: note: in expansion of macro 'min'
  r = min(r, VMCOREINFO_BYTES - vmcoreinfo_size);
      ^

This patch fixes it.

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
---
 kernel/crash_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/crash_core.c b/kernel/crash_core.c
index 4a4a4ba..6db80fc 100644
--- a/kernel/crash_core.c
+++ b/kernel/crash_core.c
@@ -357,7 +357,7 @@ void vmcoreinfo_append_str(const char *fmt, ...)
     r = vscnprintf(buf, sizeof(buf), fmt, args);
     va_end(args);
 
-    r = min(r, VMCOREINFO_BYTES - vmcoreinfo_size);
+    r = min(r, (size_t)VMCOREINFO_BYTES - vmcoreinfo_size);
 
     memcpy(&vmcoreinfo_data[vmcoreinfo_size], buf, r);
 
-- 
1.8.3.1

^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
@ 2017-05-15  1:56 Stephen Rothwell
  2017-05-15  4:02 ` Xunlei Pang
  0 siblings, 1 reply; 145+ messages in thread
From: Stephen Rothwell @ 2017-05-15  1:56 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Xunlei Pang

Hi Andrew,

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

In file included from include/asm-generic/bug.h:15:0,
                 from arch/arm/include/asm/bug.h:59,
                 from include/linux/bug.h:4,
                 from include/linux/elfcore.h:5,
                 from include/linux/crash_core.h:5,
                 from kernel/crash_core.c:9:
kernel/crash_core.c: In function 'vmcoreinfo_append_str':
include/linux/kernel.h:757:16: warning: comparison of distinct pointer types lacks a cast
  (void) (&min1 == &min2);   \
                ^
include/linux/kernel.h:760:2: note: in expansion of macro '__min'
  __min(typeof(x), typeof(y),   \
  ^
kernel/crash_core.c:360:6: note: in expansion of macro 'min'
  r = min(r, VMCOREINFO_BYTES - vmcoreinfo_size);
      ^

Introduced by commit

  fc7d2b44367f ("powerpc/fadump: use the correct VMCOREINFO_NOTE_SIZE for phdr")

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
@ 2017-02-02  6:49 Stephen Rothwell
  0 siblings, 0 replies; 145+ messages in thread
From: Stephen Rothwell @ 2017-02-02  6:49 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Dave Jiang, Matthew Wilcox

Hi Andrew,

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

fs/ext4/file.c:279:1: warning: 'ext4_dax_huge_fault' defined but not used [-Wunused-function]
 ext4_dax_huge_fault(struct vm_fault *vmf)
 ^

Introduced by commit

  80a841811260 ("mm,fs,dax: change ->pmd_fault to ->huge_fault")

Looks like the replacement in ext4_dax_vm_ops may be incorrect?

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2016-11-09 21:21   ` Andrew Morton
@ 2016-11-10  2:56     ` Stephen Rothwell
  0 siblings, 0 replies; 145+ messages in thread
From: Stephen Rothwell @ 2016-11-10  2:56 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Huang Shijie, linux-next, linux-kernel, nd

Hi Andrew,

On Wed, 9 Nov 2016 13:21:53 -0800 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Wed, 9 Nov 2016 15:18:24 +0800 Huang Shijie <shijie.huang@arm.com> wrote:
> 
> > On Wed, Nov 09, 2016 at 03:10:06PM +1100, Stephen Rothwell wrote:
> > Hi Stephen,  
> > > Hi Andrew,
> > > 
> > > After merging the akpm-current tree, today's linux-next build (powerpc
> > > ppc64_defconfig) produced this warning:
> > > 
> > > mm/hugetlb.c:1166:21: warning: 'alloc_gigantic_page' defined but not used [-Wunused-function]
> > >  static struct page *alloc_gigantic_page(int nid, unsigned int order)  
> > The warning should be fixed by the patch (or next version of this patch):
> >   http://marc.info/?l=linux-mm&m=147867535926059&w=2	  
> 
> I'll drop "mm/hugetlb.c: rename some allocation functions" for now. 
> Please change it to fix this warning then add it to the surplus-page
> series when resending that.

I have dropped it from linux-next today.

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2016-11-09  7:18 ` Huang Shijie
@ 2016-11-09 21:21   ` Andrew Morton
  2016-11-10  2:56     ` Stephen Rothwell
  0 siblings, 1 reply; 145+ messages in thread
From: Andrew Morton @ 2016-11-09 21:21 UTC (permalink / raw)
  To: Huang Shijie; +Cc: Stephen Rothwell, linux-next, linux-kernel, nd

On Wed, 9 Nov 2016 15:18:24 +0800 Huang Shijie <shijie.huang@arm.com> wrote:

> On Wed, Nov 09, 2016 at 03:10:06PM +1100, Stephen Rothwell wrote:
> Hi Stephen,
> > Hi Andrew,
> > 
> > After merging the akpm-current tree, today's linux-next build (powerpc
> > ppc64_defconfig) produced this warning:
> > 
> > mm/hugetlb.c:1166:21: warning: 'alloc_gigantic_page' defined but not used [-Wunused-function]
> >  static struct page *alloc_gigantic_page(int nid, unsigned int order)
> The warning should be fixed by the patch (or next version of this patch):
>   http://marc.info/?l=linux-mm&m=147867535926059&w=2	

I'll drop "mm/hugetlb.c: rename some allocation functions" for now. 
Please change it to fix this warning then add it to the surplus-page
series when resending that.

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2016-11-09  4:10 Stephen Rothwell
@ 2016-11-09  7:18 ` Huang Shijie
  2016-11-09 21:21   ` Andrew Morton
  0 siblings, 1 reply; 145+ messages in thread
From: Huang Shijie @ 2016-11-09  7:18 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Andrew Morton, linux-next, linux-kernel, nd

On Wed, Nov 09, 2016 at 03:10:06PM +1100, Stephen Rothwell wrote:
Hi Stephen,
> Hi Andrew,
> 
> After merging the akpm-current tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
> 
> mm/hugetlb.c:1166:21: warning: 'alloc_gigantic_page' defined but not used [-Wunused-function]
>  static struct page *alloc_gigantic_page(int nid, unsigned int order)
The warning should be fixed by the patch (or next version of this patch):
  http://marc.info/?l=linux-mm&m=147867535926059&w=2	


Thanks
Huang Shijie

^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
@ 2016-11-09  4:10 Stephen Rothwell
  2016-11-09  7:18 ` Huang Shijie
  0 siblings, 1 reply; 145+ messages in thread
From: Stephen Rothwell @ 2016-11-09  4:10 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Huang Shijie

Hi Andrew,

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

mm/hugetlb.c:1166:21: warning: 'alloc_gigantic_page' defined but not used [-Wunused-function]
 static struct page *alloc_gigantic_page(int nid, unsigned int order)
                     ^

Introduced by commit

  4acc8ccc3c57 ("mm/hugetlb.c: rename some allocation functions")

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2016-06-23  6:53 Stephen Rothwell
@ 2016-06-23 14:00 ` Mel Gorman
  0 siblings, 0 replies; 145+ messages in thread
From: Mel Gorman @ 2016-06-23 14:00 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Andrew Morton, linux-next, linux-kernel

On Thu, Jun 23, 2016 at 04:53:21PM +1000, Stephen Rothwell wrote:
> Hi Andrew,
> 
> After merging the akpm-current tree, today's linux-next build (powerpc
> ppc64_defconfig and x86_64 allmodconfig) produced this warning:
> 

I asked that Andrew drop the patch series that introduced this problem.
It's fixed in a private tree but it's not ready for reposting yet.

-- 
Mel Gorman
SUSE Labs

^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
@ 2016-06-23  6:53 Stephen Rothwell
  2016-06-23 14:00 ` Mel Gorman
  0 siblings, 1 reply; 145+ messages in thread
From: Stephen Rothwell @ 2016-06-23  6:53 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Mel Gorman

Hi Andrew,

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

drivers/base/node.c: In function 'node_read_meminfo':
drivers/base/node.c:127:31: warning: passing argument 1 of 'node_page_state' makes pointer from integer without a cast [-Wint-conversion]
          nid, node_page_state(nid, NR_KERNEL_STACK) *
                               ^
In file included from include/linux/mm.h:999:0,
                 from drivers/base/node.c:7:
include/linux/vmstat.h:200:22: note: expected 'struct pglist_data *' but argument is of type 'int'
 extern unsigned long node_page_state(struct pglist_data *pgdat,
                      ^

Introduced by commit

  2bfac6c1ec44 ("mm, vmstat: add infrastructure for per-node vmstats")

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2016-05-27  3:07 Stephen Rothwell
@ 2016-05-27 19:53 ` Andrew Morton
  0 siblings, 0 replies; 145+ messages in thread
From: Andrew Morton @ 2016-05-27 19:53 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Michal Hocko

On Fri, 27 May 2016 13:07:10 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Andrew,
> 
> After merging the akpm-current tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning:
> 
> mm/oom_kill.c: In function '__oom_reap_task':
> mm/oom_kill.c:537:2: warning: 'mm' may be used uninitialized in this function [-Wmaybe-uninitialized]
>   mmput_async(mm);
>   ^
> 
> Introduced by commit
> 
>   df1e2f56632d ("oom_reaper: close race with exiting task")
> 
> This is real - the first "goto unlock_oom" is before "mm" has been
> assigned.

Yup, thanks.

From: Andrew Morton <akpm@linux-foundation.org>
Subject: oom_reaper-close-race-with-exiting-task-fix

fix use of unused `mm', Per Stephen

Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 mm/oom_kill.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff -puN mm/oom_kill.c~oom_reaper-close-race-with-exiting-task-fix mm/oom_kill.c
--- a/mm/oom_kill.c~oom_reaper-close-race-with-exiting-task-fix
+++ a/mm/oom_kill.c
@@ -443,7 +443,7 @@ static bool __oom_reap_task(struct task_
 {
 	struct mmu_gather tlb;
 	struct vm_area_struct *vma;
-	struct mm_struct *mm;
+	struct mm_struct *mm = NULL;
 	struct task_struct *p;
 	struct zap_details details = {.check_swap_entries = true,
 				      .ignore_dirty = true};
@@ -534,7 +534,8 @@ unlock_oom:
 	 * different context because we shouldn't risk we get stuck there and
 	 * put the oom_reaper out of the way.
 	 */
-	mmput_async(mm);
+	if (mm)
+		mmput_async(mm);
 	return ret;
 }
 
_

^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
@ 2016-05-27  3:07 Stephen Rothwell
  2016-05-27 19:53 ` Andrew Morton
  0 siblings, 1 reply; 145+ messages in thread
From: Stephen Rothwell @ 2016-05-27  3:07 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Michal Hocko

Hi Andrew,

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

mm/oom_kill.c: In function '__oom_reap_task':
mm/oom_kill.c:537:2: warning: 'mm' may be used uninitialized in this function [-Wmaybe-uninitialized]
  mmput_async(mm);
  ^

Introduced by commit

  df1e2f56632d ("oom_reaper: close race with exiting task")

This is real - the first "goto unlock_oom" is before "mm" has been
assigned.

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2016-04-29 14:03   ` Josh Poimboeuf
@ 2016-04-30  5:52     ` Stephen Rothwell
  0 siblings, 0 replies; 145+ messages in thread
From: Stephen Rothwell @ 2016-04-30  5:52 UTC (permalink / raw)
  To: Josh Poimboeuf
  Cc: Andrew Morton, linux-next, linux-kernel, Arnd Bergmann, Quinn Tran

Hi Josh,

On Fri, 29 Apr 2016 09:03:42 -0500 Josh Poimboeuf <jpoimboe@redhat.com> wrote:
>
> On Fri, Apr 29, 2016 at 08:32:19AM -0500, Josh Poimboeuf wrote:
> > On Fri, Apr 29, 2016 at 04:45:43PM +1000, Stephen Rothwell wrote:  
> > > Hi Andrew,
> > > 
> > > After merging the akpm-current tree, today's linux-next build (x86_64
> > > allmodconfig) produced this warning:
> > > 
> > > drivers/scsi/ipr.c: In function 'ipr_show_device_id':
> > > drivers/scsi/ipr.c:4462:34: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
> > >    len = snprintf(buf, PAGE_SIZE, "0x%llx\n", be64_to_cpu(res->dev_id));
> > >                                   ^
> > > 
> > > Lots and lots like this :-(
> > > 
> > > Probably introduced by commit
> > > 
> > >   eef17fb79096 ("byteswap: try to avoid __builtin_constant_p gcc bug")
> > > 
> > > I guess __builtin_bswap64() has type "unsigned long int" :-(  
> > 
> > Hm, I suppose this is cross-compiled on a powerpc host?
> > 
> > We probably need to add a (__u64) cast to the return value of
> > __builtin_bswap64(), like:
> > 
> > diff --git a/include/uapi/linux/swab.h b/include/uapi/linux/swab.h
> > index de56fd5..d737804 100644
> > --- a/include/uapi/linux/swab.h
> > +++ b/include/uapi/linux/swab.h
> > @@ -123,7 +123,7 @@ static inline __attribute_const__ __u32 __fswahb32(__u32 val)
> >   * @x: value to byteswap
> >   */
> >  #ifdef __HAVE_BUILTIN_BSWAP64__
> > -#define __swab64(x) __builtin_bswap64((__u64)(x))
> > +#define __swab64(x) (__u64)__builtin_bswap64((__u64)(x))
> >  #else
> >  #define __swab64(x)				\
> >  	(__builtin_constant_p((__u64)(x)) ?	\  
> 
> 
> Never mind about cross-compiling on powerpc, this has nothing to do with
> that.  But the above patch does seem to fix it.

Thanks.  I have added Andrew's tidied up version to linux-next to
replace the revert.

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2016-04-29 13:32 ` Josh Poimboeuf
@ 2016-04-29 14:03   ` Josh Poimboeuf
  2016-04-30  5:52     ` Stephen Rothwell
  0 siblings, 1 reply; 145+ messages in thread
From: Josh Poimboeuf @ 2016-04-29 14:03 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, linux-next, linux-kernel, Arnd Bergmann, Quinn Tran

On Fri, Apr 29, 2016 at 08:32:19AM -0500, Josh Poimboeuf wrote:
> On Fri, Apr 29, 2016 at 04:45:43PM +1000, Stephen Rothwell wrote:
> > Hi Andrew,
> > 
> > After merging the akpm-current tree, today's linux-next build (x86_64
> > allmodconfig) produced this warning:
> > 
> > drivers/scsi/ipr.c: In function 'ipr_show_device_id':
> > drivers/scsi/ipr.c:4462:34: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
> >    len = snprintf(buf, PAGE_SIZE, "0x%llx\n", be64_to_cpu(res->dev_id));
> >                                   ^
> > 
> > Lots and lots like this :-(
> > 
> > Probably introduced by commit
> > 
> >   eef17fb79096 ("byteswap: try to avoid __builtin_constant_p gcc bug")
> > 
> > I guess __builtin_bswap64() has type "unsigned long int" :-(
> 
> Hm, I suppose this is cross-compiled on a powerpc host?
> 
> We probably need to add a (__u64) cast to the return value of
> __builtin_bswap64(), like:
> 
> diff --git a/include/uapi/linux/swab.h b/include/uapi/linux/swab.h
> index de56fd5..d737804 100644
> --- a/include/uapi/linux/swab.h
> +++ b/include/uapi/linux/swab.h
> @@ -123,7 +123,7 @@ static inline __attribute_const__ __u32 __fswahb32(__u32 val)
>   * @x: value to byteswap
>   */
>  #ifdef __HAVE_BUILTIN_BSWAP64__
> -#define __swab64(x) __builtin_bswap64((__u64)(x))
> +#define __swab64(x) (__u64)__builtin_bswap64((__u64)(x))
>  #else
>  #define __swab64(x)				\
>  	(__builtin_constant_p((__u64)(x)) ?	\


Never mind about cross-compiling on powerpc, this has nothing to do with
that.  But the above patch does seem to fix it.

-- 
Josh

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2016-04-29  6:45 Stephen Rothwell
  2016-04-29  6:55 ` Stephen Rothwell
@ 2016-04-29 13:32 ` Josh Poimboeuf
  2016-04-29 14:03   ` Josh Poimboeuf
  1 sibling, 1 reply; 145+ messages in thread
From: Josh Poimboeuf @ 2016-04-29 13:32 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, linux-next, linux-kernel, Arnd Bergmann, Quinn Tran

On Fri, Apr 29, 2016 at 04:45:43PM +1000, Stephen Rothwell wrote:
> Hi Andrew,
> 
> After merging the akpm-current tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
> 
> drivers/scsi/ipr.c: In function 'ipr_show_device_id':
> drivers/scsi/ipr.c:4462:34: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
>    len = snprintf(buf, PAGE_SIZE, "0x%llx\n", be64_to_cpu(res->dev_id));
>                                   ^
> 
> Lots and lots like this :-(
> 
> Probably introduced by commit
> 
>   eef17fb79096 ("byteswap: try to avoid __builtin_constant_p gcc bug")
> 
> I guess __builtin_bswap64() has type "unsigned long int" :-(

Hm, I suppose this is cross-compiled on a powerpc host?

We probably need to add a (__u64) cast to the return value of
__builtin_bswap64(), like:

diff --git a/include/uapi/linux/swab.h b/include/uapi/linux/swab.h
index de56fd5..d737804 100644
--- a/include/uapi/linux/swab.h
+++ b/include/uapi/linux/swab.h
@@ -123,7 +123,7 @@ static inline __attribute_const__ __u32 __fswahb32(__u32 val)
  * @x: value to byteswap
  */
 #ifdef __HAVE_BUILTIN_BSWAP64__
-#define __swab64(x) __builtin_bswap64((__u64)(x))
+#define __swab64(x) (__u64)__builtin_bswap64((__u64)(x))
 #else
 #define __swab64(x)				\
 	(__builtin_constant_p((__u64)(x)) ?	\

-- 
Josh

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2016-04-29  6:45 Stephen Rothwell
@ 2016-04-29  6:55 ` Stephen Rothwell
  2016-04-29 13:32 ` Josh Poimboeuf
  1 sibling, 0 replies; 145+ messages in thread
From: Stephen Rothwell @ 2016-04-29  6:55 UTC (permalink / raw)
  To: Andrew Morton
  Cc: linux-next, linux-kernel, Arnd Bergmann, Josh Poimboeuf, Quinn Tran

Hi All,

On Fri, 29 Apr 2016 16:45:43 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the akpm-current tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
> 
> drivers/scsi/ipr.c: In function 'ipr_show_device_id':
> drivers/scsi/ipr.c:4462:34: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
>    len = snprintf(buf, PAGE_SIZE, "0x%llx\n", be64_to_cpu(res->dev_id));
>                                   ^
> 
> Lots and lots like this :-(
> 
> Introduced by commit
> 
>   eef17fb79096 ("byteswap: try to avoid __builtin_constant_p gcc bug")
> 
> I guess __builtin_bswap64() has type "unsigned long int" :-(

So, I have reverted that commit for today ... it produces too many
warnings :-(

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
@ 2016-04-29  6:45 Stephen Rothwell
  2016-04-29  6:55 ` Stephen Rothwell
  2016-04-29 13:32 ` Josh Poimboeuf
  0 siblings, 2 replies; 145+ messages in thread
From: Stephen Rothwell @ 2016-04-29  6:45 UTC (permalink / raw)
  To: Andrew Morton
  Cc: linux-next, linux-kernel, Arnd Bergmann, Josh Poimboeuf, Quinn Tran

Hi Andrew,

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

drivers/scsi/ipr.c: In function 'ipr_show_device_id':
drivers/scsi/ipr.c:4462:34: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
   len = snprintf(buf, PAGE_SIZE, "0x%llx\n", be64_to_cpu(res->dev_id));
                                  ^

Lots and lots like this :-(

Probably introduced by commit

  eef17fb79096 ("byteswap: try to avoid __builtin_constant_p gcc bug")

I guess __builtin_bswap64() has type "unsigned long int" :-(

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2015-07-16  5:26 Stephen Rothwell
@ 2015-07-16 23:00 ` Andrew Morton
  0 siblings, 0 replies; 145+ messages in thread
From: Andrew Morton @ 2015-07-16 23:00 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: linux-next, linux-kernel, Vladimir Zapolskiy, Greg Kroah-Hartman

On Thu, 16 Jul 2015 15:26:00 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Andrew,
> 
> After merging the akpm-current tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning:
> 
> lib/genalloc.c: In function 'gen_pool_get':
> /scratch/sfr/next/lib/genalloc.c:599:6: warning: passing argument 4 of 'devres_find' discards 'const' qualifier from pointer target type
>   p = devres_find(dev, devm_gen_pool_release, devm_gen_pool_match, name);
>       ^
> In file included from /scratch/sfr/next/include/linux/node.h:17:0,
>                  from /scratch/sfr/next/include/linux/cpu.h:16,
>                  from /scratch/sfr/next/include/linux/of_device.h:4,
>                  from /scratch/sfr/next/lib/genalloc.c:37:
> /scratch/sfr/next/include/linux/device.h:620:14: note: expected 'void *' but argument is of type 'const char *'
>  extern void *devres_find(struct device *dev, dr_release_t release,
>               ^
> 
> Caused by commit
> 
>   e89a70fd54f2 ("genalloc: add support of multiple gen_pools per device")

urgh.  devres_find()'s `void *match' argument should always have been const.

I started to fix that but the fix spreads like a virus - by the time I had a
700 line diff I gave up.

So I guess we cast away the constness at the caller, like all the other
callers do :(

--- a/lib/genalloc.c~genalloc-add-support-of-multiple-gen_pools-per-device-fix
+++ a/lib/genalloc.c
@@ -596,7 +596,8 @@ struct gen_pool *gen_pool_get(struct dev
 {
 	struct gen_pool **p;
 
-	p = devres_find(dev, devm_gen_pool_release, devm_gen_pool_match, name);
+	p = devres_find(dev, devm_gen_pool_release, devm_gen_pool_match,
+			(void *)name);
 	if (!p)
 		return NULL;
 	return *p;
_


^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
@ 2015-07-16  5:26 Stephen Rothwell
  2015-07-16 23:00 ` Andrew Morton
  0 siblings, 1 reply; 145+ messages in thread
From: Stephen Rothwell @ 2015-07-16  5:26 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Vladimir Zapolskiy

Hi Andrew,

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

lib/genalloc.c: In function 'gen_pool_get':
/scratch/sfr/next/lib/genalloc.c:599:6: warning: passing argument 4 of 'devres_find' discards 'const' qualifier from pointer target type
  p = devres_find(dev, devm_gen_pool_release, devm_gen_pool_match, name);
      ^
In file included from /scratch/sfr/next/include/linux/node.h:17:0,
                 from /scratch/sfr/next/include/linux/cpu.h:16,
                 from /scratch/sfr/next/include/linux/of_device.h:4,
                 from /scratch/sfr/next/lib/genalloc.c:37:
/scratch/sfr/next/include/linux/device.h:620:14: note: expected 'void *' but argument is of type 'const char *'
 extern void *devres_find(struct device *dev, dr_release_t release,
              ^

Caused by commit

  e89a70fd54f2 ("genalloc: add support of multiple gen_pools per device")

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2015-06-04 12:29 Stephen Rothwell
@ 2015-06-04 13:56 ` Andrea Arcangeli
  0 siblings, 0 replies; 145+ messages in thread
From: Andrea Arcangeli @ 2015-06-04 13:56 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Andrew Morton, linux-next, linux-kernel

Hello,

On Thu, Jun 04, 2015 at 10:29:28PM +1000, Stephen Rothwell wrote:
> Hi Andrew,
> 
> After merging the akpm-current tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
> 
> ./usr/include/linux/userfaultfd.h:14: found __[us]{8,16,32,64} type without #include <linux/types.h>
> 
> Introduced by commit 2873f48b446c ("userfaultfd: uAPI").

Here's the fix:

===
>From 02b31b0a5e9dd5ddbcb4ad86f63fbcb0a2b5d8f2 Mon Sep 17 00:00:00 2001
From: Andrea Arcangeli <aarcange@redhat.com>
Date: Thu, 4 Jun 2015 14:54:40 +0200
Subject: [PATCH] userfaultfd: uAPI: add missing include/types.h

This will avoid the below warning:

./usr/include/linux/userfaultfd.h:14: found __[us]{8,16,32,64} type
without #include <linux/types.h>

Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
---
 include/uapi/linux/userfaultfd.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/uapi/linux/userfaultfd.h b/include/uapi/linux/userfaultfd.h
index 9a8cd56..09c2e2a 100644
--- a/include/uapi/linux/userfaultfd.h
+++ b/include/uapi/linux/userfaultfd.h
@@ -9,6 +9,8 @@
 #ifndef _LINUX_USERFAULTFD_H
 #define _LINUX_USERFAULTFD_H
 
+#include <linux/types.h>
+
 #define UFFD_API ((__u64)0xAA)
 /* FIXME: add "|UFFD_BIT_WP" to UFFD_API_BITS after implementing it */
 #define UFFD_API_BITS (UFFD_BIT_WRITE)

^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
@ 2015-06-04 12:29 Stephen Rothwell
  2015-06-04 13:56 ` Andrea Arcangeli
  0 siblings, 1 reply; 145+ messages in thread
From: Stephen Rothwell @ 2015-06-04 12:29 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Andrea Arcangeli

[-- Attachment #1: Type: text/plain, Size: 361 bytes --]

Hi Andrew,

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

./usr/include/linux/userfaultfd.h:14: found __[us]{8,16,32,64} type without #include <linux/types.h>

Introduced by commit 2873f48b446c ("userfaultfd: uAPI").

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2015-02-04  7:48 Stephen Rothwell
@ 2015-02-04  7:53 ` Jan Kiszka
  0 siblings, 0 replies; 145+ messages in thread
From: Jan Kiszka @ 2015-02-04  7:53 UTC (permalink / raw)
  To: Stephen Rothwell, Andrew Morton; +Cc: linux-next, linux-kernel

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2015-02-04 08:48, Stephen Rothwell wrote:
> Hi Andrew,
> 
> After merging the akpm-current tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
> 
> warning: (GDB_SCRIPTS) selects DEBUG_INFO which has unmet direct dependencies (DEBUG_KERNEL && !COMPILE_TEST)
> warning: (GDB_SCRIPTS) selects DEBUG_INFO which has unmet direct dependencies (DEBUG_KERNEL && !COMPILE_TEST)
> 
> Introduced by commit 3cf8bb219e44 ("scripts/gdb: add infrastructure").

I've posted a fix earlier today [1]. The Intel test robot informed me
already.

Jan

[1] http://thread.gmane.org/gmane.linux.kernel/1881832

- -- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlTRz/EACgkQitSsb3rl5xS3dQCg1ZPql+9XOcaC/hk7WSztRHDb
6JkAn1XATlgzopMoj9KgpbMApDnkKQYc
=Edbi
-----END PGP SIGNATURE-----

^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
@ 2015-02-04  7:48 Stephen Rothwell
  2015-02-04  7:53 ` Jan Kiszka
  0 siblings, 1 reply; 145+ messages in thread
From: Stephen Rothwell @ 2015-02-04  7:48 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Jan Kiszka

[-- Attachment #1: Type: text/plain, Size: 493 bytes --]

Hi Andrew,

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

warning: (GDB_SCRIPTS) selects DEBUG_INFO which has unmet direct dependencies (DEBUG_KERNEL && !COMPILE_TEST)
warning: (GDB_SCRIPTS) selects DEBUG_INFO which has unmet direct dependencies (DEBUG_KERNEL && !COMPILE_TEST)

Introduced by commit 3cf8bb219e44 ("scripts/gdb: add infrastructure").
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2015-01-19  7:45 Stephen Rothwell
@ 2015-01-19 15:50 ` Chris Mason
  0 siblings, 0 replies; 145+ messages in thread
From: Chris Mason @ 2015-01-19 15:50 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Andrew Morton, linux-next, linux-kernel



On Mon, Jan 19, 2015 at 2:45 AM, Stephen Rothwell 
<sfr@canb.auug.org.au> wrote:
> Hi Andrew,
> 
> After merging the akpm-current tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
> 
> fs/eventfd.c: In function 'eventfd_poll':
> fs/eventfd.c:121:16: warning: unused variable 'flags' 
> [-Wunused-variable]
>   unsigned long flags;
>                 ^
> 
> Introduced by commit a90de8a54127 ("eventfd: don't take the spinlock 
> in
> eventfd_poll").


Whoops, I'll send a v2.

-chris




^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
@ 2015-01-19  7:45 Stephen Rothwell
  2015-01-19 15:50 ` Chris Mason
  0 siblings, 1 reply; 145+ messages in thread
From: Stephen Rothwell @ 2015-01-19  7:45 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Chris Mason

[-- Attachment #1: Type: text/plain, Size: 452 bytes --]

Hi Andrew,

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

fs/eventfd.c: In function 'eventfd_poll':
fs/eventfd.c:121:16: warning: unused variable 'flags' [-Wunused-variable]
  unsigned long flags;
                ^

Introduced by commit a90de8a54127 ("eventfd: don't take the spinlock in
eventfd_poll").

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2014-10-30  5:19 Stephen Rothwell
@ 2014-10-30  9:00 ` Aneesh Kumar K.V
  0 siblings, 0 replies; 145+ messages in thread
From: Aneesh Kumar K.V @ 2014-10-30  9:00 UTC (permalink / raw)
  To: Stephen Rothwell, Andrew Morton; +Cc: linux-next, linux-kernel

Stephen Rothwell <sfr@canb.auug.org.au> writes:

> Hi Andrew,
>
> After merging the akpm tree, today's linux-next build (arm multi_v7_defconfig)
> produced this warning:
>
> In file included from include/linux/mm.h:52:0,
>                  from mm/gup.c:7:
> arch/arm/include/asm/pgtable.h:184:0: warning: "pgd_huge" redefined
>  #define pgd_huge(pgd)  (0)
>  ^
> In file included from mm/gup.c:6:0:
> include/linux/hugetlb.h:183:0: note: this is the location of the previous definition
>  #define pgd_huge(x) 0
>  ^
>
> Introduced by commit fee025d5dd4e ("mm: update generic gup
> implementation to handle hugepage directory").


Should be fixed by.
http://mid.gmane.org/1414570785-18966-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com
IIUC the changes are going via powerpc tree. So not sure how it gets updated.

-aneesh


^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
@ 2014-10-30  5:19 Stephen Rothwell
  2014-10-30  9:00 ` Aneesh Kumar K.V
  0 siblings, 1 reply; 145+ messages in thread
From: Stephen Rothwell @ 2014-10-30  5:19 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Aneesh Kumar K.V

[-- Attachment #1: Type: text/plain, Size: 638 bytes --]

Hi Andrew,

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

In file included from include/linux/mm.h:52:0,
                 from mm/gup.c:7:
arch/arm/include/asm/pgtable.h:184:0: warning: "pgd_huge" redefined
 #define pgd_huge(pgd)  (0)
 ^
In file included from mm/gup.c:6:0:
include/linux/hugetlb.h:183:0: note: this is the location of the previous definition
 #define pgd_huge(x) 0
 ^

Introduced by commit fee025d5dd4e ("mm: update generic gup
implementation to handle hugepage directory").
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2014-09-26 10:42 Stephen Rothwell
@ 2014-09-29 21:30 ` Andrew Morton
  0 siblings, 0 replies; 145+ messages in thread
From: Andrew Morton @ 2014-09-29 21:30 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Marek Szyprowski

On Fri, 26 Sep 2014 20:42:00 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Andrew,
> 
> After merging the akpm tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
> 
> drivers/of/of_reserved_mem.c: In function 'of_reserved_mem_device_init':
> drivers/of/of_reserved_mem.c:253:3: warning: 'return' with no value, in function returning non-void [-Wreturn-type]
>    return;
>    ^
> drivers/of/of_reserved_mem.c:259:3: warning: 'return' with no value, in function returning non-void [-Wreturn-type]
>    return;
>    ^
> 
> Caused by commit 1a29544cc8c9 ("drivers: of: add return value to
> of_reserved_mem_device_init").  This patch changed the return type of a
> function but did not update any or the return statements in that
> function.

OK, thanks, I dropped it.  I could have fixed it but it doesn't appear
to be well tested.


^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
@ 2014-09-26 10:42 Stephen Rothwell
  2014-09-29 21:30 ` Andrew Morton
  0 siblings, 1 reply; 145+ messages in thread
From: Stephen Rothwell @ 2014-09-26 10:42 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Marek Szyprowski

[-- Attachment #1: Type: text/plain, Size: 757 bytes --]

Hi Andrew,

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

drivers/of/of_reserved_mem.c: In function 'of_reserved_mem_device_init':
drivers/of/of_reserved_mem.c:253:3: warning: 'return' with no value, in function returning non-void [-Wreturn-type]
   return;
   ^
drivers/of/of_reserved_mem.c:259:3: warning: 'return' with no value, in function returning non-void [-Wreturn-type]
   return;
   ^

Caused by commit 1a29544cc8c9 ("drivers: of: add return value to
of_reserved_mem_device_init").  This patch changed the return type of a
function but did not update any or the return statements in that
function.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
@ 2014-09-08  8:57 Stephen Rothwell
  0 siblings, 0 replies; 145+ messages in thread
From: Stephen Rothwell @ 2014-09-08  8:57 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Zhang Zhen

[-- Attachment #1: Type: text/plain, Size: 501 bytes --]

Hi Andrew,

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

drivers/base/memory.c: In function 'show_valid_zones':
drivers/base/memory.c:384:22: warning: unused variable 'zone_prev' [-Wunused-variable]
  struct zone *zone, *zone_prev;
                      ^

Introduced by commit 46d9999e7374 ("memory-hotplug: fix not enough
check of valid zones").

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 145+ messages in thread

* Re: linux-next: build warning after merge of the akpm-current tree
  2014-06-20  5:27 Stephen Rothwell
@ 2014-06-20  5:29 ` Yinghai Lu
  0 siblings, 0 replies; 145+ messages in thread
From: Yinghai Lu @ 2014-06-20  5:29 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Andrew Morton, linux-next, Linux Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 385 bytes --]

On Thu, Jun 19, 2014 at 10:27 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Andrew,
>
> After merging the akpm-current tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
>
> Introduced by commit 8d9dfa4b0125 ("initramfs: support initramfs that
> is more than 2G").  Grep is your friend :-(

Please check if attached patch fix the problem.

Yinghai

[-- Attachment #2: fix_uLong_print.patch --]
[-- Type: text/x-patch, Size: 2789 bytes --]

diff --git a/crypto/zlib.c b/crypto/zlib.c
index 06b62e5..c9ee681 100644
--- a/crypto/zlib.c
+++ b/crypto/zlib.c
@@ -168,7 +168,7 @@ static int zlib_compress_update(struct crypto_pcomp *tfm,
 	}
 
 	ret = req->avail_out - stream->avail_out;
-	pr_debug("avail_in %u, avail_out %u (consumed %u, produced %u)\n",
+	pr_debug("avail_in %lu, avail_out %lu (consumed %lu, produced %u)\n",
 		 stream->avail_in, stream->avail_out,
 		 req->avail_in - stream->avail_in, ret);
 	req->next_in = stream->next_in;
@@ -198,7 +198,7 @@ static int zlib_compress_final(struct crypto_pcomp *tfm,
 	}
 
 	ret = req->avail_out - stream->avail_out;
-	pr_debug("avail_in %u, avail_out %u (consumed %u, produced %u)\n",
+	pr_debug("avail_in %lu, avail_out %lu (consumed %lu, produced %u)\n",
 		 stream->avail_in, stream->avail_out,
 		 req->avail_in - stream->avail_in, ret);
 	req->next_in = stream->next_in;
@@ -283,7 +283,7 @@ static int zlib_decompress_update(struct crypto_pcomp *tfm,
 	}
 
 	ret = req->avail_out - stream->avail_out;
-	pr_debug("avail_in %u, avail_out %u (consumed %u, produced %u)\n",
+	pr_debug("avail_in %lu, avail_out %lu (consumed %lu, produced %u)\n",
 		 stream->avail_in, stream->avail_out,
 		 req->avail_in - stream->avail_in, ret);
 	req->next_in = stream->next_in;
@@ -331,7 +331,7 @@ static int zlib_decompress_final(struct crypto_pcomp *tfm,
 	}
 
 	ret = req->avail_out - stream->avail_out;
-	pr_debug("avail_in %u, avail_out %u (consumed %u, produced %u)\n",
+	pr_debug("avail_in %lu, avail_out %lu (consumed %lu, produced %u)\n",
 		 stream->avail_in, stream->avail_out,
 		 req->avail_in - stream->avail_in, ret);
 	req->next_in = stream->next_in;
diff --git a/fs/jffs2/compr_zlib.c b/fs/jffs2/compr_zlib.c
index 0b9a1e4..11ea1ee 100644
--- a/fs/jffs2/compr_zlib.c
+++ b/fs/jffs2/compr_zlib.c
@@ -94,11 +94,11 @@ static int jffs2_zlib_compress(unsigned char *data_in,
 
 	while (def_strm.total_out < *dstlen - STREAM_END_SPACE && def_strm.total_in < *sourcelen) {
 		def_strm.avail_out = *dstlen - (def_strm.total_out + STREAM_END_SPACE);
-		def_strm.avail_in = min((unsigned)(*sourcelen-def_strm.total_in), def_strm.avail_out);
-		jffs2_dbg(1, "calling deflate with avail_in %d, avail_out %d\n",
+		def_strm.avail_in = min((unsigned long)(*sourcelen-def_strm.total_in), def_strm.avail_out);
+		jffs2_dbg(1, "calling deflate with avail_in %ld, avail_out %ld\n",
 			  def_strm.avail_in, def_strm.avail_out);
 		ret = zlib_deflate(&def_strm, Z_PARTIAL_FLUSH);
-		jffs2_dbg(1, "deflate returned with avail_in %d, avail_out %d, total_in %ld, total_out %ld\n",
+		jffs2_dbg(1, "deflate returned with avail_in %ld, avail_out %ld, total_in %ld, total_out %ld\n",
 			  def_strm.avail_in, def_strm.avail_out,
 			  def_strm.total_in, def_strm.total_out);
 		if (ret != Z_OK) {

^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
@ 2014-06-20  5:27 Stephen Rothwell
  2014-06-20  5:29 ` Yinghai Lu
  0 siblings, 1 reply; 145+ messages in thread
From: Stephen Rothwell @ 2014-06-20  5:27 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Yinghai Lu

[-- Attachment #1: Type: text/plain, Size: 8538 bytes --]

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:257:0,
                 from include/linux/kernel.h:13,
                 from arch/x86/include/asm/percpu.h:44,
                 from arch/x86/include/asm/preempt.h:5,
                 from include/linux/preempt.h:18,
                 from include/linux/spinlock.h:50,
                 from include/linux/seqlock.h:35,
                 from include/linux/time.h:5,
                 from include/linux/stat.h:18,
                 from include/linux/module.h:10,
                 from crypto/zlib.c:26:
crypto/zlib.c: In function 'zlib_compress_update':
include/linux/dynamic_debug.h:64:16: warning: format '%u' expects argument of type 'unsigned int', but argument 4 has type 'uLong' [-Wformat=]
  static struct _ddebug  __aligned(8)   \
                ^
include/linux/dynamic_debug.h:76:2: note: in expansion of macro 'DEFINE_DYNAMIC_DEBUG_METADATA'
  DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt);  \
  ^
include/linux/printk.h:263:2: note: in expansion of macro 'dynamic_pr_debug'
  dynamic_pr_debug(fmt, ##__VA_ARGS__)
  ^
crypto/zlib.c:171:2: note: in expansion of macro 'pr_debug'
  pr_debug("avail_in %u, avail_out %u (consumed %u, produced %u)\n",
  ^
include/linux/dynamic_debug.h:64:16: warning: format '%u' expects argument of type 'unsigned int', but argument 5 has type 'uLong' [-Wformat=]
  static struct _ddebug  __aligned(8)   \
                ^
include/linux/dynamic_debug.h:76:2: note: in expansion of macro 'DEFINE_DYNAMIC_DEBUG_METADATA'
  DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt);  \
  ^
include/linux/printk.h:263:2: note: in expansion of macro 'dynamic_pr_debug'
  dynamic_pr_debug(fmt, ##__VA_ARGS__)
  ^
crypto/zlib.c:171:2: note: in expansion of macro 'pr_debug'
  pr_debug("avail_in %u, avail_out %u (consumed %u, produced %u)\n",
  ^
include/linux/dynamic_debug.h:64:16: warning: format '%u' expects argument of type 'unsigned int', but argument 6 has type 'uLong' [-Wformat=]
  static struct _ddebug  __aligned(8)   \
                ^
include/linux/dynamic_debug.h:76:2: note: in expansion of macro 'DEFINE_DYNAMIC_DEBUG_METADATA'
  DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt);  \
  ^
include/linux/printk.h:263:2: note: in expansion of macro 'dynamic_pr_debug'
  dynamic_pr_debug(fmt, ##__VA_ARGS__)
  ^
crypto/zlib.c:171:2: note: in expansion of macro 'pr_debug'
  pr_debug("avail_in %u, avail_out %u (consumed %u, produced %u)\n",
  ^
crypto/zlib.c: In function 'zlib_compress_final':
include/linux/dynamic_debug.h:64:16: warning: format '%u' expects argument of type 'unsigned int', but argument 4 has type 'uLong' [-Wformat=]
  static struct _ddebug  __aligned(8)   \
                ^
include/linux/dynamic_debug.h:76:2: note: in expansion of macro 'DEFINE_DYNAMIC_DEBUG_METADATA'
  DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt);  \
  ^
include/linux/printk.h:263:2: note: in expansion of macro 'dynamic_pr_debug'
  dynamic_pr_debug(fmt, ##__VA_ARGS__)
  ^
crypto/zlib.c:201:2: note: in expansion of macro 'pr_debug'
  pr_debug("avail_in %u, avail_out %u (consumed %u, produced %u)\n",
  ^
include/linux/dynamic_debug.h:64:16: warning: format '%u' expects argument of type 'unsigned int', but argument 5 has type 'uLong' [-Wformat=]
  static struct _ddebug  __aligned(8)   \
                ^
include/linux/dynamic_debug.h:76:2: note: in expansion of macro 'DEFINE_DYNAMIC_DEBUG_METADATA'
  DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt);  \
  ^
include/linux/printk.h:263:2: note: in expansion of macro 'dynamic_pr_debug'
  dynamic_pr_debug(fmt, ##__VA_ARGS__)
  ^
crypto/zlib.c:201:2: note: in expansion of macro 'pr_debug'
  pr_debug("avail_in %u, avail_out %u (consumed %u, produced %u)\n",
  ^
include/linux/dynamic_debug.h:64:16: warning: format '%u' expects argument of type 'unsigned int', but argument 6 has type 'uLong' [-Wformat=]
  static struct _ddebug  __aligned(8)   \
                ^
include/linux/dynamic_debug.h:76:2: note: in expansion of macro 'DEFINE_DYNAMIC_DEBUG_METADATA'
  DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt);  \
  ^
include/linux/printk.h:263:2: note: in expansion of macro 'dynamic_pr_debug'
  dynamic_pr_debug(fmt, ##__VA_ARGS__)
  ^
crypto/zlib.c:201:2: note: in expansion of macro 'pr_debug'
  pr_debug("avail_in %u, avail_out %u (consumed %u, produced %u)\n",
  ^
crypto/zlib.c: In function 'zlib_decompress_update':
include/linux/dynamic_debug.h:64:16: warning: format '%u' expects argument of type 'unsigned int', but argument 4 has type 'uLong' [-Wformat=]
  static struct _ddebug  __aligned(8)   \
                ^
include/linux/dynamic_debug.h:76:2: note: in expansion of macro 'DEFINE_DYNAMIC_DEBUG_METADATA'
  DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt);  \
  ^
include/linux/printk.h:263:2: note: in expansion of macro 'dynamic_pr_debug'
  dynamic_pr_debug(fmt, ##__VA_ARGS__)
  ^
crypto/zlib.c:286:2: note: in expansion of macro 'pr_debug'
  pr_debug("avail_in %u, avail_out %u (consumed %u, produced %u)\n",
  ^
include/linux/dynamic_debug.h:64:16: warning: format '%u' expects argument of type 'unsigned int', but argument 5 has type 'uLong' [-Wformat=]
  static struct _ddebug  __aligned(8)   \
                ^
include/linux/dynamic_debug.h:76:2: note: in expansion of macro 'DEFINE_DYNAMIC_DEBUG_METADATA'
  DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt);  \
  ^
include/linux/printk.h:263:2: note: in expansion of macro 'dynamic_pr_debug'
  dynamic_pr_debug(fmt, ##__VA_ARGS__)
  ^
crypto/zlib.c:286:2: note: in expansion of macro 'pr_debug'
  pr_debug("avail_in %u, avail_out %u (consumed %u, produced %u)\n",
  ^
include/linux/dynamic_debug.h:64:16: warning: format '%u' expects argument of type 'unsigned int', but argument 6 has type 'uLong' [-Wformat=]
  static struct _ddebug  __aligned(8)   \
                ^
include/linux/dynamic_debug.h:76:2: note: in expansion of macro 'DEFINE_DYNAMIC_DEBUG_METADATA'
  DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt);  \
  ^
include/linux/printk.h:263:2: note: in expansion of macro 'dynamic_pr_debug'
  dynamic_pr_debug(fmt, ##__VA_ARGS__)
  ^
crypto/zlib.c:286:2: note: in expansion of macro 'pr_debug'
  pr_debug("avail_in %u, avail_out %u (consumed %u, produced %u)\n",
  ^
crypto/zlib.c: In function 'zlib_decompress_final':
include/linux/dynamic_debug.h:64:16: warning: format '%u' expects argument of type 'unsigned int', but argument 4 has type 'uLong' [-Wformat=]
  static struct _ddebug  __aligned(8)   \
                ^
include/linux/dynamic_debug.h:76:2: note: in expansion of macro 'DEFINE_DYNAMIC_DEBUG_METADATA'
  DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt);  \
  ^
include/linux/printk.h:263:2: note: in expansion of macro 'dynamic_pr_debug'
  dynamic_pr_debug(fmt, ##__VA_ARGS__)
  ^
crypto/zlib.c:334:2: note: in expansion of macro 'pr_debug'
  pr_debug("avail_in %u, avail_out %u (consumed %u, produced %u)\n",
  ^
include/linux/dynamic_debug.h:64:16: warning: format '%u' expects argument of type 'unsigned int', but argument 5 has type 'uLong' [-Wformat=]
  static struct _ddebug  __aligned(8)   \
                ^
include/linux/dynamic_debug.h:76:2: note: in expansion of macro 'DEFINE_DYNAMIC_DEBUG_METADATA'
  DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt);  \
  ^
include/linux/printk.h:263:2: note: in expansion of macro 'dynamic_pr_debug'
  dynamic_pr_debug(fmt, ##__VA_ARGS__)
  ^
crypto/zlib.c:334:2: note: in expansion of macro 'pr_debug'
  pr_debug("avail_in %u, avail_out %u (consumed %u, produced %u)\n",
  ^
include/linux/dynamic_debug.h:64:16: warning: format '%u' expects argument of type 'unsigned int', but argument 6 has type 'uLong' [-Wformat=]
  static struct _ddebug  __aligned(8)   \
                ^
include/linux/dynamic_debug.h:76:2: note: in expansion of macro 'DEFINE_DYNAMIC_DEBUG_METADATA'
  DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt);  \
  ^
include/linux/printk.h:263:2: note: in expansion of macro 'dynamic_pr_debug'
  dynamic_pr_debug(fmt, ##__VA_ARGS__)
  ^
crypto/zlib.c:334:2: note: in expansion of macro 'pr_debug'
  pr_debug("avail_in %u, avail_out %u (consumed %u, produced %u)\n",
  ^


Introduced by commit 8d9dfa4b0125 ("initramfs: support initramfs that
is more than 2G").  Grep is your friend :-(

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 145+ messages in thread

* linux-next: build warning after merge of the akpm-current tree
@ 2014-06-16  1:57 Stephen Rothwell
  0 siblings, 0 replies; 145+ messages in thread
From: Stephen Rothwell @ 2014-06-16  1:57 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Naoya Horiguchi

[-- Attachment #1: Type: text/plain, Size: 1710 bytes --]

Hi Andrew,

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

In file included from arch/powerpc/include/asm/mmu-hash64.h:23:0,
                 from arch/powerpc/include/asm/mmu.h:197,
                 from arch/powerpc/include/asm/lppaca.h:36,
                 from arch/powerpc/include/asm/paca.h:20,
                 from arch/powerpc/include/asm/hw_irq.h:41,
                 from arch/powerpc/include/asm/irqflags.h:11,
                 from include/linux/irqflags.h:15,
                 from include/linux/spinlock.h:53,
                 from include/linux/mmzone.h:7,
                 from include/linux/gfp.h:5,
                 from include/linux/mm.h:9,
                 from include/linux/mman.h:4,
                 from mm/madvise.c:8:
mm/madvise.c: In function 'swapin_walk_pte_entry':
arch/powerpc/include/asm/pgtable-ppc64.h:183:3: warning: statement with no effect [-Wunused-value]
   (((pte_t *) pmd_page_vaddr(*(dir))) + (((addr) >> PAGE_SHIFT) & (PTRS_PER_PTE - 1)))
   ^
arch/powerpc/include/asm/pgtable-ppc64.h:185:34: note: in expansion of macro 'pte_offset_kernel'
 #define pte_offset_map(dir,addr) pte_offset_kernel((dir), (addr))
                                  ^
mm/madvise.c:161:2: note: in expansion of macro 'pte_offset_map'
  pte_offset_map(walk->pmd, start & PMD_MASK);
  ^
mm/madvise.c:145:9: warning: unused variable 'orig_pte' [-Wunused-variable]
  pte_t *orig_pte = pte - ((start & (PMD_SIZE - 1)) >> PAGE_SHIFT);
         ^

Introduced by commit 17336ae3d58a ("madvise: cleanup swapin_walk_pmd_entry()")
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 145+ messages in thread

end of thread, other threads:[~2021-11-23 22:30 UTC | newest]

Thread overview: 145+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-07-31  6:11 linux-next: build warning after merge of the akpm-current tree Stephen Rothwell
2019-07-31  6:28 ` Miles Chen
2019-08-01  5:51   ` Stephen Rothwell
2019-08-01  6:15     ` Michal Hocko
2019-08-01  6:30       ` Miles Chen
2019-08-01  6:38         ` Michal Hocko
2019-08-01  6:39         ` Stephen Rothwell
2019-08-01  6:42           ` Miles Chen
  -- strict thread matches above, loose matches on Subject: below --
2021-11-23  5:26 Stephen Rothwell
2021-11-23  8:38 ` Suren Baghdasaryan
2021-11-23 19:03   ` Suren Baghdasaryan
2021-11-23 22:26     ` Stephen Rothwell
2021-11-23 22:30       ` Suren Baghdasaryan
2021-07-19  7:52 Stephen Rothwell
2021-07-19  8:47 ` Feng Tang
2021-05-21  5:39 Stephen Rothwell
2021-05-21  6:53 ` Miaohe Lin
2021-03-30 20:04 Stephen Rothwell
2021-03-15  5:35 Stephen Rothwell
2021-03-16 18:18 ` Minchan Kim
2021-03-16 21:49   ` Stephen Rothwell
2021-03-16 23:09     ` Jonathan Corbet
2021-03-17 13:22       ` Mauro Carvalho Chehab
2020-12-10  9:38 Stephen Rothwell
2020-12-10 16:05 ` Georgi Djakov
2020-11-13  6:01 Stephen Rothwell
2020-11-16 10:03 ` Andy Shevchenko
2020-11-06  6:26 Stephen Rothwell
2020-11-05  6:45 Stephen Rothwell
2020-11-05  7:03 ` Mike Rapoport
2020-11-05  7:42   ` Anand K. Mistry
2020-11-05  7:45     ` Anand K. Mistry
2020-11-05  9:17       ` Mike Rapoport
2020-11-05  8:00     ` Stephen Rothwell
2020-11-05  8:03       ` Stephen Rothwell
2020-09-14  7:00 Stephen Rothwell
2020-09-15  4:03 ` David Gow
2020-09-15  4:16   ` Stephen Rothwell
2020-09-15  9:57   ` Marco Elver
2020-09-14  6:57 Stephen Rothwell
2020-07-17 10:31 Stephen Rothwell
2020-07-17 17:47 ` Roman Gushchin
2020-07-09  9:11 Stephen Rothwell
2020-06-21 14:40 Stephen Rothwell
2020-03-31  8:56 Stephen Rothwell
2020-04-01 22:58 ` Andrew Morton
2020-04-01 23:00   ` Jason Gunthorpe
2020-04-01 23:06     ` Mike Kravetz
2020-03-13 10:42 Stephen Rothwell
2020-03-13 10:55 ` Baoquan He
2020-03-13 12:56 ` Baoquan He
2020-03-14  0:09   ` Stephen Rothwell
2020-03-14  0:35     ` Baoquan He
2020-03-16  4:58 ` Baoquan He
2020-03-16  6:13   ` Stephen Rothwell
2020-03-16  6:51     ` Baoquan He
2020-03-16  6:54     ` Stephen Rothwell
2020-03-12  7:31 Stephen Rothwell
2020-03-12 16:48 ` Mike Kravetz
2020-03-12  7:27 Stephen Rothwell
2020-03-13  0:31 ` Andrew Morton
2020-03-05  5:37 Stephen Rothwell
2020-03-05  5:54 ` Dmitry Vyukov
2020-03-07  5:03   ` Walter Wu
2020-03-05  8:54 ` Walter Wu
2020-03-05  9:33   ` Stephen Rothwell
2020-03-06 18:59     ` Walter Wu
2020-03-06 20:45       ` Walter Wu
2020-02-17  2:00 Stephen Rothwell
2019-11-06  7:05 Stephen Rothwell
2019-11-06  7:52 ` Shaokun Zhang
2019-11-06  6:54 Stephen Rothwell
2019-08-07  8:00 Stephen Rothwell
2019-08-07 11:29 ` Rikard Falkeborn
2019-08-07 23:31   ` Stephen Rothwell
2019-07-31  6:16 Stephen Rothwell
2019-07-31 12:01 ` Jia-Ju Bai
2019-07-29  3:48 Stephen Rothwell
2019-07-29  3:44 Stephen Rothwell
2019-05-30  4:55 Stephen Rothwell
2019-05-30  9:02 ` Matteo Croce
2019-03-29  2:39 Stephen Rothwell
2019-04-16  6:52 ` Stephen Rothwell
2019-04-16 22:45   ` Andrew Morton
2019-01-31  5:01 Stephen Rothwell
2018-06-08  4:45 Stephen Rothwell
2018-05-04  4:17 Stephen Rothwell
2018-05-04 15:39 ` Randy Dunlap
2018-05-07 14:10   ` Minchan Kim
2018-05-07 16:47     ` Randy Dunlap
2018-05-08 10:48       ` Minchan Kim
2018-04-06  4:53 Stephen Rothwell
2018-01-02  7:04 Stephen Rothwell
2017-12-15  2:48 Stephen Rothwell
2017-11-23  2:01 Stephen Rothwell
2017-11-13  5:54 Stephen Rothwell
2017-11-13  5:42 Stephen Rothwell
2017-11-13  8:09 ` Michal Hocko
2017-11-13  8:23   ` Michal Hocko
2017-11-13 11:43   ` Arnd Bergmann
2017-11-13 11:54     ` Michal Hocko
2017-11-13 12:24       ` Arnd Bergmann
2017-11-13 12:29       ` Michal Hocko
2017-11-16 22:44     ` Stephen Rothwell
2017-11-17  3:53       ` Stephen Rothwell
2017-11-17  9:36         ` Zhangshaokun
2017-11-17  9:56         ` Arnd Bergmann
2017-08-01  5:22 Stephen Rothwell
2017-05-26  2:43 Stephen Rothwell
2017-05-26 10:16 ` Jeff Layton
2017-05-26 11:28   ` Dave Kleikamp
2017-05-19  4:44 Stephen Rothwell
2017-05-15  1:56 Stephen Rothwell
2017-05-15  4:02 ` Xunlei Pang
2017-05-15  5:07   ` Stephen Rothwell
2017-02-02  6:49 Stephen Rothwell
2016-11-09  4:10 Stephen Rothwell
2016-11-09  7:18 ` Huang Shijie
2016-11-09 21:21   ` Andrew Morton
2016-11-10  2:56     ` Stephen Rothwell
2016-06-23  6:53 Stephen Rothwell
2016-06-23 14:00 ` Mel Gorman
2016-05-27  3:07 Stephen Rothwell
2016-05-27 19:53 ` Andrew Morton
2016-04-29  6:45 Stephen Rothwell
2016-04-29  6:55 ` Stephen Rothwell
2016-04-29 13:32 ` Josh Poimboeuf
2016-04-29 14:03   ` Josh Poimboeuf
2016-04-30  5:52     ` Stephen Rothwell
2015-07-16  5:26 Stephen Rothwell
2015-07-16 23:00 ` Andrew Morton
2015-06-04 12:29 Stephen Rothwell
2015-06-04 13:56 ` Andrea Arcangeli
2015-02-04  7:48 Stephen Rothwell
2015-02-04  7:53 ` Jan Kiszka
2015-01-19  7:45 Stephen Rothwell
2015-01-19 15:50 ` Chris Mason
2014-10-30  5:19 Stephen Rothwell
2014-10-30  9:00 ` Aneesh Kumar K.V
2014-09-26 10:42 Stephen Rothwell
2014-09-29 21:30 ` Andrew Morton
2014-09-08  8:57 Stephen Rothwell
2014-06-20  5:27 Stephen Rothwell
2014-06-20  5:29 ` Yinghai Lu
2014-06-16  1:57 Stephen Rothwell

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).