Linux-Next Archive on lore.kernel.org
 help / color / Atom feed
* linux-next: build failure after merge of the akpm-current tree
@ 2019-08-30 13:55 Stephen Rothwell
  2019-08-30 14:28 ` Jason Gunthorpe
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2019-08-30 13:55 UTC (permalink / raw)
  To: Andrew Morton, Jason Gunthorpe
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Christoph Hellwig, Minchan Kim

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

Hi all,

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

mm/madvise.c: In function 'madvise_cold_page_range':
mm/madvise.c:459:4: error: 'struct mm_walk' has no member named 'pmd_entry'
  459 |   .pmd_entry = madvise_cold_or_pageout_pte_range,
      |    ^~~~~~~~~
mm/madvise.c:459:16: error: initialization of 'const struct mm_walk_ops *' from incompatible pointer type 'int (*)(pmd_t *, long unsigned int,  long unsigned int,  struct mm_walk *)' {aka 'int (*)(unsigned int *, long unsigned int,  long unsigned int,  struct mm_walk *)'} [-Werror=incompatible-pointer-types]
  459 |   .pmd_entry = madvise_cold_or_pageout_pte_range,
      |                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
mm/madvise.c:459:16: note: (near initialization for 'cold_walk.ops')
mm/madvise.c:465:18: warning: passing argument 1 of 'walk_page_range' makes pointer from integer without a cast [-Wint-conversion]
  465 |  walk_page_range(addr, end, &cold_walk);
      |                  ^~~~
      |                  |
      |                  long unsigned int
In file included from mm/madvise.c:24:
include/linux/pagewalk.h:60:39: note: expected 'struct mm_struct *' but argument is of type 'long unsigned int'
   60 | int walk_page_range(struct mm_struct *mm, unsigned long start,
      |                     ~~~~~~~~~~~~~~~~~~^~
mm/madvise.c:465:29: warning: passing argument 3 of 'walk_page_range' makes integer from pointer without a cast [-Wint-conversion]
  465 |  walk_page_range(addr, end, &cold_walk);
      |                             ^~~~~~~~~~
      |                             |
      |                             struct mm_walk *
In file included from mm/madvise.c:24:
include/linux/pagewalk.h:61:17: note: expected 'long unsigned int' but argument is of type 'struct mm_walk *'
   61 |   unsigned long end, const struct mm_walk_ops *ops,
      |   ~~~~~~~~~~~~~~^~~
mm/madvise.c:465:2: error: too few arguments to function 'walk_page_range'
  465 |  walk_page_range(addr, end, &cold_walk);
      |  ^~~~~~~~~~~~~~~
In file included from mm/madvise.c:24:
include/linux/pagewalk.h:60:5: note: declared here
   60 | int walk_page_range(struct mm_struct *mm, unsigned long start,
      |     ^~~~~~~~~~~~~~~
mm/madvise.c: In function 'madvise_pageout_page_range':
mm/madvise.c:498:4: error: 'struct mm_walk' has no member named 'pmd_entry'
  498 |   .pmd_entry = madvise_cold_or_pageout_pte_range,
      |    ^~~~~~~~~
mm/madvise.c:498:16: error: initialization of 'const struct mm_walk_ops *' from incompatible pointer type 'int (*)(pmd_t *, long unsigned int,  long unsigned int,  struct mm_walk *)' {aka 'int (*)(unsigned int *, long unsigned int,  long unsigned int,  struct mm_walk *)'} [-Werror=incompatible-pointer-types]
  498 |   .pmd_entry = madvise_cold_or_pageout_pte_range,
      |                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
mm/madvise.c:498:16: note: (near initialization for 'pageout_walk.ops')
mm/madvise.c:504:18: warning: passing argument 1 of 'walk_page_range' makes pointer from integer without a cast [-Wint-conversion]
  504 |  walk_page_range(addr, end, &pageout_walk);
      |                  ^~~~
      |                  |
      |                  long unsigned int
In file included from mm/madvise.c:24:
include/linux/pagewalk.h:60:39: note: expected 'struct mm_struct *' but argument is of type 'long unsigned int'
   60 | int walk_page_range(struct mm_struct *mm, unsigned long start,
      |                     ~~~~~~~~~~~~~~~~~~^~
mm/madvise.c:504:29: warning: passing argument 3 of 'walk_page_range' makes integer from pointer without a cast [-Wint-conversion]
  504 |  walk_page_range(addr, end, &pageout_walk);
      |                             ^~~~~~~~~~~~~
      |                             |
      |                             struct mm_walk *
In file included from mm/madvise.c:24:
include/linux/pagewalk.h:61:17: note: expected 'long unsigned int' but argument is of type 'struct mm_walk *'
   61 |   unsigned long end, const struct mm_walk_ops *ops,
      |   ~~~~~~~~~~~~~~^~~
mm/madvise.c:504:2: error: too few arguments to function 'walk_page_range'
  504 |  walk_page_range(addr, end, &pageout_walk);
      |  ^~~~~~~~~~~~~~~
In file included from mm/madvise.c:24:
include/linux/pagewalk.h:60:5: note: declared here
   60 | int walk_page_range(struct mm_struct *mm, unsigned long start,
      |     ^~~~~~~~~~~~~~~

Caused by commit

  1c8999b3963d ("mm: introduce MADV_COLD")
(and following commits)

interacting with commit

  923bfc561e75 ("pagewalk: separate function pointers from iterator data")

from the hmm tree.

I have applied the following patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 30 Aug 2019 23:39:37 +1000
Subject: [PATCH] mm: merge fix for "pagewalk: separate function pointers from iterator data"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 mm/madvise.c | 24 ++++++++++--------------
 1 file changed, 10 insertions(+), 14 deletions(-)

diff --git a/mm/madvise.c b/mm/madvise.c
index 7ec7c8f6d5ab..20598df8360a 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -446,6 +446,10 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
 	return 0;
 }
 
+static const struct mm_walk_ops cold_walk_ops = {
+	.pmd_entry = madvise_cold_or_pageout_pte_range,
+};
+
 static void madvise_cold_page_range(struct mmu_gather *tlb,
 			     struct vm_area_struct *vma,
 			     unsigned long addr, unsigned long end)
@@ -455,14 +459,8 @@ static void madvise_cold_page_range(struct mmu_gather *tlb,
 		.pageout = false,
 	};
 
-	struct mm_walk cold_walk = {
-		.pmd_entry = madvise_cold_or_pageout_pte_range,
-		.mm = vma->vm_mm,
-		.private = &walk_private,
-	};
-
 	tlb_start_vma(tlb, vma);
-	walk_page_range(addr, end, &cold_walk);
+	walk_page_range(vma->vm_mm, addr, end, &cold_walk_ops, &walk_private);
 	tlb_end_vma(tlb, vma);
 }
 
@@ -485,6 +483,10 @@ static long madvise_cold(struct vm_area_struct *vma,
 	return 0;
 }
 
+static const struct mm_walk_ops pageout_walk_ops = {
+	.pmd_entry = madvise_cold_or_pageout_pte_range,
+};
+
 static void madvise_pageout_page_range(struct mmu_gather *tlb,
 			     struct vm_area_struct *vma,
 			     unsigned long addr, unsigned long end)
@@ -494,14 +496,8 @@ static void madvise_pageout_page_range(struct mmu_gather *tlb,
 		.tlb = tlb,
 	};
 
-	struct mm_walk pageout_walk = {
-		.pmd_entry = madvise_cold_or_pageout_pte_range,
-		.mm = vma->vm_mm,
-		.private = &walk_private,
-	};
-
 	tlb_start_vma(tlb, vma);
-	walk_page_range(addr, end, &pageout_walk);
+	walk_page_range(vma->vm_mm, addr, end, &pageout_walk_ops, &walk_private);
 	tlb_end_vma(tlb, vma);
 }
 
-- 
2.23.0.rc1

-- 
Cheers,
Stephen Rothwell

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

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2019-08-30 13:55 linux-next: build failure after merge of the akpm-current tree Stephen Rothwell
@ 2019-08-30 14:28 ` Jason Gunthorpe
  0 siblings, 0 replies; 330+ messages in thread
From: Jason Gunthorpe @ 2019-08-30 14:28 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Linux Next Mailing List,
	Linux Kernel Mailing List, Christoph Hellwig, Minchan Kim

On Fri, Aug 30, 2019 at 11:55:30PM +1000, Stephen Rothwell wrote:

> Caused by commit
> 
>   1c8999b3963d ("mm: introduce MADV_COLD")
> (and following commits)
> 
> interacting with commit
> 
>   923bfc561e75 ("pagewalk: separate function pointers from iterator data")
> 
> from the hmm tree.

Yes, this is expected thanks

> diff --git a/mm/madvise.c b/mm/madvise.c
> index 7ec7c8f6d5ab..20598df8360a 100644
> --- a/mm/madvise.c
> +++ b/mm/madvise.c
> @@ -446,6 +446,10 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
>  	return 0;
>  }
>  
> +static const struct mm_walk_ops cold_walk_ops = {
> +	.pmd_entry = madvise_cold_or_pageout_pte_range,
> +};
> +

> +static const struct mm_walk_ops pageout_walk_ops = {
> +	.pmd_entry = madvise_cold_or_pageout_pte_range,
> +};

These two can be shared

Looks OK otherwise

Jason

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2019-08-16 12:16 Stephen Rothwell
@ 2019-08-16 14:00 ` Catalin Marinas
  0 siblings, 0 replies; 330+ messages in thread
From: Catalin Marinas @ 2019-08-16 14:00 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Linux Next Mailing List, Linux Kernel Mailing List

On Fri, Aug 16, 2019 at 10:16:03PM +1000, Stephen Rothwell wrote:
> After merging the akpm-current tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> mm/kmemleak.c: In function 'kmemleak_disable':
> mm/kmemleak.c:1884:2: error: 'kmemleak_early_log' undeclared (first use in this function); did you mean 'kmemleak_alloc'?
>   kmemleak_early_log = 0;
>   ^~~~~~~~~~~~~~~~~~
>   kmemleak_alloc
> mm/kmemleak.c:1884:2: note: each undeclared identifier is reported only once for each function it appears in
> 
> Caused by commit
> 
>   fcf3a5b62f43 ("mm: kmemleak: disable early logging in case of error")
> 
> from Linus' tree mismerging with commits
> 
>   bce40af67cba ("mm: kmemleak: disable early logging in case of error")
>   c405460afc4a ("mm: kmemleak: use the memory pool for early allocations")
> 
> from the akpm-current tree.
> 
> I just removed the above line again (as was dome in the last commit
> above).

Thanks. Commit c405460 should remove all traces of kmemleak_early_log
from current Linus' tree but somehow during merging in -next the line
reappeared.

-- 
Catalin

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

* linux-next: build failure after merge of the akpm-current tree
@ 2019-08-16 12:16 Stephen Rothwell
  2019-08-16 14:00 ` Catalin Marinas
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2019-08-16 12:16 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Catalin Marinas

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

Hi all,

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

mm/kmemleak.c: In function 'kmemleak_disable':
mm/kmemleak.c:1884:2: error: 'kmemleak_early_log' undeclared (first use in this function); did you mean 'kmemleak_alloc'?
  kmemleak_early_log = 0;
  ^~~~~~~~~~~~~~~~~~
  kmemleak_alloc
mm/kmemleak.c:1884:2: note: each undeclared identifier is reported only once for each function it appears in

Caused by commit

  fcf3a5b62f43 ("mm: kmemleak: disable early logging in case of error")

from Linus' tree mismerging with commits

  bce40af67cba ("mm: kmemleak: disable early logging in case of error")
  c405460afc4a ("mm: kmemleak: use the memory pool for early allocations")

from the akpm-current tree.

I just removed the above line again (as was dome in the last commit
above).

-- 
Cheers,
Stephen Rothwell

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

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2019-08-07  7:24 Stephen Rothwell
@ 2019-08-07 14:39 ` Song Liu
  0 siblings, 0 replies; 330+ messages in thread
From: Song Liu @ 2019-08-07 14:39 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Linux Next Mailing List, Linux Kernel Mailing List

Hi Stephen, 

> On Aug 7, 2019, at 12:24 AM, 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) failed like this:
> 
> In file included from include/linux/kernel.h:11,
>                 from kernel/events/uprobes.c:12:
> kernel/events/uprobes.c: In function 'uprobe_write_opcode':
> include/linux/compiler.h:350:38: error: call to '__compiletime_assert_557' declared with attribute error: BUILD_BUG failed
>  _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
>                                      ^
> include/linux/compiler.h:331:4: note: in definition of macro '__compiletime_assert'
>    prefix ## suffix();    \
>    ^~~~~~
> include/linux/compiler.h:350:2: note: in expansion of macro '_compiletime_assert'
>  _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
>  ^~~~~~~~~~~~~~~~~~~
> include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert'
> #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
>                                     ^~~~~~~~~~~~~~~~~~
> include/linux/build_bug.h:59:21: note: in expansion of macro 'BUILD_BUG_ON_MSG'
> #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
>                     ^~~~~~~~~~~~~~~~
> include/linux/huge_mm.h:272:27: note: in expansion of macro 'BUILD_BUG'
> #define HPAGE_PMD_MASK ({ BUILD_BUG(); 0; })
>                           ^~~~~~~~~
> kernel/events/uprobes.c:557:39: note: in expansion of macro 'HPAGE_PMD_MASK'
>   collapse_pte_mapped_thp(mm, vaddr & HPAGE_PMD_MASK);
>                                       ^~~~~~~~~~~~~~
> 
> Caused by commit
> 
>  9cc0b998b380 ("uprobe: collapse THP pmd after removing all uprobes")
> 
> I have reverted that commit for today.

Thanks for the heads-up. 

This looks like v3 of the patchset. I have fixed this issue in v4:

https://lkml.org/lkml/2019/8/2/1587
https://lkml.org/lkml/2019/8/2/1588
https://lkml.org/lkml/2019/8/2/1589

Is this sufficient? Or shall I submit fixes on top of v3?

Thanks,
Song




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

* linux-next: build failure after merge of the akpm-current tree
@ 2019-08-07  7:24 Stephen Rothwell
  2019-08-07 14:39 ` Song Liu
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2019-08-07  7:24 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Song Liu

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

Hi all,

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

In file included from include/linux/kernel.h:11,
                 from kernel/events/uprobes.c:12:
kernel/events/uprobes.c: In function 'uprobe_write_opcode':
include/linux/compiler.h:350:38: error: call to '__compiletime_assert_557' declared with attribute error: BUILD_BUG failed
  _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
                                      ^
include/linux/compiler.h:331:4: note: in definition of macro '__compiletime_assert'
    prefix ## suffix();    \
    ^~~~~~
include/linux/compiler.h:350:2: note: in expansion of macro '_compiletime_assert'
  _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
  ^~~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert'
 #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
                                     ^~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:59:21: note: in expansion of macro 'BUILD_BUG_ON_MSG'
 #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
                     ^~~~~~~~~~~~~~~~
include/linux/huge_mm.h:272:27: note: in expansion of macro 'BUILD_BUG'
 #define HPAGE_PMD_MASK ({ BUILD_BUG(); 0; })
                           ^~~~~~~~~
kernel/events/uprobes.c:557:39: note: in expansion of macro 'HPAGE_PMD_MASK'
   collapse_pte_mapped_thp(mm, vaddr & HPAGE_PMD_MASK);
                                       ^~~~~~~~~~~~~~

Caused by commit

  9cc0b998b380 ("uprobe: collapse THP pmd after removing all uprobes")

I have reverted that commit for today.

-- 
Cheers,
Stephen Rothwell

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

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

* linux-next: build failure after merge of the akpm-current tree
@ 2019-07-26  4:27 Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2019-07-26  4:27 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Minchan Kim,
	Michal Hocko, Johannes Weiner

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

Hi all,

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

mm/madvise.c: In function 'madvise_cold_or_pageout_pte_range':
mm/madvise.c:346:7: error: implicit declaration of function 'is_huge_zero_pmd'; did you mean 'is_huge_zero_pud'? [-Werror=implicit-function-declaration]
   if (is_huge_zero_pmd(orig_pmd))
       ^~~~~~~~~~~~~~~~
       is_huge_zero_pud
mm/madvise.c:373:7: error: implicit declaration of function 'pmd_young'; did you mean 'pte_young'? [-Werror=implicit-function-declaration]
   if (pmd_young(orig_pmd)) {
       ^~~~~~~~~
       pte_young
mm/madvise.c:375:15: error: implicit declaration of function 'pmd_mkold'; did you mean 'pte_mkold'? [-Werror=implicit-function-declaration]
    orig_pmd = pmd_mkold(orig_pmd);
               ^~~~~~~~~
               pte_mkold
mm/madvise.c:377:4: error: implicit declaration of function 'set_pmd_at'; did you mean 'set_pte_at'? [-Werror=implicit-function-declaration]
    set_pmd_at(mm, addr, pmd, orig_pmd);
    ^~~~~~~~~~
    set_pte_at

Caused by commit

  d6d92199f211 ("mm, madvise: introduce MADV_COLD")

I have reverted (I assume the first four depend on the last):

  674db9810e45 ("mm, madvise: factor out common parts between MADV_COLD and MADV_PAGEOUT")
  5bd341efe8f1 ("mm, madvise: introduce MADV_PAGEOUT")
  c487c618dcf1 ("mm, madvise: account nr_isolated_xxx in [isolate|putback]_lru_page")
  1ef762b1c799 ("mm, madvise: change PAGEREF_RECLAIM_CLEAN with PAGE_REFRECLAIM")
  d6d92199f211 ("mm, madvise: introduce MADV_COLD")

for today (as - I just noticed - is suggested in another email).

-- 
Cheers,
Stephen Rothwell

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

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2019-07-12 10:59       ` Arnd Bergmann
@ 2019-07-12 21:15         ` Andrew Morton
  0 siblings, 0 replies; 330+ messages in thread
From: Andrew Morton @ 2019-07-12 21:15 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Michal Hocko, Stephen Rothwell, Linux Next Mailing List,
	Linux Kernel Mailing List, Yang Shi

On Fri, 12 Jul 2019 12:59:45 +0200 Arnd Bergmann <arnd@arndb.de> wrote:

> On Thu, Jul 11, 2019 at 2:41 AM Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> >
> > From: Yang Shi <yang.shi@linux.alibaba.com>
> > Subject: mm: shrinker: make shrinker not depend on memcg kmem
> >
> > Currently shrinker is just allocated and can work when memcg kmem is
> > enabled.  But, THP deferred split shrinker is not slab shrinker, it
> > doesn't make too much sense to have such shrinker depend on memcg kmem.
> > It should be able to reclaim THP even though memcg kmem is disabled.
> >
> > Introduce a new shrinker flag, SHRINKER_NONSLAB, for non-slab shrinker.
> > When memcg kmem is disabled, just such shrinkers can be called in
> > shrinking memcg slab.
> >
> 
> Today's linux-next again fails without CONFIG_MEMCG_KMEM:
> 
> mm/vmscan.c:220:7: error: implicit declaration of function
> 'memcg_expand_shrinker_maps' [-Werror,-Wimplicit-function-declaration]
>                 if (memcg_expand_shrinker_maps(id)) {
>                     ^
> mm/vmscan.c:608:56: error: no member named 'shrinker_map' in 'struct
> mem_cgroup_per_node'
>         map = rcu_dereference_protected(memcg->nodeinfo[nid]->shrinker_map,
>                                         ~~~~~~~~~~~~~~~~~~~~  ^
> 

Thanks.  With this and the mysterious list_del() corruption issue I
think I'll drop the patchset.


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

* Re: linux-next: build failure after merge of the akpm-current tree
  2019-07-11  0:34     ` Andrew Morton
@ 2019-07-12 10:59       ` Arnd Bergmann
  2019-07-12 21:15         ` Andrew Morton
  0 siblings, 1 reply; 330+ messages in thread
From: Arnd Bergmann @ 2019-07-12 10:59 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Michal Hocko, Stephen Rothwell, Linux Next Mailing List,
	Linux Kernel Mailing List, Yang Shi

On Thu, Jul 11, 2019 at 2:41 AM Andrew Morton <akpm@linux-foundation.org> wrote:
>
>
> From: Yang Shi <yang.shi@linux.alibaba.com>
> Subject: mm: shrinker: make shrinker not depend on memcg kmem
>
> Currently shrinker is just allocated and can work when memcg kmem is
> enabled.  But, THP deferred split shrinker is not slab shrinker, it
> doesn't make too much sense to have such shrinker depend on memcg kmem.
> It should be able to reclaim THP even though memcg kmem is disabled.
>
> Introduce a new shrinker flag, SHRINKER_NONSLAB, for non-slab shrinker.
> When memcg kmem is disabled, just such shrinkers can be called in
> shrinking memcg slab.
>

Today's linux-next again fails without CONFIG_MEMCG_KMEM:

mm/vmscan.c:220:7: error: implicit declaration of function
'memcg_expand_shrinker_maps' [-Werror,-Wimplicit-function-declaration]
                if (memcg_expand_shrinker_maps(id)) {
                    ^
mm/vmscan.c:608:56: error: no member named 'shrinker_map' in 'struct
mem_cgroup_per_node'
        map = rcu_dereference_protected(memcg->nodeinfo[nid]->shrinker_map,
                                        ~~~~~~~~~~~~~~~~~~~~  ^

     Arnd

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2019-07-10  7:05   ` Michal Hocko
@ 2019-07-11  0:34     ` Andrew Morton
  2019-07-12 10:59       ` Arnd Bergmann
  0 siblings, 1 reply; 330+ messages in thread
From: Andrew Morton @ 2019-07-11  0:34 UTC (permalink / raw)
  To: Michal Hocko
  Cc: Stephen Rothwell, Linux Next Mailing List,
	Linux Kernel Mailing List, Yang Shi

On Wed, 10 Jul 2019 09:05:09 +0200 Michal Hocko <mhocko@kernel.org> wrote:

> >  	return false;
> >  }
> > +static inline void memcg_set_shrinker_bit(struct mem_cgroup *memcg,
> > +					  int nid, int shrinker_id)
> > +{
> > +}
> >  #endif
> 
> Can we get the full series resent please. I have completely lost track
> of all the follow up fixes.

It's just mm-shrinker-make-shrinker-not-depend-on-memcg-kmem.patch that
had all the little buildy fixes.  Below.

But this patchset seems to have a list handling bug
http://lkml.kernel.org/r/1562795006.8510.19.camel@lca.pw.



From: Yang Shi <yang.shi@linux.alibaba.com>
Subject: mm: shrinker: make shrinker not depend on memcg kmem

Currently shrinker is just allocated and can work when memcg kmem is
enabled.  But, THP deferred split shrinker is not slab shrinker, it
doesn't make too much sense to have such shrinker depend on memcg kmem. 
It should be able to reclaim THP even though memcg kmem is disabled.

Introduce a new shrinker flag, SHRINKER_NONSLAB, for non-slab shrinker. 
When memcg kmem is disabled, just such shrinkers can be called in
shrinking memcg slab.

[akpm@linux-foundation.org: fix build]
  Link: http://lkml.kernel.org/r/201907052120.OGYPhvno%lkp@intel.com
[shy828301@gmail.com: fixes]
  Link: http://lkml.kernel.org/r/CAHbLzkr8h0t+2xs6f7htKZFdKDbsD5F4z-AAt+CDa-uVwSkQ1Q@mail.gmail.com
[akpm@linux-foundation.org: coding style fixes]
[akpm@linux-foundation.org: build fix]
Link: http://lkml.kernel.org/r/1561507361-59349-4-git-send-email-yang.shi@linux.alibaba.com
Signed-off-by: Yang Shi <yang.shi@linux.alibaba.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Kirill Tkhai <ktkhai@virtuozzo.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Shakeel Butt <shakeelb@google.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 include/linux/shrinker.h |    3 ++-
 mm/vmscan.c              |   36 +++++++++++++++++++-----------------
 2 files changed, 21 insertions(+), 18 deletions(-)

--- a/include/linux/shrinker.h~mm-shrinker-make-shrinker-not-depend-on-memcg-kmem
+++ a/include/linux/shrinker.h
@@ -69,7 +69,7 @@ struct shrinker {
 
 	/* These are for internal use */
 	struct list_head list;
-#ifdef CONFIG_MEMCG_KMEM
+#ifdef CONFIG_MEMCG
 	/* ID in shrinker_idr */
 	int id;
 #endif
@@ -81,6 +81,7 @@ struct shrinker {
 /* Flags */
 #define SHRINKER_NUMA_AWARE	(1 << 0)
 #define SHRINKER_MEMCG_AWARE	(1 << 1)
+#define SHRINKER_NONSLAB	(1 << 2)
 
 extern int prealloc_shrinker(struct shrinker *shrinker);
 extern void register_shrinker_prepared(struct shrinker *shrinker);
--- a/mm/vmscan.c~mm-shrinker-make-shrinker-not-depend-on-memcg-kmem
+++ a/mm/vmscan.c
@@ -174,8 +174,7 @@ unsigned long vm_total_pages;
 static LIST_HEAD(shrinker_list);
 static DECLARE_RWSEM(shrinker_rwsem);
 
-#ifdef CONFIG_MEMCG_KMEM
-
+#ifdef CONFIG_MEMCG
 /*
  * We allow subsystems to populate their shrinker-related
  * LRU lists before register_shrinker_prepared() is called
@@ -227,18 +226,7 @@ static void unregister_memcg_shrinker(st
 	idr_remove(&shrinker_idr, id);
 	up_write(&shrinker_rwsem);
 }
-#else /* CONFIG_MEMCG_KMEM */
-static int prealloc_memcg_shrinker(struct shrinker *shrinker)
-{
-	return 0;
-}
 
-static void unregister_memcg_shrinker(struct shrinker *shrinker)
-{
-}
-#endif /* CONFIG_MEMCG_KMEM */
-
-#ifdef CONFIG_MEMCG
 static bool global_reclaim(struct scan_control *sc)
 {
 	return !sc->target_mem_cgroup;
@@ -293,6 +281,15 @@ static bool memcg_congested(pg_data_t *p
 
 }
 #else
+static int prealloc_memcg_shrinker(struct shrinker *shrinker)
+{
+	return 0;
+}
+
+static void unregister_memcg_shrinker(struct shrinker *shrinker)
+{
+}
+
 static bool global_reclaim(struct scan_control *sc)
 {
 	return true;
@@ -579,7 +576,7 @@ static unsigned long do_shrink_slab(stru
 	return freed;
 }
 
-#ifdef CONFIG_MEMCG_KMEM
+#ifdef CONFIG_MEMCG
 static unsigned long shrink_slab_memcg(gfp_t gfp_mask, int nid,
 			struct mem_cgroup *memcg, int priority)
 {
@@ -587,7 +584,7 @@ static unsigned long shrink_slab_memcg(g
 	unsigned long ret, freed = 0;
 	int i;
 
-	if (!memcg_kmem_enabled() || !mem_cgroup_online(memcg))
+	if (!mem_cgroup_online(memcg))
 		return 0;
 
 	if (!down_read_trylock(&shrinker_rwsem))
@@ -613,6 +610,11 @@ static unsigned long shrink_slab_memcg(g
 			continue;
 		}
 
+		/* Call non-slab shrinkers even though kmem is disabled */
+		if (!memcg_kmem_enabled() &&
+		    !(shrinker->flags & SHRINKER_NONSLAB))
+			continue;
+
 		ret = do_shrink_slab(&sc, shrinker, priority);
 		if (ret == SHRINK_EMPTY) {
 			clear_bit(i, map->map);
@@ -649,13 +651,13 @@ unlock:
 	up_read(&shrinker_rwsem);
 	return freed;
 }
-#else /* CONFIG_MEMCG_KMEM */
+#else /* CONFIG_MEMCG */
 static unsigned long shrink_slab_memcg(gfp_t gfp_mask, int nid,
 			struct mem_cgroup *memcg, int priority)
 {
 	return 0;
 }
-#endif /* CONFIG_MEMCG_KMEM */
+#endif /* CONFIG_MEMCG */
 
 /**
  * shrink_slab - shrink slab caches
_


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

* Re: linux-next: build failure after merge of the akpm-current tree
  2019-07-09 20:42 ` Andrew Morton
@ 2019-07-10  7:05   ` Michal Hocko
  2019-07-11  0:34     ` Andrew Morton
  0 siblings, 1 reply; 330+ messages in thread
From: Michal Hocko @ 2019-07-10  7:05 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Stephen Rothwell, Linux Next Mailing List,
	Linux Kernel Mailing List, Yang Shi

On Tue 09-07-19 13:42:33, Andrew Morton wrote:
> On Tue, 9 Jul 2019 21:15:59 +1000 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) failed like this:
> > 
> > arm-linux-gnueabi-ld: mm/list_lru.o: in function `list_lru_add':
> > list_lru.c:(.text+0x1a0): undefined reference to `memcg_set_shrinker_bit'
> > 
> > Caused by commit
> > 
> >   ca37e9e5f18d ("mm-shrinker-make-shrinker-not-depend-on-memcg-kmem-fix-2")
> > 
> > CONFIG_MEMCG is not set for this build.
> > 
> > I have reverted that commit for today.
> 
> Thanks.  This, I suppose:
> 
> --- a/include/linux/memcontrol.h~mm-shrinker-make-shrinker-not-depend-on-memcg-kmem-fix-2-fix
> +++ a/include/linux/memcontrol.h
> @@ -1259,6 +1259,8 @@ static inline bool mem_cgroup_under_sock
>  	} while ((memcg = parent_mem_cgroup(memcg)));
>  	return false;
>  }
> +extern void memcg_set_shrinker_bit(struct mem_cgroup *memcg,
> +                                  int nid, int shrinker_id);
>  #else
>  #define mem_cgroup_sockets_enabled 0
>  static inline void mem_cgroup_sk_alloc(struct sock *sk) { };
> @@ -1267,6 +1269,10 @@ static inline bool mem_cgroup_under_sock
>  {
>  	return false;
>  }
> +static inline void memcg_set_shrinker_bit(struct mem_cgroup *memcg,
> +					  int nid, int shrinker_id)
> +{
> +}
>  #endif

Can we get the full series resent please. I have completely lost track
of all the follow up fixes.

Thanks!
-- 
Michal Hocko
SUSE Labs

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2019-07-09 11:15 Stephen Rothwell
@ 2019-07-09 20:42 ` Andrew Morton
  2019-07-10  7:05   ` Michal Hocko
  0 siblings, 1 reply; 330+ messages in thread
From: Andrew Morton @ 2019-07-09 20:42 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Yang Shi

On Tue, 9 Jul 2019 21:15:59 +1000 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) failed like this:
> 
> arm-linux-gnueabi-ld: mm/list_lru.o: in function `list_lru_add':
> list_lru.c:(.text+0x1a0): undefined reference to `memcg_set_shrinker_bit'
> 
> Caused by commit
> 
>   ca37e9e5f18d ("mm-shrinker-make-shrinker-not-depend-on-memcg-kmem-fix-2")
> 
> CONFIG_MEMCG is not set for this build.
> 
> I have reverted that commit for today.

Thanks.  This, I suppose:

--- a/include/linux/memcontrol.h~mm-shrinker-make-shrinker-not-depend-on-memcg-kmem-fix-2-fix
+++ a/include/linux/memcontrol.h
@@ -1259,6 +1259,8 @@ static inline bool mem_cgroup_under_sock
 	} while ((memcg = parent_mem_cgroup(memcg)));
 	return false;
 }
+extern void memcg_set_shrinker_bit(struct mem_cgroup *memcg,
+                                  int nid, int shrinker_id);
 #else
 #define mem_cgroup_sockets_enabled 0
 static inline void mem_cgroup_sk_alloc(struct sock *sk) { };
@@ -1267,6 +1269,10 @@ static inline bool mem_cgroup_under_sock
 {
 	return false;
 }
+static inline void memcg_set_shrinker_bit(struct mem_cgroup *memcg,
+					  int nid, int shrinker_id)
+{
+}
 #endif
 
 struct kmem_cache *memcg_kmem_get_cache(struct kmem_cache *cachep);
_


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

* linux-next: build failure after merge of the akpm-current tree
@ 2019-07-09 11:15 Stephen Rothwell
  2019-07-09 20:42 ` Andrew Morton
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2019-07-09 11:15 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Yang Shi

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

Hi all,

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

arm-linux-gnueabi-ld: mm/list_lru.o: in function `list_lru_add':
list_lru.c:(.text+0x1a0): undefined reference to `memcg_set_shrinker_bit'

Caused by commit

  ca37e9e5f18d ("mm-shrinker-make-shrinker-not-depend-on-memcg-kmem-fix-2")

CONFIG_MEMCG is not set for this build.

I have reverted that commit for today.

-- 
Cheers,
Stephen Rothwell

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

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2019-07-05  9:27 ` Marco Elver
@ 2019-07-05 10:18   ` Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2019-07-05 10:18 UTC (permalink / raw)
  To: Marco Elver
  Cc: Andrew Morton, Linux Next Mailing List, Linux Kernel Mailing List

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

Hi Marco,

On Fri, 5 Jul 2019 11:27:58 +0200 Marco Elver <elver@google.com> wrote:
>
> Apologies for the breakage -- thanks for the fix! Shall I send a v+1
> or will your patch persist?

I assume Andrew will grab it and squash it into the original patch
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] 330+ messages in thread

* Re: linux-next: build failure after merge of the akpm-current tree
  2019-07-05  8:49 Stephen Rothwell
@ 2019-07-05  9:27 ` Marco Elver
  2019-07-05 10:18   ` Stephen Rothwell
  0 siblings, 1 reply; 330+ messages in thread
From: Marco Elver @ 2019-07-05  9:27 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Linux Next Mailing List, Linux Kernel Mailing List

On Fri, 5 Jul 2019 at 10:49, 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) failed like this:
>
> In file included from include/linux/compiler.h:257,
>                  from arch/arm/kernel/asm-offsets.c:10:
> include/linux/kasan-checks.h:14:15: error: unknown type name 'bool'
>  static inline bool __kasan_check_read(const volatile void *p, unsigned int size)
>                ^~~~
> include/linux/kasan-checks.h:18:15: error: unknown type name 'bool'
>  static inline bool __kasan_check_write(const volatile void *p, unsigned int size)
>                ^~~~
> include/linux/kasan-checks.h:38:15: error: unknown type name 'bool'
>  static inline bool kasan_check_read(const volatile void *p, unsigned int size)
>                ^~~~
> include/linux/kasan-checks.h:42:15: error: unknown type name 'bool'
>  static inline bool kasan_check_write(const volatile void *p, unsigned int size)
>                ^~~~
>
> Caused by commit
>
>   4bb170e54bbd ("mm/kasan: change kasan_check_{read,write} to return boolean")
>
> I have added the following patch for today:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 5 Jul 2019 18:44:55 +1000
> Subject: [PATCH] mm/kasan: include types.h for "bool"
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  include/linux/kasan-checks.h | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/include/linux/kasan-checks.h b/include/linux/kasan-checks.h
> index 2c7f0b6307b2..53cbf0ae14b5 100644
> --- a/include/linux/kasan-checks.h
> +++ b/include/linux/kasan-checks.h
> @@ -2,6 +2,8 @@
>  #ifndef _LINUX_KASAN_CHECKS_H
>  #define _LINUX_KASAN_CHECKS_H
>
> +#include <linux/types.h>
> +
>  /*
>   * __kasan_check_*: Always available when KASAN is enabled. This may be used
>   * even in compilation units that selectively disable KASAN, but must use KASAN
> --
> 2.20.1
>
> --
> Cheers,
> Stephen Rothwell

Apologies for the breakage -- thanks for the fix! Shall I send a v+1
or will your patch persist?

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

* linux-next: build failure after merge of the akpm-current tree
@ 2019-07-05  8:49 Stephen Rothwell
  2019-07-05  9:27 ` Marco Elver
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2019-07-05  8:49 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Marco Elver

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

Hi all,

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

In file included from include/linux/compiler.h:257,
                 from arch/arm/kernel/asm-offsets.c:10:
include/linux/kasan-checks.h:14:15: error: unknown type name 'bool'
 static inline bool __kasan_check_read(const volatile void *p, unsigned int size)
               ^~~~
include/linux/kasan-checks.h:18:15: error: unknown type name 'bool'
 static inline bool __kasan_check_write(const volatile void *p, unsigned int size)
               ^~~~
include/linux/kasan-checks.h:38:15: error: unknown type name 'bool'
 static inline bool kasan_check_read(const volatile void *p, unsigned int size)
               ^~~~
include/linux/kasan-checks.h:42:15: error: unknown type name 'bool'
 static inline bool kasan_check_write(const volatile void *p, unsigned int size)
               ^~~~

Caused by commit

  4bb170e54bbd ("mm/kasan: change kasan_check_{read,write} to return boolean")

I have added the following patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 5 Jul 2019 18:44:55 +1000
Subject: [PATCH] mm/kasan: include types.h for "bool"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 include/linux/kasan-checks.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/linux/kasan-checks.h b/include/linux/kasan-checks.h
index 2c7f0b6307b2..53cbf0ae14b5 100644
--- a/include/linux/kasan-checks.h
+++ b/include/linux/kasan-checks.h
@@ -2,6 +2,8 @@
 #ifndef _LINUX_KASAN_CHECKS_H
 #define _LINUX_KASAN_CHECKS_H
 
+#include <linux/types.h>
+
 /*
  * __kasan_check_*: Always available when KASAN is enabled. This may be used
  * even in compilation units that selectively disable KASAN, but must use KASAN
-- 
2.20.1

-- 
Cheers,
Stephen Rothwell

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

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2019-06-26 13:13 ` Christoph Hellwig
@ 2019-06-27  0:01   ` Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2019-06-27  0:01 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Andrew Morton, Linux Next Mailing List,
	Linux Kernel Mailing List, sparclinux, David S. Miller

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

Hi Christoph,

On Wed, 26 Jun 2019 15:13:18 +0200 Christoph Hellwig <hch@lst.de> wrote:
>
> As that function is in code only there to provide compile coverage
> something like this should fix the problem:
> 
> 
> diff --git a/arch/sparc/include/asm/pgtable_64.h b/arch/sparc/include/asm/pgtable_64.h
> index 547ff96fb228..1599de730532 100644
> --- a/arch/sparc/include/asm/pgtable_64.h
> +++ b/arch/sparc/include/asm/pgtable_64.h
> @@ -861,10 +861,12 @@ static inline unsigned long pud_page_vaddr(pud_t pud)
>  #define pud_clear(pudp)			(pud_val(*(pudp)) = 0UL)
>  #define pgd_page_vaddr(pgd)		\
>  	((unsigned long) __va(pgd_val(pgd)))
> -#define pgd_page(pgd)			pfn_to_page(pgd_pfn(pgd))
>  #define pgd_present(pgd)		(pgd_val(pgd) != 0U)
>  #define pgd_clear(pgdp)			(pgd_val(*(pgdp)) = 0UL)
>  
> +/* only used by the stubbed out hugetlb gup code, should never be called */
> +#define pgd_page(pgd)			NULL
> +
>  static inline unsigned long pud_large(pud_t pud)
>  {
>  	pte_t pte = __pte(pud_val(pud));

Thanks.

-- 
Cheers,
Stephen Rothwell

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

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2019-06-26 12:58 Stephen Rothwell
@ 2019-06-26 13:13 ` Christoph Hellwig
  2019-06-27  0:01   ` Stephen Rothwell
  0 siblings, 1 reply; 330+ messages in thread
From: Christoph Hellwig @ 2019-06-26 13:13 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Linux Next Mailing List,
	Linux Kernel Mailing List, Christoph Hellwig, sparclinux,
	David S. Miller

As that function is in code only there to provide compile coverage
something like this should fix the problem:


diff --git a/arch/sparc/include/asm/pgtable_64.h b/arch/sparc/include/asm/pgtable_64.h
index 547ff96fb228..1599de730532 100644
--- a/arch/sparc/include/asm/pgtable_64.h
+++ b/arch/sparc/include/asm/pgtable_64.h
@@ -861,10 +861,12 @@ static inline unsigned long pud_page_vaddr(pud_t pud)
 #define pud_clear(pudp)			(pud_val(*(pudp)) = 0UL)
 #define pgd_page_vaddr(pgd)		\
 	((unsigned long) __va(pgd_val(pgd)))
-#define pgd_page(pgd)			pfn_to_page(pgd_pfn(pgd))
 #define pgd_present(pgd)		(pgd_val(pgd) != 0U)
 #define pgd_clear(pgdp)			(pgd_val(*(pgdp)) = 0UL)
 
+/* only used by the stubbed out hugetlb gup code, should never be called */
+#define pgd_page(pgd)			NULL
+
 static inline unsigned long pud_large(pud_t pud)
 {
 	pte_t pte = __pte(pud_val(pud));

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

* linux-next: build failure after merge of the akpm-current tree
@ 2019-06-26 12:58 Stephen Rothwell
  2019-06-26 13:13 ` Christoph Hellwig
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2019-06-26 12:58 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Christoph Hellwig

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

Hi all,

After merging the akpm tree, today's linux-next build (sparc64 defconfig)
failed like this:

In file included from arch/sparc/include/asm/page_64.h:130:0,
                 from arch/sparc/include/asm/page.h:8,
                 from arch/sparc/include/asm/thread_info_64.h:27,
                 from arch/sparc/include/asm/thread_info.h:5,
                 from include/linux/thread_info.h:38,
                 from include/asm-generic/preempt.h:5,
                 from ./arch/sparc/include/generated/asm/preempt.h:1,
                 from include/linux/preempt.h:78,
                 from include/linux/spinlock.h:51,
                 from mm/gup.c:5:
mm/gup.c: In function 'gup_huge_pgd':
arch/sparc/include/asm/pgtable_64.h:864:37: error: implicit declaration of function 'pgd_pfn'; did you mean 'pud_pfn'? [-Werror=implicit-function-declaration]
 #define pgd_page(pgd)   pfn_to_page(pgd_pfn(pgd))
                                     ^
include/asm-generic/memory_model.h:54:40: note: in definition of macro '__pfn_to_page'
 #define __pfn_to_page(pfn) (vmemmap + (pfn))
                                        ^~~
mm/gup.c:2147:9: note: in expansion of macro 'pgd_page'
  page = pgd_page(orig) + ((addr & ~PGDIR_MASK) >> PAGE_SHIFT);
         ^~~~~~~~

Caused by commit

  51bbf54b3f26 ("sparc64: add the missing pgd_page definition")

I don't see a simple way to fix this, so sparc64 is broken for today :-(
-- 
Cheers,
Stephen Rothwell

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

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2019-06-26 12:02 ` Anshuman Khandual
@ 2019-06-26 12:34   ` Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2019-06-26 12:34 UTC (permalink / raw)
  To: Anshuman Khandual
  Cc: Andrew Morton, Linux Next Mailing List, Linux Kernel Mailing List

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

Hi Anshuman,

On Wed, 26 Jun 2019 17:32:18 +0530 Anshuman Khandual <anshuman.khandual@arm.com> wrote:
>
> I believe this might be caused by a patch for powerpc enabling HAVE_ARCH_HUGE_VMAP
> without an arch_ioremap_p4d_supported() definition.

Ah, OK.

> All it needs is a powerpc definition for arch_ioremap_p4d_supported() which can just
> return false if it is not supported. Shall I send a patch for the powerpc fix or just
> re-spin the original patch which added arch_ioremap_p4d_supported(). Please suggest.

I'll add a merge fix patch tomorrow.  Though if you can send that patch,
that would be nice :-)

> Today's linux-next (next-20190625) does not have powerpc subscribing HAVE_ARCH_HUGE_VMAP.
> Could you please point to the branch I should pull for this failure. Thanks !

git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git branch next

-- 
Cheers,
Stephen Rothwell

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

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2019-06-26 11:41 Stephen Rothwell
@ 2019-06-26 12:02 ` Anshuman Khandual
  2019-06-26 12:34   ` Stephen Rothwell
  0 siblings, 1 reply; 330+ messages in thread
From: Anshuman Khandual @ 2019-06-26 12:02 UTC (permalink / raw)
  To: Stephen Rothwell, Andrew Morton
  Cc: Linux Next Mailing List, Linux Kernel Mailing List

Hello Stephen,

On 06/26/2019 05:11 PM, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the akpm-current tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> ld: lib/ioremap.o: in function `.ioremap_huge_init':
> ioremap.c:(.init.text+0x3c): undefined reference to `.arch_ioremap_p4d_supported'

I believe this might be caused by a patch for powerpc enabling HAVE_ARCH_HUGE_VMAP
without an arch_ioremap_p4d_supported() definition.

> 
> Caused by commit
> 
>   749940680d0b ("mm/ioremap: probe platform for p4d huge map support")
> 
> I have reverted that commit for today.

All it needs is a powerpc definition for arch_ioremap_p4d_supported() which can just
return false if it is not supported. Shall I send a patch for the powerpc fix or just
re-spin the original patch which added arch_ioremap_p4d_supported(). Please suggest.

Today's linux-next (next-20190625) does not have powerpc subscribing HAVE_ARCH_HUGE_VMAP.
Could you please point to the branch I should pull for this failure. Thanks !

- Anshuman


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

* linux-next: build failure after merge of the akpm-current tree
@ 2019-06-26 11:41 Stephen Rothwell
  2019-06-26 12:02 ` Anshuman Khandual
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2019-06-26 11:41 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Anshuman Khandual

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

Hi all,

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

ld: lib/ioremap.o: in function `.ioremap_huge_init':
ioremap.c:(.init.text+0x3c): undefined reference to `.arch_ioremap_p4d_supported'

Caused by commit

  749940680d0b ("mm/ioremap: probe platform for p4d huge map support")

I have reverted that commit for today.

-- 
Cheers,
Stephen Rothwell

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

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2019-06-24 11:00 Stephen Rothwell
@ 2019-06-24 21:59 ` Andrew Morton
  0 siblings, 0 replies; 330+ messages in thread
From: Andrew Morton @ 2019-06-24 21:59 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Linux Next Mailing List, Linux Kernel Mailing List,
	Daniel Jordan, Nikolay Borisov

On Mon, 24 Jun 2019 21:00:43 +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) failed like this:
> 
> mm/util.c: In function '__account_locked_vm':
> mm/util.c:372:2: error: implicit declaration of function 'lockdep_assert_held_exclusive'; did you mean 'lockdep_assert_held_once'? [-Werror=implicit-function-declaration]
>   lockdep_assert_held_exclusive(&mm->mmap_sem);
>   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>   lockdep_assert_held_once
> cc1: some warnings being treated as errors
> 
> Caused by commit
> 
>   610509219f27 ("mm-add-account_locked_vm-utility-function-v3")
> 
> interacting with commit
> 
>   9ffbe8ac05db ("locking/lockdep: Rename lockdep_assert_held_exclusive() -> lockdep_assert_held_write()")
> 
> from the tip tree.
> 
> I have applied the following merge fix patch.
> 
> ...
>
> --- a/mm/util.c
> +++ b/mm/util.c
> @@ -369,7 +369,7 @@ int __account_locked_vm(struct mm_struct *mm, unsigned long pages, bool inc,
>  	unsigned long locked_vm, limit;
>  	int ret = 0;
>  
> -	lockdep_assert_held_exclusive(&mm->mmap_sem);
> +	lockdep_assert_held_write(&mm->mmap_sem);
>  
>  	locked_vm = mm->locked_vm;
>  	if (inc) {

OK, thanks, I'll stage mm-add-account_locked_vm-utility-function.patch
behind linux-next and shall fix this up.


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

* linux-next: build failure after merge of the akpm-current tree
@ 2019-06-24 11:00 Stephen Rothwell
  2019-06-24 21:59 ` Andrew Morton
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2019-06-24 11:00 UTC (permalink / raw)
  To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Daniel Jordan, Nikolay Borisov

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

Hi Andrew,

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

mm/util.c: In function '__account_locked_vm':
mm/util.c:372:2: error: implicit declaration of function 'lockdep_assert_held_exclusive'; did you mean 'lockdep_assert_held_once'? [-Werror=implicit-function-declaration]
  lockdep_assert_held_exclusive(&mm->mmap_sem);
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  lockdep_assert_held_once
cc1: some warnings being treated as errors

Caused by commit

  610509219f27 ("mm-add-account_locked_vm-utility-function-v3")

interacting with commit

  9ffbe8ac05db ("locking/lockdep: Rename lockdep_assert_held_exclusive() -> lockdep_assert_held_write()")

from the tip tree.

I have applied the following merge fix patch.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 24 Jun 2019 20:57:23 +1000
Subject: [PATCH] merge fix for "locking/lockdep: Rename lockdep_assert_held_exclusive() -> lockdep_assert_held_write()"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 mm/util.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/util.c b/mm/util.c
index 021648a8a3a3..932b00a7c28e 100644
--- a/mm/util.c
+++ b/mm/util.c
@@ -369,7 +369,7 @@ int __account_locked_vm(struct mm_struct *mm, unsigned long pages, bool inc,
 	unsigned long locked_vm, limit;
 	int ret = 0;
 
-	lockdep_assert_held_exclusive(&mm->mmap_sem);
+	lockdep_assert_held_write(&mm->mmap_sem);
 
 	locked_vm = mm->locked_vm;
 	if (inc) {
-- 
2.20.1

-- 
Cheers,
Stephen Rothwell

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

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2019-06-19 10:06 Stephen Rothwell
@ 2019-06-20 16:20 ` Masahiro Yamada
  0 siblings, 0 replies; 330+ messages in thread
From: Masahiro Yamada @ 2019-06-20 16:20 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Linux Next Mailing List,
	Linux Kernel Mailing List, Christoph Hellwig

On Wed, Jun 19, 2019 at 7:06 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) failed like this:
>
> In file included from usr/include/linux/byteorder/big_endian.hdrtest.c:1:
> ./usr/include/linux/byteorder/big_endian.h:6:2: error: #error "Unsupported endianness, check your toolchain"
>  #error "Unsupported endianness, check your toolchain"
>   ^~~~~
>
> Caused by commit
>
>   1ac94caaee11 ("byteorder: sanity check toolchain vs kernel endianness")
>
> Presumably exposed by commit
>
>   b91976b7c0e3 ("kbuild: compile-test UAPI headers to ensure they are self-contained")
>
> from the kbuild tree.
>
> I have reverted 1ac94caaee11 (and its following fixup) for today.


I can exclude big_endian.h and little_endian.h
from the header test.


-- 
Best Regards
Masahiro Yamada

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2019-06-20  9:42 Stephen Rothwell
@ 2019-06-20 10:17 ` David Hildenbrand
  0 siblings, 0 replies; 330+ messages in thread
From: David Hildenbrand @ 2019-06-20 10:17 UTC (permalink / raw)
  To: Stephen Rothwell, Andrew Morton
  Cc: Linux Next Mailing List, Linux Kernel Mailing List

On 20.06.19 11:42, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the akpm-current tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> drivers/base/memory.c: In function 'find_memory_block':
> drivers/base/memory.c:621:43: error: 'hint' undeclared (first use in this function); did you mean 'uint'?
>   return find_memory_block_by_id(block_id, hint);
>                                            ^~~~
>                                            uint
> drivers/base/memory.c:621:43: note: each undeclared identifier is reported only once for each function it appears in
> drivers/base/memory.c:622:1: warning: control reaches end of non-void function [-Wreturn-type]
>  }
>  ^
> 
> Caused by commit
> 
>   29be27f12cc8 ("drivers/base/memory.c: Get rid of find_memory_block_hinted()")
> 
> I have reverted that commit for today.
> 
Uh, how did that happen. "hint" -> "NULL". But we can drop the hint
completely. Will send a new patch. Grml.

Sorry for the noise.

-- 

Thanks,

David / dhildenb

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

* linux-next: build failure after merge of the akpm-current tree
@ 2019-06-20  9:42 Stephen Rothwell
  2019-06-20 10:17 ` David Hildenbrand
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2019-06-20  9:42 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, David Hildenbrand

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

Hi all,

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

drivers/base/memory.c: In function 'find_memory_block':
drivers/base/memory.c:621:43: error: 'hint' undeclared (first use in this function); did you mean 'uint'?
  return find_memory_block_by_id(block_id, hint);
                                           ^~~~
                                           uint
drivers/base/memory.c:621:43: note: each undeclared identifier is reported only once for each function it appears in
drivers/base/memory.c:622:1: warning: control reaches end of non-void function [-Wreturn-type]
 }
 ^

Caused by commit

  29be27f12cc8 ("drivers/base/memory.c: Get rid of find_memory_block_hinted()")

I have reverted that commit for today.

-- 
Cheers,
Stephen Rothwell

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

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

* linux-next: build failure after merge of the akpm-current tree
@ 2019-06-19 10:06 Stephen Rothwell
  2019-06-20 16:20 ` Masahiro Yamada
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2019-06-19 10:06 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Christoph Hellwig, Masahiro Yamada

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

Hi all,

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

In file included from usr/include/linux/byteorder/big_endian.hdrtest.c:1:
./usr/include/linux/byteorder/big_endian.h:6:2: error: #error "Unsupported endianness, check your toolchain"
 #error "Unsupported endianness, check your toolchain"
  ^~~~~

Caused by commit

  1ac94caaee11 ("byteorder: sanity check toolchain vs kernel endianness")

Presumably exposed by commit

  b91976b7c0e3 ("kbuild: compile-test UAPI headers to ensure they are self-contained")

from the kbuild tree.

I have reverted 1ac94caaee11 (and its following fixup) for today.

-- 
Cheers,
Stephen Rothwell

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

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

* linux-next: build failure after merge of the akpm-current tree
@ 2019-05-30  4:45 Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2019-05-30  4:45 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Nicholas Piggin

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

Hi all,

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


Caused by commit

  a826492f28d9 ("mm: move ioremap page table mapping function to mm/")

I have applied the following patch for today (which makes it build at
least):

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 30 May 2019 14:42:20 +1000
Subject: [PATCH] fix "mm: move ioremap page table mapping function to mm/"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 mm/vmalloc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 6370e0876a2c..f3abede9f161 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -322,7 +322,7 @@ int vmap_range(unsigned long addr,
 	int ret;
 
 	ret = vmap_range_noflush(addr, end, phys_addr, prot, max_page_shift);
-	flush_cache_vmap(start, end);
+	flush_cache_vmap(addr, end);
 	return ret;
 }
 
-- 
2.20.1

-- 
Cheers,
Stephen Rothwell

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

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

* linux-next: build failure after merge of the akpm-current tree
@ 2019-05-28  3:50 Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2019-05-28  3:50 UTC (permalink / raw)
  To: Andrew Morton, Steven Rostedt
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Masami Hiramatsu, Christophe Leroy

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

Hi all,

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

In file included from arch/arm/mm/extable.c:6:
include/linux/uaccess.h:302:29: error: static declaration of 'probe_user_read' follows non-static declaration
 static __always_inline long probe_user_read(void *dst, const void __user *src,
                             ^~~~~~~~~~~~~~~
include/linux/uaccess.h:254:13: note: previous declaration of 'probe_user_read' was here
 extern long probe_user_read(void *dst, const void __user *src, size_t size);
             ^~~~~~~~~~~~~~~

(and more ...)

Caused by commit

  3d127e17e970 ("include/linux/uaccess.h: add probe_user_read()")

interacting with commit

  3d7081822f7f ("uaccess: Add non-pagefault user-space read functions")

from the ftrace tree.

I have reverted the akpm-current tree fix for today (and the following
"mm-add-probe_user_read-fix").  Hopefully the following commit

  f414d1502add ("powerpc: use probe_user_read()") is still valid.

-- 
Cheers,
Stephen Rothwell

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

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2019-04-17 23:02     ` Stephen Rothwell
@ 2019-04-21 16:56       ` Alexey Dobriyan
  0 siblings, 0 replies; 330+ messages in thread
From: Alexey Dobriyan @ 2019-04-21 16:56 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Kees Cook, Andrew Morton, Linux Next Mailing List,
	Linux Kernel Mailing List

On Thu, Apr 18, 2019 at 09:02:47AM +1000, Stephen Rothwell wrote:
> Hi Kees,
> 
> On Wed, 17 Apr 2019 17:28:39 -0500 Kees Cook <keescook@chromium.org> wrote:
> >
> > On Wed, Apr 17, 2019 at 5:22 PM Kees Cook <keescook@chromium.org> wrote:
> > >
> > > On Wed, Apr 17, 2019 at 1:53 AM 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) failed like this:
> > > >
> > > > fs/binfmt_elf.c: In function 'load_elf_binary':
> > > > fs/binfmt_elf.c:1140:7: error: 'elf_interpreter' undeclared (first use in this function); did you mean 'interpreter'?
> > > >   if (!elf_interpreter)
> > > >        ^~~~~~~~~~~~~~~
> > > >        interpreter  
> > >
> > > static int load_elf_binary(struct linux_binprm *bprm)
> > > {
> > > ...
> > >         char * elf_interpreter = NULL;
> > >
> > > This is _absolutely_ a valid variable.  
> 
> It was. However commit a34f642bccf1 from Andrew's tree changes its scope.
> 
> So there is nothing wrong with commit 3ebf0dd657ce, it is the incorrect
> rebase of it on top of a34f642bccf1 that causes the build problem.
> 
> > > > Caused by commit
> > > >
> > > >   3ebf0dd657ce ("fs/binfmt_elf.c: move brk out of mmap when doing direct loader exec")
> > > >
> > > > interacting with commit
> > > >
> > > >   a34f642bccf1 ("fs/binfmt_elf.c: free PT_INTERP filename ASAP")
> > > >
> > > > I have applied the following patch for today.
> > > >
> > > > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > > > Date: Wed, 17 Apr 2019 16:48:29 +1000
> > > > Subject: [PATCH] fix "fs/binfmt_elf.c: move brk out of mmap when doing direct loader exec"
> > > >
> > > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > > > ---
> > > >  fs/binfmt_elf.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
> > > > index b3bbe6bca499..fe5668a1bbaa 100644
> > > > --- a/fs/binfmt_elf.c
> > > > +++ b/fs/binfmt_elf.c
> > > > @@ -1137,7 +1137,7 @@ static int load_elf_binary(struct linux_binprm *bprm)
> > > >          * collide early with the stack growing down), and into the unused
> > > >          * ELF_ET_DYN_BASE region.
> > > >          */
> > > > -       if (!elf_interpreter)
> > > > +       if (!interpreter)  
> > >
> > > No, this is very wrong and will, I think, cause all PIE binaries to fail to run.  
> > 
> > I may be wrong: I think this will cause all static binaries to see
> > their brk moved very unexpectedly. All static PIE binaries will fail?
> 
> Are you sure that elf_interpreter == NULL is not equivalent to
> interpreter == NULL by this point in the code?  Earlier if
> elf_intpreter is not NULL, we have set interpreter (using open_exec)
> and errored out if that fails.

My patch was done based on this very observation: if interpreter has been
opened then its filename has been allocated before otherwise how do you
know which interpreter to open? Just like with pathname resolution, once
lookup is done and inode has been fished out, pathname becomes irrelevant.

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2019-04-17 22:28   ` Kees Cook
  2019-04-17 22:46     ` Kees Cook
@ 2019-04-17 23:02     ` Stephen Rothwell
  2019-04-21 16:56       ` Alexey Dobriyan
  1 sibling, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2019-04-17 23:02 UTC (permalink / raw)
  To: Kees Cook
  Cc: Andrew Morton, Linux Next Mailing List,
	Linux Kernel Mailing List, Alexey Dobriyan

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

Hi Kees,

On Wed, 17 Apr 2019 17:28:39 -0500 Kees Cook <keescook@chromium.org> wrote:
>
> On Wed, Apr 17, 2019 at 5:22 PM Kees Cook <keescook@chromium.org> wrote:
> >
> > On Wed, Apr 17, 2019 at 1:53 AM 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) failed like this:
> > >
> > > fs/binfmt_elf.c: In function 'load_elf_binary':
> > > fs/binfmt_elf.c:1140:7: error: 'elf_interpreter' undeclared (first use in this function); did you mean 'interpreter'?
> > >   if (!elf_interpreter)
> > >        ^~~~~~~~~~~~~~~
> > >        interpreter  
> >
> > static int load_elf_binary(struct linux_binprm *bprm)
> > {
> > ...
> >         char * elf_interpreter = NULL;
> >
> > This is _absolutely_ a valid variable.  

It was. However commit a34f642bccf1 from Andrew's tree changes its scope.

So there is nothing wrong with commit 3ebf0dd657ce, it is the incorrect
rebase of it on top of a34f642bccf1 that causes the build problem.

> > > Caused by commit
> > >
> > >   3ebf0dd657ce ("fs/binfmt_elf.c: move brk out of mmap when doing direct loader exec")
> > >
> > > interacting with commit
> > >
> > >   a34f642bccf1 ("fs/binfmt_elf.c: free PT_INTERP filename ASAP")
> > >
> > > I have applied the following patch for today.
> > >
> > > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > > Date: Wed, 17 Apr 2019 16:48:29 +1000
> > > Subject: [PATCH] fix "fs/binfmt_elf.c: move brk out of mmap when doing direct loader exec"
> > >
> > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > > ---
> > >  fs/binfmt_elf.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
> > > index b3bbe6bca499..fe5668a1bbaa 100644
> > > --- a/fs/binfmt_elf.c
> > > +++ b/fs/binfmt_elf.c
> > > @@ -1137,7 +1137,7 @@ static int load_elf_binary(struct linux_binprm *bprm)
> > >          * collide early with the stack growing down), and into the unused
> > >          * ELF_ET_DYN_BASE region.
> > >          */
> > > -       if (!elf_interpreter)
> > > +       if (!interpreter)  
> >
> > No, this is very wrong and will, I think, cause all PIE binaries to fail to run.  
> 
> I may be wrong: I think this will cause all static binaries to see
> their brk moved very unexpectedly. All static PIE binaries will fail?

Are you sure that elf_interpreter == NULL is not equivalent to
interpreter == NULL by this point in the code?  Earlier if
elf_intpreter is not NULL, we have set interpreter (using open_exec)
and errored out if that fails.
-- 
Cheers,
Stephen Rothwell

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

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2019-04-17 22:28   ` Kees Cook
@ 2019-04-17 22:46     ` Kees Cook
  2019-04-17 23:02     ` Stephen Rothwell
  1 sibling, 0 replies; 330+ messages in thread
From: Kees Cook @ 2019-04-17 22:46 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Linux Next Mailing List,
	Linux Kernel Mailing List, Kees Cook, Alexey Dobriyan

On Wed, Apr 17, 2019 at 5:28 PM Kees Cook <keescook@chromium.org> wrote:
>
> On Wed, Apr 17, 2019 at 5:22 PM Kees Cook <keescook@chromium.org> wrote:
> >
> > On Wed, Apr 17, 2019 at 1:53 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > [...]
> > > Caused by commit
> > >
> > >   3ebf0dd657ce ("fs/binfmt_elf.c: move brk out of mmap when doing direct loader exec")
> > >
> > > interacting with commit
> > >
> > >   a34f642bccf1 ("fs/binfmt_elf.c: free PT_INTERP filename ASAP")

I should read more closely! I see now this is the patch where
elf_interpreter got moved. :)

And, yes, your fix is correct. *sigh* I will go find a brown paper bag now...

-- 
Kees Cook

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2019-04-17 22:22 ` Kees Cook
@ 2019-04-17 22:28   ` Kees Cook
  2019-04-17 22:46     ` Kees Cook
  2019-04-17 23:02     ` Stephen Rothwell
  0 siblings, 2 replies; 330+ messages in thread
From: Kees Cook @ 2019-04-17 22:28 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Linux Next Mailing List,
	Linux Kernel Mailing List, Kees Cook, Alexey Dobriyan

On Wed, Apr 17, 2019 at 5:22 PM Kees Cook <keescook@chromium.org> wrote:
>
> On Wed, Apr 17, 2019 at 1:53 AM 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) failed like this:
> >
> > fs/binfmt_elf.c: In function 'load_elf_binary':
> > fs/binfmt_elf.c:1140:7: error: 'elf_interpreter' undeclared (first use in this function); did you mean 'interpreter'?
> >   if (!elf_interpreter)
> >        ^~~~~~~~~~~~~~~
> >        interpreter
>
> static int load_elf_binary(struct linux_binprm *bprm)
> {
> ...
>         char * elf_interpreter = NULL;
>
> This is _absolutely_ a valid variable.

I saw a 0day report[1] as well on MIPS for this. Neither have I been
able to reproduce, though. I'm wondering if, due to the misplaced
kfree() that has existed for a while, if some kind of weird scoping is
happening.

What compiler are you using?

[1] https://lists.01.org/pipermail/kbuild-all/2019-April/060058.html

>
> >
> >
> > Caused by commit
> >
> >   3ebf0dd657ce ("fs/binfmt_elf.c: move brk out of mmap when doing direct loader exec")
> >
> > interacting with commit
> >
> >   a34f642bccf1 ("fs/binfmt_elf.c: free PT_INTERP filename ASAP")
> >
> > I have applied the following patch for today.
> >
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Date: Wed, 17 Apr 2019 16:48:29 +1000
> > Subject: [PATCH] fix "fs/binfmt_elf.c: move brk out of mmap when doing direct loader exec"
> >
> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > ---
> >  fs/binfmt_elf.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
> > index b3bbe6bca499..fe5668a1bbaa 100644
> > --- a/fs/binfmt_elf.c
> > +++ b/fs/binfmt_elf.c
> > @@ -1137,7 +1137,7 @@ static int load_elf_binary(struct linux_binprm *bprm)
> >          * collide early with the stack growing down), and into the unused
> >          * ELF_ET_DYN_BASE region.
> >          */
> > -       if (!elf_interpreter)
> > +       if (!interpreter)
>
> No, this is very wrong and will, I think, cause all PIE binaries to fail to run.

I may be wrong: I think this will cause all static binaries to see
their brk moved very unexpectedly. All static PIE binaries will fail?





--
Kees Cook

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2019-04-17  6:53 Stephen Rothwell
@ 2019-04-17 22:22 ` Kees Cook
  2019-04-17 22:28   ` Kees Cook
  0 siblings, 1 reply; 330+ messages in thread
From: Kees Cook @ 2019-04-17 22:22 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Linux Next Mailing List,
	Linux Kernel Mailing List, Kees Cook, Alexey Dobriyan

On Wed, Apr 17, 2019 at 1:53 AM 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) failed like this:
>
> fs/binfmt_elf.c: In function 'load_elf_binary':
> fs/binfmt_elf.c:1140:7: error: 'elf_interpreter' undeclared (first use in this function); did you mean 'interpreter'?
>   if (!elf_interpreter)
>        ^~~~~~~~~~~~~~~
>        interpreter

static int load_elf_binary(struct linux_binprm *bprm)
{
...
        char * elf_interpreter = NULL;

This is _absolutely_ a valid variable.

>
>
> Caused by commit
>
>   3ebf0dd657ce ("fs/binfmt_elf.c: move brk out of mmap when doing direct loader exec")
>
> interacting with commit
>
>   a34f642bccf1 ("fs/binfmt_elf.c: free PT_INTERP filename ASAP")
>
> I have applied the following patch for today.
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 17 Apr 2019 16:48:29 +1000
> Subject: [PATCH] fix "fs/binfmt_elf.c: move brk out of mmap when doing direct loader exec"
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  fs/binfmt_elf.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
> index b3bbe6bca499..fe5668a1bbaa 100644
> --- a/fs/binfmt_elf.c
> +++ b/fs/binfmt_elf.c
> @@ -1137,7 +1137,7 @@ static int load_elf_binary(struct linux_binprm *bprm)
>          * collide early with the stack growing down), and into the unused
>          * ELF_ET_DYN_BASE region.
>          */
> -       if (!elf_interpreter)
> +       if (!interpreter)

No, this is very wrong and will, I think, cause all PIE binaries to fail to run.

>                 current->mm->brk = current->mm->start_brk = ELF_ET_DYN_BASE;
>
>         if ((current->flags & PF_RANDOMIZE) && (randomize_va_space > 1)) {
> --
> 2.20.1
>
> --
> Cheers,
> Stephen Rothwell



-- 
Kees Cook

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

* linux-next: build failure after merge of the akpm-current tree
@ 2019-04-17  6:53 Stephen Rothwell
  2019-04-17 22:22 ` Kees Cook
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2019-04-17  6:53 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Kees Cook,
	Alexey Dobriyan

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

Hi Andrew,

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

fs/binfmt_elf.c: In function 'load_elf_binary':
fs/binfmt_elf.c:1140:7: error: 'elf_interpreter' undeclared (first use in this function); did you mean 'interpreter'?
  if (!elf_interpreter)
       ^~~~~~~~~~~~~~~
       interpreter


Caused by commit

  3ebf0dd657ce ("fs/binfmt_elf.c: move brk out of mmap when doing direct loader exec")

interacting with commit

  a34f642bccf1 ("fs/binfmt_elf.c: free PT_INTERP filename ASAP")

I have applied the following patch for today.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 17 Apr 2019 16:48:29 +1000
Subject: [PATCH] fix "fs/binfmt_elf.c: move brk out of mmap when doing direct loader exec"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/binfmt_elf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index b3bbe6bca499..fe5668a1bbaa 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -1137,7 +1137,7 @@ static int load_elf_binary(struct linux_binprm *bprm)
 	 * collide early with the stack growing down), and into the unused
 	 * ELF_ET_DYN_BASE region.
 	 */
-	if (!elf_interpreter)
+	if (!interpreter)
 		current->mm->brk = current->mm->start_brk = ELF_ET_DYN_BASE;
 
 	if ((current->flags & PF_RANDOMIZE) && (randomize_va_space > 1)) {
-- 
2.20.1

-- 
Cheers,
Stephen Rothwell

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

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

* linux-next: build failure after merge of the akpm-current tree
@ 2019-04-17  6:43 Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2019-04-17  6:43 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Johannes Weiner

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

Hi Andrew,

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

mm/vmscan.c: In function 'snapshot_refaults':
mm/vmscan.c:2969:14: error: implicit declaration of function 'lruvec_page_state_local'; did you mean 'lruvec_page_state'? [-Werror=implicit-function-declaration]
   refaults = lruvec_page_state_local(lruvec, WORKINGSET_ACTIVATE);
              ^~~~~~~~~~~~~~~~~~~~~~~
              lruvec_page_state

Caused by commit

  3c1fea8fbdf7 ("mm: fix inactive list balancing between NUMA nodes and cgroups")

I applied the following patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 17 Apr 2019 16:40:02 +1000
Subject: [PATCH] fix "mm: fix inactive list balancing between NUMA nodes and cgroups"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 mm/vmscan.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index b828aae50d37..d545ace5e177 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2966,7 +2966,7 @@ static void snapshot_refaults(struct mem_cgroup *root_memcg, pg_data_t *pgdat)
 		struct lruvec *lruvec;
 
 		lruvec = mem_cgroup_lruvec(pgdat, memcg);
-		refaults = lruvec_page_state_local(lruvec, WORKINGSET_ACTIVATE);
+		refaults = lruvec_page_state(lruvec, WORKINGSET_ACTIVATE);
 		lruvec->refaults = refaults;
 	} while ((memcg = mem_cgroup_iter(root_memcg, memcg, NULL)));
 }
-- 
2.20.1

-- 
Cheers,
Stephen Rothwell

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

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

* linux-next: build failure after merge of the akpm-current tree
@ 2019-02-20  6:44 Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2019-02-20  6:44 UTC (permalink / raw)
  To: Andrew Morton, Dave Airlie, DRI
  Cc: Souptick Joarder, Jérôme Glisse,
	Linux Next Mailing List, Linux Kernel Mailing List, Ben Skeggs

[-- Attachment #1.1: Type: text/plain, Size: 2137 bytes --]

Hi all,

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

drivers/gpu/drm/nouveau/nouveau_dmem.c:299:11: error: initialization of 'vm_fault_t (*)(struct hmm_devmem *, struct vm_area_struct *, long unsigned int,  const struct page *, unsigned int,  pmd_t *)' {aka 'unsigned int (*)(struct hmm_devmem *, struct vm_area_struct *, long unsigned int,  const struct page *, unsigned int,  struct <anonymous> *)'} from incompatible pointer type 'int (*)(struct hmm_devmem *, struct vm_area_struct *, long unsigned int,  const struct page *, unsigned int,  pmd_t *)' {aka 'int (*)(struct hmm_devmem *, struct vm_area_struct *, long unsigned int,  const struct page *, unsigned int,  struct <anonymous> *)'} [-Werror=incompatible-pointer-types]
  .fault = nouveau_dmem_fault,
           ^~~~~~~~~~~~~~~~~~
drivers/gpu/drm/nouveau/nouveau_dmem.c:299:11: note: (near initialization for 'nouveau_dmem_devmem_ops.fault')

Caused by commit

  5be73b690875 ("drm/nouveau/dmem: device memory helpers for SVM")

from the drm tree interacting with commit

  ed814eb7f91d ("mm/hmm: convert to use vm_fault_t")

from the akpm-current tree.

I added this merge fix patch:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 20 Feb 2019 17:36:18 +1100
Subject: [PATCH] drm/nouveau/dmem: update for struct hmm_devmem_ops member
 change

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/gpu/drm/nouveau/nouveau_dmem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c b/drivers/gpu/drm/nouveau/nouveau_dmem.c
index 8be7a83ced9b..e2539f64de60 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dmem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dmem.c
@@ -261,7 +261,7 @@ static const struct migrate_vma_ops nouveau_dmem_fault_migrate_ops = {
 	.finalize_and_map	= nouveau_dmem_fault_finalize_and_map,
 };
 
-static int
+static vm_fault_t
 nouveau_dmem_fault(struct hmm_devmem *devmem,
 		   struct vm_area_struct *vma,
 		   unsigned long addr,
-- 
2.20.1

-- 
Cheers,
Stephen Rothwell

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

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2019-02-13  6:25 Stephen Rothwell
@ 2019-02-13 22:29 ` Andrew Morton
  0 siblings, 0 replies; 330+ messages in thread
From: Andrew Morton @ 2019-02-13 22:29 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Jens Axboe, Linux Next Mailing List, Linux Kernel Mailing List,
	Nikolay Borisov

On Wed, 13 Feb 2019 17:25:18 +1100 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) failed like this:
> 
> fs/io_uring.c: In function 'io_async_list_note':
> fs/io_uring.c:931:16: error: 'VM_MAX_READAHEAD' undeclared (first use in this function); did you mean 'VM_MAYREAD'?
>     max_pages = VM_MAX_READAHEAD >> (PAGE_SHIFT - 10);
>                 ^~~~~~~~~~~~~~~~
>                 VM_MAYREAD
> 
> Caused by commit
> 
>   4c416502dae2 ("mm: Refactor readahead defines in mm.h")
> 
> interacting with commit
> 
>   6eff5fa16a2e ("io_uring: allow workqueue item to handle multiple buffered requests")
> 
> from the block tree.
> 

Thanks.  I'll fix mm-refactor-readahead-defines-in-mmh.patch and shall
stage it after the block tree so everything lands nicely.

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

* linux-next: build failure after merge of the akpm-current tree
@ 2019-02-13  6:25 Stephen Rothwell
  2019-02-13 22:29 ` Andrew Morton
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2019-02-13  6:25 UTC (permalink / raw)
  To: Andrew Morton, Jens Axboe
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Nikolay Borisov

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

Hi Andrew,

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

fs/io_uring.c: In function 'io_async_list_note':
fs/io_uring.c:931:16: error: 'VM_MAX_READAHEAD' undeclared (first use in this function); did you mean 'VM_MAYREAD'?
    max_pages = VM_MAX_READAHEAD >> (PAGE_SHIFT - 10);
                ^~~~~~~~~~~~~~~~
                VM_MAYREAD

Caused by commit

  4c416502dae2 ("mm: Refactor readahead defines in mm.h")

interacting with commit

  6eff5fa16a2e ("io_uring: allow workqueue item to handle multiple buffered requests")

from the block tree.

I have applied this merge fix patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 13 Feb 2019 17:21:44 +1100
Subject: [PATCH] io_uring: fix up for readahead defines refactor

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/io_uring.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/io_uring.c b/fs/io_uring.c
index 1ff4acc9654d..c8272bc96d84 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -928,7 +928,7 @@ static void io_async_list_note(int rw, struct io_kiocb *req, size_t len)
 		/* Use 8x RA size as a decent limiter for both reads/writes */
 		max_pages = filp->f_ra.ra_pages;
 		if (!max_pages)
-			max_pages = VM_MAX_READAHEAD >> (PAGE_SHIFT - 10);
+			max_pages = VM_READAHEAD_PAGES;
 		max_pages *= 8;
 
 		/* If max pages are exceeded, reset the state */
-- 
2.20.1

-- 
Cheers,
Stephen Rothwell

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

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

* linux-next: build failure after merge of the akpm-current tree
@ 2019-01-16 23:40 Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2019-01-16 23:40 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Firoz Khan

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

Hi all,

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

make[2]: *** No rule to make target '/kisskb/src/scripts/syscalltbl.sh', needed by 'arch/sh/include/generated/asm/syscall_table.h'.  Stop.
make[1]: *** [arch/sh/Makefile:232: archheaders] Error 2

Probably caused by commit

  60a47bb1b736 ("sh: generate uapi header and syscall table header files")

I will revert that commit from linux-next today.

-- 
Cheers,
Stephen Rothwell

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

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2019-01-08  4:54 ` Anshuman Khandual
@ 2019-01-08  9:50   ` Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2019-01-08  9:50 UTC (permalink / raw)
  To: Anshuman Khandual
  Cc: Andrew Morton, Linux Next Mailing List, Linux Kernel Mailing List

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

Hi Anshuman,

On Tue, 8 Jan 2019 10:24:18 +0530 Anshuman Khandual <anshuman.khandual@arm.com> wrote:
>
> Just curious why the NUMA_NO_NODE definition did not get resolved from the local
> numa.h which had the same ones copied over from linux/numa.h but anyways the fix
> looks okay.

I assume that <numa.h> is /usr/include/numa.h (i.e. the system include
file which is whatever the distro installed) while <linux/numa.h> comes
out of the tools/include directory (i.e. the one we copied over from
the kernel source).

-- 
Cheers,
Stephen Rothwell

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

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2019-01-08  2:11 Stephen Rothwell
@ 2019-01-08  4:54 ` Anshuman Khandual
  2019-01-08  9:50   ` Stephen Rothwell
  0 siblings, 1 reply; 330+ messages in thread
From: Anshuman Khandual @ 2019-01-08  4:54 UTC (permalink / raw)
  To: Stephen Rothwell, Andrew Morton
  Cc: Linux Next Mailing List, Linux Kernel Mailing List



On 01/08/2019 07:41 AM, Stephen Rothwell wrote:
> Hi Andrew,
> 
> After merging the akpm-current tree, today's linux-next build (native
> perf) failed like this:
> 
> bench/numa.c: In function 'bind_to_node':
> bench/numa.c:301:21: error: 'NUMA_NO_NODE' undeclared (first use in this function); did you mean 'NUMA_NUM_NODES'?
>   if (target_node == NUMA_NO_NODE) {
>                      ^~~~~~~~~~~~
>                      NUMA_NUM_NODES
> bench/numa.c:301:21: note: each undeclared identifier is reported only once for each function it appears in
> bench/numa.c: In function 'bind_to_memnode':
> bench/numa.c:342:14: error: 'NUMA_NO_NODE' undeclared (first use in this function); did you mean 'NUMA_NUM_NODES'?
>   if (node == NUMA_NO_NODE)
>               ^~~~~~~~~~~~
>               NUMA_NUM_NODES
> bench/numa.c: In function 'init_thread_data':
> bench/numa.c:1366:19: error: 'NUMA_NO_NODE' undeclared (first use in this function); did you mean 'NUMA_NUM_NODES'?
>    td->bind_node = NUMA_NO_NODE;
>                    ^~~~~~~~~~~~
>                    NUMA_NUM_NODES
> 
> Caused by commit
> 
>   3856193d8452 ("tools/: replace open encodings for NUMA_NO_NODE")
> 
> [BTW, I did not write that patch, just added fixes last time]

Yes I had consolidated parts from the original patch into the build failure fix.


> [BTW 2, there are lots of cc's that probably no longer apply since this
> was split form the previous patch]

Hmm. I had sent it as a series. So the second patch just carried over all the CC
for the first one as well.

> 
> I have applied the following fix patch:
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 8 Jan 2019 13:08:32 +1100
> Subject: [PATCH] tools/: fix for replace open encodings for NUMA_NO_NODE
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  tools/perf/bench/numa.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/tools/perf/bench/numa.c b/tools/perf/bench/numa.c
> index e0ad5f1de226..98ad783efc69 100644
> --- a/tools/perf/bench/numa.c
> +++ b/tools/perf/bench/numa.c
> @@ -34,6 +34,7 @@
>  #include <sys/types.h>
>  #include <linux/kernel.h>
>  #include <linux/time64.h>
> +#include <linux/numa.h>
>  
>  #include <numa.h>

Just curious why the NUMA_NO_NODE definition did not get resolved from the local
numa.h which had the same ones copied over from linux/numa.h but anyways the fix
looks okay.

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

* linux-next: build failure after merge of the akpm-current tree
@ 2019-01-08  2:11 Stephen Rothwell
  2019-01-08  4:54 ` Anshuman Khandual
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2019-01-08  2:11 UTC (permalink / raw)
  To: Andrew Morton, Anshuman Khandual
  Cc: Linux Next Mailing List, Linux Kernel Mailing List

Hi Andrew,

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

bench/numa.c: In function 'bind_to_node':
bench/numa.c:301:21: error: 'NUMA_NO_NODE' undeclared (first use in this function); did you mean 'NUMA_NUM_NODES'?
  if (target_node == NUMA_NO_NODE) {
                     ^~~~~~~~~~~~
                     NUMA_NUM_NODES
bench/numa.c:301:21: note: each undeclared identifier is reported only once for each function it appears in
bench/numa.c: In function 'bind_to_memnode':
bench/numa.c:342:14: error: 'NUMA_NO_NODE' undeclared (first use in this function); did you mean 'NUMA_NUM_NODES'?
  if (node == NUMA_NO_NODE)
              ^~~~~~~~~~~~
              NUMA_NUM_NODES
bench/numa.c: In function 'init_thread_data':
bench/numa.c:1366:19: error: 'NUMA_NO_NODE' undeclared (first use in this function); did you mean 'NUMA_NUM_NODES'?
   td->bind_node = NUMA_NO_NODE;
                   ^~~~~~~~~~~~
                   NUMA_NUM_NODES

Caused by commit

  3856193d8452 ("tools/: replace open encodings for NUMA_NO_NODE")

[BTW, I did not write that patch, just added fixes last time]
[BTW 2, there are lots of cc's that probably no longer apply since this
was split form the previous patch]

I have applied the following fix patch:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 8 Jan 2019 13:08:32 +1100
Subject: [PATCH] tools/: fix for replace open encodings for NUMA_NO_NODE

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 tools/perf/bench/numa.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/perf/bench/numa.c b/tools/perf/bench/numa.c
index e0ad5f1de226..98ad783efc69 100644
--- a/tools/perf/bench/numa.c
+++ b/tools/perf/bench/numa.c
@@ -34,6 +34,7 @@
 #include <sys/types.h>
 #include <linux/kernel.h>
 #include <linux/time64.h>
+#include <linux/numa.h>
 
 #include <numa.h>
 #include <numaif.h>
-- 
2.20.1

-- 
Cheers,
Stephen Rothwell

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

* linux-next: build failure after merge of the akpm-current tree
@ 2018-12-05  5:14 Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2018-12-05  5:14 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Mel Gorman

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

Hi Andrew,

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

arm-linux-gnueabi-ld: kernel/sysctl.o: in function `.LANCHOR0':
sysctl.c:(.data+0x7b4): undefined reference to `fragment_stall_order_sysctl_handler'

Caused by commit

  a247ff3201c1 ("mm: stall movable allocations until kswapd progresses during serious external fragmentation event")

The fragment_stall_order_sysctl_handler() definition is protected by
CONFIG_NUMA, so I added this fix patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 5 Dec 2018 16:05:51 +1100
Subject: [PATCH] mm: fix for "stall movable allocations until kswapd
 progresses during serious external fragmentation event"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 kernel/sysctl.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 2f445c82fe38..93352cfb3239 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -1487,6 +1487,7 @@ static struct ctl_table vm_table[] = {
 		.extra1		= &one,
 		.extra2		= &one_thousand,
 	},
+#ifdef CONFIG_NUMA
 	{
 		.procname	= "fragment_stall_order",
 		.data		= &fragment_stall_order,
@@ -1496,6 +1497,7 @@ static struct ctl_table vm_table[] = {
 		.extra1		= &zero,
 		.extra2		= &max_order,
 	},
+#endif
 	{
 		.procname	= "percpu_pagelist_fraction",
 		.data		= &percpu_pagelist_fraction,
-- 
2.19.1

-- 
Cheers,
Stephen Rothwell

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

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

* linux-next: build failure after merge of the akpm-current tree
@ 2018-08-13  8:22 Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2018-08-13  8:22 UTC (permalink / raw)
  To: Andrew Morton, Eric W. Biederman
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Jürg Billeter

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

Hi all,

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

kernel/exit.c: In function 'reparent_leader':
kernel/exit.c:640:3: error: too few arguments to function 'group_send_sig_info'
   group_send_sig_info(p->signal->pdeath_signal_proc,
   ^~~~~~~~~~~~~~~~~~~
In file included from include/linux/sched/signal.h:6:0,
                 from include/linux/sched/cputime.h:5,
                 from kernel/exit.c:14:
include/linux/signal.h:262:12: note: declared here
 extern int group_send_sig_info(int sig, struct siginfo *info,
            ^~~~~~~~~~~~~~~~~~~

Caused by commit

  b04bd4d0117c ("prctl: add PR_[GS]ET_PDEATHSIG_PROC")

interacting with commit

  0102498083d5 ("signal: Pass pid type into group_send_sig_info")

from the uerns tree.

I have applied the following merge fix patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 13 Aug 2018 18:07:07 +1000
Subject: [PATCH] merge fix up for "signal: Pass pid type into
 group_send_sig_info"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 kernel/exit.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/exit.c b/kernel/exit.c
index 7b72bed283d4..066c66448258 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -638,7 +638,7 @@ static void reparent_leader(struct task_struct *father, struct task_struct *p,
 
 	if (p->signal->pdeath_signal_proc)
 		group_send_sig_info(p->signal->pdeath_signal_proc,
-				    SEND_SIG_NOINFO, p);
+				    SEND_SIG_NOINFO, p, PIDTYPE_TGID);
 
 	/* We don't want people slaying init. */
 	p->exit_signal = SIGCHLD;
-- 
2.18.0

-- 
Cheers,
Stephen Rothwell

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

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2018-07-23  9:42 Stephen Rothwell
@ 2018-07-25 23:18 ` Omar Sandoval
  0 siblings, 0 replies; 330+ messages in thread
From: Omar Sandoval @ 2018-07-25 23:18 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Linux-Next Mailing List,
	Linux Kernel Mailing List, Omar Sandoval

On Mon, Jul 23, 2018 at 07:42:31PM +1000, Stephen Rothwell wrote:
> Hi Andrew,
> 
> After merging the akpm tree, today's linux-next build (sparc (32 bit)
> defconfig) failed like this:
> 
> In file included from kernel/crash_core.c:9:0:
> kernel/crash_core.c: In function 'crash_save_vmcoreinfo_init':
> include/linux/crash_core.h:44:66: error: lvalue required as unary '&' operand
>   vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)&name)
>                                                                   ^
> kernel/crash_core.c:404:2: note: in expansion of macro 'VMCOREINFO_SYMBOL'
>   VMCOREINFO_SYMBOL(swapper_pg_dir);
>   ^~~~~~~~~~~~~~~~~
> 
> Caused by commit
> 
>   e527c514996a ("proc/kcore: add vmcoreinfo note to /proc/kcore")
> 
> It seems that sparc does not declare swapper_pg_dir for 32 but builds,
> they just define it to be NULL.  As do some others:
> 
> $ git grep -w 'define.*swapper_pg_dir'
> arch/arm/include/asm/pgtable-nommu.h:#define swapper_pg_dir ((pgd_t *) 0)
> arch/c6x/include/asm/pgtable.h:#define swapper_pg_dir ((pgd_t *) 0)
> arch/h8300/include/asm/pgtable.h:#define swapper_pg_dir ((pgd_t *) 0)
> arch/m68k/include/asm/pgtable_no.h:#define swapper_pg_dir ((pgd_t *) 0)
> arch/microblaze/include/asm/pgtable.h:#define swapper_pg_dir ((pgd_t *) NULL)
> arch/sparc/include/asm/pgtable_32.h:#define swapper_pg_dir NULL
> arch/xtensa/include/asm/pgtable.h:# define swapper_pg_dir NULL

Mm, I wrongly assumed that this would only be the case for !MMU. Looks
like it's always either NULL or an array, so VMCOREINFO_SYMBOL_ARRAY
should work here. I'll send a new version.

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

* linux-next: build failure after merge of the akpm-current tree
@ 2018-07-23  9:42 Stephen Rothwell
  2018-07-25 23:18 ` Omar Sandoval
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2018-07-23  9:42 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Omar Sandoval

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

Hi Andrew,

After merging the akpm tree, today's linux-next build (sparc (32 bit)
defconfig) failed like this:

In file included from kernel/crash_core.c:9:0:
kernel/crash_core.c: In function 'crash_save_vmcoreinfo_init':
include/linux/crash_core.h:44:66: error: lvalue required as unary '&' operand
  vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)&name)
                                                                  ^
kernel/crash_core.c:404:2: note: in expansion of macro 'VMCOREINFO_SYMBOL'
  VMCOREINFO_SYMBOL(swapper_pg_dir);
  ^~~~~~~~~~~~~~~~~

Caused by commit

  e527c514996a ("proc/kcore: add vmcoreinfo note to /proc/kcore")

It seems that sparc does not declare swapper_pg_dir for 32 but builds,
they just define it to be NULL.  As do some others:

$ git grep -w 'define.*swapper_pg_dir'
arch/arm/include/asm/pgtable-nommu.h:#define swapper_pg_dir ((pgd_t *) 0)
arch/c6x/include/asm/pgtable.h:#define swapper_pg_dir ((pgd_t *) 0)
arch/h8300/include/asm/pgtable.h:#define swapper_pg_dir ((pgd_t *) 0)
arch/m68k/include/asm/pgtable_no.h:#define swapper_pg_dir ((pgd_t *) 0)
arch/microblaze/include/asm/pgtable.h:#define swapper_pg_dir ((pgd_t *) NULL)
arch/sparc/include/asm/pgtable_32.h:#define swapper_pg_dir NULL
arch/xtensa/include/asm/pgtable.h:# define swapper_pg_dir NULL

I have reverted that commit for today.

-- 
Cheers,
Stephen Rothwell

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

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2018-06-29 21:25 ` Alexey Dobriyan
@ 2018-06-30  3:18   ` Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2018-06-30  3:18 UTC (permalink / raw)
  To: Alexey Dobriyan
  Cc: Andrew Morton, Linux-Next Mailing List, Linux Kernel Mailing List

[-- Attachment #1.1: Type: text/plain, Size: 910 bytes --]

Hi Alexey,

On Sat, 30 Jun 2018 00:25:22 +0300 Alexey Dobriyan <adobriyan@gmail.com> wrote:
>
> On Fri, Jun 29, 2018 at 05:49:46PM +1000, Stephen Rothwell wrote:
> > fs/proc/inode.c:110:2: note: in expansion of macro 'BUILD_BUG_ON'
> >   BUILD_BUG_ON(sizeof(struct proc_dir_entry) >= SIZEOF_PDE);
> >   ^~~~~~~~~~~~
> > 
> > Caused by commit
> > 
> >   527ae8759f10 ("proc: fixup PDE allocation bloat")
> > 
> > I have reverted that commit for today.  
> 
> Can't reproduce it with commit 7aa4b0a46be8badd053c958481f0e89e634ae4df
> (the one before revert) both on 32-bit and 64-bit.
> 
> Can you post fs/proc/inode.i ?

Attached (xz compresesed).

This is built with gcc 7.3.1 (built from source) hosted on PowerPC LE
and targeted at PowerPC BE (a powerpc allyesconfig build).  I did not
have any trouble with any of my other PowerPC targeted builds.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #1.2: inode.i.xz --]
[-- Type: application/x-xz, Size: 151384 bytes --]

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

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2018-06-29  7:49 Stephen Rothwell
@ 2018-06-29 21:25 ` Alexey Dobriyan
  2018-06-30  3:18   ` Stephen Rothwell
  0 siblings, 1 reply; 330+ messages in thread
From: Alexey Dobriyan @ 2018-06-29 21:25 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Linux-Next Mailing List, Linux Kernel Mailing List

On Fri, Jun 29, 2018 at 05:49:46PM +1000, Stephen Rothwell wrote:
> fs/proc/inode.c:110:2: note: in expansion of macro 'BUILD_BUG_ON'
>   BUILD_BUG_ON(sizeof(struct proc_dir_entry) >= SIZEOF_PDE);
>   ^~~~~~~~~~~~
> 
> Caused by commit
> 
>   527ae8759f10 ("proc: fixup PDE allocation bloat")
> 
> I have reverted that commit for today.

Can't reproduce it with commit 7aa4b0a46be8badd053c958481f0e89e634ae4df
(the one before revert) both on 32-bit and 64-bit.

Can you post fs/proc/inode.i ?

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

* linux-next: build failure after merge of the akpm-current tree
@ 2018-06-29  7:49 Stephen Rothwell
  2018-06-29 21:25 ` Alexey Dobriyan
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2018-06-29  7:49 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Alexey Dobriyan

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

Hi Andrew,

After merging the akpm tree, today's linux-next build (powerpc
allyesconfig) failed like this:

In file included from include/linux/kernel.h:10:0,
                 from include/linux/list.h:9,
                 from include/linux/preempt.h:11,
                 from include/linux/spinlock.h:51,
                 from include/linux/seqlock.h:36,
                 from include/linux/time.h:6,
                 from fs/proc/inode.c:9:
fs/proc/inode.c: In function 'proc_init_kmemcache':
include/linux/compiler.h:339:38: error: call to '__compiletime_assert_110' declared with attribute error: BUILD_BUG_ON failed: sizeof(struct proc_dir_entry) >= SIZEOF_PDE
  _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
                                      ^
include/linux/compiler.h:319:4: note: in definition of macro '__compiletime_assert'
    prefix ## suffix();    \
    ^~~~~~
include/linux/compiler.h:339:2: note: in expansion of macro '_compiletime_assert'
  _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
  ^~~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:45:37: note: in expansion of macro 'compiletime_assert'
 #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
                                     ^~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:69:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
  BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
  ^~~~~~~~~~~~~~~~
fs/proc/inode.c:110:2: note: in expansion of macro 'BUILD_BUG_ON'
  BUILD_BUG_ON(sizeof(struct proc_dir_entry) >= SIZEOF_PDE);
  ^~~~~~~~~~~~

Caused by commit

  527ae8759f10 ("proc: fixup PDE allocation bloat")

I have reverted that commit for today.

-- 
Cheers,
Stephen Rothwell

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

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

* linux-next: build failure after merge of the akpm-current tree
@ 2018-03-14  5:45 Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2018-03-14  5:45 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Mike Kravetz

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

Hi Andrew,

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

In file included from include/linux/kernel.h:15:0,
                 from include/linux/list.h:9,
                 from mm/hugetlb.c:5:
mm/hugetlb.c: In function 'hugetlb_reserve_pages':
include/linux/build_bug.h:36:33: error: void value not ignored as it ought to be
 #define BUILD_BUG_ON_INVALID(e) ((void)(sizeof((__force long)(e))))
                                 ^
include/linux/mmdebug.h:52:34: note: in expansion of macro 'BUILD_BUG_ON_INVALID'
 #define VM_WARN(cond, format...) BUILD_BUG_ON_INVALID(cond)
                                  ^~~~~~~~~~~~~~~~~~~~
mm/hugetlb.c:4379:6: note: in expansion of macro 'VM_WARN'
  if (VM_WARN(from > to, "%s called with a negative range\n", __func__))
      ^~~~~~~
scripts/Makefile.build:324: recipe for target 'mm/hugetlb.o' failed

Caused by commit

  df9b0bfadaa3 ("hugetlbfs-check-for-pgoff-value-overflow-v3-fix")

I have applied the following patch (a partial revert of the above):

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 14 Mar 2018 16:38:50 +1100
Subject: [PATCH] pertially revert
 "hugetlbfs-check-for-pgoff-value-overflow-v3-fix"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 mm/hugetlb.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 3b31dcfb7621..218679138255 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -4376,8 +4376,11 @@ int hugetlb_reserve_pages(struct inode *inode,
 	struct resv_map *resv_map;
 	long gbl_reserve;
 
-	if (VM_WARN(from > to, "%s called with a negative range\n", __func__))
+	/* This should never happen */
+	if (from > to) {
+		VM_WARN(1, "%s called with a negative range\n", __func__);
 		return -EINVAL;
+	}
 
 	/*
 	 * Only apply hugepage reservation if asked. At fault time, an
-- 
2.16.1

-- 
Cheers,
Stephen Rothwell

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

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2018-03-13 19:44 ` Andrew Morton
@ 2018-03-13 20:58   ` Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2018-03-13 20:58 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Kees Cook

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

Hi Andrew,

On Tue, 13 Mar 2018 12:44:34 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Tue, 13 Mar 2018 20:51:19 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > After merging the akpm-current tree, today's linux-next build (lots of
> > configuations) failed like this:
> > 
> > (from the i386 defconfig build)
> > 
> > In file included from include/linux/memcontrol.h:29:0,
> >                  from include/linux/swap.h:9,
> >                  from include/linux/suspend.h:5,
> >                  from arch/x86/kernel/asm-offsets.c:13:
> > include/linux/mm.h: In function 'get_mm_hiwater_rss':
> > include/linux/mm.h:1569:9: error: first argument to '__builtin_choose_expr' not a constant
> > include/linux/mm.h: In function 'get_mm_hiwater_vm':
> > include/linux/mm.h:1574:9: error: first argument to '__builtin_choose_expr' not a constant
> > 
> > and many more ...
> > 
> > Caused by commit
> > 
> >   c7c133f3d5ff ("kernel.h: skip single-eval logic on literals in min()/max()")
> > (and perhaps the folloups)
> > 
> > Just a few of my builds actaully worked (including those I do
> > during the day).  For complete logs see
> > http://kisskb.ellerman.id.au/kisskb/head/13556/ .
> > 
> > I guess it could be compiler version specific.  The failing ones are
> > done with gcc 4.6.3.  My successful ones with gcc 7.3.1.  
> 
> Yes, this is being a pain in the butt.  I guess we should drop the
> patches for now.

OK, I have removed them from my copy of your tree (rather than add
reverts on top).

-- 
Cheers,
Stephen Rothwell

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

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2018-03-13  9:51 Stephen Rothwell
@ 2018-03-13 19:44 ` Andrew Morton
  2018-03-13 20:58   ` Stephen Rothwell
  0 siblings, 1 reply; 330+ messages in thread
From: Andrew Morton @ 2018-03-13 19:44 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Kees Cook

On Tue, 13 Mar 2018 20:51:19 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Andrew,
> 
> After merging the akpm-current tree, today's linux-next build (lots of
> configuations) failed like this:
> 
> (from the i386 defconfig build)
> 
> In file included from include/linux/memcontrol.h:29:0,
>                  from include/linux/swap.h:9,
>                  from include/linux/suspend.h:5,
>                  from arch/x86/kernel/asm-offsets.c:13:
> include/linux/mm.h: In function 'get_mm_hiwater_rss':
> include/linux/mm.h:1569:9: error: first argument to '__builtin_choose_expr' not a constant
> include/linux/mm.h: In function 'get_mm_hiwater_vm':
> include/linux/mm.h:1574:9: error: first argument to '__builtin_choose_expr' not a constant
> 
> and many more ...
> 
> Caused by commit
> 
>   c7c133f3d5ff ("kernel.h: skip single-eval logic on literals in min()/max()")
> (and perhaps the folloups)
> 
> Just a few of my builds actaully worked (including those I do
> during the day).  For complete logs see
> http://kisskb.ellerman.id.au/kisskb/head/13556/ .
> 
> I guess it could be compiler version specific.  The failing ones are
> done with gcc 4.6.3.  My successful ones with gcc 7.3.1.

Yes, this is being a pain in the butt.  I guess we should drop the
patches for now.

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

* linux-next: build failure after merge of the akpm-current tree
@ 2018-03-13  9:51 Stephen Rothwell
  2018-03-13 19:44 ` Andrew Morton
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2018-03-13  9:51 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Kees Cook

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

Hi Andrew,

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

(from the i386 defconfig build)

In file included from include/linux/memcontrol.h:29:0,
                 from include/linux/swap.h:9,
                 from include/linux/suspend.h:5,
                 from arch/x86/kernel/asm-offsets.c:13:
include/linux/mm.h: In function 'get_mm_hiwater_rss':
include/linux/mm.h:1569:9: error: first argument to '__builtin_choose_expr' not a constant
include/linux/mm.h: In function 'get_mm_hiwater_vm':
include/linux/mm.h:1574:9: error: first argument to '__builtin_choose_expr' not a constant

and many more ...

Caused by commit

  c7c133f3d5ff ("kernel.h: skip single-eval logic on literals in min()/max()")
(and perhaps the folloups)

Just a few of my builds actaully worked (including those I do
during the day).  For complete logs see
http://kisskb.ellerman.id.au/kisskb/head/13556/ .

I guess it could be compiler version specific.  The failing ones are
done with gcc 4.6.3.  My successful ones with gcc 7.3.1.

-- 
Cheers,
Stephen Rothwell

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

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

* linux-next: build failure after merge of the akpm-current tree
@ 2018-03-08  4:52 Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2018-03-08  4:52 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Huacai Chen

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

Hi Andrew,

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

`__stack_chk_guard' referenced in section `.text' of arch/arm/boot/compressed/decompress.o: defined in discarded section `.data' of arch/arm/boot/compressed/misc.o
`__stack_chk_guard' referenced in section `.text' of arch/arm/boot/compressed/decompress.o: defined in discarded section `.data' of arch/arm/boot/compressed/misc.o
arch/arm/boot/compressed/Makefile:185: recipe for target 'arch/arm/boot/compressed/vmlinux' failed

Caused by commit

  2412eae312bf ("zboot: fix stack protector in compressed boot phase")

I have reverted that commit for today.

-- 
Cheers,
Stephen Rothwell

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

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

* linux-next: build failure after merge of the akpm-current tree
@ 2018-02-26  5:15 Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2018-02-26  5:15 UTC (permalink / raw)
  To: Andrew Morton, Linus Torvalds
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	David Howells, Randy Dunlap

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

Hi Andrew,

After merging the akpm tree, today's linux-next build (powerpc
allyesconfig) failed like this:

security/keys/big_key.c: In function 'big_key_free_buffer':
security/keys/big_key.c:146:3: error: implicit declaration of function 'vunmap'; did you mean 'kunmap'? [-Werror=implicit-function-declaration]
   vunmap(buf->virt);
   ^~~~~~
   kunmap
security/keys/big_key.c: In function 'big_key_alloc_buffer':
security/keys/big_key.c:187:14: error: implicit declaration of function 'vmap'; did you mean 'kmap'? [-Werror=implicit-function-declaration]
  buf->virt = vmap(buf->pages, buf->nr_pages, VM_MAP, PAGE_KERNEL);
              ^~~~
              kmap
security/keys/big_key.c:187:46: error: 'VM_MAP' undeclared (first use in this function); did you mean 'VM_SAO'?
  buf->virt = vmap(buf->pages, buf->nr_pages, VM_MAP, PAGE_KERNEL);
                                              ^~~~~~
                                              VM_SAO
security/keys/big_key.c:187:46: note: each undeclared identifier is reported only once for each function it appears in

Caused by commit

  d9f4bb1a0f4d ("KEYS: Use individual pages in big_key for crypto buffers")

in Linus' tree, but most likely exposed by commit

  e8bd5e5c63b6 ("headers: untangle kmemleak.h from mm.h")

in the akpm-current tree (kmemleak.h includes vmalloc.h).

I have added the following patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 26 Feb 2018 15:58:03 +1100
Subject: [PATCH] KEYS: include vmalloc.h for vmap etc

This was discovered after a patch that removed kmemleak.h from slab.h.

Fixes: d9f4bb1a0f4d ("KEYS: Use individual pages in big_key for crypto buffers")
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 security/keys/big_key.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/security/keys/big_key.c b/security/keys/big_key.c
index fa728f662a6f..e5823de23f4f 100644
--- a/security/keys/big_key.c
+++ b/security/keys/big_key.c
@@ -18,6 +18,7 @@
 #include <linux/err.h>
 #include <linux/scatterlist.h>
 #include <linux/random.h>
+#include <linux/vmalloc.h>
 #include <keys/user-type.h>
 #include <keys/big_key-type.h>
 #include <crypto/aead.h>
-- 
2.16.1

Linus, is it worth putting this directly into your tree, or should it
just wait for the patch from Andrew's tree that exposes it?
-- 
Cheers,
Stephen Rothwell

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

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

* linux-next: build failure after merge of the akpm-current tree
@ 2018-01-05  4:59 Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2018-01-05  4:59 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 (x86_64
allmodconfig) failed like this:

mm/migrate.c: In function 'migrate_misplaced_page':
mm/migrate.c:1933:46: error: passing argument 2 of 'migrate_pages' from incompatible pointer type [-Werror=incompatible-pointer-types]
  nr_remaining = migrate_pages(&migratepages, alloc_misplaced_dst_page,
                                              ^
mm/migrate.c:1358:5: note: expected 'struct page * (*)(struct page *, long unsigned int)' but argument is of type 'struct page * (*)(struct page *, long unsigned int,  int **)'
 int migrate_pages(struct list_head *from, new_page_t get_new_page,
     ^

Caused by commit

  d6f08a86f78a ("mm, migrate: remove reason argument from new_page_t")

I applied the following fix patch for today (the mm/memory-failure.c
error turned up after fixing the above):

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 5 Jan 2018 15:46:02 +1100
Subject: [PATCH] mm, migrate: remove reason argument from new_page_t fix

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 mm/memory-failure.c | 2 +-
 mm/migrate.c        | 3 +--
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index 4acdf393a801..d530ac1db680 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -1483,7 +1483,7 @@ int unpoison_memory(unsigned long pfn)
 }
 EXPORT_SYMBOL(unpoison_memory);
 
-static struct page *new_page(struct page *p, unsigned long private, int **x)
+static struct page *new_page(struct page *p, unsigned long private)
 {
 	int nid = page_to_nid(p);
 
diff --git a/mm/migrate.c b/mm/migrate.c
index 3cb0f5955b41..5d0dc7b85f90 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -1797,8 +1797,7 @@ static bool migrate_balanced_pgdat(struct pglist_data *pgdat,
 }
 
 static struct page *alloc_misplaced_dst_page(struct page *page,
-					   unsigned long data,
-					   int **result)
+					   unsigned long data)
 {
 	int nid = (int) data;
 	struct page *newpage;
-- 
2.15.0

-- 
Cheers,
Stephen Rothwell

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

* linux-next: build failure after merge of the akpm-current tree
@ 2017-12-11  5:05 Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2017-12-11  5:05 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Dan Williams,
	Benjamin Herrenschmidt, Michael Ellerman

Hi Andrew,

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

In file included from include/linux/hugetlb.h:451:0,
                 from arch/powerpc/mm/hugetlbpage.c:14:
arch/powerpc/include/asm/hugetlb.h:125:26: error: redefinition of 'vma_mmu_pagesize'
 #define vma_mmu_pagesize vma_mmu_pagesize
                          ^
arch/powerpc/mm/hugetlbpage.c:563:15: note: in expansion of macro 'vma_mmu_pagesize'
 unsigned long vma_mmu_pagesize(struct vm_area_struct *vma)
               ^
In file included from arch/powerpc/mm/hugetlbpage.c:14:0:
include/linux/hugetlb.h:274:29: note: previous definition of 'vma_mmu_pagesize' was here
 static inline unsigned long vma_mmu_pagesize(struct vm_area_struct *vma)
                             ^

Caused by commit

  ac9284a6b670 ("mm, hugetlbfs: introduce ->pagesize() to vm_operations_struct")

I have added the following fix patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 11 Dec 2017 15:51:41 +1100
Subject: [PATCH] mm, hugetlbfs: move testing of vma_mmu_pagesize to after
 inclusion of asm/hugetlb.h

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/powerpc/include/asm/hugetlb.h |  1 +
 include/linux/hugetlb.h            | 26 +++++++++++++-------------
 2 files changed, 14 insertions(+), 13 deletions(-)

diff --git a/arch/powerpc/include/asm/hugetlb.h b/arch/powerpc/include/asm/hugetlb.h
index 14c9d44f355b..3cc6ca1bdaf2 100644
--- a/arch/powerpc/include/asm/hugetlb.h
+++ b/arch/powerpc/include/asm/hugetlb.h
@@ -123,6 +123,7 @@ void hugetlb_free_pgd_range(struct mmu_gather *tlb, unsigned long addr,
  * to override the version in mm/hugetlb.c
  */
 #define vma_mmu_pagesize vma_mmu_pagesize
+unsigned long vma_mmu_pagesize(struct vm_area_struct *vma);
 
 /*
  * If the arch doesn't supply something else, assume that hugepage
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index c354befab724..b0f1f6768336 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -264,19 +264,6 @@ static inline unsigned long vma_kernel_pagesize(struct vm_area_struct *vma)
 	return PAGE_SIZE;
 }
 
-/*
- * Return the page size being used by the MMU to back a VMA. In the majority
- * of cases, the page size used by the kernel matches the MMU size. On
- * architectures where it differs, an architecture-specific version of this
- * function is required.
- */
-#ifndef vma_mmu_pagesize
-static inline unsigned long vma_mmu_pagesize(struct vm_area_struct *vma)
-{
-	return vma_kernel_pagesize(vma);
-}
-#endif
-
 #ifdef CONFIG_HUGETLBFS
 struct hugetlbfs_sb_info {
 	long	max_inodes;   /* inodes allowed */
@@ -615,6 +602,19 @@ static inline void set_huge_swap_pte_at(struct mm_struct *mm, unsigned long addr
 }
 #endif	/* CONFIG_HUGETLB_PAGE */
 
+/*
+ * Return the page size being used by the MMU to back a VMA. In the majority
+ * of cases, the page size used by the kernel matches the MMU size. On
+ * architectures where it differs, an architecture-specific version of this
+ * function is required.
+ */
+#ifndef vma_mmu_pagesize
+static inline unsigned long vma_mmu_pagesize(struct vm_area_struct *vma)
+{
+	return vma_kernel_pagesize(vma);
+}
+#endif
+
 static inline spinlock_t *huge_pte_lock(struct hstate *h,
 					struct mm_struct *mm, pte_t *pte)
 {
-- 
2.15.0

-- 
Cheers,
Stephen Rothwell

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

* linux-next: build failure after merge of the akpm-current tree
@ 2017-11-30  3:46 Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2017-11-30  3:46 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Waiman Long,
	David S. Miller, sparclinux

Hi Andrew,

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

mm/list_lru.c: In function 'list_lru_del':
mm/list_lru.c:141:2: error: implicit declaration of function 'prefetchw' [-Werror=implicit-function-declaration]
  prefetchw(item->prev);
  ^

Caused by commit

  9b4516980e87 ("mm/list_lru.c: prefetch neighboring list entries before acquiring lock")

Missing include of linux/prefetch.h?

I have reverted that commit for today.

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2017-11-20  4:32   ` Stephen Rothwell
@ 2017-11-20  4:34     ` Dan Williams
  0 siblings, 0 replies; 330+ messages in thread
From: Dan Williams @ 2017-11-20  4:34 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Linux-Next Mailing List, Linux Kernel Mailing List

On Sun, Nov 19, 2017 at 8:32 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Dan,
>
> On Sun, 19 Nov 2017 20:25:18 -0800 Dan Williams <dan.j.williams@intel.com> wrote:
>>
>> Ugh, yes. Looks correct. I might have confused my build success
>> notifications from 0day. I'll spin out a new branch to make sure this
>> is the last of it.
>
> Thanks.
>
> While I have your attention ... did you consider using the other
> paradigm:
>
> In arch include files:
> #define pud_write       pud_write
> static inline int pud_write(pud_t pud)
>  .....
>
> Then in include/asm-generic/pgtable.h:
>
> #ifndef pud_write
> tatic inline int pud_write(pud_t pud)
> {
>         ....
> }
> #endif
>
> If you had, then the powerpc code would have worked ... ;-)
> and many of the other interfaces in include/asm-generic/pgtable.h are
> protected that way ...

I like that better. I simply cargo-culted the way pmd_write() was
defined, and should have given it a bit more thought. Andrew, I'll
respin these with Stephen's suggestion.

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2017-11-20  4:25 ` Dan Williams
@ 2017-11-20  4:32   ` Stephen Rothwell
  2017-11-20  4:34     ` Dan Williams
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2017-11-20  4:32 UTC (permalink / raw)
  To: Dan Williams
  Cc: Andrew Morton, Linux-Next Mailing List, Linux Kernel Mailing List

Hi Dan,

On Sun, 19 Nov 2017 20:25:18 -0800 Dan Williams <dan.j.williams@intel.com> wrote:
>
> Ugh, yes. Looks correct. I might have confused my build success
> notifications from 0day. I'll spin out a new branch to make sure this
> is the last of it.

Thanks.

While I have your attention ... did you consider using the other
paradigm:

In arch include files:
#define pud_write	pud_write
static inline int pud_write(pud_t pud)
 .....

Then in include/asm-generic/pgtable.h:

#ifndef pud_write
tatic inline int pud_write(pud_t pud)
{
	....
}
#endif

If you had, then the powerpc code would have worked ... ;-)
and many of the other interfaces in include/asm-generic/pgtable.h are
protected that way ...

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2017-11-20  1:57 Stephen Rothwell
@ 2017-11-20  4:25 ` Dan Williams
  2017-11-20  4:32   ` Stephen Rothwell
  0 siblings, 1 reply; 330+ messages in thread
From: Dan Williams @ 2017-11-20  4:25 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Linux-Next Mailing List, Linux Kernel Mailing List

On Sun, Nov 19, 2017 at 5:57 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Andrew,
>
> After merging the akpm-current tree, today's linux-next build (powerpc64
> allnoconfig) failed like this:
>
> In file included from arch/powerpc/include/asm/book3s/64/mmu
> -hash.h:24:0,
>                  from arch/powerpc/include/asm/book3s/64/mmu.h:30,
>                  from arch/powerpc/include/asm/mmu.h:305,
>                  from arch/powerpc/include/asm/lppaca.h:36,
>                  from arch/powerpc/include/asm/paca.h:21,
>                  from arch/powerpc/include/asm/current.h:16,
>                  from include/linux/sched.h:12,
>                  from arch/powerpc/kernel/asm-offsets.c:17:
> arch/powerpc/include/asm/book3s/64/pgtable.h:844:35: error: expected declaration specifiers or '...' before 'pud_pte'
>  #define pud_write(pud)  pte_write(pud_pte(pud))
>                                    ^
> include/asm-generic/pgtable.h:817:19: note: in expansion of macro 'pud_write'
>  static inline int pud_write(pud_t pud)
>                    ^
>
> Caused by commit
>
>   5292abe86ee6 ("mm: fix device-dax pud write-faults triggered by get_user_pages()")
>
> grep is your friend ... there may be more fixes needed.

Ugh, yes. Looks correct. I might have confused my build success
notifications from 0day. I'll spin out a new branch to make sure this
is the last of it.

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

* linux-next: build failure after merge of the akpm-current tree
@ 2017-11-20  1:57 Stephen Rothwell
  2017-11-20  4:25 ` Dan Williams
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2017-11-20  1:57 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Dan Williams

Hi Andrew,

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

In file included from arch/powerpc/include/asm/book3s/64/mmu
-hash.h:24:0,
                 from arch/powerpc/include/asm/book3s/64/mmu.h:30,
                 from arch/powerpc/include/asm/mmu.h:305,
                 from arch/powerpc/include/asm/lppaca.h:36,
                 from arch/powerpc/include/asm/paca.h:21,
                 from arch/powerpc/include/asm/current.h:16,
                 from include/linux/sched.h:12,
                 from arch/powerpc/kernel/asm-offsets.c:17:
arch/powerpc/include/asm/book3s/64/pgtable.h:844:35: error: expected declaration specifiers or '...' before 'pud_pte'
 #define pud_write(pud)  pte_write(pud_pte(pud))
                                   ^
include/asm-generic/pgtable.h:817:19: note: in expansion of macro 'pud_write'
 static inline int pud_write(pud_t pud)
                   ^

Caused by commit

  5292abe86ee6 ("mm: fix device-dax pud write-faults triggered by get_user_pages()")

grep is your friend ... there may be more fixes needed.

I added the following fix patch:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 20 Nov 2017 12:52:24 +1100
Subject: [PATCH] mm: fix device-dax pud write-faults triggered by
 get_user_pages() fix

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/powerpc/include/asm/book3s/64/pgtable.h | 1 +
 arch/powerpc/include/asm/nohash/64/pgtable.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h b/arch/powerpc/include/asm/book3s/64/pgtable.h
index 9a677cd5997f..700b26cbd867 100644
--- a/arch/powerpc/include/asm/book3s/64/pgtable.h
+++ b/arch/powerpc/include/asm/book3s/64/pgtable.h
@@ -841,6 +841,7 @@ static inline pud_t pte_pud(pte_t pte)
 {
 	return __pud_raw(pte_raw(pte));
 }
+#define __HAVE_ARCH_PUD_WRITE
 #define pud_write(pud)		pte_write(pud_pte(pud))
 
 static inline int pud_bad(pud_t pud)
diff --git a/arch/powerpc/include/asm/nohash/64/pgtable.h b/arch/powerpc/include/asm/nohash/64/pgtable.h
index abddf5830ad5..424053fdf8d2 100644
--- a/arch/powerpc/include/asm/nohash/64/pgtable.h
+++ b/arch/powerpc/include/asm/nohash/64/pgtable.h
@@ -144,6 +144,7 @@ static inline pud_t pte_pud(pte_t pte)
 {
 	return __pud(pte_val(pte));
 }
+#define __HAVE_ARCH_PUD_WRITE
 #define pud_write(pud)		pte_write(pud_pte(pud))
 #define pgd_write(pgd)		pte_write(pgd_pte(pgd))
 
-- 
2.15.0

-- 
Cheers,
Stephen Rothwell

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

* linux-next: build failure after merge of the akpm-current tree
@ 2017-10-13  2:38 Mark Brown
  0 siblings, 0 replies; 330+ messages in thread
From: Mark Brown @ 2017-10-13  2:38 UTC (permalink / raw)
  To: Andrew Morton, Jakub Kicinski, Simon Horman, David S. Miller
  Cc: netdev, Linux-Next Mailing List, Linux Kernel Mailing List

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

Hi Andrew,

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

  CC [M]  drivers/net/ethernet/netronome/nfp/nfp_app.o
In file included from /home/broonie/tmpfs/next/drivers/net/ethernet/netronome/nfp/nfp_asm.c:40:0:
/home/broonie/tmpfs/next/drivers/net/ethernet/netronome/nfp/nfp_asm.h: In function '__enc_swreg_lm':
/home/broonie/tmpfs/next/drivers/net/ethernet/netronome/nfp/nfp_asm.h:301:2: error: implicit declaration of function 'WARN_ON' [-Werror=implicit-function-declaration]
  WARN_ON(id > 3 || (off && mode != NN_LM_MOD_NONE));
  ^
cc1: some warnings being treated as errors

Caused by some reliance on an implicit include being exposed by a header
reorganization in your tree.  I'll add a patch for this which I'll post,
probably tomorrow morning.

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

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2017-09-08  3:43                   ` Stephen Rothwell
@ 2017-09-08 17:54                     ` Zi Yan
  0 siblings, 0 replies; 330+ messages in thread
From: Zi Yan @ 2017-09-08 17:54 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Linux-Next Mailing List, Linux Kernel Mailing List

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

I checked. __pmd() works.

BTW, my sparc32 fix was added in linux-next on August 11th
and __pmd() is there, too. This means __pmd() + my fix has survived
for almost a month in linux-next. It should be good.

--
Best Regards
Yan Zi

On 7 Sep 2017, at 23:43, Stephen Rothwell wrote:

> Hi all,
>
> On Fri, 8 Sep 2017 12:49:59 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> OK, so today I have applied this instead (which is the same as dropping
>> mm-thp-enable-thp-migration-in-generic-path-fix-fix-fix):
>>
>> From: Stephen Rothwell <sfr@canb.auug.org.au>
>> Date: Fri, 8 Sep 2017 12:40:39 +1000
>> Subject: [PATCH] mm-thp-enable-thp-migration-in-generic-path-fix-fix
>>
>> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
>> ---
>>  include/linux/swapops.h | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/include/linux/swapops.h b/include/linux/swapops.h
>> index b88441d284e2..291c4b534658 100644
>> --- a/include/linux/swapops.h
>> +++ b/include/linux/swapops.h
>> @@ -291,7 +291,7 @@ static inline swp_entry_t pmd_to_swp_entry(pmd_t pmd)
>>
>>  static inline pmd_t swp_entry_to_pmd(swp_entry_t entry)
>>  {
>> -	return (pmd_t){};
>> +	return __pmd(0);
>>  }
>>
>>  static inline int is_pmd_migration_entry(pmd_t pmd)
>
> That survived my "during the day" builds (including sparc32).  Some one
> should just check the overnight build results:
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fkisskb.ellerman.id.au%2Flinux-next&data=02%7C01%7Czi.yan%40cs.rutgers.edu%7C2fd0d9ae031f4c49a49208d4f66bcc34%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C0%7C636404390233531971&sdata=%2F2RdKh9%2Fl5P8F1sIticPEnTLJaWyt0xR%2BV6YXFBhsRs%3D&reserved=0
> -- 
> Cheers,
> Stephen Rothwell

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

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2017-09-08  2:49                 ` Stephen Rothwell
@ 2017-09-08  3:43                   ` Stephen Rothwell
  2017-09-08 17:54                     ` Zi Yan
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2017-09-08  3:43 UTC (permalink / raw)
  To: Zi Yan; +Cc: Andrew Morton, Linux-Next Mailing List, Linux Kernel Mailing List

Hi all,

On Fri, 8 Sep 2017 12:49:59 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> OK, so today I have applied this instead (which is the same as dropping
> mm-thp-enable-thp-migration-in-generic-path-fix-fix-fix):
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 8 Sep 2017 12:40:39 +1000
> Subject: [PATCH] mm-thp-enable-thp-migration-in-generic-path-fix-fix
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  include/linux/swapops.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/linux/swapops.h b/include/linux/swapops.h
> index b88441d284e2..291c4b534658 100644
> --- a/include/linux/swapops.h
> +++ b/include/linux/swapops.h
> @@ -291,7 +291,7 @@ static inline swp_entry_t pmd_to_swp_entry(pmd_t pmd)
>  
>  static inline pmd_t swp_entry_to_pmd(swp_entry_t entry)
>  {
> -	return (pmd_t){};
> +	return __pmd(0);
>  }
>  
>  static inline int is_pmd_migration_entry(pmd_t pmd)

That survived my "during the day" builds (including sparc32).  Some one
should just check the overnight build results:
http://kisskb.ellerman.id.au/linux-next
-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2017-09-07 10:59               ` Zi Yan
@ 2017-09-08  2:49                 ` Stephen Rothwell
  2017-09-08  3:43                   ` Stephen Rothwell
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2017-09-08  2:49 UTC (permalink / raw)
  To: Zi Yan; +Cc: Andrew Morton, Linux-Next Mailing List, Linux Kernel Mailing List

Hi all,

On Thu, 07 Sep 2017 06:59:09 -0400 "Zi Yan" <zi.yan@cs.rutgers.edu> wrote:
>
> I think __pmd(0) can be used now. I fixed __pmd() in sparc32 at commit
> 9157259d16a8ee8116a98d32f29b797689327e8d, which is in 4.13 now.
> I should have told you this earlier, sorry about that.
> 
> Just wonder if any other reason prevents us using __pmd().

OK, so today I have applied this instead (which is the same as dropping
mm-thp-enable-thp-migration-in-generic-path-fix-fix-fix):

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 8 Sep 2017 12:40:39 +1000
Subject: [PATCH] mm-thp-enable-thp-migration-in-generic-path-fix-fix

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 include/linux/swapops.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/swapops.h b/include/linux/swapops.h
index b88441d284e2..291c4b534658 100644
--- a/include/linux/swapops.h
+++ b/include/linux/swapops.h
@@ -291,7 +291,7 @@ static inline swp_entry_t pmd_to_swp_entry(pmd_t pmd)
 
 static inline pmd_t swp_entry_to_pmd(swp_entry_t entry)
 {
-	return (pmd_t){};
+	return __pmd(0);
 }
 
 static inline int is_pmd_migration_entry(pmd_t pmd)
-- 
2.13.2

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2017-09-07  7:46             ` Andrew Morton
@ 2017-09-07 10:59               ` Zi Yan
  2017-09-08  2:49                 ` Stephen Rothwell
  0 siblings, 1 reply; 330+ messages in thread
From: Zi Yan @ 2017-09-07 10:59 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Stephen Rothwell, Linux-Next Mailing List, Linux Kernel Mailing List

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

On 7 Sep 2017, at 3:46, Andrew Morton wrote:

> On Thu, 7 Sep 2017 15:23:55 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
>> Hi all,
>>
>> On Wed, 2 Aug 2017 16:31:45 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>>
>>> On Wed, 2 Aug 2017 15:45:54 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>>>
>>>> On Tue, 01 Aug 2017 09:08:01 -0400 "Zi Yan" <zi.yan@cs.rutgers.edu> wrote:
>>>>>
>>>>> I found two possible fixes.
>>>>>
>>>>> 1. This uses C++ zero initializer, GCC is OK with it.
>>>>> I tested with GCC 4.9.3 (has the initialization bug) and GCC 6.4.0.
>>>>>
>>>>> --- a/include/linux/swapops.h~a
>>>>> +++ a/include/linux/swapops.h
>>>>> @@ -217,7 +217,7 @@ static inline swp_entry_t pmd_to_swp_ent
>>>>>
>>>>>  static inline pmd_t swp_entry_to_pmd(swp_entry_t entry)
>>>>>  {
>>>>> -	return (pmd_t){ 0 };
>>>>> +	return (pmd_t){};
>>>>>  }
>>>>
>>>> I have done that for today ... please decide which is best (or find
>>>> something better - maybe every platform really needs to have a __pmd()
>>>> definition) and submit a real fix patch to Andrew.
>>>
>>> OK, that failed for my compiler (gcc 5.2.0) like this:
>>>
>>> In file included from mm/vmscan.c:55:0:
>>> include/linux/swapops.h: In function 'swp_entry_to_pmd':
>>> include/linux/swapops.h:226:16: error: empty scalar initializer
>>>   return (pmd_t){};
>>>                 ^
>>> include/linux/swapops.h:226:16: note: (near initialization for '(anonymous)')
>>
>> This has reappeared today :-( (for the arm multi_v7_defconfig build at
>> least)
>>
>>> So I used the other idea (on top of Andrew's current tree):
>>
>> The fix patch now looks like this:
>>
>> From: Stephen Rothwell <sfr@canb.auug.org.au>
>> Date: Wed, 2 Aug 2017 15:55:02 +1000
>> Subject: [PATCH] mm-thp-enable-thp-migration-in-generic-path-fix-fix
>>
>> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
>> ---
>>  include/linux/swapops.h | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/linux/swapops.h b/include/linux/swapops.h
>> index 45b092aa6419..61cffa148a79 100644
>> --- a/include/linux/swapops.h
>> +++ b/include/linux/swapops.h
>> @@ -223,7 +223,9 @@ static inline swp_entry_t pmd_to_swp_entry(pmd_t pmd)
>>
>>  static inline pmd_t swp_entry_to_pmd(swp_entry_t entry)
>>  {
>> -	return (pmd_t){};
>> +	pmd_t e;
>> +	memset(&e, 0, sizeof(pmd_t));
>> +	return e;
>>  }
>
> err, yeah.  I didn't want to add that one :(
>
> At the very least we should add a good comment explaining why we had to
> resort to this.

Hi Andrew,

I think __pmd(0) can be used now. I fixed __pmd() in sparc32 at commit
9157259d16a8ee8116a98d32f29b797689327e8d, which is in 4.13 now.
I should have told you this earlier, sorry about that.

Just wonder if any other reason prevents us using __pmd().

Thanks.

—
Best Regards,
Yan Zi

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

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2017-09-07  5:23           ` Stephen Rothwell
@ 2017-09-07  7:46             ` Andrew Morton
  2017-09-07 10:59               ` Zi Yan
  0 siblings, 1 reply; 330+ messages in thread
From: Andrew Morton @ 2017-09-07  7:46 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Zi Yan, Linux-Next Mailing List, Linux Kernel Mailing List

On Thu, 7 Sep 2017 15:23:55 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> On Wed, 2 Aug 2017 16:31:45 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > On Wed, 2 Aug 2017 15:45:54 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
> > > On Tue, 01 Aug 2017 09:08:01 -0400 "Zi Yan" <zi.yan@cs.rutgers.edu> wrote:  
> > > >
> > > > I found two possible fixes.
> > > > 
> > > > 1. This uses C++ zero initializer, GCC is OK with it.
> > > > I tested with GCC 4.9.3 (has the initialization bug) and GCC 6.4.0.
> > > > 
> > > > --- a/include/linux/swapops.h~a
> > > > +++ a/include/linux/swapops.h
> > > > @@ -217,7 +217,7 @@ static inline swp_entry_t pmd_to_swp_ent
> > > > 
> > > >  static inline pmd_t swp_entry_to_pmd(swp_entry_t entry)
> > > >  {
> > > > -	return (pmd_t){ 0 };
> > > > +	return (pmd_t){};
> > > >  }    
> > > 
> > > I have done that for today ... please decide which is best (or find
> > > something better - maybe every platform really needs to have a __pmd()
> > > definition) and submit a real fix patch to Andrew.  
> > 
> > OK, that failed for my compiler (gcc 5.2.0) like this:
> > 
> > In file included from mm/vmscan.c:55:0:
> > include/linux/swapops.h: In function 'swp_entry_to_pmd':
> > include/linux/swapops.h:226:16: error: empty scalar initializer
> >   return (pmd_t){};
> >                 ^
> > include/linux/swapops.h:226:16: note: (near initialization for '(anonymous)')
> 
> This has reappeared today :-( (for the arm multi_v7_defconfig build at
> least)
> 
> > So I used the other idea (on top of Andrew's current tree):
> 
> The fix patch now looks like this:
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 2 Aug 2017 15:55:02 +1000
> Subject: [PATCH] mm-thp-enable-thp-migration-in-generic-path-fix-fix
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  include/linux/swapops.h | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/include/linux/swapops.h b/include/linux/swapops.h
> index 45b092aa6419..61cffa148a79 100644
> --- a/include/linux/swapops.h
> +++ b/include/linux/swapops.h
> @@ -223,7 +223,9 @@ static inline swp_entry_t pmd_to_swp_entry(pmd_t pmd)
>  
>  static inline pmd_t swp_entry_to_pmd(swp_entry_t entry)
>  {
> -	return (pmd_t){};
> +	pmd_t e;
> +	memset(&e, 0, sizeof(pmd_t));
> +	return e;
>  }

err, yeah.  I didn't want to add that one :(

At the very least we should add a good comment explaining why we had to
resort to this.

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2017-08-02  6:31         ` Stephen Rothwell
@ 2017-09-07  5:23           ` Stephen Rothwell
  2017-09-07  7:46             ` Andrew Morton
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2017-09-07  5:23 UTC (permalink / raw)
  To: Zi Yan; +Cc: Andrew Morton, Linux-Next Mailing List, Linux Kernel Mailing List

Hi all,

On Wed, 2 Aug 2017 16:31:45 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Wed, 2 Aug 2017 15:45:54 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > On Tue, 01 Aug 2017 09:08:01 -0400 "Zi Yan" <zi.yan@cs.rutgers.edu> wrote:  
> > >
> > > I found two possible fixes.
> > > 
> > > 1. This uses C++ zero initializer, GCC is OK with it.
> > > I tested with GCC 4.9.3 (has the initialization bug) and GCC 6.4.0.
> > > 
> > > --- a/include/linux/swapops.h~a
> > > +++ a/include/linux/swapops.h
> > > @@ -217,7 +217,7 @@ static inline swp_entry_t pmd_to_swp_ent
> > > 
> > >  static inline pmd_t swp_entry_to_pmd(swp_entry_t entry)
> > >  {
> > > -	return (pmd_t){ 0 };
> > > +	return (pmd_t){};
> > >  }    
> > 
> > I have done that for today ... please decide which is best (or find
> > something better - maybe every platform really needs to have a __pmd()
> > definition) and submit a real fix patch to Andrew.  
> 
> OK, that failed for my compiler (gcc 5.2.0) like this:
> 
> In file included from mm/vmscan.c:55:0:
> include/linux/swapops.h: In function 'swp_entry_to_pmd':
> include/linux/swapops.h:226:16: error: empty scalar initializer
>   return (pmd_t){};
>                 ^
> include/linux/swapops.h:226:16: note: (near initialization for '(anonymous)')

This has reappeared today :-( (for the arm multi_v7_defconfig build at
least)

> So I used the other idea (on top of Andrew's current tree):

The fix patch now looks like this:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 2 Aug 2017 15:55:02 +1000
Subject: [PATCH] mm-thp-enable-thp-migration-in-generic-path-fix-fix

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 include/linux/swapops.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/linux/swapops.h b/include/linux/swapops.h
index 45b092aa6419..61cffa148a79 100644
--- a/include/linux/swapops.h
+++ b/include/linux/swapops.h
@@ -223,7 +223,9 @@ static inline swp_entry_t pmd_to_swp_entry(pmd_t pmd)
 
 static inline pmd_t swp_entry_to_pmd(swp_entry_t entry)
 {
-	return (pmd_t){};
+	pmd_t e;
+	memset(&e, 0, sizeof(pmd_t));
+	return e;
 }
 
 static inline int is_pmd_migration_entry(pmd_t pmd)

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2017-08-31  8:21 Stephen Rothwell
@ 2017-09-06 12:32 ` Martin Wilck
  0 siblings, 0 replies; 330+ messages in thread
From: Martin Wilck @ 2017-09-06 12:32 UTC (permalink / raw)
  To: Stephen Rothwell, Andrew Morton, Jens Axboe
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Kees Cook,
	Sagi Grimberg, Christoph Hellwig

Hello Stephen,

On Thu, 2017-08-31 at 18:21 +1000, Stephen Rothwell wrote:
> Hi Andrew,
> 
> After merging the akpm-current tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> In file included from
> /home/sfr/next/next/include/uapi/linux/uuid.h:21:0,
>                  from /home/sfr/next/next/include/linux/uuid.h:19,
>                  from
> /home/sfr/next/next/include/linux/mod_devicetable.h:12,
>                  from /home/sfr/next/next/scripts/mod/devicetable-
> offsets.c:2:
> /home/sfr/next/next/include/linux/string.h: In function
> 'memcpy_and_pad':
> /home/sfr/next/next/include/linux/string.h:450:3: error: implicit
> declaration of function 'fortify_panic' [-Werror=implicit-function-
> declaration]
>    fortify_panic(__func__);
>    ^
> 
> Caused by commit
> 
>   9b04e51112ba ("fortify: use WARN instead of BUG for now")
> 
> interacting with commit
> 
>   01f33c336e2d ("string.h: add memcpy_and_pad()")
> 
> from the block tree.
> 
> I have applied the following merge fix patch:
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 31 Aug 2017 18:13:43 +1000
> Subject: [PATCH] fortify: use WARN instead of BUG for now fix
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  include/linux/string.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/linux/string.h b/include/linux/string.h
> index edd2b6154b80..e3b713114732 100644
> --- a/include/linux/string.h
> +++ b/include/linux/string.h
> @@ -447,7 +447,7 @@ __FORTIFY_INLINE void memcpy_and_pad(void *dest,
> size_t dest_len,
>  			__read_overflow3();
>  	}
>  	if (dest_size < dest_len)
> -		fortify_panic(__func__);
> +		fortify_overflow(__func__);
>  	if (dest_len > count) {
>  		memcpy(dest, src, count);
>  		memset(dest + count, pad,  dest_len - count);
> -- 
> 2.13.2

Arnd Bergmann spotted another problem with that patch. I decided to rip
out the "fortify" related code. I'll send a patch in a follow-up email.

Regards,
Martin

-- 
Dr. Martin Wilck <mwilck@suse.com>, Tel. +49 (0)911 74053 2107
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

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

* linux-next: build failure after merge of the akpm-current tree
@ 2017-09-04  8:56 Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2017-09-04  8:56 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Jérôme Glisse, Evgeny Baskakov, John Hubbard,
	Mark Hairgrove, Sherry Cheung, Subhash Gutti

Hi Andrew,

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

/home/sfr/next/next/mm/hmm.c:202:2: error: unknown field 'invalidate_page' specified in initializer
  .invalidate_page = hmm_invalidate_page,
  ^
/home/sfr/next/next/mm/hmm.c:202:21: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
  .invalidate_page = hmm_invalidate_page,
                     ^

Caused by commit

  b49705c24406 ("mm/hmm/mirror: mirror process address space on device with HMM helpers")

interacting with commit

  5f32b265400d ("mm/mmu_notifier: kill invalidate_page")

from Linus' tree.

I have disabled CONFIG_HMM_MIRROR for today.

-- 
Cheers,
Stephen Rothwell

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

* linux-next: build failure after merge of the akpm-current tree
@ 2017-08-31  8:21 Stephen Rothwell
  2017-09-06 12:32 ` Martin Wilck
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2017-08-31  8:21 UTC (permalink / raw)
  To: Andrew Morton, Jens Axboe
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Kees Cook,
	Martin Wilck, Sagi Grimberg, Christoph Hellwig

Hi Andrew,

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

In file included from /home/sfr/next/next/include/uapi/linux/uuid.h:21:0,
                 from /home/sfr/next/next/include/linux/uuid.h:19,
                 from /home/sfr/next/next/include/linux/mod_devicetable.h:12,
                 from /home/sfr/next/next/scripts/mod/devicetable-offsets.c:2:
/home/sfr/next/next/include/linux/string.h: In function 'memcpy_and_pad':
/home/sfr/next/next/include/linux/string.h:450:3: error: implicit declaration of function 'fortify_panic' [-Werror=implicit-function-declaration]
   fortify_panic(__func__);
   ^

Caused by commit

  9b04e51112ba ("fortify: use WARN instead of BUG for now")

interacting with commit

  01f33c336e2d ("string.h: add memcpy_and_pad()")

from the block tree.

I have applied the following merge fix patch:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 31 Aug 2017 18:13:43 +1000
Subject: [PATCH] fortify: use WARN instead of BUG for now fix

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 include/linux/string.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/string.h b/include/linux/string.h
index edd2b6154b80..e3b713114732 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -447,7 +447,7 @@ __FORTIFY_INLINE void memcpy_and_pad(void *dest, size_t dest_len,
 			__read_overflow3();
 	}
 	if (dest_size < dest_len)
-		fortify_panic(__func__);
+		fortify_overflow(__func__);
 	if (dest_len > count) {
 		memcpy(dest, src, count);
 		memset(dest + count, pad,  dest_len - count);
-- 
2.13.2

-- 
Cheers,
Stephen Rothwell

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

* linux-next: build failure after merge of the akpm-current tree
@ 2017-08-28  8:18 Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2017-08-28  8:18 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Jérôme Glisse, Arnd Bergmann

Hi Andrew,

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

kernel/fork.c: In function 'mm_init':
kernel/fork.c:821:2: error: implicit declaration of function 'hmm_mm_init' [-Werror=implicit-function-declaration]
  hmm_mm_init(mm);
  ^
kernel/fork.c: In function '__mmdrop':
kernel/fork.c:900:2: error: implicit declaration of function 'hmm_mm_destroy' [-Werror=implicit-function-declaration]
  hmm_mm_destroy(mm);
  ^

Caused by commit

  af097d7ae64e ("mm/hmm: struct hmm is only use by HMM mirror functionality v2")

I added the following patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 28 Aug 2017 18:14:09 +1000
Subject: [PATCH] mm/hmm: struct hmm is only use by HMM mirror functionality v2 fix

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 include/linux/hmm.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/linux/hmm.h b/include/linux/hmm.h
index 9583d9a15f9c..0758072f6585 100644
--- a/include/linux/hmm.h
+++ b/include/linux/hmm.h
@@ -514,5 +514,8 @@ static inline void hmm_mm_init(struct mm_struct *mm) {}
 #endif /* IS_ENABLED(CONFIG_HMM_MIRROR) */
 
 
+#else /* IS_ENABLED(CONFIG_HMM) */
+static inline void hmm_mm_destroy(struct mm_struct *mm) {}
+static inline void hmm_mm_init(struct mm_struct *mm) {}
 #endif /* IS_ENABLED(CONFIG_HMM) */
 #endif /* LINUX_HMM_H */
-- 
2.13.2

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2017-08-25  9:34 ` Christoph Hellwig
@ 2017-08-25  9:35   ` Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2017-08-25  9:35 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Andrew Morton, Jens Axboe, Linux-Next Mailing List,
	Linux Kernel Mailing List, Minchan Kim

Hi Christoph,

On Fri, 25 Aug 2017 11:34:19 +0200 Christoph Hellwig <hch@lst.de> wrote:
>
> On Fri, Aug 25, 2017 at 06:12:54PM +1000, Stephen Rothwell wrote:
> > Hi all,
> > 
> > After merging the akpm-current tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> > 
> > drivers/block/zram/zram_drv.c: In function 'read_from_bdev_a
> > sync':
> > drivers/block/zram/zram_drv.c:461:5: error: 'struct bio' has
> >  no member named 'bi_bdev'
> >   bio->bi_bdev = zram->bdev;
> >      ^
> > drivers/block/zram/zram_drv.c: In function 'write_to_bdev':
> > drivers/block/zram/zram_drv.c:555:5: error: 'struct bio' has
> >  no member named 'bi_bdev'
> >   bio->bi_bdev = zram->bdev;  
> 
> Replace this with:
> 
> 	bio_set_dev(bio, zram->bdev);

Excellent thanks, I will do that in the next release.

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2017-08-25  8:12 Stephen Rothwell
@ 2017-08-25  9:34 ` Christoph Hellwig
  2017-08-25  9:35   ` Stephen Rothwell
  0 siblings, 1 reply; 330+ messages in thread
From: Christoph Hellwig @ 2017-08-25  9:34 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Jens Axboe, Linux-Next Mailing List,
	Linux Kernel Mailing List, Christoph Hellwig, Minchan Kim

On Fri, Aug 25, 2017 at 06:12:54PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the akpm-current tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/block/zram/zram_drv.c: In function 'read_from_bdev_a
> sync':
> drivers/block/zram/zram_drv.c:461:5: error: 'struct bio' has
>  no member named 'bi_bdev'
>   bio->bi_bdev = zram->bdev;
>      ^
> drivers/block/zram/zram_drv.c: In function 'write_to_bdev':
> drivers/block/zram/zram_drv.c:555:5: error: 'struct bio' has
>  no member named 'bi_bdev'
>   bio->bi_bdev = zram->bdev;

Replace this with:

	bio_set_dev(bio, zram->bdev);

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

* linux-next: build failure after merge of the akpm-current tree
@ 2017-08-25  8:12 Stephen Rothwell
  2017-08-25  9:34 ` Christoph Hellwig
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2017-08-25  8:12 UTC (permalink / raw)
  To: Andrew Morton, Jens Axboe
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Christoph Hellwig, Minchan Kim

Hi all,

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

drivers/block/zram/zram_drv.c: In function 'read_from_bdev_a
sync':
drivers/block/zram/zram_drv.c:461:5: error: 'struct bio' has
 no member named 'bi_bdev'
  bio->bi_bdev = zram->bdev;
     ^
drivers/block/zram/zram_drv.c: In function 'write_to_bdev':
drivers/block/zram/zram_drv.c:555:5: error: 'struct bio' has
 no member named 'bi_bdev'
  bio->bi_bdev = zram->bdev;
     ^

Caused by commits

  827180946edf ("zram: write incompressible pages to backing device")
  83ff0ec8b13f ("zram: read page from backing device")

interacting with commit

  74d46992e0d9 ("block: replace bi_bdev with a gendisk pointer and partitions index")

from the block tree.

I have no idea how to fix this up, so I just disabled CONFIG_ZRAM
for today.

If someone could look at providing a resolution, that would help.
-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2017-08-23 10:41 Stephen Rothwell
@ 2017-08-23 22:13 ` Andrew Morton
  0 siblings, 0 replies; 330+ messages in thread
From: Andrew Morton @ 2017-08-23 22:13 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Matthew Wilcox

On Wed, 23 Aug 2017 20:41:59 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> After merging the akpm-current tree, today's linux-next build (mips
> defconfig) failed like this:
> 
> In file included from include/linux/selection.h:11:0,
>                  from drivers/video/console/newport_con.c:16:
> include/linux/vt_buffer.h: In function 'scr_memsetw':
> include/linux/vt_buffer.h:34:2: error: implicit declaration of function 'memset16' [-Werror=implicit-function-declaration]
> include/linux/vt_buffer.h: In function 'scr_memcpyw':
> include/linux/vt_buffer.h:47:2: error: implicit declaration of function 'memcpy' [-Werror=implicit-function-declaration]
> include/linux/vt_buffer.h: In function 'scr_memmovew':
> include/linux/vt_buffer.h:66:2: error: implicit declaration of function 'memmove' [-Werror=implicit-function-declaration]
> In file included from include/linux/string.h:18:0,

This?

--- a/include/linux/vt_buffer.h~vga-optimise-console-scrolling-fix
+++ a/include/linux/vt_buffer.h
@@ -13,6 +13,7 @@
 #ifndef _LINUX_VT_BUFFER_H_
 #define _LINUX_VT_BUFFER_H_
 
+#include <linux/string.h>
 
 #if defined(CONFIG_VGA_CONSOLE) || defined(CONFIG_MDA_CONSOLE)
 #include <asm/vga.h>
_

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

* linux-next: build failure after merge of the akpm-current tree
@ 2017-08-23 10:41 Stephen Rothwell
  2017-08-23 22:13 ` Andrew Morton
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2017-08-23 10:41 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Matthew Wilcox

Hi Andrew,

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

In file included from include/linux/selection.h:11:0,
                 from drivers/video/console/newport_con.c:16:
include/linux/vt_buffer.h: In function 'scr_memsetw':
include/linux/vt_buffer.h:34:2: error: implicit declaration of function 'memset16' [-Werror=implicit-function-declaration]
include/linux/vt_buffer.h: In function 'scr_memcpyw':
include/linux/vt_buffer.h:47:2: error: implicit declaration of function 'memcpy' [-Werror=implicit-function-declaration]
include/linux/vt_buffer.h: In function 'scr_memmovew':
include/linux/vt_buffer.h:66:2: error: implicit declaration of function 'memmove' [-Werror=implicit-function-declaration]
In file included from include/linux/string.h:18:0,
                 from include/linux/bitmap.h:8,
                 from include/linux/cpumask.h:11,
                 from arch/mips/include/asm/processor.h:15,
                 from arch/mips/include/asm/thread_info.h:15,
                 from include/linux/thread_info.h:37,
                 from include/asm-generic/preempt.h:4,
                 from ./arch/mips/include/generated/asm/preempt.h:1,
                 from include/linux/preempt.h:80,
                 from include/linux/spinlock.h:50,
                 from include/linux/wait.h:8,
                 from include/linux/wait_bit.h:7,
                 from include/linux/fs.h:5,
                 from include/linux/tty.h:4,
                 from include/linux/vt_kern.h:11,
                 from drivers/video/console/newport_con.c:18:
arch/mips/include/asm/string.h: At top level:
arch/mips/include/asm/string.h:138:14: error: conflicting types for 'memcpy'
include/linux/vt_buffer.h:47:2: note: previous implicit declaration of 'memcpy' was here
arch/mips/include/asm/string.h:141:14: error: conflicting types for 'memmove'
include/linux/vt_buffer.h:66:2: note: previous implicit declaration of 'memmove' was here
In file included from include/linux/bitmap.h:8:0,
                 from include/linux/cpumask.h:11,
                 from arch/mips/include/asm/processor.h:15,
                 from arch/mips/include/asm/thread_info.h:15,
                 from include/linux/thread_info.h:37,
                 from include/asm-generic/preempt.h:4,
                 from ./arch/mips/include/generated/asm/preempt.h:1,
                 from include/linux/preempt.h:80,
                 from include/linux/spinlock.h:50,
                 from include/linux/wait.h:8,
                 from include/linux/wait_bit.h:7,
                 from include/linux/fs.h:5,
                 from include/linux/tty.h:4,
                 from include/linux/vt_kern.h:11,
                 from drivers/video/console/newport_con.c:18:
include/linux/string.h:104:14: error: conflicting types for 'memset16'
include/linux/vt_buffer.h:34:2: note: previous implicit declaration of 'memset16' was here

Caused by commit

  3cd3d896e663 ("vga: optimise console scrolling")

-- 
Cheers,
Stephen Rothwell

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

* linux-next: build failure after merge of the akpm-current tree
@ 2017-08-16  4:47 Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2017-08-16  4:47 UTC (permalink / raw)
  To: Andrew Morton, Daniel Vetter, Intel Graphics, DRI
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Michal Hocko,
	Jason Ekstrand, Chris Wilson, Dave Airlie

Hi all,

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

drivers/gpu/drm/i915/i915_gem_execbuffer.c: In function 'get_fence_array':
drivers/gpu/drm/i915/i915_gem_execbuffer.c:2163:20: error: 'GFP_TEMPORARY' undeclared (first use in this function)
     __GFP_NOWARN | GFP_TEMPORARY);
                    ^

Caused by commit

  4d6fc0a48c52 ("mm: treewide: remove GFP_TEMPORARY allocation flag")

interacting with commit

  cf6e7bac6357 ("drm/i915: Add support for drm syncobjs")

from the drm-intel tree.

I applied the following merge fix patch (and I suspect - given the
comments in the former commit message - that this could be applied to
the drm-intel tree right now without any problems):

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 16 Aug 2017 14:41:24 +1000
Subject: [PATCH] drm/i915: fix up for mm: treewide: remove GFP_TEMPORARY allocation flag

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 8fbdefe0216e..15ab3e6792f9 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -2160,7 +2160,7 @@ get_fence_array(struct drm_i915_gem_execbuffer2 *args,
 		return ERR_PTR(-EFAULT);
 
 	fences = kvmalloc_array(args->num_cliprects, sizeof(*fences),
-				__GFP_NOWARN | GFP_TEMPORARY);
+				__GFP_NOWARN | GFP_KERNEL);
 	if (!fences)
 		return ERR_PTR(-ENOMEM);
 
-- 
2.13.2

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2017-08-02  5:45       ` Stephen Rothwell
@ 2017-08-02  6:31         ` Stephen Rothwell
  2017-09-07  5:23           ` Stephen Rothwell
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2017-08-02  6:31 UTC (permalink / raw)
  To: Zi Yan; +Cc: Andrew Morton, Linux-Next Mailing List, Linux Kernel Mailing List

Hi all,

On Wed, 2 Aug 2017 15:45:54 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Tue, 01 Aug 2017 09:08:01 -0400 "Zi Yan" <zi.yan@cs.rutgers.edu> wrote:
> >
> > I found two possible fixes.
> > 
> > 1. This uses C++ zero initializer, GCC is OK with it.
> > I tested with GCC 4.9.3 (has the initialization bug) and GCC 6.4.0.
> > 
> > --- a/include/linux/swapops.h~a
> > +++ a/include/linux/swapops.h
> > @@ -217,7 +217,7 @@ static inline swp_entry_t pmd_to_swp_ent
> > 
> >  static inline pmd_t swp_entry_to_pmd(swp_entry_t entry)
> >  {
> > -	return (pmd_t){ 0 };
> > +	return (pmd_t){};
> >  }  
> 
> I have done that for today ... please decide which is best (or find
> something better - maybe every platform really needs to have a __pmd()
> definition) and submit a real fix patch to Andrew.

OK, that failed for my compiler (gcc 5.2.0) like this:

In file included from mm/vmscan.c:55:0:
include/linux/swapops.h: In function 'swp_entry_to_pmd':
include/linux/swapops.h:226:16: error: empty scalar initializer
  return (pmd_t){};
                ^
include/linux/swapops.h:226:16: note: (near initialization for '(anonymous)')

So I used the other idea (on top of Andrew's current tree):

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 2 Aug 2017 15:55:02 +1000
Subject: [PATCH] mm-thp-enable-thp-migration-in-generic-path-fix-fix

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 include/linux/swapops.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/linux/swapops.h b/include/linux/swapops.h
index 45b092aa6419..61cffa148a79 100644
--- a/include/linux/swapops.h
+++ b/include/linux/swapops.h
@@ -223,7 +223,9 @@ static inline swp_entry_t pmd_to_swp_entry(pmd_t pmd)
 
 static inline pmd_t swp_entry_to_pmd(swp_entry_t entry)
 {
-	return __pmd(0);
+	pmd_t e;
+	memset(&e, 0, sizeof(pmd_t));
+	return e;
 }
 
 static inline int is_pmd_migration_entry(pmd_t pmd)
-- 
2.13.2

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2017-08-01 13:08     ` Zi Yan
@ 2017-08-02  5:45       ` Stephen Rothwell
  2017-08-02  6:31         ` Stephen Rothwell
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2017-08-02  5:45 UTC (permalink / raw)
  To: Zi Yan; +Cc: Andrew Morton, Linux-Next Mailing List, Linux Kernel Mailing List

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

Hi Zi,

On Tue, 01 Aug 2017 09:08:01 -0400 "Zi Yan" <zi.yan@cs.rutgers.edu> wrote:
>
> I found two possible fixes.
> 
> 1. This uses C++ zero initializer, GCC is OK with it.
> I tested with GCC 4.9.3 (has the initialization bug) and GCC 6.4.0.
> 
> --- a/include/linux/swapops.h~a
> +++ a/include/linux/swapops.h
> @@ -217,7 +217,7 @@ static inline swp_entry_t pmd_to_swp_ent
> 
>  static inline pmd_t swp_entry_to_pmd(swp_entry_t entry)
>  {
> -	return (pmd_t){ 0 };
> +	return (pmd_t){};
>  }

I have done that for today ... please decide which is best (or find
something better - maybe every platform really needs to have a __pmd()
definition) and submit a real fix patch to Andrew.

-- 
Cheers,
Stephen Rothwell

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

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2017-08-01 11:30   ` Zi Yan
@ 2017-08-01 13:08     ` Zi Yan
  2017-08-02  5:45       ` Stephen Rothwell
  0 siblings, 1 reply; 330+ messages in thread
From: Zi Yan @ 2017-08-01 13:08 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Linux-Next Mailing List, Linux Kernel Mailing List

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

Hi Stephen,

I found two possible fixes.

1. This uses C++ zero initializer, GCC is OK with it.
I tested with GCC 4.9.3 (has the initialization bug) and GCC 6.4.0.

--- a/include/linux/swapops.h~a
+++ a/include/linux/swapops.h
@@ -217,7 +217,7 @@ static inline swp_entry_t pmd_to_swp_ent

 static inline pmd_t swp_entry_to_pmd(swp_entry_t entry)
 {
-	return (pmd_t){ 0 };
+	return (pmd_t){};
 }

 static inline int is_pmd_migration_entry(pmd_t pmd)


2. This is ugly but working.
It works with GCC 4.9.3 and GCC 6.4.0.


--- a/include/linux/swapops.h
+++ b/include/linux/swapops.h
@@ -219,7 +219,10 @@ static inline swp_entry_t pmd_to_swp_entry(pmd_t pmd)

 static inline pmd_t swp_entry_to_pmd(swp_entry_t entry)
 {
-       return (pmd_t){ 0 };
+       pmd_t e;
+       memset(&e, 0, sizeof(pmd_t));
+       return e;
 }

 static inline int is_pmd_migration_entry(pmd_t pmd)


—
Best Regards,
Yan Zi

On 1 Aug 2017, at 7:30, Zi Yan wrote:

> Hi Stephen,
>
> The warning after removing __pmd() is caused by a gcc bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119
> so (pmd_t) {0} causes warning in some GCC versions.
>
> __pmd() is defined in alpha, arm, arm64, frv, ia64, m32r, m68k, microblaze, mips, parisc,
> powerpc, s390, sh, sparc, tile, um, x86, and asm-generic, according to
> http://elixir.free-electrons.com/linux/latest/ident/__pmd
>
> I am not sure about whether arc, blackfin, c6x, cris, h8300, hexagon, metag, mn10300, nios2, score,
> xtensa use __pmd() in asm-generic or not.
>
> I am looking for other workarounds for this warning now.
>
>
> —
> Best Regards,
> Yan Zi
>
> On 1 Aug 2017, at 6:50, Stephen Rothwell wrote:
>
>> Hi all,
>>
>> On Tue, 1 Aug 2017 16:39:04 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>>
>>> After merging the akpm tree, today's linux-next build (sparc defconfig)
>>> failed like this:
>>>
>>> In file included from mm/vmscan.c:55:0:
>>> include/linux/swapops.h: In function 'swp_entry_to_pmd':
>>> include/linux/swapops.h:226:9: error: implicit declaration of function '__pmd' [-Werror=implicit-function-declaration]
>>>   return __pmd(0);
>>>          ^
>>> include/linux/swapops.h:226:9: error: incompatible types when returning type 'int' but 'pmd_t {aka struct <anonymous>}' was expected
>>>
>>> Caused by commit
>>>
>>>   9bb18490758c ("mm-thp-enable-thp-migration-in-generic-path-fix")
>>>
>>> It looks like sparc 32 bit has no __pmd() ...
>>>
>>> I have reverted that commit for today.
>>
>> OK, that is a pain as it causes many build warnings some of which are
>> treated as errors :-(  (see e.g.
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fkisskb.ellerman.id.au%2Fkisskb%2Fbuildresult%2F13112192%2F&data=02%7C01%7Czi.yan%40cs.rutgers.edu%7Cbf7a7ad57ad04505172f08d4d8cb31c5%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C0%7C636371814609835949&sdata=diTid245prNY3Jy1pPEaL5q8dSBifFVzliKRq54fXhk%3D&reserved=0).  So maybe
>> we need to fix sthe sparc32 build instead?  Are there any other
>> architectures/platforms that do not define __pmd() ?
>>
>> -- 
>> Cheers,
>> Stephen Rothwell

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

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2017-08-01 10:50 ` Stephen Rothwell
@ 2017-08-01 11:30   ` Zi Yan
  2017-08-01 13:08     ` Zi Yan
  0 siblings, 1 reply; 330+ messages in thread
From: Zi Yan @ 2017-08-01 11:30 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Linux-Next Mailing List, Linux Kernel Mailing List

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

Hi Stephen,

The warning after removing __pmd() is caused by a gcc bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119
so (pmd_t) {0} causes warning in some GCC versions.

__pmd() is defined in alpha, arm, arm64, frv, ia64, m32r, m68k, microblaze, mips, parisc,
powerpc, s390, sh, sparc, tile, um, x86, and asm-generic, according to
http://elixir.free-electrons.com/linux/latest/ident/__pmd

I am not sure about whether arc, blackfin, c6x, cris, h8300, hexagon, metag, mn10300, nios2, score,
xtensa use __pmd() in asm-generic or not.

I am looking for other workarounds for this warning now.


—
Best Regards,
Yan Zi

On 1 Aug 2017, at 6:50, Stephen Rothwell wrote:

> Hi all,
>
> On Tue, 1 Aug 2017 16:39:04 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> After merging the akpm tree, today's linux-next build (sparc defconfig)
>> failed like this:
>>
>> In file included from mm/vmscan.c:55:0:
>> include/linux/swapops.h: In function 'swp_entry_to_pmd':
>> include/linux/swapops.h:226:9: error: implicit declaration of function '__pmd' [-Werror=implicit-function-declaration]
>>   return __pmd(0);
>>          ^
>> include/linux/swapops.h:226:9: error: incompatible types when returning type 'int' but 'pmd_t {aka struct <anonymous>}' was expected
>>
>> Caused by commit
>>
>>   9bb18490758c ("mm-thp-enable-thp-migration-in-generic-path-fix")
>>
>> It looks like sparc 32 bit has no __pmd() ...
>>
>> I have reverted that commit for today.
>
> OK, that is a pain as it causes many build warnings some of which are
> treated as errors :-(  (see e.g.
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fkisskb.ellerman.id.au%2Fkisskb%2Fbuildresult%2F13112192%2F&data=02%7C01%7Czi.yan%40cs.rutgers.edu%7Cbf7a7ad57ad04505172f08d4d8cb31c5%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C0%7C636371814609835949&sdata=diTid245prNY3Jy1pPEaL5q8dSBifFVzliKRq54fXhk%3D&reserved=0).  So maybe
> we need to fix sthe sparc32 build instead?  Are there any other
> architectures/platforms that do not define __pmd() ?
>
> -- 
> Cheers,
> Stephen Rothwell

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

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2017-08-01  6:39 Stephen Rothwell
@ 2017-08-01 10:50 ` Stephen Rothwell
  2017-08-01 11:30   ` Zi Yan
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2017-08-01 10:50 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Zi Yan

Hi all,

On Tue, 1 Aug 2017 16:39:04 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the akpm tree, today's linux-next build (sparc defconfig)
> failed like this:
> 
> In file included from mm/vmscan.c:55:0:
> include/linux/swapops.h: In function 'swp_entry_to_pmd':
> include/linux/swapops.h:226:9: error: implicit declaration of function '__pmd' [-Werror=implicit-function-declaration]
>   return __pmd(0);
>          ^
> include/linux/swapops.h:226:9: error: incompatible types when returning type 'int' but 'pmd_t {aka struct <anonymous>}' was expected
> 
> Caused by commit
> 
>   9bb18490758c ("mm-thp-enable-thp-migration-in-generic-path-fix")
> 
> It looks like sparc 32 bit has no __pmd() ...
> 
> I have reverted that commit for today.

OK, that is a pain as it causes many build warnings some of which are
treated as errors :-(  (see e.g.
http://kisskb.ellerman.id.au/kisskb/buildresult/13112192/).  So maybe
we need to fix sthe sparc32 build instead?  Are there any other
architectures/platforms that do not define __pmd() ?

-- 
Cheers,
Stephen Rothwell

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

* linux-next: build failure after merge of the akpm-current tree
@ 2017-08-01  6:39 Stephen Rothwell
  2017-08-01 10:50 ` Stephen Rothwell
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2017-08-01  6:39 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Zi Yan

Hi Andrew,

After merging the akpm tree, today's linux-next build (sparc defconfig)
failed like this:

In file included from mm/vmscan.c:55:0:
include/linux/swapops.h: In function 'swp_entry_to_pmd':
include/linux/swapops.h:226:9: error: implicit declaration of function '__pmd' [-Werror=implicit-function-declaration]
  return __pmd(0);
         ^
include/linux/swapops.h:226:9: error: incompatible types when returning type 'int' but 'pmd_t {aka struct <anonymous>}' was expected

Caused by commit

  9bb18490758c ("mm-thp-enable-thp-migration-in-generic-path-fix")

It looks like sparc 32 bit has no __pmd() ...

I have reverted that commit for today.

-- 
Cheers,
Stephen Rothwell

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

* linux-next: build failure after merge of the akpm-current tree
@ 2017-08-01  5:29 Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2017-08-01  5:29 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) failed like this:

arch/powerpc/kernel/rtas.c: In function 'rtas_online_cpus_mask':
arch/powerpc/kernel/rtas.c:917:37: error: 'GFP_KENREL' undeclared (first use in this function)
   if (!alloc_cpumask_var(&tmp_mask, GFP_KENREL))
                                     ^

Caused by commit

  404170cf1c4c ("mm: treewide: remove GFP_TEMPORARY allocation flag")

I added the following patch:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 1 Aug 2017 15:25:33 +1000
Subject: [PATCH] mm: treewide: remove GFP_TEMPORARY allocation flag fix

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/powerpc/kernel/rtas.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index 90d27dcd0da8..1643e9e53655 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -914,7 +914,7 @@ int rtas_online_cpus_mask(cpumask_var_t cpus)
 	if (ret) {
 		cpumask_var_t tmp_mask;
 
-		if (!alloc_cpumask_var(&tmp_mask, GFP_KENREL))
+		if (!alloc_cpumask_var(&tmp_mask, GFP_KERNEL))
 			return ret;
 
 		/* Use tmp_mask to preserve cpus mask from first failure */
-- 
2.13.2

-- 
Cheers,
Stephen Rothwell

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

* linux-next: build failure after merge of the akpm-current tree
@ 2017-07-10  5:21 Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2017-07-10  5:21 UTC (permalink / raw)
  To: Andrew Morton, Al Viro
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Ian Abbott

Hi all,

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

In file included from include/uapi/linux/stddef.h:1:0,
                 from include/linux/stddef.h:4,
                 from include/uapi/linux/posix_types.h:4,
                 from include/uapi/linux/types.h:13,
                 from include/linux/types.h:5,
                 from include/linux/syscalls.h:71,
                 from fs/dcache.c:17:
fs/dcache.c: In function 'release_dentry_name_snapshot':
include/linux/compiler.h:542:38: error: call to '__compiletime_assert_305' declared with attribute error: pointer type mismatch in container_of()
  _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
                                      ^
include/linux/compiler.h:525:4: note: in definition of macro '__compiletime_assert'
    prefix ## suffix();    \
    ^
include/linux/compiler.h:542:2: note: in expansion of macro '_compiletime_assert'
  _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
  ^
include/linux/build_bug.h:46:37: note: in expansion of macro 'compiletime_assert'
 #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
                                     ^
include/linux/kernel.h:860:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
  BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \
  ^
fs/dcache.c:305:7: note: in expansion of macro 'container_of'
   p = container_of(name->name, struct external_name, name[0]);
       ^

Caused by commit

  2f23633e9c84 ("kernel.h: handle pointers to arrays better in container_of()")

interacting with commit

  49d31c2f389a ("dentry name snapshots")

from the vfs tree.

I applied the following fix patch.  I hope it is ok.  If so, please
apply to the vfs tree.

-- 
Cheers,
Stephen Rothwell

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 10 Jul 2017 15:09:12 +1000
Subject: [PATCH] fix type for "dentry name snapshots"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 include/linux/dcache.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/dcache.h b/include/linux/dcache.h
index fcaba2d8638a..aae1cdb76851 100644
--- a/include/linux/dcache.h
+++ b/include/linux/dcache.h
@@ -597,8 +597,8 @@ static inline struct inode *d_real_inode(const struct dentry *dentry)
 }
 
 struct name_snapshot {
-	const char *name;
-	char inline_name[DNAME_INLINE_LEN];
+	const unsigned char *name;
+	unsigned char inline_name[DNAME_INLINE_LEN];
 };
 void take_dentry_name_snapshot(struct name_snapshot *, struct dentry *);
 void release_dentry_name_snapshot(struct name_snapshot *);
-- 
2.13.2

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2017-06-16 17:17         ` Andrew Morton
@ 2017-06-19 20:28           ` Kees Cook
  0 siblings, 0 replies; 330+ messages in thread
From: Kees Cook @ 2017-06-19 20:28 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Stephen Rothwell, Linux-Next Mailing List,
	Linux Kernel Mailing List, Daniel Micay

On Fri, Jun 16, 2017 at 10:17 AM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Thu, 15 Jun 2017 16:46:33 -0700 Kees Cook <keescook@chromium.org> wrote:
>
>> On Thu, Jun 15, 2017 at 12:12 PM, Andrew Morton
>> <akpm@linux-foundation.org> wrote:
>> > On Wed, 14 Jun 2017 18:56:30 -0700 Kees Cook <keescook@chromium.org> wrote:
>> >
>> >> >> Caused by commit
>> >> >>
>> >> >>   088a5ecf7581 ("include/linux/string.h: add the option of fortified string.h functions")
>> >> >>
>> >> >> We really need to fix all the known problems it detects *before*
>> >> >> merging this commit ...
>> >> >>
>> >> >> I have reverted it for today.
>> >> >
>> >> > I am still needing to revert this every day ...
>> >>
>> >> I sent a series for -mm (or maintainers) to merge that should catch
>> >> everything. Do you want me to carry it in my kspp tree instead? (My
>> >> original intention was to carry all the fixes and the fortify patch in
>> >> kspp but akpm took it into -mm somewhat unexpectedly, not that I'm
>> >> complaining.)
>> >
>> > This is all getting a bit foggy in my mind.  Can we please have a full
>> > resend of everything?  Sufficient to hopefully produce a tree which has
>> > no build-time or run-time regressions?  Including the buildbot's
>> > recently-reported alpha and xtensa issues?
>>
>> It's been sent a few times (and a few fixes have been collected in
>> other trees already). What I've got in my for-next/kspp tree right now
>> is all the fixes that haven't already been picked up by other tree
>> maintainers, and I added the fortify patch itself to the end of the
>> tree too now since sfr asked for that a few hours ago.
>
> I think it's best to try to keep everything in a single tree, with
> maintainer acks where possible.
>
> I do this stuff all the time - please just send everything at me when
> we think we have all the fixes and I'll sort it out.

I'll send you the series now and remove it from my kspp tree.

-Kees

-- 
Kees Cook
Pixel Security

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

* linux-next: build failure after merge of the akpm-current tree
@ 2017-06-19  8:14 Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2017-06-19  8:14 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Thomas Meyer,
	David S. Miller, Rich Felker

Hi Andrew,

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

arch/sparc/mm/extable.c:16:1: error: conflicting types for 'search_extable'
 search_extable(const struct exception_table_entry *start,
 ^
In file included from arch/sparc/mm/extable.c:6:0:
include/linux/extable.h:11:1: note: previous declaration of 'search_extable' was here
 search_extable(const struct exception_table_entry *first,
 ^

Caused by commit

  222785199d50 ("lib/extable.c: use bsearch() library function in search_extable()")

This would also affect the sh architecture.  Grep is your friend.  I am
not sure why they have separate implementations.

I have reverted that commit (and its following fixup) for today.

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2017-06-15 23:46       ` Kees Cook
  2017-06-16  0:05         ` Daniel Micay
@ 2017-06-16 17:17         ` Andrew Morton
  2017-06-19 20:28           ` Kees Cook
  1 sibling, 1 reply; 330+ messages in thread
From: Andrew Morton @ 2017-06-16 17:17 UTC (permalink / raw)
  To: Kees Cook
  Cc: Stephen Rothwell, Linux-Next Mailing List,
	Linux Kernel Mailing List, Daniel Micay

On Thu, 15 Jun 2017 16:46:33 -0700 Kees Cook <keescook@chromium.org> wrote:

> On Thu, Jun 15, 2017 at 12:12 PM, Andrew Morton
> <akpm@linux-foundation.org> wrote:
> > On Wed, 14 Jun 2017 18:56:30 -0700 Kees Cook <keescook@chromium.org> wrote:
> >
> >> >> Caused by commit
> >> >>
> >> >>   088a5ecf7581 ("include/linux/string.h: add the option of fortified string.h functions")
> >> >>
> >> >> We really need to fix all the known problems it detects *before*
> >> >> merging this commit ...
> >> >>
> >> >> I have reverted it for today.
> >> >
> >> > I am still needing to revert this every day ...
> >>
> >> I sent a series for -mm (or maintainers) to merge that should catch
> >> everything. Do you want me to carry it in my kspp tree instead? (My
> >> original intention was to carry all the fixes and the fortify patch in
> >> kspp but akpm took it into -mm somewhat unexpectedly, not that I'm
> >> complaining.)
> >
> > This is all getting a bit foggy in my mind.  Can we please have a full
> > resend of everything?  Sufficient to hopefully produce a tree which has
> > no build-time or run-time regressions?  Including the buildbot's
> > recently-reported alpha and xtensa issues?
> 
> It's been sent a few times (and a few fixes have been collected in
> other trees already). What I've got in my for-next/kspp tree right now
> is all the fixes that haven't already been picked up by other tree
> maintainers, and I added the fortify patch itself to the end of the
> tree too now since sfr asked for that a few hours ago.

I think it's best to try to keep everything in a single tree, with
maintainer acks where possible.

I do this stuff all the time - please just send everything at me when
we think we have all the fixes and I'll sort it out.

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2017-06-16  0:35           ` Kees Cook
@ 2017-06-16  1:20             ` Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2017-06-16  1:20 UTC (permalink / raw)
  To: Kees Cook
  Cc: Daniel Micay, Andrew Morton, Linux-Next Mailing List,
	Linux Kernel Mailing List

Hi Kees,

On Thu, 15 Jun 2017 17:35:43 -0700 Kees Cook <keescook@chromium.org> wrote:
>
> Sounds good. I've added ARCH_HAS_FORTIFY_SOURCE to the patch (and noted it).

And that just made it in time for today's linux-next.  I have removed
the patches from Andrew's tree.

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2017-06-16  0:05         ` Daniel Micay
@ 2017-06-16  0:35           ` Kees Cook
  2017-06-16  1:20             ` Stephen Rothwell
  0 siblings, 1 reply; 330+ messages in thread
From: Kees Cook @ 2017-06-16  0:35 UTC (permalink / raw)
  To: Daniel Micay
  Cc: Andrew Morton, Stephen Rothwell, Linux-Next Mailing List,
	Linux Kernel Mailing List

On Thu, Jun 15, 2017 at 5:05 PM, Daniel Micay <danielmicay@gmail.com> wrote:
> On Thu, 2017-06-15 at 16:46 -0700, Kees Cook wrote:
>> On Thu, Jun 15, 2017 at 12:12 PM, Andrew Morton
>> <akpm@linux-foundation.org> wrote:
>> > On Wed, 14 Jun 2017 18:56:30 -0700 Kees Cook <keescook@chromium.org>
>> > wrote:
>> >
>> > > > > Caused by commit
>> > > > >
>> > > > >   088a5ecf7581 ("include/linux/string.h: add the option of
>> > > > > fortified string.h functions")
>> > > > >
>> > > > > We really need to fix all the known problems it detects
>> > > > > *before*
>> > > > > merging this commit ...
>> > > > >
>> > > > > I have reverted it for today.
>> > > >
>> > > > I am still needing to revert this every day ...
>> > >
>> > > I sent a series for -mm (or maintainers) to merge that should
>> > > catch
>> > > everything. Do you want me to carry it in my kspp tree instead?
>> > > (My
>> > > original intention was to carry all the fixes and the fortify
>> > > patch in
>> > > kspp but akpm took it into -mm somewhat unexpectedly, not that I'm
>> > > complaining.)
>> >
>> > This is all getting a bit foggy in my mind.  Can we please have a
>> > full
>> > resend of everything?  Sufficient to hopefully produce a tree which
>> > has
>> > no build-time or run-time regressions?  Including the buildbot's
>> > recently-reported alpha and xtensa issues?
>>
>> It's been sent a few times (and a few fixes have been collected in
>> other trees already). What I've got in my for-next/kspp tree right now
>> is all the fixes that haven't already been picked up by other tree
>> maintainers, and I added the fortify patch itself to the end of the
>> tree too now since sfr asked for that a few hours ago.
>>
>> Merged with latest -next, this passes x86_64, i386, arm64, and powerpc
>> allmodconfig builds for me. It doesn't pass arm, though. Perhaps we
>> need to add an ARCH_HAS_FORTIFY_SOURCE to gate the all*config builds?
>>
>> Should we let the dust settle first? I'm happy to do whatever makes
>> the most sense, I'm just following what (I understand) sfr suggested
>> most recently. :)
>>
>> -Kees
>>
>
> If it needs to build and boot on every architecture, I think we should
> gate it on i386, x86_64, arm64 or powerpc where it has been tested.
>
> I think I know what has to be fixed for alpha and xtensa but there might
> be more problems. It's better to wait for someone willing / able to do
> it properly by building it themselves and doing basic runtime testing.

Sounds good. I've added ARCH_HAS_FORTIFY_SOURCE to the patch (and noted it).

-Kees

-- 
Kees Cook
Pixel Security

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2017-06-15 23:46       ` Kees Cook
@ 2017-06-16  0:05         ` Daniel Micay
  2017-06-16  0:35           ` Kees Cook
  2017-06-16 17:17         ` Andrew Morton
  1 sibling, 1 reply; 330+ messages in thread
From: Daniel Micay @ 2017-06-16  0:05 UTC (permalink / raw)
  To: Kees Cook, Andrew Morton
  Cc: Stephen Rothwell, Linux-Next Mailing List, Linux Kernel Mailing List

On Thu, 2017-06-15 at 16:46 -0700, Kees Cook wrote:
> On Thu, Jun 15, 2017 at 12:12 PM, Andrew Morton
> <akpm@linux-foundation.org> wrote:
> > On Wed, 14 Jun 2017 18:56:30 -0700 Kees Cook <keescook@chromium.org>
> > wrote:
> > 
> > > > > Caused by commit
> > > > > 
> > > > >   088a5ecf7581 ("include/linux/string.h: add the option of
> > > > > fortified string.h functions")
> > > > > 
> > > > > We really need to fix all the known problems it detects
> > > > > *before*
> > > > > merging this commit ...
> > > > > 
> > > > > I have reverted it for today.
> > > > 
> > > > I am still needing to revert this every day ...
> > > 
> > > I sent a series for -mm (or maintainers) to merge that should
> > > catch
> > > everything. Do you want me to carry it in my kspp tree instead?
> > > (My
> > > original intention was to carry all the fixes and the fortify
> > > patch in
> > > kspp but akpm took it into -mm somewhat unexpectedly, not that I'm
> > > complaining.)
> > 
> > This is all getting a bit foggy in my mind.  Can we please have a
> > full
> > resend of everything?  Sufficient to hopefully produce a tree which
> > has
> > no build-time or run-time regressions?  Including the buildbot's
> > recently-reported alpha and xtensa issues?
> 
> It's been sent a few times (and a few fixes have been collected in
> other trees already). What I've got in my for-next/kspp tree right now
> is all the fixes that haven't already been picked up by other tree
> maintainers, and I added the fortify patch itself to the end of the
> tree too now since sfr asked for that a few hours ago.
> 
> Merged with latest -next, this passes x86_64, i386, arm64, and powerpc
> allmodconfig builds for me. It doesn't pass arm, though. Perhaps we
> need to add an ARCH_HAS_FORTIFY_SOURCE to gate the all*config builds?
> 
> Should we let the dust settle first? I'm happy to do whatever makes
> the most sense, I'm just following what (I understand) sfr suggested
> most recently. :)
> 
> -Kees
> 

If it needs to build and boot on every architecture, I think we should
gate it on i386, x86_64, arm64 or powerpc where it has been tested.

I think I know what has to be fixed for alpha and xtensa but there might
be more problems. It's better to wait for someone willing / able to do
it properly by building it themselves and doing basic runtime testing.

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2017-06-15 19:12     ` Andrew Morton
@ 2017-06-15 23:46       ` Kees Cook
  2017-06-16  0:05         ` Daniel Micay
  2017-06-16 17:17         ` Andrew Morton
  0 siblings, 2 replies; 330+ messages in thread
From: Kees Cook @ 2017-06-15 23:46 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Stephen Rothwell, Linux-Next Mailing List,
	Linux Kernel Mailing List, Daniel Micay

On Thu, Jun 15, 2017 at 12:12 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Wed, 14 Jun 2017 18:56:30 -0700 Kees Cook <keescook@chromium.org> wrote:
>
>> >> Caused by commit
>> >>
>> >>   088a5ecf7581 ("include/linux/string.h: add the option of fortified string.h functions")
>> >>
>> >> We really need to fix all the known problems it detects *before*
>> >> merging this commit ...
>> >>
>> >> I have reverted it for today.
>> >
>> > I am still needing to revert this every day ...
>>
>> I sent a series for -mm (or maintainers) to merge that should catch
>> everything. Do you want me to carry it in my kspp tree instead? (My
>> original intention was to carry all the fixes and the fortify patch in
>> kspp but akpm took it into -mm somewhat unexpectedly, not that I'm
>> complaining.)
>
> This is all getting a bit foggy in my mind.  Can we please have a full
> resend of everything?  Sufficient to hopefully produce a tree which has
> no build-time or run-time regressions?  Including the buildbot's
> recently-reported alpha and xtensa issues?

It's been sent a few times (and a few fixes have been collected in
other trees already). What I've got in my for-next/kspp tree right now
is all the fixes that haven't already been picked up by other tree
maintainers, and I added the fortify patch itself to the end of the
tree too now since sfr asked for that a few hours ago.

Merged with latest -next, this passes x86_64, i386, arm64, and powerpc
allmodconfig builds for me. It doesn't pass arm, though. Perhaps we
need to add an ARCH_HAS_FORTIFY_SOURCE to gate the all*config builds?

Should we let the dust settle first? I'm happy to do whatever makes
the most sense, I'm just following what (I understand) sfr suggested
most recently. :)

-Kees

-- 
Kees Cook
Pixel Security

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2017-06-15  1:56   ` Kees Cook
  2017-06-15  1:58     ` Daniel Micay
  2017-06-15  2:06     ` Stephen Rothwell
@ 2017-06-15 19:12     ` Andrew Morton
  2017-06-15 23:46       ` Kees Cook
  2 siblings, 1 reply; 330+ messages in thread
From: Andrew Morton @ 2017-06-15 19:12 UTC (permalink / raw)
  To: Kees Cook
  Cc: Stephen Rothwell, Linux-Next Mailing List,
	Linux Kernel Mailing List, Daniel Micay

On Wed, 14 Jun 2017 18:56:30 -0700 Kees Cook <keescook@chromium.org> wrote:

> >> Caused by commit
> >>
> >>   088a5ecf7581 ("include/linux/string.h: add the option of fortified string.h functions")
> >>
> >> We really need to fix all the known problems it detects *before*
> >> merging this commit ...
> >>
> >> I have reverted it for today.
> >
> > I am still needing to revert this every day ...
> 
> I sent a series for -mm (or maintainers) to merge that should catch
> everything. Do you want me to carry it in my kspp tree instead? (My
> original intention was to carry all the fixes and the fortify patch in
> kspp but akpm took it into -mm somewhat unexpectedly, not that I'm
> complaining.)

This is all getting a bit foggy in my mind.  Can we please have a full
resend of everything?  Sufficient to hopefully produce a tree which has
no build-time or run-time regressions?  Including the buildbot's
recently-reported alpha and xtensa issues?

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2017-06-15  5:56           ` Michael Ellerman
@ 2017-06-15 15:19             ` Kees Cook
  0 siblings, 0 replies; 330+ messages in thread
From: Kees Cook @ 2017-06-15 15:19 UTC (permalink / raw)
  To: Michael Ellerman
  Cc: Daniel Micay, Stephen Rothwell, Andrew Morton,
	Linux-Next Mailing List, Linux Kernel Mailing List

]

On Wed, Jun 14, 2017 at 10:56 PM, Michael Ellerman <mpe@ellerman.id.au> wrote:
> Daniel Micay <danielmicay@gmail.com> writes:
>> ...
>>
>> The arch mailing list was pinged about this which is how the powerpc
>> folks got involved and fixed the issues there, including at least one
>> runtime one. Not sure where (if anywhere) those are queued up, but Kees
>> could pick those up too.
>
> I was expecting Kees to pick them up.

Okay, cool. I'll get them into the kspp tree.

-Kees

-- 
Kees Cook
Pixel Security

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2017-06-15  3:18         ` Daniel Micay
@ 2017-06-15  5:56           ` Michael Ellerman
  2017-06-15 15:19             ` Kees Cook
  0 siblings, 1 reply; 330+ messages in thread
From: Michael Ellerman @ 2017-06-15  5:56 UTC (permalink / raw)
  To: Daniel Micay, Kees Cook, Stephen Rothwell
  Cc: Andrew Morton, Linux-Next Mailing List, Linux Kernel Mailing List

Daniel Micay <danielmicay@gmail.com> writes:
> ...
>
> The arch mailing list was pinged about this which is how the powerpc
> folks got involved and fixed the issues there, including at least one
> runtime one. Not sure where (if anywhere) those are queued up, but Kees
> could pick those up too.

I was expecting Kees to pick them up.

cheers

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2017-06-15  2:16       ` Kees Cook
@ 2017-06-15  3:18         ` Daniel Micay
  2017-06-15  5:56           ` Michael Ellerman
  0 siblings, 1 reply; 330+ messages in thread
From: Daniel Micay @ 2017-06-15  3:18 UTC (permalink / raw)
  To: Kees Cook, Stephen Rothwell
  Cc: Andrew Morton, Linux-Next Mailing List, Linux Kernel Mailing List

On Wed, 2017-06-14 at 19:16 -0700, Kees Cook wrote:
> On Wed, Jun 14, 2017 at 7:06 PM, Stephen Rothwell <sfr@canb.auug.org.a
> u> wrote:
> > Hi Kees,
> > 
> > On Wed, 14 Jun 2017 18:56:30 -0700 Kees Cook <keescook@chromium.org>
> > wrote:
> > > 
> > > I sent a series for -mm (or maintainers) to merge that should
> > > catch
> > > everything. Do you want me to carry it in my kspp tree instead?
> > > (My
> > > original intention was to carry all the fixes and the fortify
> > > patch in
> > > kspp but akpm took it into -mm somewhat unexpectedly, not that I'm
> > > complaining.)
> > 
> > Andrew is currently not responding to stuff (he warned us last
> > week),
> > so if you do put the series in your tree, I will remove it from my
> > copy
> > of Andrew's quilt series.  All the fixes necessary to make this
> > usable
> > should really be in the same tree if possible.
> > 
> > (I am assuming that the fix patches have been reviewed and acked by
> > appropriate people.)
> 
> Mostly, yes. But they're usually trivial. All have been sent out for
> review (some a few times).
> 
> Given that the fixes are already scattered between various trees and
> you merge -mm last in -next, I'll just carry the remaining fixes and
> you can leave akpm's fortify patch in -mm.
> 
> -Kees

I think compile-time fixes should be totally done for 32-bit x86,
x86_64, arm64 and powerpc but the patches just aren't all queued up in
-mm/-next.

The arch mailing list was pinged about this which is how the powerpc
folks got involved and fixed the issues there, including at least one
runtime one. Not sure where (if anywhere) those are queued up, but Kees
could pick those up too.

For other archs, these might end up being issues requiring #ifndef
CONFIG_FORTIFY_SOURCE wrapped around them as was done for 32-bit x86, or
just removal because it's obsolete with GCC from the past 6+ years:

arch/alpha/include/asm/string.h:21:#define memcpy __builtin_memcpy
arch/m68k/include/asm/string.h:63:#define memcmp(d, s, n) __builtin_memcmp(d, s, n)
arch/m68k/include/asm/string.h:67:#define memset(d, c, n) __builtin_memset(d, c, n)
arch/m68k/include/asm/string.h:71:#define memcpy(d, s, n) __builtin_memcpy(d, s, n)

I didn't do anything about those because I can't compile it or test it
right now, but maybe someone can be pinged about it. Might be a one or
two other archs with the same issue. An -mm build bot complained about
alpha (probably that) and xtensa (seems to define inline functions in
arch/xtensa/include/asm/string.h).

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2017-06-15  2:19           ` Kees Cook
@ 2017-06-15  2:25             ` Daniel Micay
  0 siblings, 0 replies; 330+ messages in thread
From: Daniel Micay @ 2017-06-15  2:25 UTC (permalink / raw)
  To: Kees Cook
  Cc: Stephen Rothwell, Andrew Morton, Linux-Next Mailing List,
	Linux Kernel Mailing List

On Wed, 2017-06-14 at 19:19 -0700, Kees Cook wrote:
> On Wed, Jun 14, 2017 at 7:12 PM, Daniel Micay <danielmicay@gmail.com>
> wrote:
> > On Thu, 2017-06-15 at 12:04 +1000, Stephen Rothwell wrote:
> > > Hi Daniel,
> > > 
> > > On Wed, 14 Jun 2017 21:58:42 -0400 Daniel Micay <danielmicay@gmail
> > > .com
> > > > wrote:
> > > > 
> > > > They're false positive warnings. I think objtool has a list of
> > > > __noreturn functions and needs fortify_panic added there. It's
> > > > just
> > > > a
> > > > warning so it doesn't need to happen immediately.
> > > 
> > > There are *lots* of them, so it does need to be fixed (Linus will
> > > be
> > > very irritated if it hits his tree like that).  Create a patch to
> > > objtool and get the x86 guys to Ack it?
> > 
> > Okay, I'll send a patch. It turns out that it's very
> > straightforward.
> > 
> > c1fad9ef7ed14aad464972e6444e7a3bd5670f26 is an example of an earlier
> > one.
> 
> Oops, I just sent one too! :P I can use whatever; like you said, it's
> a trivial fix.
> 
> -Kees

Less work for me is better ;).

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2017-06-15  2:12         ` Daniel Micay
@ 2017-06-15  2:19           ` Kees Cook
  2017-06-15  2:25             ` Daniel Micay
  0 siblings, 1 reply; 330+ messages in thread
From: Kees Cook @ 2017-06-15  2:19 UTC (permalink / raw)
  To: Daniel Micay
  Cc: Stephen Rothwell, Andrew Morton, Linux-Next Mailing List,
	Linux Kernel Mailing List

On Wed, Jun 14, 2017 at 7:12 PM, Daniel Micay <danielmicay@gmail.com> wrote:
> On Thu, 2017-06-15 at 12:04 +1000, Stephen Rothwell wrote:
>> Hi Daniel,
>>
>> On Wed, 14 Jun 2017 21:58:42 -0400 Daniel Micay <danielmicay@gmail.com
>> > wrote:
>> >
>> > They're false positive warnings. I think objtool has a list of
>> > __noreturn functions and needs fortify_panic added there. It's just
>> > a
>> > warning so it doesn't need to happen immediately.
>>
>> There are *lots* of them, so it does need to be fixed (Linus will be
>> very irritated if it hits his tree like that).  Create a patch to
>> objtool and get the x86 guys to Ack it?
>
> Okay, I'll send a patch. It turns out that it's very straightforward.
>
> c1fad9ef7ed14aad464972e6444e7a3bd5670f26 is an example of an earlier
> one.

Oops, I just sent one too! :P I can use whatever; like you said, it's
a trivial fix.

-Kees

-- 
Kees Cook
Pixel Security

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2017-06-15  2:06     ` Stephen Rothwell
@ 2017-06-15  2:16       ` Kees Cook
  2017-06-15  3:18         ` Daniel Micay
  0 siblings, 1 reply; 330+ messages in thread
From: Kees Cook @ 2017-06-15  2:16 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Linux-Next Mailing List,
	Linux Kernel Mailing List, Daniel Micay

On Wed, Jun 14, 2017 at 7:06 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Kees,
>
> On Wed, 14 Jun 2017 18:56:30 -0700 Kees Cook <keescook@chromium.org> wrote:
>>
>> I sent a series for -mm (or maintainers) to merge that should catch
>> everything. Do you want me to carry it in my kspp tree instead? (My
>> original intention was to carry all the fixes and the fortify patch in
>> kspp but akpm took it into -mm somewhat unexpectedly, not that I'm
>> complaining.)
>
> Andrew is currently not responding to stuff (he warned us last week),
> so if you do put the series in your tree, I will remove it from my copy
> of Andrew's quilt series.  All the fixes necessary to make this usable
> should really be in the same tree if possible.
>
> (I am assuming that the fix patches have been reviewed and acked by
> appropriate people.)

Mostly, yes. But they're usually trivial. All have been sent out for
review (some a few times).

Given that the fixes are already scattered between various trees and
you merge -mm last in -next, I'll just carry the remaining fixes and
you can leave akpm's fortify patch in -mm.

-Kees

-- 
Kees Cook
Pixel Security

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2017-06-15  2:04       ` Stephen Rothwell
@ 2017-06-15  2:12         ` Daniel Micay
  2017-06-15  2:19           ` Kees Cook
  0 siblings, 1 reply; 330+ messages in thread
From: Daniel Micay @ 2017-06-15  2:12 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Kees Cook, Andrew Morton, Linux-Next Mailing List,
	Linux Kernel Mailing List

On Thu, 2017-06-15 at 12:04 +1000, Stephen Rothwell wrote:
> Hi Daniel,
> 
> On Wed, 14 Jun 2017 21:58:42 -0400 Daniel Micay <danielmicay@gmail.com
> > wrote:
> > 
> > They're false positive warnings. I think objtool has a list of
> > __noreturn functions and needs fortify_panic added there. It's just
> > a
> > warning so it doesn't need to happen immediately.
> 
> There are *lots* of them, so it does need to be fixed (Linus will be
> very irritated if it hits his tree like that).  Create a patch to
> objtool and get the x86 guys to Ack it?

Okay, I'll send a patch. It turns out that it's very straightforward.

c1fad9ef7ed14aad464972e6444e7a3bd5670f26 is an example of an earlier
one.

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2017-06-15  1:56   ` Kees Cook
  2017-06-15  1:58     ` Daniel Micay
@ 2017-06-15  2:06     ` Stephen Rothwell
  2017-06-15  2:16       ` Kees Cook
  2017-06-15 19:12     ` Andrew Morton
  2 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2017-06-15  2:06 UTC (permalink / raw)
  To: Kees Cook
  Cc: Andrew Morton, Linux-Next Mailing List,
	Linux Kernel Mailing List, Daniel Micay

Hi Kees,

On Wed, 14 Jun 2017 18:56:30 -0700 Kees Cook <keescook@chromium.org> wrote:
>
> I sent a series for -mm (or maintainers) to merge that should catch
> everything. Do you want me to carry it in my kspp tree instead? (My
> original intention was to carry all the fixes and the fortify patch in
> kspp but akpm took it into -mm somewhat unexpectedly, not that I'm
> complaining.)

Andrew is currently not responding to stuff (he warned us last week),
so if you do put the series in your tree, I will remove it from my copy
of Andrew's quilt series.  All the fixes necessary to make this usable
should really be in the same tree if possible.

(I am assuming that the fix patches have been reviewed and acked by
appropriate people.)
-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2017-06-15  1:58     ` Daniel Micay
@ 2017-06-15  2:04       ` Stephen Rothwell
  2017-06-15  2:12         ` Daniel Micay
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2017-06-15  2:04 UTC (permalink / raw)
  To: Daniel Micay
  Cc: Kees Cook, Andrew Morton, Linux-Next Mailing List,
	Linux Kernel Mailing List

Hi Daniel,

On Wed, 14 Jun 2017 21:58:42 -0400 Daniel Micay <danielmicay@gmail.com> wrote:
>
> They're false positive warnings. I think objtool has a list of
> __noreturn functions and needs fortify_panic added there. It's just a
> warning so it doesn't need to happen immediately.

There are *lots* of them, so it does need to be fixed (Linus will be
very irritated if it hits his tree like that).  Create a patch to
objtool and get the x86 guys to Ack it?

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2017-06-15  1:56   ` Kees Cook
@ 2017-06-15  1:58     ` Daniel Micay
  2017-06-15  2:04       ` Stephen Rothwell
  2017-06-15  2:06     ` Stephen Rothwell
  2017-06-15 19:12     ` Andrew Morton
  2 siblings, 1 reply; 330+ messages in thread
From: Daniel Micay @ 2017-06-15  1:58 UTC (permalink / raw)
  To: Kees Cook, Stephen Rothwell
  Cc: Andrew Morton, Linux-Next Mailing List, Linux Kernel Mailing List

On Wed, 2017-06-14 at 18:56 -0700, Kees Cook wrote:
> On Wed, Jun 14, 2017 at 6:35 PM, Stephen Rothwell <sfr@canb.auug.org.a
> u> wrote:
> > Hi all,
> > 
> > On Mon, 5 Jun 2017 17:01:17 +1000 Stephen Rothwell <sfr@canb.auug.or
> > g.au> wrote:
> > > 
> > > After merging the akpm-current tree, today's linux-next build
> > > (x86_64
> > > allmodconfig) failed like this:
> > > 
> > > sound/pcmcia/pdaudiocf/pdaudiocf.o: warning: objtool: .text:
> > > unexpected end of section
> > > arch/x86/ras/mce_amd_inj.o: warning: objtool: inj_readme_read()
> > > falls through to next function extcpu_fops_open()
> > > sound/sound_core.o: warning: objtool:
> > > register_sound_special_device() falls through to next function
> > > register_sound_special()
> 
> Are these related to the fortify patch? I wouldn't expect that...

They're false positive warnings. I think objtool has a list of
__noreturn functions and needs fortify_panic added there. It's just a
warning so it doesn't need to happen immediately.

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2017-06-15  1:35 ` Stephen Rothwell
@ 2017-06-15  1:56   ` Kees Cook
  2017-06-15  1:58     ` Daniel Micay
                       ` (2 more replies)
  0 siblings, 3 replies; 330+ messages in thread
From: Kees Cook @ 2017-06-15  1:56 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Linux-Next Mailing List,
	Linux Kernel Mailing List, Daniel Micay

On Wed, Jun 14, 2017 at 6:35 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> On Mon, 5 Jun 2017 17:01:17 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> After merging the akpm-current tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
>>
>> sound/pcmcia/pdaudiocf/pdaudiocf.o: warning: objtool: .text: unexpected end of section
>> arch/x86/ras/mce_amd_inj.o: warning: objtool: inj_readme_read() falls through to next function extcpu_fops_open()
>> sound/sound_core.o: warning: objtool: register_sound_special_device() falls through to next function register_sound_special()

Are these related to the fortify patch? I wouldn't expect that...

>>
>> and many more like those. Also:
>>
>> In file included from /home/sfr/next/next/include/linux/bitmap.h:8:0,
>>                  from /home/sfr/next/next/include/linux/cpumask.h:11,
>>                  from /home/sfr/next/next/arch/x86/include/asm/cpumask.h:4,
>>                  from /home/sfr/next/next/arch/x86/include/asm/msr.h:10,
>>                  from /home/sfr/next/next/arch/x86/include/asm/processor.h:20,
>>                  from /home/sfr/next/next/arch/x86/include/asm/cpufeature.h:4,
>>                  from /home/sfr/next/next/arch/x86/include/asm/thread_info.h:52,
>>                  from /home/sfr/next/next/include/linux/thread_info.h:37,
>>                  from /home/sfr/next/next/arch/x86/include/asm/preempt.h:6,
>>                  from /home/sfr/next/next/include/linux/preempt.h:80,
>>                  from /home/sfr/next/next/include/linux/spinlock.h:50,
>>                  from /home/sfr/next/next/include/linux/mmzone.h:7,
>>                  from /home/sfr/next/next/include/linux/gfp.h:5,
>>                  from /home/sfr/next/next/arch/x86/power/hibernate_64.c:11:
>> In function 'memcpy',
>>     inlined from 'relocate_restore_code' at /home/sfr/next/next/arch/x86/power/hibernate_64.c:150:2,
>>     inlined from 'swsusp_arch_resume' at /home/sfr/next/next/arch/x86/power/hibernate_64.c:185:8:
>> /home/sfr/next/next/include/linux/string.h:309:4: error: call to '__read_overflow2' declared with attribute error: detected read beyond size of object passed as 2nd parameter
>>     __read_overflow2();
>>     ^
>>
>> Caused by commit
>>
>>   088a5ecf7581 ("include/linux/string.h: add the option of fortified string.h functions")
>>
>> We really need to fix all the known problems it detects *before*
>> merging this commit ...
>>
>> I have reverted it for today.
>
> I am still needing to revert this every day ...

I sent a series for -mm (or maintainers) to merge that should catch
everything. Do you want me to carry it in my kspp tree instead? (My
original intention was to carry all the fixes and the fortify patch in
kspp but akpm took it into -mm somewhat unexpectedly, not that I'm
complaining.)

-Kees

-- 
Kees Cook
Pixel Security

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2017-06-05  7:01 Stephen Rothwell
  2017-06-05 13:06 ` Daniel Micay
@ 2017-06-15  1:35 ` Stephen Rothwell
  2017-06-15  1:56   ` Kees Cook
  1 sibling, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2017-06-15  1:35 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Daniel Micay,
	Kees Cook

Hi all,

On Mon, 5 Jun 2017 17:01:17 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the akpm-current tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> sound/pcmcia/pdaudiocf/pdaudiocf.o: warning: objtool: .text: unexpected end of section
> arch/x86/ras/mce_amd_inj.o: warning: objtool: inj_readme_read() falls through to next function extcpu_fops_open()
> sound/sound_core.o: warning: objtool: register_sound_special_device() falls through to next function register_sound_special()
> 
> and many more like those. Also:
> 
> In file included from /home/sfr/next/next/include/linux/bitmap.h:8:0,
>                  from /home/sfr/next/next/include/linux/cpumask.h:11,
>                  from /home/sfr/next/next/arch/x86/include/asm/cpumask.h:4,
>                  from /home/sfr/next/next/arch/x86/include/asm/msr.h:10,
>                  from /home/sfr/next/next/arch/x86/include/asm/processor.h:20,
>                  from /home/sfr/next/next/arch/x86/include/asm/cpufeature.h:4,
>                  from /home/sfr/next/next/arch/x86/include/asm/thread_info.h:52,
>                  from /home/sfr/next/next/include/linux/thread_info.h:37,
>                  from /home/sfr/next/next/arch/x86/include/asm/preempt.h:6,
>                  from /home/sfr/next/next/include/linux/preempt.h:80,
>                  from /home/sfr/next/next/include/linux/spinlock.h:50,
>                  from /home/sfr/next/next/include/linux/mmzone.h:7,
>                  from /home/sfr/next/next/include/linux/gfp.h:5,
>                  from /home/sfr/next/next/arch/x86/power/hibernate_64.c:11:
> In function 'memcpy',
>     inlined from 'relocate_restore_code' at /home/sfr/next/next/arch/x86/power/hibernate_64.c:150:2,
>     inlined from 'swsusp_arch_resume' at /home/sfr/next/next/arch/x86/power/hibernate_64.c:185:8:
> /home/sfr/next/next/include/linux/string.h:309:4: error: call to '__read_overflow2' declared with attribute error: detected read beyond size of object passed as 2nd parameter
>     __read_overflow2();
>     ^
> 
> Caused by commit
> 
>   088a5ecf7581 ("include/linux/string.h: add the option of fortified string.h functions")
> 
> We really need to fix all the known problems it detects *before*
> merging this commit ...
> 
> I have reverted it for today.

I am still needing to revert this every day ...

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2017-06-05 13:06 ` Daniel Micay
@ 2017-06-05 13:34   ` Daniel Micay
  0 siblings, 0 replies; 330+ messages in thread
From: Daniel Micay @ 2017-06-05 13:34 UTC (permalink / raw)
  To: Stephen Rothwell, Andrew Morton
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Kees Cook

> It also probably finds more architecture-specific issues and may need
> compatibility fixes for them. I could mark it as compatible with only
> arm64 and x86(_64) since they're what I've tested to build and work at
> runtime and the compile-time errors could be turned into warnings for
> now, if it's mandatory that FORTIFY_SOURCE=y doesn't find problems at
> compile-time anywhere. If it's a warning, it will still catch the
> issue
> at runtime like the rest where the size isn't a constant.

I'm already leaving out intra-object overflow checks and the alloc_size
attributes in this initial submission to make it easier to land so
scaling it back a bit more (errors -> warnings, gating on archs) isn't a
problem if it's needed to get started.

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2017-06-05  7:01 Stephen Rothwell
@ 2017-06-05 13:06 ` Daniel Micay
  2017-06-05 13:34   ` Daniel Micay
  2017-06-15  1:35 ` Stephen Rothwell
  1 sibling, 1 reply; 330+ messages in thread
From: Daniel Micay @ 2017-06-05 13:06 UTC (permalink / raw)
  To: Stephen Rothwell, Andrew Morton
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Kees Cook

On Mon, 2017-06-05 at 17:01 +1000, Stephen Rothwell wrote:
> Hi Andrew,
> 
> After merging the akpm-current tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> sound/pcmcia/pdaudiocf/pdaudiocf.o: warning: objtool: .text:
> unexpected end of section
> arch/x86/ras/mce_amd_inj.o: warning: objtool: inj_readme_read() falls
> through to next function extcpu_fops_open()
> sound/sound_core.o: warning: objtool: register_sound_special_device()
> falls through to next function register_sound_special()
> 
> and many more like those.

It looks like that's complaining about the __noreturn fortify_panic. It
isn't a compile-time error, just a false positive warning which needs to
be fixed in objtool. I guess it needs another symbol added to a hard-
wired list of __noreturn functions which sounds like it exists.

> In file included from /home/sfr/next/next/include/linux/bitmap.h:8:0,
>                  from /home/sfr/next/next/include/linux/cpumask.h:11,
>                  from
> /home/sfr/next/next/arch/x86/include/asm/cpumask.h:4,
>                  from
> /home/sfr/next/next/arch/x86/include/asm/msr.h:10,
>                  from
> /home/sfr/next/next/arch/x86/include/asm/processor.h:20,
>                  from
> /home/sfr/next/next/arch/x86/include/asm/cpufeature.h:4,
>                  from
> /home/sfr/next/next/arch/x86/include/asm/thread_info.h:52,
>                  from
> /home/sfr/next/next/include/linux/thread_info.h:37,
>                  from
> /home/sfr/next/next/arch/x86/include/asm/preempt.h:6,
>                  from /home/sfr/next/next/include/linux/preempt.h:80,
>                  from /home/sfr/next/next/include/linux/spinlock.h:50,
>                  from /home/sfr/next/next/include/linux/mmzone.h:7,
>                  from /home/sfr/next/next/include/linux/gfp.h:5,
>                  from
> /home/sfr/next/next/arch/x86/power/hibernate_64.c:11:
> In function 'memcpy',
>     inlined from 'relocate_restore_code' at
> /home/sfr/next/next/arch/x86/power/hibernate_64.c:150:2,
>     inlined from 'swsusp_arch_resume' at
> /home/sfr/next/next/arch/x86/power/hibernate_64.c:185:8:
> /home/sfr/next/next/include/linux/string.h:309:4: error: call to
> '__read_overflow2' declared with attribute error: detected read beyond
> size of object passed as 2nd parameter
>     __read_overflow2();
>     ^
> 
> Caused by commit
> 
>   088a5ecf7581 ("include/linux/string.h: add the option of fortified
> string.h functions")
> 
> We really need to fix all the known problems it detects *before*
> merging this commit ...
> 
> I have reverted it for today.

The errors caught at compile-time including these are all fixed, but not
all the fixes have landed in -next yet. They're in various other trees.
GCC 7 came out which found an extra bug or two which are now fixed too.
I guess those need to be queued up with it in -mm if it's going to land
with -mm but I wasn't sure how things were going to work.

It also probably finds more architecture-specific issues and may need
compatibility fixes for them. I could mark it as compatible with only
arm64 and x86(_64) since they're what I've tested to build and work at
runtime and the compile-time errors could be turned into warnings for
now, if it's mandatory that FORTIFY_SOURCE=y doesn't find problems at
compile-time anywhere. If it's a warning, it will still catch the issue
at runtime like the rest where the size isn't a constant.

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

* linux-next: build failure after merge of the akpm-current tree
@ 2017-06-05  7:01 Stephen Rothwell
  2017-06-05 13:06 ` Daniel Micay
  2017-06-15  1:35 ` Stephen Rothwell
  0 siblings, 2 replies; 330+ messages in thread
From: Stephen Rothwell @ 2017-06-05  7:01 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Daniel Micay,
	Kees Cook

Hi Andrew,

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

sound/pcmcia/pdaudiocf/pdaudiocf.o: warning: objtool: .text: unexpected end of section
arch/x86/ras/mce_amd_inj.o: warning: objtool: inj_readme_read() falls through to next function extcpu_fops_open()
sound/sound_core.o: warning: objtool: register_sound_special_device() falls through to next function register_sound_special()

and many more like those. Also:

In file included from /home/sfr/next/next/include/linux/bitmap.h:8:0,
                 from /home/sfr/next/next/include/linux/cpumask.h:11,
                 from /home/sfr/next/next/arch/x86/include/asm/cpumask.h:4,
                 from /home/sfr/next/next/arch/x86/include/asm/msr.h:10,
                 from /home/sfr/next/next/arch/x86/include/asm/processor.h:20,
                 from /home/sfr/next/next/arch/x86/include/asm/cpufeature.h:4,
                 from /home/sfr/next/next/arch/x86/include/asm/thread_info.h:52,
                 from /home/sfr/next/next/include/linux/thread_info.h:37,
                 from /home/sfr/next/next/arch/x86/include/asm/preempt.h:6,
                 from /home/sfr/next/next/include/linux/preempt.h:80,
                 from /home/sfr/next/next/include/linux/spinlock.h:50,
                 from /home/sfr/next/next/include/linux/mmzone.h:7,
                 from /home/sfr/next/next/include/linux/gfp.h:5,
                 from /home/sfr/next/next/arch/x86/power/hibernate_64.c:11:
In function 'memcpy',
    inlined from 'relocate_restore_code' at /home/sfr/next/next/arch/x86/power/hibernate_64.c:150:2,
    inlined from 'swsusp_arch_resume' at /home/sfr/next/next/arch/x86/power/hibernate_64.c:185:8:
/home/sfr/next/next/include/linux/string.h:309:4: error: call to '__read_overflow2' declared with attribute error: detected read beyond size of object passed as 2nd parameter
    __read_overflow2();
    ^

Caused by commit

  088a5ecf7581 ("include/linux/string.h: add the option of fortified string.h functions")

We really need to fix all the known problems it detects *before*
merging this commit ...

I have reverted it for today.
-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2017-04-10 21:33   ` Stephen Rothwell
@ 2017-04-10 23:55     ` Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2017-04-10 23:55 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Huang Ying

Hi Andrew,

On Tue, 11 Apr 2017 07:33:09 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Mon, 10 Apr 2017 14:06:06 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > No, mm-introduce-kvalloc-helpers.patch is still in there but I had it
> > staged after
> > mm-swap-use-kvzalloc-to-allocate-some-swap-data-structure.patch.  ANd
> > after linux-next.patch which is presumably what tricked you.  
> 
> Yeah, I noticed that later.  So presumably patch
> 
>   "mm, swap: U=use kvzalloc to allocate some swap data structure"
> 
> needs to be moved to after
> 
>   mm-introduce-kvalloc-helpers.patch

I have done that in linux-next today.

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2017-04-10 21:06 ` Andrew Morton
@ 2017-04-10 21:33   ` Stephen Rothwell
  2017-04-10 23:55     ` Stephen Rothwell
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2017-04-10 21:33 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Huang Ying

Hi Andrew,

On Mon, 10 Apr 2017 14:06:06 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> No, mm-introduce-kvalloc-helpers.patch is still in there but I had it
> staged after
> mm-swap-use-kvzalloc-to-allocate-some-swap-data-structure.patch.  ANd
> after linux-next.patch which is presumably what tricked you.

Yeah, I noticed that later.  So presumably patch

  "mm, swap: U=use kvzalloc to allocate some swap data structure"

needs to be moved to after

  mm-introduce-kvalloc-helpers.patch

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2017-04-10  6:45 Stephen Rothwell
@ 2017-04-10 21:06 ` Andrew Morton
  2017-04-10 21:33   ` Stephen Rothwell
  0 siblings, 1 reply; 330+ messages in thread
From: Andrew Morton @ 2017-04-10 21:06 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Huang Ying

On Mon, 10 Apr 2017 16:45:57 +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) failed like this:
> 
> mm/swap_slots.c: In function 'alloc_swap_slot_cache':
> mm/swap_slots.c:126:10: error: implicit declaration of function 'kvzalloc' [-Werror=implicit-function-declaration]
>   slots = kvzalloc(sizeof(swp_entry_t) * SWAP_SLOTS_CACHE_SIZE,
>           ^
> mm/swap_slots.c:126:8: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
>   slots = kvzalloc(sizeof(swp_entry_t) * SWAP_SLOTS_CACHE_SIZE,
>         ^
> mm/swap_slots.c:131:12: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
>   slots_ret = kvzalloc(sizeof(swp_entry_t) * SWAP_SLOTS_CACHE_SIZE,
>             ^
> 
> Caused by commit
> 
>   22cf2f4616c6 ("mm, swap: U=use kvzalloc to allocate some swap data structure")
> 
> The patches adding kvzalloc seem to have vanished :-(
> 
> I have reverted that commit for today.
> 

No, mm-introduce-kvalloc-helpers.patch is still in there but I had it
staged after
mm-swap-use-kvzalloc-to-allocate-some-swap-data-structure.patch.  ANd
after linux-next.patch which is presumably what tricked you.

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

* linux-next: build failure after merge of the akpm-current tree
@ 2017-04-10  6:45 Stephen Rothwell
  2017-04-10 21:06 ` Andrew Morton
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2017-04-10  6:45 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Huang Ying

Hi Andrew,

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

mm/swap_slots.c: In function 'alloc_swap_slot_cache':
mm/swap_slots.c:126:10: error: implicit declaration of function 'kvzalloc' [-Werror=implicit-function-declaration]
  slots = kvzalloc(sizeof(swp_entry_t) * SWAP_SLOTS_CACHE_SIZE,
          ^
mm/swap_slots.c:126:8: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
  slots = kvzalloc(sizeof(swp_entry_t) * SWAP_SLOTS_CACHE_SIZE,
        ^
mm/swap_slots.c:131:12: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
  slots_ret = kvzalloc(sizeof(swp_entry_t) * SWAP_SLOTS_CACHE_SIZE,
            ^

Caused by commit

  22cf2f4616c6 ("mm, swap: U=use kvzalloc to allocate some swap data structure")

The patches adding kvzalloc seem to have vanished :-(

I have reverted that commit for today.

-- 
Cheers,
Stephen Rothwell

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

* linux-next: build failure after merge of the akpm-current tree
@ 2017-02-14  5:59 Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2017-02-14  5:59 UTC (permalink / raw)
  To: Andrew Morton, Michael Ellerman, Benjamin Herrenschmidt, PowerPC
  Cc: linux-next, linux-kernel, Anju T, Luis R. Rodriguez

Hi Andrew,

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

arch/powerpc/lib/code-patching.c:61:16: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'is_conditional_branch'
 bool __kprobes is_conditional_branch(unsigned int instr)
                ^

Caused by commit

  916c821aaf13 ("kprobes: move kprobe declarations to asm-generic/kprobes.h")

interacting with commit

  51c9c0843993 ("powerpc/kprobes: Implement Optprobes")

from the powerpc tree.

I have applied this merge fix patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 14 Feb 2017 16:56:11 +1100
Subject: [PATCH] powerpc/kprobes: fixup for kprobes declarations moving

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/powerpc/lib/code-patching.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c
index 0899315e1434..0d3002b7e2b4 100644
--- a/arch/powerpc/lib/code-patching.c
+++ b/arch/powerpc/lib/code-patching.c
@@ -14,6 +14,7 @@
 #include <asm/page.h>
 #include <asm/code-patching.h>
 #include <linux/uaccess.h>
+#include <linux/kprobes.h>
 
 
 int patch_instruction(unsigned int *addr, unsigned int instr)
-- 
2.10.2

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2017-02-07 23:15 ` Andrew Morton
@ 2017-02-07 23:16   ` Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2017-02-07 23:16 UTC (permalink / raw)
  To: Andrew Morton
  Cc: linux-next, linux-kernel, Mike Rapoport, Mark Brown,
	kernel-build-reports, linaro-kernel, Hillf Danton

Hi Andrew,

On Tue, 7 Feb 2017 15:15:08 -0800 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> That patch has a string of fixes and I think we have that fixed up. 
> I'll be doing another mmotm in a few minutes...

Excellent, thanks.

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2017-02-07 23:08 Stephen Rothwell
@ 2017-02-07 23:15 ` Andrew Morton
  2017-02-07 23:16   ` Stephen Rothwell
  0 siblings, 1 reply; 330+ messages in thread
From: Andrew Morton @ 2017-02-07 23:15 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: linux-next, linux-kernel, Mike Rapoport, Mark Brown,
	kernel-build-reports, linaro-kernel, Hillf Danton

On Wed, 8 Feb 2017 10:08:03 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Andrew,
> 
> After merging the akpm-current tree, today's linux-next build (arm
> allnoconfig, bfin (most, if not all, configs) and many others) failed
> like this:
> 
> mm/nommu.c:1201:15: error: conflicting types for 'do_mmap'
> mm/nommu.c:1580:5: error: conflicting types for 'do_munmap'
> mm/nommu.c:1638:1: error: conflicting types for 'do_munmap'
> ipc/shm.c:1368:3: error: too few arguments to function 'do_munmap'
> 
> Caused by commit
> 
>   24424bfbce7e ("userfaultfd: non-cooperative: add event for memory unmaps")
> 
> This forgot to update the mm/nommu.c versions of these functions :-(
> 
> Sorry for not reporting this earlier.
> 
> I have no idea what to do about this as this patch is deep within the mm
> changes and so almost certainly will not revert cleanly (and dropping
> this patch will presumably have flow on effects to the reset of the
> mm patches).

That patch has a string of fixes and I think we have that fixed up. 
I'll be doing another mmotm in a few minutes...

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

* linux-next: build failure after merge of the akpm-current tree
@ 2017-02-07 23:08 Stephen Rothwell
  2017-02-07 23:15 ` Andrew Morton
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2017-02-07 23:08 UTC (permalink / raw)
  To: Andrew Morton
  Cc: linux-next, linux-kernel, Mike Rapoport, Mark Brown,
	kernel-build-reports, linaro-kernel, Hillf Danton

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (arm
allnoconfig, bfin (most, if not all, configs) and many others) failed
like this:

mm/nommu.c:1201:15: error: conflicting types for 'do_mmap'
mm/nommu.c:1580:5: error: conflicting types for 'do_munmap'
mm/nommu.c:1638:1: error: conflicting types for 'do_munmap'
ipc/shm.c:1368:3: error: too few arguments to function 'do_munmap'

Caused by commit

  24424bfbce7e ("userfaultfd: non-cooperative: add event for memory unmaps")

This forgot to update the mm/nommu.c versions of these functions :-(

Sorry for not reporting this earlier.

I have no idea what to do about this as this patch is deep within the mm
changes and so almost certainly will not revert cleanly (and dropping
this patch will presumably have flow on effects to the reset of the
mm patches).

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2017-01-13  3:42   ` Stephen Rothwell
@ 2017-01-13  6:01     ` Eric Ren
  0 siblings, 0 replies; 330+ messages in thread
From: Eric Ren @ 2017-01-13  6:01 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Andrew Morton, linux-next, linux-kernel

Hi,

On 01/13/2017 11:42 AM, Stephen Rothwell wrote:
> Hi Eric,
>
> On Thu, 12 Jan 2017 13:06:01 +0800 Eric Ren <zren@suse.com> wrote:
>> Thanks for your report and the fix for it. The 0-day project has reported several days ago,
>> but this patch set is still in discussion, so I am waiting for more days to see if  other
>> developers
>> have any other questions.
>>
>> I am confused that how to deal with your patch if I need to work out the V2 patch set. Perhaps,
>> pick up your fix and  add your efforts in the change log?
> If you had already fixed the problem, then just submit your new
> version.  You only need to give credit when you use someone's work.
>
> If you want to give credit, then maybe a line like:
>
> [sfr@canb.auug.org.au remove some inlines]
>
> among the Signed-off-by: lines
Sure! I always keep it in mind;-)

Thanks,
Eric

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2017-01-12  5:06 ` Eric Ren
  2017-01-12 23:33   ` Andrew Morton
@ 2017-01-13  3:42   ` Stephen Rothwell
  2017-01-13  6:01     ` Eric Ren
  1 sibling, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2017-01-13  3:42 UTC (permalink / raw)
  To: Eric Ren; +Cc: Andrew Morton, linux-next, linux-kernel

Hi Eric,

On Thu, 12 Jan 2017 13:06:01 +0800 Eric Ren <zren@suse.com> wrote:
>
> Thanks for your report and the fix for it. The 0-day project has reported several days ago,
> but this patch set is still in discussion, so I am waiting for more days to see if  other 
> developers
> have any other questions.
> 
> I am confused that how to deal with your patch if I need to work out the V2 patch set. Perhaps,
> pick up your fix and  add your efforts in the change log?

If you had already fixed the problem, then just submit your new
version.  You only need to give credit when you use someone's work.

If you want to give credit, then maybe a line like:

[sfr@canb.auug.org.au remove some inlines]

among the Signed-off-by: lines
-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2017-01-12 23:33   ` Andrew Morton
@ 2017-01-13  3:39     ` Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2017-01-13  3:39 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Eric Ren, linux-next, linux-kernel

Hi Andrew,

On Thu, 12 Jan 2017 15:33:53 -0800 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> I'll drop
> 
> ocfs2-dlmglue-prepare-tracking-logic-to-avoid-recursive-cluster-lock.patch
> and
> ocfs2-fix-deadlocks-when-taking-inode-lock-at-vfs-entry-points.patch

I removed them from linux-next today.

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2017-01-12  5:06 ` Eric Ren
@ 2017-01-12 23:33   ` Andrew Morton
  2017-01-13  3:39     ` Stephen Rothwell
  2017-01-13  3:42   ` Stephen Rothwell
  1 sibling, 1 reply; 330+ messages in thread
From: Andrew Morton @ 2017-01-12 23:33 UTC (permalink / raw)
  To: Eric Ren; +Cc: Stephen Rothwell, linux-next, linux-kernel

On Thu, 12 Jan 2017 13:06:01 +0800 Eric Ren <zren@suse.com> wrote:

> On 01/12/2017 11:49 AM, Stephen Rothwell wrote:
> > Hi Andrew,
> >
> > After merging the akpm tree, today's linux-next build (powerpc
> > allyesconfig) failed like this:
> >
> > In file included from fs/ocfs2/file.c:49:0:
> > fs/ocfs2/file.c: In function 'ocfs2_permission':
> > fs/ocfs2/dlmglue.h:189:29: error: inlining failed in call to always_inline 'ocfs2_is_locked_by_me': function body not available
> >   inline struct ocfs2_holder *ocfs2_is_locked_by_me(struct ocfs2_lock_res *lockres);
> >                               ^
> > fs/ocfs2/file.c:1345:16: error: called from here
> >    has_locked = (ocfs2_is_locked_by_me(lockres) != NULL);
> >                  ^
> ...
> >
> > Caused by commits
> >
> >    984c4659d463 ("ocfs2/dlmglue: prepare tracking logic to avoid recursive cluster lock")
> >    0ca17730270e ("ocfs2: fix deadlocks when taking inode lock at vfs entry points")
> >

(top-posting repaired.  Please don't do that)

> Hi  Stephen,
> 
> Thanks for your report and the fix for it. The 0-day project has reported several days ago,
> but this patch set is still in discussion, so I am waiting for more days to see if  other 
> developers
> have any other questions.
> 
> I am confused that how to deal with your patch if I need to work out the V2 patch set. Perhaps,
> pick up your fix and  add your efforts in the change log?
> 

I'll drop

ocfs2-dlmglue-prepare-tracking-logic-to-avoid-recursive-cluster-lock.patch
and
ocfs2-fix-deadlocks-when-taking-inode-lock-at-vfs-entry-points.patch

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2017-01-12  3:49 Stephen Rothwell
@ 2017-01-12  5:06 ` Eric Ren
  2017-01-12 23:33   ` Andrew Morton
  2017-01-13  3:42   ` Stephen Rothwell
  0 siblings, 2 replies; 330+ messages in thread
From: Eric Ren @ 2017-01-12  5:06 UTC (permalink / raw)
  To: Stephen Rothwell, Andrew Morton; +Cc: linux-next, linux-kernel

Hi  Stephen,

Thanks for your report and the fix for it. The 0-day project has reported several days ago,
but this patch set is still in discussion, so I am waiting for more days to see if  other 
developers
have any other questions.

I am confused that how to deal with your patch if I need to work out the V2 patch set. Perhaps,
pick up your fix and  add your efforts in the change log?

Thanks,
Eric


On 01/12/2017 11:49 AM, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
> In file included from fs/ocfs2/file.c:49:0:
> fs/ocfs2/file.c: In function 'ocfs2_permission':
> fs/ocfs2/dlmglue.h:189:29: error: inlining failed in call to always_inline 'ocfs2_is_locked_by_me': function body not available
>   inline struct ocfs2_holder *ocfs2_is_locked_by_me(struct ocfs2_lock_res *lockres);
>                               ^
> fs/ocfs2/file.c:1345:16: error: called from here
>    has_locked = (ocfs2_is_locked_by_me(lockres) != NULL);
>                  ^
> In file included from fs/ocfs2/file.c:49:0:
> fs/ocfs2/dlmglue.h:189:29: error: inlining failed in call to always_inline 'ocfs2_is_locked_by_me': function body not available
>   inline struct ocfs2_holder *ocfs2_is_locked_by_me(struct ocfs2_lock_res *lockres);
>                               ^
> fs/ocfs2/file.c:1345:16: error: called from here
>    has_locked = (ocfs2_is_locked_by_me(lockres) != NULL);
>                  ^
> In file included from fs/ocfs2/file.c:49:0:
> fs/ocfs2/dlmglue.h:185:13: error: inlining failed in call to always_inline 'ocfs2_add_holder': function body not available
>   inline void ocfs2_add_holder(struct ocfs2_lock_res *lockres,
>               ^
> fs/ocfs2/file.c:1353:3: error: called from here
>     ocfs2_add_holder(lockres, &oh);
>     ^
> In file included from fs/ocfs2/file.c:49:0:
> fs/ocfs2/dlmglue.h:187:13: error: inlining failed in call to always_inline 'ocfs2_remove_holder': function body not available
>   inline void ocfs2_remove_holder(struct ocfs2_lock_res *lockres,
>               ^
> fs/ocfs2/file.c:1359:3: error: called from here
>     ocfs2_remove_holder(lockres, &oh);
>     ^
> In file included from fs/ocfs2/acl.c:31:0:
> fs/ocfs2/acl.c: In function 'ocfs2_iop_set_acl':
> fs/ocfs2/dlmglue.h:189:29: error: inlining failed in call to always_inline 'ocfs2_is_locked_by_me': function body not available
>   inline struct ocfs2_holder *ocfs2_is_locked_by_me(struct ocfs2_lock_res *lockres);
>                               ^
> fs/ocfs2/acl.c:292:16: error: called from here
>    has_locked = (ocfs2_is_locked_by_me(lockres) != NULL);
>                  ^
> In file included from fs/ocfs2/acl.c:31:0:
> fs/ocfs2/dlmglue.h:189:29: error: inlining failed in call to always_inline 'ocfs2_is_locked_by_me': function body not available
>   inline struct ocfs2_holder *ocfs2_is_locked_by_me(struct ocfs2_lock_res *lockres);
>                               ^
> fs/ocfs2/acl.c:292:16: error: called from here
>    has_locked = (ocfs2_is_locked_by_me(lockres) != NULL);
>                  ^
> In file included from fs/ocfs2/acl.c:31:0:
> fs/ocfs2/dlmglue.h:185:13: error: inlining failed in call to always_inline 'ocfs2_add_holder': function body not available
>   inline void ocfs2_add_holder(struct ocfs2_lock_res *lockres,
>               ^
> fs/ocfs2/acl.c:302:3: error: called from here
>     ocfs2_add_holder(lockres, &oh);
>     ^
> In file included from fs/ocfs2/acl.c:31:0:
> fs/ocfs2/dlmglue.h:187:13: error: inlining failed in call to always_inline 'ocfs2_remove_holder': function body not available
>   inline void ocfs2_remove_holder(struct ocfs2_lock_res *lockres,
>               ^
> fs/ocfs2/acl.c:307:3: error: called from here
>     ocfs2_remove_holder(lockres, &oh);
>     ^
>
> Caused by commits
>
>    984c4659d463 ("ocfs2/dlmglue: prepare tracking logic to avoid recursive cluster lock")
>    0ca17730270e ("ocfs2: fix deadlocks when taking inode lock at vfs entry points")
>
> I applied this fix patch for today:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 12 Jan 2017 14:40:03 +1100
> Subject: [PATCH] ocfs2/dmglue: do not inline functions whose bodies are not in
>   scope
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>   fs/ocfs2/dlmglue.c | 6 +++---
>   fs/ocfs2/dlmglue.h | 6 +++---
>   2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/fs/ocfs2/dlmglue.c b/fs/ocfs2/dlmglue.c
> index 951f5d9a0884..f0823f4d0afd 100644
> --- a/fs/ocfs2/dlmglue.c
> +++ b/fs/ocfs2/dlmglue.c
> @@ -750,7 +750,7 @@ void ocfs2_lock_res_free(struct ocfs2_lock_res *res)
>   	res->l_flags = 0UL;
>   }
>   
> -inline void ocfs2_add_holder(struct ocfs2_lock_res *lockres,
> +void ocfs2_add_holder(struct ocfs2_lock_res *lockres,
>   				   struct ocfs2_holder *oh)
>   {
>   	INIT_LIST_HEAD(&oh->oh_list);
> @@ -761,7 +761,7 @@ inline void ocfs2_add_holder(struct ocfs2_lock_res *lockres,
>   	spin_unlock(&lockres->l_lock);
>   }
>   
> -inline void ocfs2_remove_holder(struct ocfs2_lock_res *lockres,
> +void ocfs2_remove_holder(struct ocfs2_lock_res *lockres,
>   				       struct ocfs2_holder *oh)
>   {
>   	spin_lock(&lockres->l_lock);
> @@ -771,7 +771,7 @@ inline void ocfs2_remove_holder(struct ocfs2_lock_res *lockres,
>   	put_pid(oh->oh_owner_pid);
>   }
>   
> -inline struct ocfs2_holder *ocfs2_is_locked_by_me(struct ocfs2_lock_res *lockres)
> +struct ocfs2_holder *ocfs2_is_locked_by_me(struct ocfs2_lock_res *lockres)
>   {
>   	struct ocfs2_holder *oh;
>   	struct pid *pid;
> diff --git a/fs/ocfs2/dlmglue.h b/fs/ocfs2/dlmglue.h
> index d65ff1e49552..7f0c07bb30a3 100644
> --- a/fs/ocfs2/dlmglue.h
> +++ b/fs/ocfs2/dlmglue.h
> @@ -182,10 +182,10 @@ void ocfs2_set_locking_protocol(void);
>    * Keep a list of processes who have interest in a lockres.
>    * Note: this is now only uesed for check recursive cluster lock.
>    */
> -inline void ocfs2_add_holder(struct ocfs2_lock_res *lockres,
> +void ocfs2_add_holder(struct ocfs2_lock_res *lockres,
>   			     struct ocfs2_holder *oh);
> -inline void ocfs2_remove_holder(struct ocfs2_lock_res *lockres,
> +void ocfs2_remove_holder(struct ocfs2_lock_res *lockres,
>   			     struct ocfs2_holder *oh);
> -inline struct ocfs2_holder *ocfs2_is_locked_by_me(struct ocfs2_lock_res *lockres);
> +struct ocfs2_holder *ocfs2_is_locked_by_me(struct ocfs2_lock_res *lockres);
>   
>   #endif	/* DLMGLUE_H */

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

* linux-next: build failure after merge of the akpm-current tree
@ 2017-01-12  3:49 Stephen Rothwell
  2017-01-12  5:06 ` Eric Ren
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2017-01-12  3:49 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Eric Ren

Hi Andrew,

After merging the akpm tree, today's linux-next build (powerpc
allyesconfig) failed like this:

In file included from fs/ocfs2/file.c:49:0:
fs/ocfs2/file.c: In function 'ocfs2_permission':
fs/ocfs2/dlmglue.h:189:29: error: inlining failed in call to always_inline 'ocfs2_is_locked_by_me': function body not available
 inline struct ocfs2_holder *ocfs2_is_locked_by_me(struct ocfs2_lock_res *lockres);
                             ^
fs/ocfs2/file.c:1345:16: error: called from here
  has_locked = (ocfs2_is_locked_by_me(lockres) != NULL);
                ^
In file included from fs/ocfs2/file.c:49:0:
fs/ocfs2/dlmglue.h:189:29: error: inlining failed in call to always_inline 'ocfs2_is_locked_by_me': function body not available
 inline struct ocfs2_holder *ocfs2_is_locked_by_me(struct ocfs2_lock_res *lockres);
                             ^
fs/ocfs2/file.c:1345:16: error: called from here
  has_locked = (ocfs2_is_locked_by_me(lockres) != NULL);
                ^
In file included from fs/ocfs2/file.c:49:0:
fs/ocfs2/dlmglue.h:185:13: error: inlining failed in call to always_inline 'ocfs2_add_holder': function body not available
 inline void ocfs2_add_holder(struct ocfs2_lock_res *lockres,
             ^
fs/ocfs2/file.c:1353:3: error: called from here
   ocfs2_add_holder(lockres, &oh);
   ^
In file included from fs/ocfs2/file.c:49:0:
fs/ocfs2/dlmglue.h:187:13: error: inlining failed in call to always_inline 'ocfs2_remove_holder': function body not available
 inline void ocfs2_remove_holder(struct ocfs2_lock_res *lockres,
             ^
fs/ocfs2/file.c:1359:3: error: called from here
   ocfs2_remove_holder(lockres, &oh);
   ^
In file included from fs/ocfs2/acl.c:31:0:
fs/ocfs2/acl.c: In function 'ocfs2_iop_set_acl':
fs/ocfs2/dlmglue.h:189:29: error: inlining failed in call to always_inline 'ocfs2_is_locked_by_me': function body not available
 inline struct ocfs2_holder *ocfs2_is_locked_by_me(struct ocfs2_lock_res *lockres);
                             ^
fs/ocfs2/acl.c:292:16: error: called from here
  has_locked = (ocfs2_is_locked_by_me(lockres) != NULL);
                ^
In file included from fs/ocfs2/acl.c:31:0:
fs/ocfs2/dlmglue.h:189:29: error: inlining failed in call to always_inline 'ocfs2_is_locked_by_me': function body not available
 inline struct ocfs2_holder *ocfs2_is_locked_by_me(struct ocfs2_lock_res *lockres);
                             ^
fs/ocfs2/acl.c:292:16: error: called from here
  has_locked = (ocfs2_is_locked_by_me(lockres) != NULL);
                ^
In file included from fs/ocfs2/acl.c:31:0:
fs/ocfs2/dlmglue.h:185:13: error: inlining failed in call to always_inline 'ocfs2_add_holder': function body not available
 inline void ocfs2_add_holder(struct ocfs2_lock_res *lockres,
             ^
fs/ocfs2/acl.c:302:3: error: called from here
   ocfs2_add_holder(lockres, &oh);
   ^
In file included from fs/ocfs2/acl.c:31:0:
fs/ocfs2/dlmglue.h:187:13: error: inlining failed in call to always_inline 'ocfs2_remove_holder': function body not available
 inline void ocfs2_remove_holder(struct ocfs2_lock_res *lockres,
             ^
fs/ocfs2/acl.c:307:3: error: called from here
   ocfs2_remove_holder(lockres, &oh);
   ^

Caused by commits

  984c4659d463 ("ocfs2/dlmglue: prepare tracking logic to avoid recursive cluster lock")
  0ca17730270e ("ocfs2: fix deadlocks when taking inode lock at vfs entry points")

I applied this fix patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 12 Jan 2017 14:40:03 +1100
Subject: [PATCH] ocfs2/dmglue: do not inline functions whose bodies are not in
 scope

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/ocfs2/dlmglue.c | 6 +++---
 fs/ocfs2/dlmglue.h | 6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/fs/ocfs2/dlmglue.c b/fs/ocfs2/dlmglue.c
index 951f5d9a0884..f0823f4d0afd 100644
--- a/fs/ocfs2/dlmglue.c
+++ b/fs/ocfs2/dlmglue.c
@@ -750,7 +750,7 @@ void ocfs2_lock_res_free(struct ocfs2_lock_res *res)
 	res->l_flags = 0UL;
 }
 
-inline void ocfs2_add_holder(struct ocfs2_lock_res *lockres,
+void ocfs2_add_holder(struct ocfs2_lock_res *lockres,
 				   struct ocfs2_holder *oh)
 {
 	INIT_LIST_HEAD(&oh->oh_list);
@@ -761,7 +761,7 @@ inline void ocfs2_add_holder(struct ocfs2_lock_res *lockres,
 	spin_unlock(&lockres->l_lock);
 }
 
-inline void ocfs2_remove_holder(struct ocfs2_lock_res *lockres,
+void ocfs2_remove_holder(struct ocfs2_lock_res *lockres,
 				       struct ocfs2_holder *oh)
 {
 	spin_lock(&lockres->l_lock);
@@ -771,7 +771,7 @@ inline void ocfs2_remove_holder(struct ocfs2_lock_res *lockres,
 	put_pid(oh->oh_owner_pid);
 }
 
-inline struct ocfs2_holder *ocfs2_is_locked_by_me(struct ocfs2_lock_res *lockres)
+struct ocfs2_holder *ocfs2_is_locked_by_me(struct ocfs2_lock_res *lockres)
 {
 	struct ocfs2_holder *oh;
 	struct pid *pid;
diff --git a/fs/ocfs2/dlmglue.h b/fs/ocfs2/dlmglue.h
index d65ff1e49552..7f0c07bb30a3 100644
--- a/fs/ocfs2/dlmglue.h
+++ b/fs/ocfs2/dlmglue.h
@@ -182,10 +182,10 @@ void ocfs2_set_locking_protocol(void);
  * Keep a list of processes who have interest in a lockres.
  * Note: this is now only uesed for check recursive cluster lock.
  */
-inline void ocfs2_add_holder(struct ocfs2_lock_res *lockres,
+void ocfs2_add_holder(struct ocfs2_lock_res *lockres,
 			     struct ocfs2_holder *oh);
-inline void ocfs2_remove_holder(struct ocfs2_lock_res *lockres,
+void ocfs2_remove_holder(struct ocfs2_lock_res *lockres,
 			     struct ocfs2_holder *oh);
-inline struct ocfs2_holder *ocfs2_is_locked_by_me(struct ocfs2_lock_res *lockres);
+struct ocfs2_holder *ocfs2_is_locked_by_me(struct ocfs2_lock_res *lockres);
 
 #endif	/* DLMGLUE_H */
-- 
2.10.2

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2016-11-24 15:02 ` Thiago Jung Bauermann
@ 2016-11-24 23:43   ` Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2016-11-24 23:43 UTC (permalink / raw)
  To: Thiago Jung Bauermann
  Cc: Andrew Morton, linux-next, linux-kernel, Michael Ellerman,
	Benjamin Herrenschmidt, PowerPC

Hi Thiago,

On Thu, 24 Nov 2016 13:02:39 -0200 Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> wrote:
>
> Am Donnerstag, 24. November 2016, 16:01:51 BRST schrieb Stephen Rothwell:
> > Hi Andrew,
> > 
> > After merging the akpm-current tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> > 
> > powerpc-linux-ld: unrecognized option '--no-dynamic-linker'
> > 
> > Caused by patch
> > 
> >   "powerpc: add purgatory for kexec_file_load implementation"
> >   
> 
> Sorry about that. --no-dynamic-linker was added in binutils 2.26.
> The patch below fixes the problem.

OK, I will apply that patch instead of disabling CONFIG_KEXEC_FILE
today.

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2016-11-24  5:01 Stephen Rothwell
@ 2016-11-24 15:02 ` Thiago Jung Bauermann
  2016-11-24 23:43   ` Stephen Rothwell
  0 siblings, 1 reply; 330+ messages in thread
From: Thiago Jung Bauermann @ 2016-11-24 15:02 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-kernel, linux-next, Andrew Morton, PowerPC

Hello Stephen,

Am Donnerstag, 24. November 2016, 16:01:51 BRST schrieb Stephen Rothwell:
> Hi Andrew,
> 
> After merging the akpm-current tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> powerpc-linux-ld: unrecognized option '--no-dynamic-linker'
> 
> Caused by patch
> 
>   "powerpc: add purgatory for kexec_file_load implementation"
> 

Sorry about that. --no-dynamic-linker was added in binutils 2.26.
The patch below fixes the problem.

-- 
Thiago Jung Bauermann
IBM Linux Technology Center


diff --git a/arch/powerpc/purgatory/Makefile b/arch/powerpc/purgatory/Makefile
index 2dfb53ac9944..cf6e78b9af86 100644
--- a/arch/powerpc/purgatory/Makefile
+++ b/arch/powerpc/purgatory/Makefile
@@ -6,8 +6,10 @@ purgatory-y := purgatory.o string.o v2wrap.o purgatory-ppc64.o crtsavres.o \
 targets += $(purgatory-y)
 PURGATORY_OBJS = $(addprefix $(obj)/,$(purgatory-y))
 
-LDFLAGS_purgatory.ro := -pie --no-dynamic-linker -e purgatory_start \
-			--no-undefined -nostartfiles -nostdlib -nodefaultlibs
+LDFLAGS_purgatory.ro := -pie -e purgatory_start --no-undefined -nostartfiles \
+			-nostdlib -nodefaultlibs
+LDFLAGS_purgatory.ro += $(call ld-option, --no-dynamic-linker)
+
 targets += purgatory.ro
 
 KBUILD_CFLAGS := $(filter-out $(CC_FLAGS_FTRACE), $(KBUILD_CFLAGS))

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

* linux-next: build failure after merge of the akpm-current tree
@ 2016-11-24  5:01 Stephen Rothwell
  2016-11-24 15:02 ` Thiago Jung Bauermann
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2016-11-24  5:01 UTC (permalink / raw)
  To: Andrew Morton
  Cc: linux-next, linux-kernel, Thiago Jung Bauermann,
	Michael Ellerman, Benjamin Herrenschmidt, PowerPC

Hi Andrew,

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

powerpc-linux-ld: unrecognized option '--no-dynamic-linker'

Caused by patch

  "powerpc: add purgatory for kexec_file_load implementation"

I have disabled KEXEC_FILE for now:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 24 Nov 2016 15:52:55 +1100
Subject: [PATCH] disable KEXEC_FILE on powerpc for now

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/powerpc/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 2d86643f280d..b72c1c7afcf0 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -475,6 +475,7 @@ config KEXEC_FILE
 	depends on PPC64
 	depends on CRYPTO=y
 	depends on CRYPTO_SHA256=y
+	depends on BROKEN
 	help
 	  This is a new version of the kexec system call. This call is
 	  file based and takes in file descriptors as system call arguments
-- 
2.10.2

-- 
Cheers,
Stephen Rothwell

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

* linux-next: build failure after merge of the akpm-current tree
@ 2016-11-22 10:05 Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2016-11-22 10:05 UTC (permalink / raw)
  To: Andrew Morton, Alex Williamson
  Cc: linux-next, linux-kernel, Kirti Wankhede, Neo Jia, Lorenzo Stoakes

Hi Andrew,

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

drivers/vfio/vfio_iommu_type1.c: In function 'vaddr_get_pfn':
drivers/vfio/vfio_iommu_type1.c:364:9: error: too few arguments to function 'get_user_pages_remote'
   ret = get_user_pages_remote(NULL, mm, vaddr, 1, flags, page,
         ^
In file included from include/linux/scatterlist.h:7:0,
                 from include/linux/iommu.h:26,
                 from drivers/vfio/vfio_iommu_type1.c:30:
include/linux/mm.h:1274:6: note: declared here
 long get_user_pages_remote(struct task_struct *tsk, struct mm_struct *mm,
      ^

Caused by commit

  d6c547ad0c61 ("mm: add locked parameter to get_user_pages_remote()")

interacting with commit

  ea85cf353e4f ("vfio iommu type1: Update argument of vaddr_get_pfn()")

from the vfio tree.

I applied this merge fix patch:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 22 Nov 2016 20:54:27 +1100
Subject: [PATCH] vfio iommu type1: merge fix for get_user_pages_remote API
 change

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/vfio/vfio_iommu_type1.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 51810a95416e..cae2e9121e48 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -362,7 +362,7 @@ static int vaddr_get_pfn(struct mm_struct *mm, unsigned long vaddr,
 
 		down_read(&mm->mmap_sem);
 		ret = get_user_pages_remote(NULL, mm, vaddr, 1, flags, page,
-					    NULL);
+					    NULL, NULL);
 		up_read(&mm->mmap_sem);
 	}
 
-- 
2.10.2

-- 
Cheers,
Stephen Rothwell

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

* linux-next: build failure after merge of the akpm-current tree
@ 2016-11-22 10:04 Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2016-11-22 10:04 UTC (permalink / raw)
  To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: linux-next, linux-kernel, Waiman Long, Davidlohr Bueso

Hi Andrew,

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

ipc/sem.c: In function 'freeary':
ipc/sem.c:1125:2: error: implicit declaration of function 'WAKE_Q' [-Werror=implicit-function-declaration]
  WAKE_Q(wake_q);
  ^
ipc/sem.c:1125:9: error: 'wake_q' undeclared (first use in this function)
  WAKE_Q(wake_q);
         ^
ipc/sem.c:1125:9: note: each undeclared identifier is reported only once for each function it appears in
ipc/sem.c: In function 'semctl_setval':
ipc/sem.c:1305:9: error: 'wake_q' undeclared (first use in this function)
  WAKE_Q(wake_q);
         ^
ipc/sem.c: In function 'semctl_main':
ipc/sem.c:1375:9: error: 'wake_q' undeclared (first use in this function)
  WAKE_Q(wake_q);
         ^
ipc/sem.c: In function 'SYSC_semtimedop':
ipc/sem.c:1931:10: error: 'wake_q' undeclared (first use in this function)
   WAKE_Q(wake_q);
          ^
ipc/sem.c: In function 'exit_sem':
ipc/sem.c:2115:10: error: 'wake_q' undeclared (first use in this function)
   WAKE_Q(wake_q);
          ^

Caused by commit

  fa8ecccee99f ("ipc/sem: rework task wakeups")

interacting with commit

  194a6b5b9cb6 ("sched/wake_q: Rename WAKE_Q to DEFINE_WAKE_Q")

from the tip tree.

I applied this merge fix patch:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 22 Nov 2016 20:34:47 +1100
Subject: [PATCH] ipc/sem: merge fix for WAKE_Q to DEFINE_WAKE_Q rename

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 ipc/sem.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/ipc/sem.c b/ipc/sem.c
index ca4aa23c622b..77c011e90414 100644
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -1122,7 +1122,7 @@ static void freeary(struct ipc_namespace *ns, struct kern_ipc_perm *ipcp)
 	struct sem_queue *q, *tq;
 	struct sem_array *sma = container_of(ipcp, struct sem_array, sem_perm);
 	int i;
-	WAKE_Q(wake_q);
+	DEFINE_WAKE_Q(wake_q);
 
 	/* Free the existing undo structures for this semaphore set.  */
 	ipc_assert_locked_object(&sma->sem_perm);
@@ -1302,7 +1302,7 @@ static int semctl_setval(struct ipc_namespace *ns, int semid, int semnum,
 	struct sem_array *sma;
 	struct sem *curr;
 	int err, val;
-	WAKE_Q(wake_q);
+	DEFINE_WAKE_Q(wake_q);
 
 #if defined(CONFIG_64BIT) && defined(__BIG_ENDIAN)
 	/* big-endian 64bit */
@@ -1372,7 +1372,7 @@ static int semctl_main(struct ipc_namespace *ns, int semid, int semnum,
 	int err, nsems;
 	ushort fast_sem_io[SEMMSL_FAST];
 	ushort *sem_io = fast_sem_io;
-	WAKE_Q(wake_q);
+	DEFINE_WAKE_Q(wake_q);
 
 	rcu_read_lock();
 	sma = sem_obtain_object_check(ns, semid);
@@ -1928,7 +1928,7 @@ SYSCALL_DEFINE4(semtimedop, int, semid, struct sembuf __user *, tsops,
 
 	error = perform_atomic_semop(sma, &queue);
 	if (error == 0) { /* non-blocking succesfull path */
-		WAKE_Q(wake_q);
+		DEFINE_WAKE_Q(wake_q);
 
 		/*
 		 * If the operation was successful, then do
@@ -2112,7 +2112,7 @@ void exit_sem(struct task_struct *tsk)
 		struct sem_array *sma;
 		struct sem_undo *un;
 		int semid, i;
-		WAKE_Q(wake_q);
+		DEFINE_WAKE_Q(wake_q);
 
 		cond_resched();
 
-- 
2.10.2

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2016-10-12  2:40 Stephen Rothwell
@ 2016-10-12 21:30 ` Andrew Morton
  0 siblings, 0 replies; 330+ messages in thread
From: Andrew Morton @ 2016-10-12 21:30 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: linux-next, linux-kernel, Thiago Jung Bauermann, Mimi Zohar

On Wed, 12 Oct 2016 13:40:10 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> After merging the akpm-current tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> In file included from include/linux/list.h:8:0,
>                  from include/linux/kobject.h:20,
>                  from include/linux/device.h:17,
>                  from arch/powerpc/include/asm/io.h:27,
>                  from include/linux/kexec.h:17,
>                  from arch/powerpc/kernel/machine_kexec_64.c:13:
> arch/powerpc/kernel/machine_kexec_64.c: In function 'arch_kexec_kernel_image_probe':
> arch/powerpc/kernel/machine_kexec_64.c:420:29: error: 'kexec_file_loaders' undeclared (first use in this function)
>   for (i = 0; i < ARRAY_SIZE(kexec_file_loaders); i++) {
>                              ^
> arch/powerpc/kernel/machine_kexec_64.c: In function 'setup_purgatory':
> arch/powerpc/kernel/machine_kexec_64.c:568:27: error: 'SLAVE_CODE_SIZE' undeclared (first use in this function)
>   slave_code_buf = kmalloc(SLAVE_CODE_SIZE, GFP_KERNEL);
>                            ^
> arch/powerpc/kernel/machine_kexec_64.c: In function 'setup_new_fdt':
> arch/powerpc/kernel/machine_kexec_64.c:774:8: error: implicit declaration of function 'setup_ima_buffer' [-Werror=implicit-function-declaration]
>   ret = setup_ima_buffer(image, fdt, chosen_node);

Yes, these patches seem to have become broken.  They've had a hard life :(

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

* linux-next: build failure after merge of the akpm-current tree
@ 2016-10-12  2:40 Stephen Rothwell
  2016-10-12 21:30 ` Andrew Morton
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2016-10-12  2:40 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Thiago Jung Bauermann

Hi Andrew,

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

In file included from include/linux/list.h:8:0,
                 from include/linux/kobject.h:20,
                 from include/linux/device.h:17,
                 from arch/powerpc/include/asm/io.h:27,
                 from include/linux/kexec.h:17,
                 from arch/powerpc/kernel/machine_kexec_64.c:13:
arch/powerpc/kernel/machine_kexec_64.c: In function 'arch_kexec_kernel_image_probe':
arch/powerpc/kernel/machine_kexec_64.c:420:29: error: 'kexec_file_loaders' undeclared (first use in this function)
  for (i = 0; i < ARRAY_SIZE(kexec_file_loaders); i++) {
                             ^
arch/powerpc/kernel/machine_kexec_64.c: In function 'setup_purgatory':
arch/powerpc/kernel/machine_kexec_64.c:568:27: error: 'SLAVE_CODE_SIZE' undeclared (first use in this function)
  slave_code_buf = kmalloc(SLAVE_CODE_SIZE, GFP_KERNEL);
                           ^
arch/powerpc/kernel/machine_kexec_64.c: In function 'setup_new_fdt':
arch/powerpc/kernel/machine_kexec_64.c:774:8: error: implicit declaration of function 'setup_ima_buffer' [-Werror=implicit-function-declaration]
  ret = setup_ima_buffer(image, fdt, chosen_node);
        ^

Caused by commits

  bbd24d7bb4cd ("powerpc: implement kexec_file_load")
  325f517062cb ("powerpc: ima: send the kexec buffer to the next kernel")

I applied the following fix patches for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 12 Oct 2016 13:28:20 +1100
Subject: [PATCH] powerpc: include asm/ima.h for setup_ima_buffer

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/powerpc/kernel/machine_kexec_64.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/kernel/machine_kexec_64.c b/arch/powerpc/kernel/machine_kexec_64.c
index 8dbaf636c95e..2d14d769fc76 100644
--- a/arch/powerpc/kernel/machine_kexec_64.c
+++ b/arch/powerpc/kernel/machine_kexec_64.c
@@ -31,6 +31,7 @@
 #include <asm/sections.h>	/* _end */
 #include <asm/prom.h>
 #include <asm/smp.h>
+#include <asm/ima.h>
 #include <asm/hw_breakpoint.h>
 #include <asm/asm-prototypes.h>
 
-- 
2.8.1

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 12 Oct 2016 13:32:58 +1100
Subject: [PATCH] powerpc: disable KEXEC_FILE for now

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/powerpc/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 40ee044f1915..c8bd188285d1 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -463,6 +463,7 @@ config KEXEC_FILE
 	depends on PPC64
 	depends on CRYPTO=y
 	depends on CRYPTO_SHA256=y
+	depends on BROKEN
 	help
 	  This is a new version of the kexec system call. This call is
 	  file based and takes in file descriptors as system call arguments
-- 
2.8.1

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2016-09-20 23:16     ` Stephen Rothwell
  2016-09-21  0:27       ` Michael Ellerman
@ 2016-09-21  5:59       ` Stephen Rothwell
  1 sibling, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2016-09-21  5:59 UTC (permalink / raw)
  To: Michael Ellerman; +Cc: Andrew Morton, linux-next, linux-kernel, bauerman

Hi all,

On Wed, 21 Sep 2016 09:16:22 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Tue, 20 Sep 2016 22:00:32 +1000 Michael Ellerman <mpe@ellerman.id.au> wrote:
> >
> > Ah yep looks like that's the problem, patch below should fix it?  
> 
> Yeah, I am just going to (logically) run "sed 's/CONFIG_WORD_SIZE/BITS/'"
> over the tree during the merge of the apm-current tree today.
> 
> > I think I'd actually prefer it if purgatory didn't redefine the CFLAGS
> > from scratch, so I'll see if Thiago can do that and send a new version.  
> 
> That could be better, but there are still some additions of
> CONFIG_WORD_SIZE elsewhere :-(

So here is the relevant parts of the merge resolution for merging the
akpm-current tree today.

diff --cc arch/powerpc/kernel/Makefile
index 1925341dbb9c,d12a84003283..e59ed6af0523
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@@ -104,11 -104,12 +104,12 @@@ obj-$(CONFIG_STACKTRACE)	+= stacktrace.
  obj-$(CONFIG_SWIOTLB)		+= dma-swiotlb.o
  
  pci64-$(CONFIG_PPC64)		+= pci_dn.o pci-hotplug.o isa-bridge.o
 -obj-$(CONFIG_PCI)		+= pci_$(CONFIG_WORD_SIZE).o $(pci64-y) \
 +obj-$(CONFIG_PCI)		+= pci_$(BITS).o $(pci64-y) \
  				   pci-common.o pci_of_scan.o
  obj-$(CONFIG_PCI_MSI)		+= msi.o
- obj-$(CONFIG_KEXEC)		+= machine_kexec.o crash.o \
+ obj-$(CONFIG_KEXEC_CORE)	+= machine_kexec.o crash.o \
 -				   machine_kexec_$(CONFIG_WORD_SIZE).o
 -obj-$(CONFIG_KEXEC_FILE)	+= kexec_elf_$(CONFIG_WORD_SIZE).o
 +				   machine_kexec_$(BITS).o
++obj-$(CONFIG_KEXEC_FILE)	+= kexec_elf_$(BITS).o
  obj-$(CONFIG_AUDIT)		+= audit.o
  obj64-$(CONFIG_AUDIT)		+= compat_audit.o
  
@@@ -123,6 -124,12 +124,12 @@@ ifneq ($(CONFIG_PPC_INDIRECT_PIO),y
  obj-y				+= iomap.o
  endif
  
+ ifneq ($(CONFIG_MODULES)$(CONFIG_KEXEC_FILE),)
 -ifeq ($(CONFIG_WORD_SIZE),64)
++ifeq ($(BITS),64)
+ obj-y				+= elf_util.o elf_util_64.o
+ endif
+ endif
+ 
  obj64-$(CONFIG_PPC_TRANSACTIONAL_MEM)	+= tm.o
  
  obj-$(CONFIG_PPC64)		+= $(obj64-y)
diff --cc arch/powerpc/purgatory/Makefile
index 000000000000,fea0308c7f01..bc3b9dc6eead
mode 000000,100644..100644
--- a/arch/powerpc/purgatory/Makefile
+++ b/arch/powerpc/purgatory/Makefile
@@@ -1,0 -1,48 +1,48 @@@
+ OBJECT_FILES_NON_STANDARD := y
+ 
+ purgatory-y := purgatory.o printf.o string.o v2wrap.o hvCall.o \
+ 		purgatory-ppc64.o console-ppc64.o crashdump_backup.o \
+ 		crtsavres.o sha256.o
+ 
+ targets += $(purgatory-y)
+ PURGATORY_OBJS = $(addprefix $(obj)/,$(purgatory-y))
+ 
+ LDFLAGS_purgatory.ro := -e purgatory_start -r --no-undefined -nostartfiles \
+ 			-nostdlib -nodefaultlibs
+ targets += purgatory.ro
+ 
+ # Default KBUILD_CFLAGS can have -pg option set when FTRACE is enabled. That
+ # in turn leaves some undefined symbols like __fentry__ in purgatory and not
+ # sure how to relocate those. Like kexec-tools, use custom flags.
+ 
+ KBUILD_CFLAGS := -Wall -Wstrict-prototypes -fno-strict-aliasing \
+ 		-fno-zero-initialized-in-bss -fno-builtin -ffreestanding \
+ 		-fno-PIC -fno-PIE -fno-stack-protector  -fno-exceptions \
 -		-msoft-float -MD -Os -m$(CONFIG_WORD_SIZE)
 -KBUILD_AFLAGS := -fno-exceptions -msoft-float -m$(CONFIG_WORD_SIZE) \
++		-msoft-float -MD -Os -m$(BITS)
++KBUILD_AFLAGS := -fno-exceptions -msoft-float -m$(BITS) \
+ 		-D__ASSEMBLY__
+ 
+ ifeq ($(CONFIG_CPU_LITTLE_ENDIAN),y)
+ KBUILD_CFLAGS += $(call cc-option,-mabi=elfv2,$(call cc-option,-mcall-aixdesc)) \
+ 		-mlittle-endian
+ KBUILD_AFLAGS += $(call cc-option,-mabi=elfv2) -mlittle-endian
+ else
+ KBUILD_CFLAGS += $(call cc-option,-mcall-aixdesc) -mbig-endian
+ KBUILD_AFLAGS += -mbig-endian
+ endif
+ 
+ $(obj)/purgatory.ro: $(PURGATORY_OBJS) FORCE
+ 		$(call if_changed,ld)
+ 
+ targets += kexec-purgatory.c
+ 
+ CMD_BIN2C = $(objtree)/scripts/basic/bin2c
+ quiet_cmd_bin2c = BIN2C   $@
+       cmd_bin2c = $(CMD_BIN2C) kexec_purgatory < $< > $@
+ 
+ $(obj)/kexec-purgatory.c: $(obj)/purgatory.ro FORCE
+ 	$(call if_changed,bin2c)
+ 	@:
+ 
+ 
+ obj-$(CONFIG_KEXEC_FILE)	+= kexec-purgatory.o

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the akpm-current tree
       [not found]   ` <87mvj2srvj.fsf@concordia.ellerman.id.au>
  2016-09-20 23:16     ` Stephen Rothwell
@ 2016-09-21  2:26     ` Thiago Jung Bauermann
  1 sibling, 0 replies; 330+ messages in thread
From: Thiago Jung Bauermann @ 2016-09-21  2:26 UTC (permalink / raw)
  To: Michael Ellerman
  Cc: Stephen Rothwell, Andrew Morton, linux-next, linux-kernel

Am Dienstag, 20 September 2016, 22:00:32 schrieb Michael Ellerman:
> Stephen Rothwell <sfr@canb.auug.org.au> writes:
> > On Tue, 20 Sep 2016 16:44:14 +1000 Stephen Rothwell 
<sfr@canb.auug.org.au> wrote:
> >> After merging the akpm-current tree, today's linux-next build (powerpc
> >> ppc64_defconfig) failed like this:
> >> 
> >> powerpc-linux-gcc: error: unrecognized command line option '-m'
> >> scripts/Makefile.build:290: recipe for target
> >> 'arch/powerpc/purgatory/printf.o' failed
> >> 
> >> and a few more like that.
> > 
> > OK, this is (most likely) caused by the CONFIG_WORD_SIZE -> BITS change
> > interacting with the KEXEC_FILE changes. Tomorrow I will do a better
> > merge conflict resolution patch that fixes all those.
> 
> Ah yep looks like that's the problem, patch below should fix it?
> 
> I think I'd actually prefer it if purgatory didn't redefine the CFLAGS
> from scratch, so I'll see if Thiago can do that and send a new version.

I could move the purgatory inside arch/powerpc/boot and use its BOOTCFLAGS. 
The needs of the purgatory and the boot wrapper are very similar. Would that 
be better?
-- 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2016-09-21  0:27       ` Michael Ellerman
  2016-09-21  1:12         ` Thiago Jung Bauermann
@ 2016-09-21  2:02         ` Stephen Rothwell
  1 sibling, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2016-09-21  2:02 UTC (permalink / raw)
  To: Michael Ellerman; +Cc: Andrew Morton, linux-next, linux-kernel, bauerman

Hi Michael,

On Wed, 21 Sep 2016 10:27:46 +1000 Michael Ellerman <mpe@ellerman.id.au> wrote:
>
> Stephen Rothwell <sfr@canb.auug.org.au> writes:
> 
> > On Tue, 20 Sep 2016 22:00:32 +1000 Michael Ellerman <mpe@ellerman.id.au> wrote:  
> >>
> >> Ah yep looks like that's the problem, patch below should fix it?  
> >
> > Yeah, I am just going to (logically) run "sed 's/CONFIG_WORD_SIZE/BITS/'"
> > over the tree during the merge of the apm-current tree today.
> >  
> >> I think I'd actually prefer it if purgatory didn't redefine the CFLAGS
> >> from scratch, so I'll see if Thiago can do that and send a new version.  
> >
> > That could be better, but there are still some additions of
> > CONFIG_WORD_SIZE elsewhere :-(  
> 
> I don't see any others in yesterday's next?

I fixed the other one I found as it caused a build failure as well but
was more obvious (and I had had time to think about what was happening).

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2016-09-21  0:27       ` Michael Ellerman
@ 2016-09-21  1:12         ` Thiago Jung Bauermann
  2016-09-21  2:02         ` Stephen Rothwell
  1 sibling, 0 replies; 330+ messages in thread
From: Thiago Jung Bauermann @ 2016-09-21  1:12 UTC (permalink / raw)
  To: Michael Ellerman
  Cc: Stephen Rothwell, Andrew Morton, linux-next, linux-kernel

Am Mittwoch, 21 September 2016, 10:27:46 schrieb Michael Ellerman:
> Stephen Rothwell <sfr@canb.auug.org.au> writes:
> > On Tue, 20 Sep 2016 22:00:32 +1000 Michael Ellerman <mpe@ellerman.id.au> 
wrote:
> >> Ah yep looks like that's the problem, patch below should fix it?
> > 
> > Yeah, I am just going to (logically) run "sed
> > 's/CONFIG_WORD_SIZE/BITS/'"
> > over the tree during the merge of the apm-current tree today.
> > 
> >> I think I'd actually prefer it if purgatory didn't redefine the CFLAGS
> >> from scratch, so I'll see if Thiago can do that and send a new version.
> > 
> > That could be better, but there are still some additions of
> > CONFIG_WORD_SIZE elsewhere :-(
> 
> I don't see any others in yesterday's next?

This kbuild failure is one case:

https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-September/148898.html

elf_util_64.o is only built if CONFIG_WORD_SIZE=64. This is affects the 
bisectabilty of many patches in the kexec_file_load series. Should I post a 
new version rebased on powerpc/next?

-- 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2016-09-20 23:16     ` Stephen Rothwell
@ 2016-09-21  0:27       ` Michael Ellerman
  2016-09-21  1:12         ` Thiago Jung Bauermann
  2016-09-21  2:02         ` Stephen Rothwell
  2016-09-21  5:59       ` Stephen Rothwell
  1 sibling, 2 replies; 330+ messages in thread
From: Michael Ellerman @ 2016-09-21  0:27 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Andrew Morton, linux-next, linux-kernel, bauerman

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

> On Tue, 20 Sep 2016 22:00:32 +1000 Michael Ellerman <mpe@ellerman.id.au> wrote:
>>
>> Ah yep looks like that's the problem, patch below should fix it?
>
> Yeah, I am just going to (logically) run "sed 's/CONFIG_WORD_SIZE/BITS/'"
> over the tree during the merge of the apm-current tree today.
>
>> I think I'd actually prefer it if purgatory didn't redefine the CFLAGS
>> from scratch, so I'll see if Thiago can do that and send a new version.
>
> That could be better, but there are still some additions of
> CONFIG_WORD_SIZE elsewhere :-(

I don't see any others in yesterday's next?

cheers

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

* Re: linux-next: build failure after merge of the akpm-current tree
       [not found]   ` <87mvj2srvj.fsf@concordia.ellerman.id.au>
@ 2016-09-20 23:16     ` Stephen Rothwell
  2016-09-21  0:27       ` Michael Ellerman
  2016-09-21  5:59       ` Stephen Rothwell
  2016-09-21  2:26     ` Thiago Jung Bauermann
  1 sibling, 2 replies; 330+ messages in thread
From: Stephen Rothwell @ 2016-09-20 23:16 UTC (permalink / raw)
  To: Michael Ellerman; +Cc: Andrew Morton, linux-next, linux-kernel, bauerman

Hi Michael,

On Tue, 20 Sep 2016 22:00:32 +1000 Michael Ellerman <mpe@ellerman.id.au> wrote:
>
> Ah yep looks like that's the problem, patch below should fix it?

Yeah, I am just going to (logically) run "sed 's/CONFIG_WORD_SIZE/BITS/'"
over the tree during the merge of the apm-current tree today.

> I think I'd actually prefer it if purgatory didn't redefine the CFLAGS
> from scratch, so I'll see if Thiago can do that and send a new version.

That could be better, but there are still some additions of
CONFIG_WORD_SIZE elsewhere :-(

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2016-09-20  6:44 Stephen Rothwell
@ 2016-09-20  7:30 ` Stephen Rothwell
       [not found]   ` <87mvj2srvj.fsf@concordia.ellerman.id.au>
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2016-09-20  7:30 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Michael Ellerman

Hi all,

On Tue, 20 Sep 2016 16:44:14 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the akpm-current tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> powerpc-linux-gcc: error: unrecognized command line option '-m'
> scripts/Makefile.build:290: recipe for target 'arch/powerpc/purgatory/printf.o' failed
> 
> and a few more like that.

OK, this is (most likely) caused by the CONFIG_WORD_SIZE -> BITS change
interacting with the KEXEC_FILE changes. Tomorrow I will do a better
merge conflict resolution patch that fixes all those.

-- 
Cheers,
Stephen Rothwell

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

* linux-next: build failure after merge of the akpm-current tree
@ 2016-09-20  6:53 Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2016-09-20  6:53 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel

Hi Andrew,

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

arch/powerpc/kernel/built-in.o: In function `.apply_relocate_add':
(.text+0x302e4): undefined reference to `.elf64_apply_relocate_add'

I needed to add the following merge resolution patch:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 20 Sep 2016 16:50:31 +1000
Subject: [PATCH] fix another merge resolution

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/powerpc/kernel/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 8dca64f2851f..e59ed6af0523 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -125,7 +125,7 @@ obj-y				+= iomap.o
 endif
 
 ifneq ($(CONFIG_MODULES)$(CONFIG_KEXEC_FILE),)
-ifeq ($(CONFIG_WORD_SIZE),64)
+ifeq ($(BITS),64)
 obj-y				+= elf_util.o elf_util_64.o
 endif
 endif
-- 
2.8.1

-- 
Cheers,
Stephen Rothwell

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

* linux-next: build failure after merge of the akpm-current tree
@ 2016-09-20  6:44 Stephen Rothwell
  2016-09-20  7:30 ` Stephen Rothwell
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2016-09-20  6:44 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel

Hi Andrew,

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

powerpc-linux-gcc: error: unrecognized command line option '-m'
scripts/Makefile.build:290: recipe for target 'arch/powerpc/purgatory/printf.o' failed

and a few more like that.

Caused by commit

  8635b1186486 ("powerpc: add purgatory for kexec_file_load implementation")

I have disabled KEXEC_FILE on powerpc again for now.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 5 Sep 2016 19:12:42 +1000
Subject: [PATCH] disable KEXEC_FILE on powerpc for now

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/powerpc/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 41300c3a1bfe..86ea07d7ead2 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -467,6 +467,7 @@ config KEXEC_FILE
 	depends on PPC64
 	depends on CRYPTO=y
 	depends on CRYPTO_SHA256=y
+	depends on BROKEN
 	help
 	  This is a new version of the kexec system call. This call is
 	  file based and takes in file descriptors as system call arguments
-- 
2.8.1

-- 
Cheers,
Stephen Rothwell

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

* linux-next: build failure after merge of the akpm-current tree
@ 2016-09-20  6:26 Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2016-09-20  6:26 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel

Hi Andrew,

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

fs/notify/notification.c: In function 'fsnotify_add_event':
fs/notify/notification.c:116:22: error: 'struct fsnotify_group' has no member named 'notification_mutex'
   mutex_unlock(&group->notification_mutex);
                      ^

Caused by a bad git merge automatic resolution.  I had to apply the
following merge fix patch:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 20 Sep 2016 16:23:48 +1000
Subject: [PATCH] fix bad merge of fs/notify/notification.c

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/notify/notification.c | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/fs/notify/notification.c b/fs/notify/notification.c
index ac14fa4d266b..1a8010e7a2a0 100644
--- a/fs/notify/notification.c
+++ b/fs/notify/notification.c
@@ -112,11 +112,6 @@ int fsnotify_add_event(struct fsnotify_group *group,
 		return 2;
 	}
 
-	if (group->shutdown) {
-		mutex_unlock(&group->notification_mutex);
-		return 2;
-	}
-
 	if (group->q_len >= group->max_events) {
 		ret = 2;
 		/* Queue overflow event only if it isn't already queued */
-- 
2.8.1

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2016-09-05 17:49 ` Thiago Jung Bauermann
@ 2016-09-05 23:27   ` Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2016-09-05 23:27 UTC (permalink / raw)
  To: Thiago Jung Bauermann; +Cc: Andrew Morton, linux-next, linux-kernel

Hi Thiago,

On Mon, 05 Sep 2016 14:49:12 -0300 Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> wrote:
>
> Sorry about that. The change below to arch/powerpc/purgatory/Makefile
> fixes the cross build from ppc64 BE to ppc64 LE.
> 
> I also noticed that building the purgatory during archprepare is not necessary,
> so I also made the change below to arch/powerpc/Makefile.
> 
> I'm preparing a v8 of the kexec_file_load implementation for powerpc series
> with those changes and will send it shortly.

OK, so I have applied that patch to Andrew's tree for today.
-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2016-09-05  9:19 Stephen Rothwell
@ 2016-09-05 17:49 ` Thiago Jung Bauermann
  2016-09-05 23:27   ` Stephen Rothwell
  0 siblings, 1 reply; 330+ messages in thread
From: Thiago Jung Bauermann @ 2016-09-05 17:49 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Andrew Morton, linux-next, linux-kernel

Am Montag, 05 September 2016, 19:19:17 schrieb Stephen Rothwell:
> Hi Andrew,
> 
> After merging the akpm tree, today's linux-next build (powerpc
> pseries_le_defconfig) failed like this:
> 
> powerpc-linux-ld: arch/powerpc/purgatory/purgatory.o: compiled for a big
> endian system and target is little endian powerpc-linux-ld: failed to
> merge target specific data of file arch/powerpc/purgatory/purgatory.o
> powerpc-linux-ld: arch/powerpc/purgatory/printf.o: compiled for a big
> endian system and target is little endian powerpc-linux-ld: failed to
> merge target specific data of file arch/powerpc/purgatory/printf.o
> 
> and so on ...
> 
> Presumably caused by commit
> 
>   b26db279958b ("powerpc: add purgatory for kexec_file_load
> implementation")
> 
> I added this patch for today:
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 5 Sep 2016 19:12:42 +1000
> Subject: [PATCH] disable KEXEC_FILE on powerpc for now
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  arch/powerpc/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 41300c3a1bfe..86ea07d7ead2 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -467,6 +467,7 @@ config KEXEC_FILE
>  	depends on PPC64
>  	depends on CRYPTO=y
>  	depends on CRYPTO_SHA256=y
> +	depends on BROKEN
>  	help
>  	  This is a new version of the kexec system call. This call is
>  	  file based and takes in file descriptors as system call arguments


Sorry about that. The change below to arch/powerpc/purgatory/Makefile
fixes the cross build from ppc64 BE to ppc64 LE.

I also noticed that building the purgatory during archprepare is not necessary,
so I also made the change below to arch/powerpc/Makefile.

I'm preparing a v8 of the kexec_file_load implementation for powerpc series
with those changes and will send it shortly.

-- 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center


diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index c91c496cfc64..0fb28cc8eb38 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -378,9 +378,6 @@ archclean:
 	$(Q)$(MAKE) $(clean)=$(boot)
 
 archprepare: checkbin
-ifeq ($(CONFIG_KEXEC_FILE),y)
-	$(Q)$(MAKE) $(build)=arch/powerpc/purgatory arch/powerpc/purgatory/kexec-purgatory.c
-endif
 
 # Use the file '.tmp_gas_check' for binutils tests, as gas won't output
 # to stdout and these checks are run even on install targets.
diff --git a/arch/powerpc/purgatory/Makefile b/arch/powerpc/purgatory/Makefile
index 4bda7f5a346a..fea0308c7f01 100644
--- a/arch/powerpc/purgatory/Makefile
+++ b/arch/powerpc/purgatory/Makefile
@@ -23,10 +23,12 @@ KBUILD_AFLAGS := -fno-exceptions -msoft-float -m$(CONFIG_WORD_SIZE) \
 		-D__ASSEMBLY__
 
 ifeq ($(CONFIG_CPU_LITTLE_ENDIAN),y)
-KBUILD_CFLAGS += $(call cc-option,-mabi=elfv2,$(call cc-option,-mcall-aixdesc))
-KBUILD_AFLAGS += $(call cc-option,-mabi=elfv2)
+KBUILD_CFLAGS += $(call cc-option,-mabi=elfv2,$(call cc-option,-mcall-aixdesc)) \
+		-mlittle-endian
+KBUILD_AFLAGS += $(call cc-option,-mabi=elfv2) -mlittle-endian
 else
-KBUILD_CFLAGS += $(call cc-option,-mcall-aixdesc)
+KBUILD_CFLAGS += $(call cc-option,-mcall-aixdesc) -mbig-endian
+KBUILD_AFLAGS += -mbig-endian
 endif
 
 $(obj)/purgatory.ro: $(PURGATORY_OBJS) FORCE

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

* linux-next: build failure after merge of the akpm-current tree
@ 2016-09-05  9:19 Stephen Rothwell
  2016-09-05 17:49 ` Thiago Jung Bauermann
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2016-09-05  9:19 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Thiago Jung Bauermann

Hi Andrew,

After merging the akpm tree, today's linux-next build (powerpc
pseries_le_defconfig) failed like this:

powerpc-linux-ld: arch/powerpc/purgatory/purgatory.o: compiled for a big endian system and target is little endian  
powerpc-linux-ld: failed to merge target specific data of file arch/powerpc/purgatory/purgatory.o
powerpc-linux-ld: arch/powerpc/purgatory/printf.o: compiled for a big endian system and target is little endian
powerpc-linux-ld: failed to merge target specific data of file arch/powerpc/purgatory/printf.o

and so on ...

Presumably caused by commit

  b26db279958b ("powerpc: add purgatory for kexec_file_load implementation")

I added this patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 5 Sep 2016 19:12:42 +1000
Subject: [PATCH] disable KEXEC_FILE on powerpc for now

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/powerpc/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 41300c3a1bfe..86ea07d7ead2 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -467,6 +467,7 @@ config KEXEC_FILE
 	depends on PPC64
 	depends on CRYPTO=y
 	depends on CRYPTO_SHA256=y
+	depends on BROKEN
 	help
 	  This is a new version of the kexec system call. This call is
 	  file based and takes in file descriptors as system call arguments
-- 
2.8.1

-- 
Cheers,
Stephen Rothwell

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

* linux-next: build failure after merge of the akpm-current tree
@ 2016-06-16  5:45 Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2016-06-16  5:45 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Ebru Akagunduz

Hi Andrew,

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

In file included from include/linux/mm.h:400:0,
                 from mm/huge_memory.c:10:
include/linux/huge_mm.h:53:22: error: initializer element is not constant
 #define HPAGE_PMD_NR (1<<HPAGE_PMD_ORDER)
                      ^
mm/huge_memory.c:104:62: note: in expansion of macro 'HPAGE_PMD_NR'
 static unsigned int khugepaged_max_ptes_swap __read_mostly = HPAGE_PMD_NR/8;
                                                              ^

Caused by commit

  5c38823a834f ("mm: make optimistic check for swapin readahead")

We had this error some time ago, so I have added teh same patch as
last time:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 2 May 2016 18:25:42 +1000
Subject: [PATCH] mm: make optimistic check for swapin readahead fix

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 mm/huge_memory.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index f0cd9dbc1157..6aabfa166b6d 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -101,7 +101,7 @@ static DECLARE_WAIT_QUEUE_HEAD(khugepaged_wait);
  * fault.
  */
 static unsigned int khugepaged_max_ptes_none __read_mostly;
-static unsigned int khugepaged_max_ptes_swap __read_mostly = HPAGE_PMD_NR/8;
+static unsigned int khugepaged_max_ptes_swap __read_mostly;
 static unsigned long allocstall;
 
 static int khugepaged(void *none);
@@ -703,6 +703,7 @@ static int __init hugepage_init(void)
 
 	khugepaged_pages_to_scan = HPAGE_PMD_NR * 8;
 	khugepaged_max_ptes_none = HPAGE_PMD_NR - 1;
+	khugepaged_max_ptes_swap = HPAGE_PMD_NR / 8;
 	/*
 	 * hugepages can't be allocated by the buddy allocator
 	 */
-- 
2.7.0

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2016-06-15 14:03     ` Josh Poimboeuf
@ 2016-06-15 21:12       ` Paul Bolle
  0 siblings, 0 replies; 330+ messages in thread
From: Paul Bolle @ 2016-06-15 21:12 UTC (permalink / raw)
  To: Josh Poimboeuf
  Cc: Andrew Morton, Arnd Bergmann, Stephen Rothwell, linux-next, linux-kernel

Hi Josh,

On wo, 2016-06-15 at 09:03 -0500, Josh Poimboeuf wrote:
> I agree it looks like a false positive, though the code is a bit
> convoluted, so I'm not surprised that gcc might get confused.

Agree.

> How about initializing opt to 0?

I'm unconvinced. Especially since this only shows up in 64 bits builds.

> --- a/net/netfilter/ipvs/ip_vs_sync.c
> +++ b/net/netfilter/ipvs/ip_vs_sync.c

>  static inline int ip_vs_proc_sync_conn(struct netns_ipvs *ipvs, __u8

> -	struct ip_vs_sync_conn_options opt;
> +	struct ip_vs_sync_conn_options opt = {0};

You forgot to append
                                                  /* I give up */

here. More common would be to use
                                                  /* silence GCC */
Thanks,


Paul Bolle

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2016-06-15  9:33   ` Paul Bolle
@ 2016-06-15 14:03     ` Josh Poimboeuf
  2016-06-15 21:12       ` Paul Bolle
  0 siblings, 1 reply; 330+ messages in thread
From: Josh Poimboeuf @ 2016-06-15 14:03 UTC (permalink / raw)
  To: Paul Bolle
  Cc: Andrew Morton, Arnd Bergmann, Stephen Rothwell, linux-next, linux-kernel

On Wed, Jun 15, 2016 at 11:33:32AM +0200, Paul Bolle wrote:
> On do, 2016-05-05 at 22:44 -0700, Andrew Morton wrote:
> > From: Arnd Bergmann <arnd@arndb.de>
> > Subject: byteswap: try to avoid __builtin_constant_p gcc bug
> > 
> > This is another attempt to avoid a regression in wwn_to_u64() after that
> > started using get_unaligned_be64(), which in turn ran into a bug on
> > gcc-4.9 through 6.1.
> > 
> > The regression got introduced due to the combination of two separate
> > workarounds (e3bde9568d99 ("include/linux/unaligned: force inlining of
> > byteswap operations") and ef3fb2422ffe ("scsi: fc: use get/put_unaligned64
> > for wwn access")) that each try to sidestep distinct problems with gcc
> > behavior (code growth and increased stack usage).  Unfortunately after
> > both have been applied, a more serious gcc bug has been uncovered, leading
> > to incorrect object code that discards part of a function and causes
> > undefined behavior.
> > 
> > As part of this problem is how __builtin_constant_p gets evaluated on an
> > argument passed by reference into an inline function, this avoids the use
> > of __builtin_constant_p() for all architectures that set
> > CONFIG_ARCH_USE_BUILTIN_BSWAP.  Most architectures do not set
> > ARCH_SUPPORTS_OPTIMIZED_INLINING, which means they probably do not suffer
> > from the problem in the qla2xxx driver, but they might still run into it
> > elsewhere.
> > 
> > Both of the original workarounds were only merged in the 4.6 kernel, and
> > the bug that is fixed by this patch should only appear if both are there,
> > so we probably don't need to backport the fix.  On the other hand, it
> > works by simplifying the code path and should not have any negative
> > effects.
> > 
> > [arnd@arndb.de: fix older gcc warnings]
> >   (http://lkml.kernel.org/r/12243652.bxSxEgjgfk@wuerfel)
> > Link: https://lkml.org/lkml/headers/2016/4/12/1103
> > Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66122
> > Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70232
> > Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646
> > Fixes: e3bde9568d99 ("include/linux/unaligned: force inlining of byteswap operations")
> > Fixes: ef3fb2422ffe ("scsi: fc: use get/put_unaligned64 for wwn access")
> > Link: http://lkml.kernel.org/r/1780465.XdtPJpi8Tt@wuerfel
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Reviewed-by: Josh Poimboeuf <jpoimboe@redhat.com>
> > Tested-by: Josh Poimboeuf <jpoimboe@redhat.com> # on gcc-5.3
> > Tested-by: Quinn Tran <quinn.tran@qlogic.com>
> > Cc: Martin Jambor <mjambor@suse.cz>
> > Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
> > Cc: James Bottomley <James.Bottomley@hansenpartnership.com>
> > Cc: Denys Vlasenko <dvlasenk@redhat.com>
> > Cc: Thomas Graf <tgraf@suug.ch>
> > Cc: Peter Zijlstra <peterz@infradead.org>
> > Cc: David Rientjes <rientjes@google.com>
> > Cc: Ingo Molnar <mingo@kernel.org>
> > Cc: Himanshu Madhani <himanshu.madhani@qlogic.com>
> > Cc: Jan Hubicka <hubicka@ucw.cz>
> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> 
> This became commit 7322dd755e7d ("byteswap: try to avoid
> __builtin_constant_p gcc bug"). That commit was included in v4.6-rc7.
> Ever since that rc I see this warning when building for x86_64:
>     net/netfilter/ipvs/ip_vs_sync.c: In function ‘ip_vs_proc_sync_conn’:
>     net/netfilter/ipvs/ip_vs_sync.c:1069:33: warning: ‘opt.init_seq’ may be used uninitialized in this function [-Wmaybe-uninitialized]
>       struct ip_vs_sync_conn_options opt;
>                                      ^
>     net/netfilter/ipvs/ip_vs_sync.c:1069:33: warning: ‘opt.delta’ may be used uninitialized in this function [-Wmaybe-uninitialized]
>     net/netfilter/ipvs/ip_vs_sync.c:1069:33: warning: ‘opt.previous_delta’ may be used uninitialized in this function [-Wmaybe-uninitialized]
>     net/netfilter/ipvs/ip_vs_sync.c:1069:33: warning: ‘*((void *)&opt+12).init_seq’ may be used uninitialized in this function [-Wmaybe-uninitialized]
>     net/netfilter/ipvs/ip_vs_sync.c:1069:33: warning: ‘*((void *)&opt+12).delta’ may be used uninitialized in this function [-Wmaybe-uninitialized]
>     net/netfilter/ipvs/ip_vs_sync.c:1069:33: warning: ‘*((void *)&opt+12).previous_delta’ may be used uninitialized in this function [-Wmaybe-uninitialized]
> 
> (It doesn't show up when building for 32 bits x86. Perhaps there's an
> int/long mismatch somewhere in the related code.)
> 
> Anyone else seeing this? 
> 
> It looks like a false positive. I can make it disappear by making sure
> ip_vs_proc_seqopt() isn't inlined. But that's not something I dare to
> put into a patch for a false positive. Anyone sitting on a better fix?

Hi Paul,

I agree it looks like a false positive, though the code is a bit
convoluted, so I'm not surprised that gcc might get confused.  How about
initializing opt to 0?

diff --git a/net/netfilter/ipvs/ip_vs_sync.c b/net/netfilter/ipvs/ip_vs_sync.c
index 803001a..f45496c 100644
--- a/net/netfilter/ipvs/ip_vs_sync.c
+++ b/net/netfilter/ipvs/ip_vs_sync.c
@@ -1066,7 +1066,7 @@ static int ip_vs_proc_str(__u8 *p, unsigned int plen, unsigned int *data_len,
  */
 static inline int ip_vs_proc_sync_conn(struct netns_ipvs *ipvs, __u8 *p, __u8 *msg_end)
 {
-	struct ip_vs_sync_conn_options opt;
+	struct ip_vs_sync_conn_options opt = {0};
 	union  ip_vs_sync_conn *s;
 	struct ip_vs_protocol *pp;
 	struct ip_vs_conn_param param;

-- 
Josh

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2016-05-06  5:44 ` Andrew Morton
  2016-05-06  6:09   ` Stephen Rothwell
@ 2016-06-15  9:33   ` Paul Bolle
  2016-06-15 14:03     ` Josh Poimboeuf
  1 sibling, 1 reply; 330+ messages in thread
From: Paul Bolle @ 2016-06-15  9:33 UTC (permalink / raw)
  To: Andrew Morton, Arnd Bergmann; +Cc: Stephen Rothwell, linux-next, linux-kernel

On do, 2016-05-05 at 22:44 -0700, Andrew Morton wrote:
> From: Arnd Bergmann <arnd@arndb.de>
> Subject: byteswap: try to avoid __builtin_constant_p gcc bug
> 
> This is another attempt to avoid a regression in wwn_to_u64() after that
> started using get_unaligned_be64(), which in turn ran into a bug on
> gcc-4.9 through 6.1.
> 
> The regression got introduced due to the combination of two separate
> workarounds (e3bde9568d99 ("include/linux/unaligned: force inlining of
> byteswap operations") and ef3fb2422ffe ("scsi: fc: use get/put_unaligned64
> for wwn access")) that each try to sidestep distinct problems with gcc
> behavior (code growth and increased stack usage).  Unfortunately after
> both have been applied, a more serious gcc bug has been uncovered, leading
> to incorrect object code that discards part of a function and causes
> undefined behavior.
> 
> As part of this problem is how __builtin_constant_p gets evaluated on an
> argument passed by reference into an inline function, this avoids the use
> of __builtin_constant_p() for all architectures that set
> CONFIG_ARCH_USE_BUILTIN_BSWAP.  Most architectures do not set
> ARCH_SUPPORTS_OPTIMIZED_INLINING, which means they probably do not suffer
> from the problem in the qla2xxx driver, but they might still run into it
> elsewhere.
> 
> Both of the original workarounds were only merged in the 4.6 kernel, and
> the bug that is fixed by this patch should only appear if both are there,
> so we probably don't need to backport the fix.  On the other hand, it
> works by simplifying the code path and should not have any negative
> effects.
> 
> [arnd@arndb.de: fix older gcc warnings]
>   (http://lkml.kernel.org/r/12243652.bxSxEgjgfk@wuerfel)
> Link: https://lkml.org/lkml/headers/2016/4/12/1103
> Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66122
> Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70232
> Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646
> Fixes: e3bde9568d99 ("include/linux/unaligned: force inlining of byteswap operations")
> Fixes: ef3fb2422ffe ("scsi: fc: use get/put_unaligned64 for wwn access")
> Link: http://lkml.kernel.org/r/1780465.XdtPJpi8Tt@wuerfel
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Reviewed-by: Josh Poimboeuf <jpoimboe@redhat.com>
> Tested-by: Josh Poimboeuf <jpoimboe@redhat.com> # on gcc-5.3
> Tested-by: Quinn Tran <quinn.tran@qlogic.com>
> Cc: Martin Jambor <mjambor@suse.cz>
> Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
> Cc: James Bottomley <James.Bottomley@hansenpartnership.com>
> Cc: Denys Vlasenko <dvlasenk@redhat.com>
> Cc: Thomas Graf <tgraf@suug.ch>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: David Rientjes <rientjes@google.com>
> Cc: Ingo Molnar <mingo@kernel.org>
> Cc: Himanshu Madhani <himanshu.madhani@qlogic.com>
> Cc: Jan Hubicka <hubicka@ucw.cz>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

This became commit 7322dd755e7d ("byteswap: try to avoid
__builtin_constant_p gcc bug"). That commit was included in v4.6-rc7.
Ever since that rc I see this warning when building for x86_64:
    net/netfilter/ipvs/ip_vs_sync.c: In function ‘ip_vs_proc_sync_conn’:
    net/netfilter/ipvs/ip_vs_sync.c:1069:33: warning: ‘opt.init_seq’ may be used uninitialized in this function [-Wmaybe-uninitialized]
      struct ip_vs_sync_conn_options opt;
                                     ^
    net/netfilter/ipvs/ip_vs_sync.c:1069:33: warning: ‘opt.delta’ may be used uninitialized in this function [-Wmaybe-uninitialized]
    net/netfilter/ipvs/ip_vs_sync.c:1069:33: warning: ‘opt.previous_delta’ may be used uninitialized in this function [-Wmaybe-uninitialized]
    net/netfilter/ipvs/ip_vs_sync.c:1069:33: warning: ‘*((void *)&opt+12).init_seq’ may be used uninitialized in this function [-Wmaybe-uninitialized]
    net/netfilter/ipvs/ip_vs_sync.c:1069:33: warning: ‘*((void *)&opt+12).delta’ may be used uninitialized in this function [-Wmaybe-uninitialized]
    net/netfilter/ipvs/ip_vs_sync.c:1069:33: warning: ‘*((void *)&opt+12).previous_delta’ may be used uninitialized in this function [-Wmaybe-uninitialized]

(It doesn't show up when building for 32 bits x86. Perhaps there's an
int/long mismatch somewhere in the related code.)

Anyone else seeing this? 

It looks like a false positive. I can make it disappear by making sure
ip_vs_proc_seqopt() isn't inlined. But that's not something I dare to
put into a patch for a false positive. Anyone sitting on a better fix?


Paul Bolle

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2016-06-06  4:03 Stephen Rothwell
@ 2016-06-06 20:22 ` Andrew Morton
  0 siblings, 0 replies; 330+ messages in thread
From: Andrew Morton @ 2016-06-06 20:22 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Russell King

On Mon, 6 Jun 2016 14:03:27 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> In file included from include/linux/crash_dump.h:5:0,
>                  from arch/powerpc/kernel/crash_dump.c:14:
> include/linux/kexec.h:358:9: note: previous implicit declaration of 'phys_to_virt' was here
>   return phys_to_virt(boot_phys_to_phys(entry));
>          ^
> 
> Caused by commit
> 
>   4382eb9055be ("kexec: allow architectures to override boot mapping")
> 
> Architecture seem to define phys_to_virt() in either asm/io.h or
> asm/memory.h or asm/virtconvert.h or asm/page*.h ... or asm-generic/io.h.
> :-(
> 
> I have reverted that commit for today (and commit c9aaeae038fa ("ARM:
> kexec: fix kexec for Keystone 2")).

Let's see how this gets along.

From: Andrew Morton <akpm@linux-foundation.org>
Subject: kexec-allow-architectures-to-override-boot-mapping-fix

kexec.h needs asm/io.h for phys_to_virt()

Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

--- a/include/linux/kexec.h~kexec-allow-architectures-to-override-boot-mapping-fix
+++ a/include/linux/kexec.h
@@ -14,6 +14,8 @@
 
 #if !defined(__ASSEMBLY__)
 
+#include <asm/io.h>
+
 #include <uapi/linux/kexec.h>
 
 #ifdef CONFIG_KEXEC_CORE

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

* linux-next: build failure after merge of the akpm-current tree
@ 2016-06-06  4:03 Stephen Rothwell
  2016-06-06 20:22 ` Andrew Morton
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2016-06-06  4:03 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Russell King

Hi Andrew,

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

include/linux/kexec.h: In function 'boot_phys_to_virt':
include/linux/kexec.h:358:9: error: implicit declaration of function 'phys_to_virt' [-Werror=implicit-function-declaration]
  return phys_to_virt(boot_phys_to_phys(entry));
         ^
include/linux/kexec.h:358:9: error: return makes pointer from integer without a cast [-Werror=int-conversion]
In file included from arch/powerpc/platforms/cell/ras.c:22:0:
arch/powerpc/include/asm/io.h: At top level:
arch/powerpc/include/asm/io.h:801:22: error: conflicting types for 'phys_to_virt'
 static inline void * phys_to_virt(unsigned long address)
                      ^
In file included from arch/powerpc/platforms/cell/ras.c:17:0:
include/linux/kexec.h:358:9: note: previous implicit declaration of 'phys_to_virt' was here
  return phys_to_virt(boot_phys_to_phys(entry));
         ^
In file included from kernel/ksysfs.c:16:0:
include/linux/kexec.h: In function 'boot_phys_to_virt':
include/linux/kexec.h:358:9: error: implicit declaration of function 'phys_to_virt' [-Werror=implicit-function-declaration]
  return phys_to_virt(boot_phys_to_phys(entry));
         ^
include/linux/kexec.h:358:9: warning: return makes pointer from integer without a cast [-Wint-conversion]
In file included from include/linux/crash_dump.h:5:0,
                 from arch/powerpc/kernel/crash_dump.c:14:
include/linux/kexec.h: In function 'boot_phys_to_virt':
include/linux/kexec.h:358:9: error: implicit declaration of function 'phys_to_virt' [-Werror=implicit-function-declaration]
  return phys_to_virt(boot_phys_to_phys(entry));
         ^
include/linux/kexec.h:358:9: error: return makes pointer from integer without a cast [-Werror=int-conversion]
In file included from include/linux/io.h:25:0,
                 from arch/powerpc/kernel/crash_dump.c:15:
arch/powerpc/include/asm/io.h: At top level:
arch/powerpc/include/asm/io.h:801:22: error: conflicting types for 'phys_to_virt'
 static inline void * phys_to_virt(unsigned long address)
                      ^
In file included from include/linux/crash_dump.h:5:0,
                 from arch/powerpc/kernel/crash_dump.c:14:
include/linux/kexec.h:358:9: note: previous implicit declaration of 'phys_to_virt' was here
  return phys_to_virt(boot_phys_to_phys(entry));
         ^

Caused by commit

  4382eb9055be ("kexec: allow architectures to override boot mapping")

Architecture seem to define phys_to_virt() in either asm/io.h or
asm/memory.h or asm/virtconvert.h or asm/page*.h ... or asm-generic/io.h.
:-(

I have reverted that commit for today (and commit c9aaeae038fa ("ARM:
kexec: fix kexec for Keystone 2")).

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2016-05-06  6:09   ` Stephen Rothwell
@ 2016-05-06  6:55     ` Michael Ellerman
  0 siblings, 0 replies; 330+ messages in thread
From: Michael Ellerman @ 2016-05-06  6:55 UTC (permalink / raw)
  To: Stephen Rothwell, Andrew Morton; +Cc: linux-next, linux-kernel, Arnd Bergmann

On Fri, 2016-05-06 at 16:09 +1000, Stephen Rothwell wrote:
> Hi Andrew,
> 
> On Thu, 5 May 2016 22:44:29 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
> > 
> > On Fri, 6 May 2016 14:58:10 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > 
> > > After merging the akpm-current tree, today's linux-next build (and a
> > > few earlier ones) (powerpc allnoconfig (and many others)) failed like
> > > this:
> > > 
> > > lib/vsprintf.c:160:2: error: initializer element is not constant
> > > lib/vsprintf.c:160:2: error: (near initialization for 'decpair[0]')
> > > lib/vsprintf.c:160:2: error: initializer element is not constant
> > > lib/vsprintf.c:160:2: error: (near initialization for 'decpair[1]')
> > > lib/vsprintf.c:160:2: error: initializer element is not constant
> > > lib/vsprintf.c:160:2: error: (near initialization for 'decpair[2]')
> > > lib/vsprintf.c:160:2: error: initializer element is not constant
> > > lib/vsprintf.c:160:2: error: (near initialization for 'decpair[3]')
> > > lib/vsprintf.c:160:2: error: initializer element is not constant
> > > 
> > > and more ... basically any big endian build of code using __swabxx
> > > or cpu_to_lexx in initailisers (in the above case cpu_to_le16()).
> > > 
> > > Caused (presumably) by commit
> > > 
> > >   eeee46ed3cda ("byteswap: try to avoid __builtin_constant_p gcc bug")
> > > 
> > > This is a buyild using gcc 4.6.3.
> > > 
> > > I have revreted that commit for today to see if it fixes the overnight
> > > builds.  
> > 
> > hm, it works for me.  powerpc allnoconfig, after setting CONFIG_PPC64=y.
> 
> Interesting ...  mine also works with gcc 5.2.0. I do 32 and 64 bit
> allnoconfig powerpc builds before I release linux-next and they work,
> but the 32 bit one fails overnight when gcc 4.6.3 is used :-( (we don't
> do a 64 bit allnoconfig overnight as it requires playing with the
> generated .config).  Basically all the powerpc builds were failing with
> gcc 4.6.3 since next-20160502.

There's a powerpc-5.3 compiler in kisskb now, I've been testing it for a while
and it seems OK, you can start using that as well of or instead if you like for
linux-next builds.

cheers

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2016-05-06  5:44 ` Andrew Morton
@ 2016-05-06  6:09   ` Stephen Rothwell
  2016-05-06  6:55     ` Michael Ellerman
  2016-06-15  9:33   ` Paul Bolle
  1 sibling, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2016-05-06  6:09 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Arnd Bergmann

Hi Andrew,

On Thu, 5 May 2016 22:44:29 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Fri, 6 May 2016 14:58:10 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > After merging the akpm-current tree, today's linux-next build (and a
> > few earlier ones) (powerpc allnoconfig (and many others)) failed like
> > this:
> > 
> > lib/vsprintf.c:160:2: error: initializer element is not constant
> > lib/vsprintf.c:160:2: error: (near initialization for 'decpair[0]')
> > lib/vsprintf.c:160:2: error: initializer element is not constant
> > lib/vsprintf.c:160:2: error: (near initialization for 'decpair[1]')
> > lib/vsprintf.c:160:2: error: initializer element is not constant
> > lib/vsprintf.c:160:2: error: (near initialization for 'decpair[2]')
> > lib/vsprintf.c:160:2: error: initializer element is not constant
> > lib/vsprintf.c:160:2: error: (near initialization for 'decpair[3]')
> > lib/vsprintf.c:160:2: error: initializer element is not constant
> > 
> > and more ... basically any big endian build of code using __swabxx
> > or cpu_to_lexx in initailisers (in the above case cpu_to_le16()).
> > 
> > Caused (presumably) by commit
> > 
> >   eeee46ed3cda ("byteswap: try to avoid __builtin_constant_p gcc bug")
> > 
> > This is a buyild using gcc 4.6.3.
> > 
> > I have revreted that commit for today to see if it fixes the overnight
> > builds.  
> 
> hm, it works for me.  powerpc allnoconfig, after setting CONFIG_PPC64=y.

Interesting ...  mine also works with gcc 5.2.0. I do 32 and 64 bit
allnoconfig powerpc builds before I release linux-next and they work,
but the 32 bit one fails overnight when gcc 4.6.3 is used :-( (we don't
do a 64 bit allnoconfig overnight as it requires playing with the
generated .config).  Basically all the powerpc builds were failing with
gcc 4.6.3 since next-20160502.

The overnight powerpc allnoconfig build has just succeeded for today's
linux-next.

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2016-05-06  4:58 Stephen Rothwell
@ 2016-05-06  5:44 ` Andrew Morton
  2016-05-06  6:09   ` Stephen Rothwell
  2016-06-15  9:33   ` Paul Bolle
  0 siblings, 2 replies; 330+ messages in thread
From: Andrew Morton @ 2016-05-06  5:44 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Arnd Bergmann

On Fri, 6 May 2016 14:58:10 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Andrew,
> 
> After merging the akpm-current tree, today's linux-next build (and a
> few earlier ones) (powerpc allnoconfig (and many others)) failed like
> this:
> 
> lib/vsprintf.c:160:2: error: initializer element is not constant
> lib/vsprintf.c:160:2: error: (near initialization for 'decpair[0]')
> lib/vsprintf.c:160:2: error: initializer element is not constant
> lib/vsprintf.c:160:2: error: (near initialization for 'decpair[1]')
> lib/vsprintf.c:160:2: error: initializer element is not constant
> lib/vsprintf.c:160:2: error: (near initialization for 'decpair[2]')
> lib/vsprintf.c:160:2: error: initializer element is not constant
> lib/vsprintf.c:160:2: error: (near initialization for 'decpair[3]')
> lib/vsprintf.c:160:2: error: initializer element is not constant
> 
> and more ... basically any big endian build of code using __swabxx
> or cpu_to_lexx in initailisers (in the above case cpu_to_le16()).
> 
> Caused (presumably) by commit
> 
>   eeee46ed3cda ("byteswap: try to avoid __builtin_constant_p gcc bug")
> 
> This is a buyild using gcc 4.6.3.
> 
> I have revreted that commit for today to see if it fixes the overnight
> builds.

hm, it works for me.  powerpc allnoconfig, after setting CONFIG_PPC64=y.

With this:


From: Arnd Bergmann <arnd@arndb.de>
Subject: byteswap: try to avoid __builtin_constant_p gcc bug

This is another attempt to avoid a regression in wwn_to_u64() after that
started using get_unaligned_be64(), which in turn ran into a bug on
gcc-4.9 through 6.1.

The regression got introduced due to the combination of two separate
workarounds (e3bde9568d99 ("include/linux/unaligned: force inlining of
byteswap operations") and ef3fb2422ffe ("scsi: fc: use get/put_unaligned64
for wwn access")) that each try to sidestep distinct problems with gcc
behavior (code growth and increased stack usage).  Unfortunately after
both have been applied, a more serious gcc bug has been uncovered, leading
to incorrect object code that discards part of a function and causes
undefined behavior.

As part of this problem is how __builtin_constant_p gets evaluated on an
argument passed by reference into an inline function, this avoids the use
of __builtin_constant_p() for all architectures that set
CONFIG_ARCH_USE_BUILTIN_BSWAP.  Most architectures do not set
ARCH_SUPPORTS_OPTIMIZED_INLINING, which means they probably do not suffer
from the problem in the qla2xxx driver, but they might still run into it
elsewhere.

Both of the original workarounds were only merged in the 4.6 kernel, and
the bug that is fixed by this patch should only appear if both are there,
so we probably don't need to backport the fix.  On the other hand, it
works by simplifying the code path and should not have any negative
effects.

[arnd@arndb.de: fix older gcc warnings]
  (http://lkml.kernel.org/r/12243652.bxSxEgjgfk@wuerfel)
Link: https://lkml.org/lkml/headers/2016/4/12/1103
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66122
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70232
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646
Fixes: e3bde9568d99 ("include/linux/unaligned: force inlining of byteswap operations")
Fixes: ef3fb2422ffe ("scsi: fc: use get/put_unaligned64 for wwn access")
Link: http://lkml.kernel.org/r/1780465.XdtPJpi8Tt@wuerfel
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Josh Poimboeuf <jpoimboe@redhat.com>
Tested-by: Josh Poimboeuf <jpoimboe@redhat.com> # on gcc-5.3
Tested-by: Quinn Tran <quinn.tran@qlogic.com>
Cc: Martin Jambor <mjambor@suse.cz>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: James Bottomley <James.Bottomley@hansenpartnership.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: Thomas Graf <tgraf@suug.ch>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Himanshu Madhani <himanshu.madhani@qlogic.com>
Cc: Jan Hubicka <hubicka@ucw.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 include/uapi/linux/swab.h |   24 +++++++++++++++---------
 1 file changed, 15 insertions(+), 9 deletions(-)

diff -puN include/uapi/linux/swab.h~byteswap-try-to-avoid-__builtin_constant_p-gcc-bug-v2 include/uapi/linux/swab.h
--- a/include/uapi/linux/swab.h~byteswap-try-to-avoid-__builtin_constant_p-gcc-bug-v2
+++ a/include/uapi/linux/swab.h
@@ -45,9 +45,7 @@
 
 static inline __attribute_const__ __u16 __fswab16(__u16 val)
 {
-#ifdef __HAVE_BUILTIN_BSWAP16__
-	return __builtin_bswap16(val);
-#elif defined (__arch_swab16)
+#if defined (__arch_swab16)
 	return __arch_swab16(val);
 #else
 	return ___constant_swab16(val);
@@ -56,9 +54,7 @@ static inline __attribute_const__ __u16
 
 static inline __attribute_const__ __u32 __fswab32(__u32 val)
 {
-#ifdef __HAVE_BUILTIN_BSWAP32__
-	return __builtin_bswap32(val);
-#elif defined(__arch_swab32)
+#if defined(__arch_swab32)
 	return __arch_swab32(val);
 #else
 	return ___constant_swab32(val);
@@ -67,9 +63,7 @@ static inline __attribute_const__ __u32
 
 static inline __attribute_const__ __u64 __fswab64(__u64 val)
 {
-#ifdef __HAVE_BUILTIN_BSWAP64__
-	return __builtin_bswap64(val);
-#elif defined (__arch_swab64)
+#if defined (__arch_swab64)
 	return __arch_swab64(val);
 #elif defined(__SWAB_64_THRU_32__)
 	__u32 h = val >> 32;
@@ -102,28 +96,40 @@ static inline __attribute_const__ __u32
  * __swab16 - return a byteswapped 16-bit value
  * @x: value to byteswap
  */
+#ifdef __HAVE_BUILTIN_BSWAP16__
+#define __swab16(x) (__u16)__builtin_bswap16((__u16)(x))
+#else
 #define __swab16(x)				\
 	(__builtin_constant_p((__u16)(x)) ?	\
 	___constant_swab16(x) :			\
 	__fswab16(x))
+#endif
 
 /**
  * __swab32 - return a byteswapped 32-bit value
  * @x: value to byteswap
  */
+#ifdef __HAVE_BUILTIN_BSWAP32__
+#define __swab32(x) (__u32)__builtin_bswap32((__u32)(x))
+#else
 #define __swab32(x)				\
 	(__builtin_constant_p((__u32)(x)) ?	\
 	___constant_swab32(x) :			\
 	__fswab32(x))
+#endif
 
 /**
  * __swab64 - return a byteswapped 64-bit value
  * @x: value to byteswap
  */
+#ifdef __HAVE_BUILTIN_BSWAP64__
+#define __swab64(x) (__u64)__builtin_bswap64((__u64)(x))
+#else
 #define __swab64(x)				\
 	(__builtin_constant_p((__u64)(x)) ?	\
 	___constant_swab64(x) :			\
 	__fswab64(x))
+#endif
 
 /**
  * __swahw32 - return a word-swapped 32-bit value
_

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

* linux-next: build failure after merge of the akpm-current tree
@ 2016-05-06  4:58 Stephen Rothwell
  2016-05-06  5:44 ` Andrew Morton
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2016-05-06  4:58 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Arnd Bergmann

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (and a
few earlier ones) (powerpc allnoconfig (and many others)) failed like
this:

lib/vsprintf.c:160:2: error: initializer element is not constant
lib/vsprintf.c:160:2: error: (near initialization for 'decpair[0]')
lib/vsprintf.c:160:2: error: initializer element is not constant
lib/vsprintf.c:160:2: error: (near initialization for 'decpair[1]')
lib/vsprintf.c:160:2: error: initializer element is not constant
lib/vsprintf.c:160:2: error: (near initialization for 'decpair[2]')
lib/vsprintf.c:160:2: error: initializer element is not constant
lib/vsprintf.c:160:2: error: (near initialization for 'decpair[3]')
lib/vsprintf.c:160:2: error: initializer element is not constant

and more ... basically any big endian build of code using __swabxx
or cpu_to_lexx in initailisers (in the above case cpu_to_le16()).

Caused (presumably) by commit

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

This is a buyild using gcc 4.6.3.

I have revreted that commit for today to see if it fixes the overnight
builds.

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2016-05-02  8:32 Stephen Rothwell
@ 2016-05-02 11:17 ` Aneesh Kumar K.V
  0 siblings, 0 replies; 330+ messages in thread
From: Aneesh Kumar K.V @ 2016-05-02 11:17 UTC (permalink / raw)
  To: Stephen Rothwell, Andrew Morton, Michael Ellerman,
	Benjamin Herrenschmidt, linuxppc-dev
  Cc: linux-next, linux-kernel, Ebru Akagunduz, Rik van Riel

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

> Hi Andrew,
>
> After merging the akpm-current tree, today's linux-next build (powerpc
> allyesconfig and pseries_le_defconfig) failed like this:
>
> In file included from include/linux/mm.h:394:0,
>                  from mm/huge_memory.c:10:
> include/linux/huge_mm.h:53:22: error: initializer element is not constant
>  #define HPAGE_PMD_NR (1<<HPAGE_PMD_ORDER)
>                       ^
> mm/huge_memory.c:104:62: note: in expansion of macro 'HPAGE_PMD_NR'
>  static unsigned int khugepaged_max_ptes_swap __read_mostly = HPAGE_PMD_NR/8;
>                                                               ^
>
> Caused by commit
>
>   6d34b9749be2 ("mm: make optimistic check for swapin readahead")
>
> interacting with commit
>
>   dd1842a2a448 ("powerpc/mm: Make page table size a variable")
>
> from the powerpc tree.
>
> I applied this fix patch for today (hopefully this is still initialised
> early enough):
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 2 May 2016 18:25:42 +1000
> Subject: [PATCH] mm: make optimistic check for swapin readahead fix
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>


Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>

> ---
>  mm/huge_memory.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index f0cd9dbc1157..6aabfa166b6d 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -101,7 +101,7 @@ static DECLARE_WAIT_QUEUE_HEAD(khugepaged_wait);
>   * fault.
>   */
>  static unsigned int khugepaged_max_ptes_none __read_mostly;
> -static unsigned int khugepaged_max_ptes_swap __read_mostly = HPAGE_PMD_NR/8;
> +static unsigned int khugepaged_max_ptes_swap __read_mostly;
>  static unsigned long allocstall;
>
>  static int khugepaged(void *none);
> @@ -703,6 +703,7 @@ static int __init hugepage_init(void)
>
>  	khugepaged_pages_to_scan = HPAGE_PMD_NR * 8;
>  	khugepaged_max_ptes_none = HPAGE_PMD_NR - 1;
> +	khugepaged_max_ptes_swap = HPAGE_PMD_NR / 8;
>  	/*
>  	 * hugepages can't be allocated by the buddy allocator
>  	 */
> -- 
> 2.7.0
>
>
>
>
> -- 
> Cheers,
> Stephen Rothwell

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

* linux-next: build failure after merge of the akpm-current tree
@ 2016-05-02  8:32 Stephen Rothwell
  2016-05-02 11:17 ` Aneesh Kumar K.V
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2016-05-02  8:32 UTC (permalink / raw)
  To: Andrew Morton, Michael Ellerman, Benjamin Herrenschmidt, linuxppc-dev
  Cc: linux-next, linux-kernel, Ebru Akagunduz, Rik van Riel, Aneesh Kumar K.V

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (powerpc
allyesconfig and pseries_le_defconfig) failed like this:

In file included from include/linux/mm.h:394:0,
                 from mm/huge_memory.c:10:
include/linux/huge_mm.h:53:22: error: initializer element is not constant
 #define HPAGE_PMD_NR (1<<HPAGE_PMD_ORDER)
                      ^
mm/huge_memory.c:104:62: note: in expansion of macro 'HPAGE_PMD_NR'
 static unsigned int khugepaged_max_ptes_swap __read_mostly = HPAGE_PMD_NR/8;
                                                              ^

Caused by commit

  6d34b9749be2 ("mm: make optimistic check for swapin readahead")

interacting with commit

  dd1842a2a448 ("powerpc/mm: Make page table size a variable")

from the powerpc tree.

I applied this fix patch for today (hopefully this is still initialised
early enough):

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 2 May 2016 18:25:42 +1000
Subject: [PATCH] mm: make optimistic check for swapin readahead fix

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 mm/huge_memory.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index f0cd9dbc1157..6aabfa166b6d 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -101,7 +101,7 @@ static DECLARE_WAIT_QUEUE_HEAD(khugepaged_wait);
  * fault.
  */
 static unsigned int khugepaged_max_ptes_none __read_mostly;
-static unsigned int khugepaged_max_ptes_swap __read_mostly = HPAGE_PMD_NR/8;
+static unsigned int khugepaged_max_ptes_swap __read_mostly;
 static unsigned long allocstall;
 
 static int khugepaged(void *none);
@@ -703,6 +703,7 @@ static int __init hugepage_init(void)
 
 	khugepaged_pages_to_scan = HPAGE_PMD_NR * 8;
 	khugepaged_max_ptes_none = HPAGE_PMD_NR - 1;
+	khugepaged_max_ptes_swap = HPAGE_PMD_NR / 8;
 	/*
 	 * hugepages can't be allocated by the buddy allocator
 	 */
-- 
2.7.0




-- 
Cheers,
Stephen Rothwell

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

* linux-next: build failure after merge of the akpm-current tree
@ 2016-04-22  5:18 Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2016-04-22  5:18 UTC (permalink / raw)
  To: Andrew Morton, David S. Miller
  Cc: linux-next, linux-kernel, Manish Chopra, Yuval Mintz,
	Tariq Toukan, Saeed Mahameed, Joonsoo Kim

Hi Andrew,

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

drivers/net/ethernet/qlogic/qede/qede_main.c: In function 'qede_fill_frag_skb':
drivers/net/ethernet/qlogic/qede/qede_main.c:961:31: error: 'struct page' has no member named '_count'
   atomic_inc(&current_bd->data->_count);
                               ^
drivers/net/ethernet/qlogic/qede/qede_main.c: In function 'qede_rx_int':
drivers/net/ethernet/qlogic/qede/qede_main.c:1412:33: error: 'struct page' has no member named '_count'
     atomic_inc(&sw_rx_data->data->_count);
                                 ^  
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c: In function 'mlx5e_alloc_rx_fragmented_mpwqe': 
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c:297:32: error: 'struct page' has no member named '_count'
       &wi->umr.dma_info[i].page->_count);
                                ^   
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c:316:32: error: 'struct page' has no member named '_count'
       &wi->umr.dma_info[i].page->_count);
                                ^   
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c: In function 'mlx5e_free_rx_fragmented_mpwqe':  
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c:341:32: error: 'struct page' has no member named '_count'
       &wi->umr.dma_info[i].page->_count);
                                ^   
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c: In function 'mlx5e_alloc_rx_linear_mpwqe':
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c:391:28: error: 'struct page' has no member named '_count'
       &wi->dma_info.page[i]._count);
                            ^
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c: In function 'mlx5e_free_rx_linear_mpwqe':
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c:415:28: error: 'struct page' has no member named '_count'
       &wi->dma_info.page[i]._count);
                            ^

Caused by commit

  2dde4bc2820e ("mm: rename _count, field of the struct page, to _refcount")

interacting with commits

  f86af2dfded6 ("qede: Fix various memory allocation error flows for fastpath")

from Linus' tree and

  bc77b240b3c5 ("net/mlx5e: Add fragmented memory support for RX multi packet WQE")

from the net-next tree.

I applied the following patch:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 22 Apr 2016 15:13:21 +1000
Subject: [PATCH] mm-rename-_count-field-of-the-struct-page-to-_refcount-fix6

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/net/ethernet/mellanox/mlx5/core/en_rx.c | 20 ++++++++++----------
 drivers/net/ethernet/qlogic/qede/qede_main.c    |  4 ++--
 2 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
index 918b7c7fd74f..0543fbc130b6 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
@@ -293,8 +293,8 @@ static int mlx5e_alloc_rx_fragmented_mpwqe(struct mlx5e_rq *rq,
 	for (i = 0; i < MLX5_MPWRQ_PAGES_PER_WQE; i++) {
 		if (unlikely(mlx5e_alloc_and_map_page(rq, wi, i)))
 			goto err_unmap;
-		atomic_add(MLX5_MPWRQ_STRIDES_PER_PAGE,
-			   &wi->umr.dma_info[i].page->_count);
+		page_ref_add(wi->umr.dma_info[i].page,
+			     MLX5_MPWRQ_STRIDES_PER_PAGE);
 		wi->skbs_frags[i] = 0;
 	}
 
@@ -312,8 +312,8 @@ err_unmap:
 	while (--i >= 0) {
 		dma_unmap_page(rq->pdev, wi->umr.dma_info[i].addr, PAGE_SIZE,
 			       PCI_DMA_FROMDEVICE);
-		atomic_sub(MLX5_MPWRQ_STRIDES_PER_PAGE,
-			   &wi->umr.dma_info[i].page->_count);
+		page_ref_sub(wi->umr.dma_info[i].page,
+			     MLX5_MPWRQ_STRIDES_PER_PAGE);
 		put_page(wi->umr.dma_info[i].page);
 	}
 	dma_unmap_single(rq->pdev, wi->umr.mtt_addr, mtt_sz, PCI_DMA_TODEVICE);
@@ -337,8 +337,8 @@ void mlx5e_free_rx_fragmented_mpwqe(struct mlx5e_rq *rq,
 	for (i = 0; i < MLX5_MPWRQ_PAGES_PER_WQE; i++) {
 		dma_unmap_page(rq->pdev, wi->umr.dma_info[i].addr, PAGE_SIZE,
 			       PCI_DMA_FROMDEVICE);
-		atomic_sub(MLX5_MPWRQ_STRIDES_PER_PAGE - wi->skbs_frags[i],
-			   &wi->umr.dma_info[i].page->_count);
+		page_ref_sub(wi->umr.dma_info[i].page,
+			     MLX5_MPWRQ_STRIDES_PER_PAGE - wi->skbs_frags[i]);
 		put_page(wi->umr.dma_info[i].page);
 	}
 	dma_unmap_single(rq->pdev, wi->umr.mtt_addr, mtt_sz, PCI_DMA_TODEVICE);
@@ -387,8 +387,8 @@ static int mlx5e_alloc_rx_linear_mpwqe(struct mlx5e_rq *rq,
 	 */
 	split_page(wi->dma_info.page, MLX5_MPWRQ_WQE_PAGE_ORDER);
 	for (i = 0; i < MLX5_MPWRQ_PAGES_PER_WQE; i++) {
-		atomic_add(MLX5_MPWRQ_STRIDES_PER_PAGE,
-			   &wi->dma_info.page[i]._count);
+		page_ref_add(&wi->dma_info.page[i],
+			     MLX5_MPWRQ_STRIDES_PER_PAGE);
 		wi->skbs_frags[i] = 0;
 	}
 
@@ -411,8 +411,8 @@ void mlx5e_free_rx_linear_mpwqe(struct mlx5e_rq *rq,
 	dma_unmap_page(rq->pdev, wi->dma_info.addr, rq->wqe_sz,
 		       PCI_DMA_FROMDEVICE);
 	for (i = 0; i < MLX5_MPWRQ_PAGES_PER_WQE; i++) {
-		atomic_sub(MLX5_MPWRQ_STRIDES_PER_PAGE - wi->skbs_frags[i],
-			   &wi->dma_info.page[i]._count);
+		page_ref_sub(&wi->dma_info.page[i],
+			     MLX5_MPWRQ_STRIDES_PER_PAGE - wi->skbs_frags[i]);
 		put_page(&wi->dma_info.page[i]);
 	}
 }
diff --git a/drivers/net/ethernet/qlogic/qede/qede_main.c b/drivers/net/ethernet/qlogic/qede/qede_main.c
index 66cd9f9bd57b..4eaa74f68883 100644
--- a/drivers/net/ethernet/qlogic/qede/qede_main.c
+++ b/drivers/net/ethernet/qlogic/qede/qede_main.c
@@ -958,7 +958,7 @@ static int qede_fill_frag_skb(struct qede_dev *edev,
 		/* Incr page ref count to reuse on allocation failure
 		 * so that it doesn't get freed while freeing SKB.
 		 */
-		atomic_inc(&current_bd->data->_count);
+		page_ref_inc(current_bd->data);
 		goto out;
 	}
 
@@ -1409,7 +1409,7 @@ static int qede_rx_int(struct qede_fastpath *fp, int budget)
 				 * freeing SKB.
 				 */
 
-				atomic_inc(&sw_rx_data->data->_count);
+				page_ref_inc(sw_rx_data->data);
 				rxq->rx_alloc_errors++;
 				qede_recycle_rx_bd_ring(rxq, edev,
 							fp_cqe->bd_num);
-- 
2.7.0

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2016-04-21  6:00 Stephen Rothwell
@ 2016-04-21  9:46 ` Hugh Dickins
  0 siblings, 0 replies; 330+ messages in thread
From: Hugh Dickins @ 2016-04-21  9:46 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Andrew Morton, linux-next, linux-kernel, Hugh Dickins

On Thu, 21 Apr 2016, Stephen Rothwell wrote:

> Hi Andrew,
> 
> After merging the akpm-current tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> mm/built-in.o: In function `handle_mm_fault':
> frame_vector.c:(.text+0x29628): undefined reference to `do_huge_pmd_anonymous_page'
> 
> (Ignore the "frame_vector.c" above it is obviously incorrect.)
> 
> Probably caused by commit
> 
>   747220c26dd0 ("huge tmpfs: add shmem_pmd_fault()")
> 
> [Andrew: I added this patch from Hugh today ... see other emails]

Many thanks for trying to include those...

> 
> The condition protecting the call to do_huge_pmd_anonymous_page()
> in __handle_mm_fault() has becom more complicated and so the call
> has presumably no longer been removed by the compiler for the
> !CONFIG_TRANSPARENT_HUGEPAGE case.
> 
> I have reverted that commit for today.

... and sorry for wasting your time again, with unfamiliar optimizer
failures.  Best ignore patches from me, until I've got into cross-
compiling with your environment.  Not this week.

Reverting just that shmem_pmd_fault() commit does leave linux-next
with lots of huge tmpfs patches in, but unable to do huge mappings
of tmpfs (but the DAX COW support that I'd broken restored).

Not worth rushing you another build fix to enable it: Andrew will be
reverting the whole series from his tree in the coming days, to make
way for some zone/node changes from Mel which it was obstructing.

Hugh

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

* linux-next: build failure after merge of the akpm-current tree
@ 2016-04-21  6:00 Stephen Rothwell
  2016-04-21  9:46 ` Hugh Dickins
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2016-04-21  6:00 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Hugh Dickins

Hi Andrew,

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

mm/built-in.o: In function `handle_mm_fault':
frame_vector.c:(.text+0x29628): undefined reference to `do_huge_pmd_anonymous_page'

(Ignore the "frame_vector.c" above it is obviously incorrect.)

Probably caused by commit

  747220c26dd0 ("huge tmpfs: add shmem_pmd_fault()")

[Andrew: I added this patch from Hugh today ... see other emails]

The condition protecting the call to do_huge_pmd_anonymous_page()
in __handle_mm_fault() has becom more complicated and so the call
has presumably no longer been removed by the compiler for the
!CONFIG_TRANSPARENT_HUGEPAGE case.

I have reverted that commit for today.

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2016-04-07  5:12 Stephen Rothwell
@ 2016-04-07  5:24 ` Hugh Dickins
  0 siblings, 0 replies; 330+ messages in thread
From: Hugh Dickins @ 2016-04-07  5:24 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Andrew Morton, linux-next, linux-kernel, Hugh Dickins

On Thu, 7 Apr 2016, Stephen Rothwell wrote:

> Hi Andrew,
> 
> After merging the akpm-current tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> In file included from include/linux/linkage.h:4:0,
>                  from include/linux/fs.h:4,
>                  from mm/shmem.c:24:
> In function 'shmem_disband_hugeteam',
>     inlined from 'shmem_getpage_gfp' at mm/shmem.c:3075:3:
> include/linux/compiler.h:510:38: error: call to '__compiletime_assert_1747' declared with attribute error: BUILD_BUG failed
>   _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
>                                       ^
> include/linux/compiler.h:493:4: note: in definition of macro '__compiletime_assert'
>     prefix ## suffix();    \
>     ^
> include/linux/compiler.h:510:2: note: in expansion of macro '_compiletime_assert'
>   _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
>   ^
> include/linux/bug.h:51:37: note: in expansion of macro 'compiletime_assert'
>  #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
>                                      ^
> include/linux/bug.h:85:21: note: in expansion of macro 'BUILD_BUG_ON_MSG'
>  #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
>                      ^
> mm/shmem.c:1747:2: note: in expansion of macro 'BUILD_BUG'
>   BUILD_BUG();
>   ^
> 
> Caused by commit
> 
>   ab61a0a665d8 ("huge tmpfs: try to allocate huge pages, split into a team")
> 
> I added the following (hacky, but builds for my compiler at least)
> patch for today:

Sorry about that, thanks a lot Stephen, your patch will do fine (though
what I'll do is simply delete that BUILD_BUG(), which isn't really
serving any useful purpose).  It certainly has been compiled before
on arm and without CONFIG_TRANSPARENT_HUGEPAGE, but I guess different
compiler versions make different optimizations, so I never noticed I
was unwittingly relying on too sophisticated an optimization there.

Hugh

> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 7 Apr 2016 14:57:45 +1000
> Subject: [PATCH] huge tmpfs: fix build problem on arm
> 
> allocated_huge will never be non-NULL if CONFIG_TRANSPARENT_HUGEPAGE is not.
> 
> Fixes: ab61a0a665d8 ("huge tmpfs: try to allocate huge pages, split into a team")
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  mm/shmem.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/shmem.c b/mm/shmem.c
> index 5b9fecc9ce72..f2307d9630aa 100644
> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -3071,7 +3071,7 @@ unlock:
>  		unlock_page(page);
>  		put_page(page);
>  	}
> -	if (alloced_huge) {
> +	if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) && alloced_huge) {
>  		shmem_disband_hugeteam(alloced_huge);
>  		alloced_huge = NULL;
>  	}
> -- 

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

* linux-next: build failure after merge of the akpm-current tree
@ 2016-04-07  5:12 Stephen Rothwell
  2016-04-07  5:24 ` Hugh Dickins
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2016-04-07  5:12 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Hugh Dickins

Hi Andrew,

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

In file included from include/linux/linkage.h:4:0,
                 from include/linux/fs.h:4,
                 from mm/shmem.c:24:
In function 'shmem_disband_hugeteam',
    inlined from 'shmem_getpage_gfp' at mm/shmem.c:3075:3:
include/linux/compiler.h:510:38: error: call to '__compiletime_assert_1747' declared with attribute error: BUILD_BUG failed
  _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
                                      ^
include/linux/compiler.h:493:4: note: in definition of macro '__compiletime_assert'
    prefix ## suffix();    \
    ^
include/linux/compiler.h:510:2: note: in expansion of macro '_compiletime_assert'
  _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
  ^
include/linux/bug.h:51:37: note: in expansion of macro 'compiletime_assert'
 #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
                                     ^
include/linux/bug.h:85:21: note: in expansion of macro 'BUILD_BUG_ON_MSG'
 #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
                     ^
mm/shmem.c:1747:2: note: in expansion of macro 'BUILD_BUG'
  BUILD_BUG();
  ^

Caused by commit

  ab61a0a665d8 ("huge tmpfs: try to allocate huge pages, split into a team")

I added the following (hacky, but builds for my compiler at least)
patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 7 Apr 2016 14:57:45 +1000
Subject: [PATCH] huge tmpfs: fix build problem on arm

allocated_huge will never be non-NULL if CONFIG_TRANSPARENT_HUGEPAGE is not.

Fixes: ab61a0a665d8 ("huge tmpfs: try to allocate huge pages, split into a team")
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 mm/shmem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/shmem.c b/mm/shmem.c
index 5b9fecc9ce72..f2307d9630aa 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -3071,7 +3071,7 @@ unlock:
 		unlock_page(page);
 		put_page(page);
 	}
-	if (alloced_huge) {
+	if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) && alloced_huge) {
 		shmem_disband_hugeteam(alloced_huge);
 		alloced_huge = NULL;
 	}
-- 
2.7.0

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2016-02-26 21:33   ` Andrew Morton
@ 2016-02-26 22:49     ` Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2016-02-26 22:49 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Dave Hansen, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel, Helge Deller

Hi Andrew,

On Fri, 26 Feb 2016 13:33:50 -0800 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> I've moved add-compile-time-check-for-__arch_si_preamble_size.patch to
> be after linux-next and have added this patch (as
> add-compile-time-check-for-__arch_si_preamble_size-fix.patch) to be
> folded into add-compile-time-check-for-__arch_si_preamble_size.patch
> later on.
> 
> So no -tip changes should be needed.

But the fix should go into the tip tree since the tip tree patch is not
correct even without this new build time check.

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2016-02-26 20:10 ` Dave Hansen
@ 2016-02-26 21:33   ` Andrew Morton
  2016-02-26 22:49     ` Stephen Rothwell
  0 siblings, 1 reply; 330+ messages in thread
From: Andrew Morton @ 2016-02-26 21:33 UTC (permalink / raw)
  To: Dave Hansen
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel, Helge Deller

On Fri, 26 Feb 2016 12:10:06 -0800 Dave Hansen <dave.hansen@linux.intel.com> wrote:

> On 02/25/2016 09:44 PM, Stephen Rothwell wrote:
> > Fixes: cd0ea35ff551 ("signals, pkeys: Notify userspace about protection key faults")
> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > ---
> >  arch/ia64/include/uapi/asm/siginfo.h | 2 +-
> >  arch/mips/include/uapi/asm/siginfo.h | 2 +-
> >  include/uapi/asm-generic/siginfo.h   | 2 +-
> >  3 files changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/arch/ia64/include/uapi/asm/siginfo.h b/arch/ia64/include/uapi/asm/siginfo.h
> > index 0151cfab929d..0c660bbccd3f 100644
> > --- a/arch/ia64/include/uapi/asm/siginfo.h
> > +++ b/arch/ia64/include/uapi/asm/siginfo.h
> > @@ -70,7 +70,7 @@ typedef struct siginfo {
> >  					void __user *_upper;
> >  				} _addr_bnd;
> >  				/* used when si_code=SEGV_PKUERR */
> > -				u64 _pkey;
> > +				int _pkey;
> >  			};
> >  		} _sigfault;
> 
> Considering Peter's feedback on my 'unsigned long' approach, I'm fine
> with your patch, Stephen.  Can it just be picked up in to the tip tree?
> 
> Acked-by: Dave Hansen <dave.hansen@linux.intel.com>

I've moved add-compile-time-check-for-__arch_si_preamble_size.patch to
be after linux-next and have added this patch (as
add-compile-time-check-for-__arch_si_preamble_size-fix.patch) to be
folded into add-compile-time-check-for-__arch_si_preamble_size.patch
later on.

So no -tip changes should be needed.

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2016-02-26  5:44 Stephen Rothwell
  2016-02-26 16:14 ` Dave Hansen
@ 2016-02-26 20:10 ` Dave Hansen
  2016-02-26 21:33   ` Andrew Morton
  1 sibling, 1 reply; 330+ messages in thread
From: Dave Hansen @ 2016-02-26 20:10 UTC (permalink / raw)
  To: Stephen Rothwell, Andrew Morton, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Helge Deller

On 02/25/2016 09:44 PM, Stephen Rothwell wrote:
> Fixes: cd0ea35ff551 ("signals, pkeys: Notify userspace about protection key faults")
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  arch/ia64/include/uapi/asm/siginfo.h | 2 +-
>  arch/mips/include/uapi/asm/siginfo.h | 2 +-
>  include/uapi/asm-generic/siginfo.h   | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/ia64/include/uapi/asm/siginfo.h b/arch/ia64/include/uapi/asm/siginfo.h
> index 0151cfab929d..0c660bbccd3f 100644
> --- a/arch/ia64/include/uapi/asm/siginfo.h
> +++ b/arch/ia64/include/uapi/asm/siginfo.h
> @@ -70,7 +70,7 @@ typedef struct siginfo {
>  					void __user *_upper;
>  				} _addr_bnd;
>  				/* used when si_code=SEGV_PKUERR */
> -				u64 _pkey;
> +				int _pkey;
>  			};
>  		} _sigfault;

Considering Peter's feedback on my 'unsigned long' approach, I'm fine
with your patch, Stephen.  Can it just be picked up in to the tip tree?

Acked-by: Dave Hansen <dave.hansen@linux.intel.com>

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2016-02-26  5:44 Stephen Rothwell
@ 2016-02-26 16:14 ` Dave Hansen
  2016-02-26 20:10 ` Dave Hansen
  1 sibling, 0 replies; 330+ messages in thread
From: Dave Hansen @ 2016-02-26 16:14 UTC (permalink / raw)
  To: Stephen Rothwell, Andrew Morton, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Helge Deller

On 02/25/2016 09:44 PM, Stephen Rothwell wrote:
> The addition of the "u64 _pkey" has presumably changed the alignment of
> the enclosing union on (some) 32 bit platforms and so added padding
> after the si_code field.  This is a user API issue. :-(
> 
> [As an aside, I am pretty sure that we should not be using "u64" in a
> uapi header in any case.]

Ahh, so if _addr_bnd wasn't 64-bit-aligned, the compiler is free to
align it and enlarge the structure.  But, this only applied to
architectures where _addr_bnd wasn't 64-bit-aligned:

Would anybody object to _pkey being an 'unsigned long'?  It would at
least keep existing 64-bit userspace (mostly my tests) from having to
change.

Here's the snippet of the struct in question:

>                         union {
>                                 /* used when si_code=SEGV_BNDERR */
>                                 struct {
>                                         void __user *_lower;
>                                         void __user *_upper;
>                                 } _addr_bnd;
>                                 /* used when si_code=SEGV_PKUERR */
>                                 u64 _pkey;
>                         };

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

* linux-next: build failure after merge of the akpm-current tree
@ 2016-02-26  5:44 Stephen Rothwell
  2016-02-26 16:14 ` Dave Hansen
  2016-02-26 20:10 ` Dave Hansen
  0 siblings, 2 replies; 330+ messages in thread
From: Stephen Rothwell @ 2016-02-26  5:44 UTC (permalink / raw)
  To: Andrew Morton, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra
  Cc: linux-next, linux-kernel, Helge Deller, Dave Hansen

Hi all,

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

In file included from /home/sfr/next/next/include/linux/linkage.h:4:0,
                 from /home/sfr/next/next/arch/arm/include/asm/bug.h:4,
                 from /home/sfr/next/next/include/linux/bug.h:4,
                 from /home/sfr/next/next/include/linux/mmdebug.h:4,
                 from /home/sfr/next/next/include/linux/gfp.h:4,
                 from /home/sfr/next/next/include/linux/slab.h:14,
                 from /home/sfr/next/next/kernel/signal.c:13:
/home/sfr/next/next/kernel/signal.c: In function 'signals_init':
/home/sfr/next/next/include/linux/compiler.h:506:38: error: call to '__compiletime_assert_3610' declared with attribute error: BUILD_BUG_ON failed: __ARCH_SI_PREAMBLE_SIZE != offsetof(struct siginfo, _sifields._pad)

Caused by commit

  21c0826ab237 ("kernel/signal.c: add compile-time check for __ARCH_SI_PREAMBLE_SIZE")

interacting with commit

  cd0ea35ff551 ("signals, pkeys: Notify userspace about protection key faults")

from the tip tree.

The addition of the "u64 _pkey" has presumably changed the alignment of
the enclosing union on (some) 32 bit platforms and so added padding
after the si_code field.  This is a user API issue. :-(

[As an aside, I am pretty sure that we should not be using "u64" in a
uapi header in any case.]

I have added the following patch for today (and will add it to the tip
tree merge from Monday unless some other fix comes along).

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 26 Feb 2016 16:31:36 +1100
Subject: [PATCH] signals, pkeys: make si_pkey 32 bits for now

to prevent a change of alignment in the siginfo structure

Fixes: cd0ea35ff551 ("signals, pkeys: Notify userspace about protection key faults")
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/ia64/include/uapi/asm/siginfo.h | 2 +-
 arch/mips/include/uapi/asm/siginfo.h | 2 +-
 include/uapi/asm-generic/siginfo.h   | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/ia64/include/uapi/asm/siginfo.h b/arch/ia64/include/uapi/asm/siginfo.h
index 0151cfab929d..0c660bbccd3f 100644
--- a/arch/ia64/include/uapi/asm/siginfo.h
+++ b/arch/ia64/include/uapi/asm/siginfo.h
@@ -70,7 +70,7 @@ typedef struct siginfo {
 					void __user *_upper;
 				} _addr_bnd;
 				/* used when si_code=SEGV_PKUERR */
-				u64 _pkey;
+				int _pkey;
 			};
 		} _sigfault;
 
diff --git a/arch/mips/include/uapi/asm/siginfo.h b/arch/mips/include/uapi/asm/siginfo.h
index 6f4edf0d794c..d2adebc0023d 100644
--- a/arch/mips/include/uapi/asm/siginfo.h
+++ b/arch/mips/include/uapi/asm/siginfo.h
@@ -93,7 +93,7 @@ typedef struct siginfo {
 					void __user *_upper;
 				} _addr_bnd;
 				/* used when si_code=SEGV_PKUERR */
-				u64 _pkey;
+				int _pkey;
 			};
 		} _sigfault;
 
diff --git a/include/uapi/asm-generic/siginfo.h b/include/uapi/asm-generic/siginfo.h
index 90384d55225b..0f23ec63c291 100644
--- a/include/uapi/asm-generic/siginfo.h
+++ b/include/uapi/asm-generic/siginfo.h
@@ -98,7 +98,7 @@ typedef struct siginfo {
 					void __user *_upper;
 				} _addr_bnd;
 				/* used when si_code=SEGV_PKUERR */
-				u64 _pkey;
+				int _pkey;
 			};
 		} _sigfault;
 
-- 
2.7.0

-- 
Cheers,
Stephen Rothwell

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

* linux-next: build failure after merge of the akpm-current tree
@ 2016-02-25  4:55 Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2016-02-25  4:55 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Kirill A. Shutemov, Russell King

Hi Andrew,

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

arch/arm/mm/mmu.c:737:37: error: macro "pte_alloc" passed 4 arguments, but takes just 3
     void *(*alloc)(unsigned long sz))
                                     ^
arch/arm/mm/mmu.c:738:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
 {
 ^
arch/arm/mm/mmu.c: In function 'early_pte_alloc':
arch/arm/mm/mmu.c:750:47: error: macro "pte_alloc" passed 4 arguments, but takes just 3
  return pte_alloc(pmd, addr, prot, early_alloc);
                                               ^
arch/arm/mm/mmu.c:750:9: error: 'pte_alloc' undeclared (first use in this function)
  return pte_alloc(pmd, addr, prot, early_alloc);
         ^
arch/arm/mm/mmu.c:750:9: note: each undeclared identifier is reported only once for each function it appears in
arch/arm/mm/mmu.c: In function 'alloc_init_pte':
arch/arm/mm/mmu.c:759:56: error: macro "pte_alloc" passed 4 arguments, but takes just 3
  pte_t *pte = pte_alloc(pmd, addr, type->prot_l1, alloc);
                                                        ^
arch/arm/mm/mmu.c:759:15: error: 'pte_alloc' undeclared (first use in this function)
  pte_t *pte = pte_alloc(pmd, addr, type->prot_l1, alloc);
               ^
arch/arm/mm/mmu.c: In function 'early_pte_alloc':
arch/arm/mm/mmu.c:751:1: warning: control reaches end of non-void function [-Wreturn-type]
 }
 ^

Caused by commit

  b9c9252f278d ("mm: cleanup *pte_alloc* interfaces")

grep is your friend ...

I applied this fix patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 25 Feb 2016 15:36:59 +1100
Subject: [PATCH] mm: cleanup *pte_alloc* interfaces fix

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/arm/mm/mmu.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index e4b681aafd6d..62f4d01941f7 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -732,7 +732,7 @@ static void *__init late_alloc(unsigned long sz)
 	return ptr;
 }
 
-static pte_t * __init pte_alloc(pmd_t *pmd, unsigned long addr,
+static pte_t * __init arm_pte_alloc(pmd_t *pmd, unsigned long addr,
 				unsigned long prot,
 				void *(*alloc)(unsigned long sz))
 {
@@ -747,7 +747,7 @@ static pte_t * __init pte_alloc(pmd_t *pmd, unsigned long addr,
 static pte_t * __init early_pte_alloc(pmd_t *pmd, unsigned long addr,
 				      unsigned long prot)
 {
-	return pte_alloc(pmd, addr, prot, early_alloc);
+	return arm_pte_alloc(pmd, addr, prot, early_alloc);
 }
 
 static void __init alloc_init_pte(pmd_t *pmd, unsigned long addr,
@@ -756,7 +756,7 @@ static void __init alloc_init_pte(pmd_t *pmd, unsigned long addr,
 				  void *(*alloc)(unsigned long sz),
 				  bool ng)
 {
-	pte_t *pte = pte_alloc(pmd, addr, type->prot_l1, alloc);
+	pte_t *pte = arm_pte_alloc(pmd, addr, type->prot_l1, alloc);
 	do {
 		set_pte_ext(pte, pfn_pte(pfn, __pgprot(type->prot_pte)),
 			    ng ? PTE_EXT_NG : 0);
-- 
2.7.0

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2016-02-10 20:51   ` Stephen Rothwell
@ 2016-02-15 10:17     ` Jiri Kosina
  0 siblings, 0 replies; 330+ messages in thread
From: Jiri Kosina @ 2016-02-15 10:17 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, linux-next, linux-kernel, Dan Williams,
	Felipe Balbi, Greg Kroah-Hartman

On Thu, 11 Feb 2016, Stephen Rothwell wrote:

> Or the trivial tree should be based on v4.5-rc1 not v4.3 (in which case 
> this patch belongs as part of ee49ac85bc24b946 (and presumably would 
> have been found in testing of the trivial tree alone).

This was indeed applied to wrong base, my error, sorry for that. I will 
drop this now from my tree and we'll merge it properly later; best thing 
would probably be to send it directly to Linus at the very end of merge 
window.

Thanks for noticing,

-- 
Jiri Kosina
SUSE Labs

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2016-02-10 19:55 ` Andrew Morton
@ 2016-02-10 20:51   ` Stephen Rothwell
  2016-02-15 10:17     ` Jiri Kosina
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2016-02-10 20:51 UTC (permalink / raw)
  To: Andrew Morton, Jiri Kosina
  Cc: linux-next, linux-kernel, Dan Williams, Felipe Balbi, Greg Kroah-Hartman

Hi Andrew,

On Wed, 10 Feb 2016 11:55:07 -0800 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Wed, 10 Feb 2016 16:55:14 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > Hi Andrew,
> > 
> > After merging the akpm-current tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> > 
> > In file included from arch/x86/include/asm/bug.h:35:0,
> >                  from include/linux/bug.h:4,
> >                  from include/linux/thread_info.h:11,
> >                  from arch/x86/include/asm/preempt.h:6,
> >                  from include/linux/preempt.h:59,
> >                  from include/linux/radix-tree.h:25,
> >                  from kernel/memremap.c:13:
> > kernel/memremap.c: In function 'devm_memremap_pages_release':
> > kernel/memremap.c:230:54: error: expected ')' before '__func__'
> >    dev_WARN(dev, "%s: page mapping is still live!\n", __func__);
> >                                                       ^
> > include/asm-generic/bug.h:74:69: note: in definition of macro '__WARN_printf'
> >  #define __WARN_printf(arg...) warn_slowpath_fmt(__FILE__, __LINE__, arg)
> >                                                                      ^
> > include/linux/device.h:1312:2: note: in expansion of macro 'WARN'
> >   WARN(condition, "%s %s: " format,   \
> >   ^
> > kernel/memremap.c:230:3: note: in expansion of macro 'dev_WARN'
> >    dev_WARN(dev, "%s: page mapping is still live!\n", __func__);
> >    ^
> > include/linux/device.h:1312:18: warning: format '%s' expects a matching 'char *' argument [-Wformat=]
> >   WARN(condition, "%s %s: " format,   \
> >                   ^
> > include/asm-generic/bug.h:74:69: note: in definition of macro '__WARN_printf'
> >  #define __WARN_printf(arg...) warn_slowpath_fmt(__FILE__, __LINE__, arg)
> >                                                                      ^
> > include/linux/device.h:1312:2: note: in expansion of macro 'WARN'
> >   WARN(condition, "%s %s: " format,   \
> >   ^
> > kernel/memremap.c:230:3: note: in expansion of macro 'dev_WARN'
> >    dev_WARN(dev, "%s: page mapping is still live!\n", __func__);
> >    ^
> > 
> > Probably exposed by commit
> > 
> >   27ffb3827ac7 ("mm: CONFIG_NR_ZONES_EXTENDED")
> > 
> > originally caused by commit
> > 
> >   5c2c2587b132 ("mm, dax, pmem: introduce {get|put}_dev_pagemap() for dax-gup")
> > 
> > which was added in v4.5-rc1.
> > 
> > I added the below patch for today but then discovered the waiting patch
> > in the akpm tree ("kernel/memremap.c: add new arg to dev_WARN") which
> > should be sent to Linus ASAP (and should have appeared much earlier in
> > the series).  
> 
> kernel-memremapc-add-new-arg-to-dev_warn.patch fixes ee49ac85bc24b946
> ("treewide: let dev_WARN() accept a condition") which is only in
> linux-next?

Yes, indeed, I guess I was a bit tired by that point :-(

However, I am not sure I would ever call an API change trivial i.e. I
wonder what that patch is doing the the trivial tree ...  I guess that
patch is needed as part of the merge of the trivial tree.  Or the
trivial tree should be based on v4.5-rc1 not v4.3 (in which case this
patch belongs as part of ee49ac85bc24b946 (and presumably would have
been found in testing of the trivial tree alone).

I will put your patch into teh merge of the trivial tree today (so it
will disappear from the akpm tree).
-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2016-02-10  5:55 Stephen Rothwell
@ 2016-02-10 19:55 ` Andrew Morton
  2016-02-10 20:51   ` Stephen Rothwell
  0 siblings, 1 reply; 330+ messages in thread
From: Andrew Morton @ 2016-02-10 19:55 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Dan Williams

On Wed, 10 Feb 2016 16:55:14 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Andrew,
> 
> After merging the akpm-current tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> In file included from arch/x86/include/asm/bug.h:35:0,
>                  from include/linux/bug.h:4,
>                  from include/linux/thread_info.h:11,
>                  from arch/x86/include/asm/preempt.h:6,
>                  from include/linux/preempt.h:59,
>                  from include/linux/radix-tree.h:25,
>                  from kernel/memremap.c:13:
> kernel/memremap.c: In function 'devm_memremap_pages_release':
> kernel/memremap.c:230:54: error: expected ')' before '__func__'
>    dev_WARN(dev, "%s: page mapping is still live!\n", __func__);
>                                                       ^
> include/asm-generic/bug.h:74:69: note: in definition of macro '__WARN_printf'
>  #define __WARN_printf(arg...) warn_slowpath_fmt(__FILE__, __LINE__, arg)
>                                                                      ^
> include/linux/device.h:1312:2: note: in expansion of macro 'WARN'
>   WARN(condition, "%s %s: " format,   \
>   ^
> kernel/memremap.c:230:3: note: in expansion of macro 'dev_WARN'
>    dev_WARN(dev, "%s: page mapping is still live!\n", __func__);
>    ^
> include/linux/device.h:1312:18: warning: format '%s' expects a matching 'char *' argument [-Wformat=]
>   WARN(condition, "%s %s: " format,   \
>                   ^
> include/asm-generic/bug.h:74:69: note: in definition of macro '__WARN_printf'
>  #define __WARN_printf(arg...) warn_slowpath_fmt(__FILE__, __LINE__, arg)
>                                                                      ^
> include/linux/device.h:1312:2: note: in expansion of macro 'WARN'
>   WARN(condition, "%s %s: " format,   \
>   ^
> kernel/memremap.c:230:3: note: in expansion of macro 'dev_WARN'
>    dev_WARN(dev, "%s: page mapping is still live!\n", __func__);
>    ^
> 
> Probably exposed by commit
> 
>   27ffb3827ac7 ("mm: CONFIG_NR_ZONES_EXTENDED")
> 
> originally caused by commit
> 
>   5c2c2587b132 ("mm, dax, pmem: introduce {get|put}_dev_pagemap() for dax-gup")
> 
> which was added in v4.5-rc1.
> 
> I added the below patch for today but then discovered the waiting patch
> in the akpm tree ("kernel/memremap.c: add new arg to dev_WARN") which
> should be sent to Linus ASAP (and should have appeared much earlier in
> the series).

kernel-memremapc-add-new-arg-to-dev_warn.patch fixes ee49ac85bc24b946
("treewide: let dev_WARN() accept a condition") which is only in
linux-next?

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

* linux-next: build failure after merge of the akpm-current tree
@ 2016-02-10  5:55 Stephen Rothwell
  2016-02-10 19:55 ` Andrew Morton
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2016-02-10  5:55 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Dan Williams

Hi Andrew,

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

In file included from arch/x86/include/asm/bug.h:35:0,
                 from include/linux/bug.h:4,
                 from include/linux/thread_info.h:11,
                 from arch/x86/include/asm/preempt.h:6,
                 from include/linux/preempt.h:59,
                 from include/linux/radix-tree.h:25,
                 from kernel/memremap.c:13:
kernel/memremap.c: In function 'devm_memremap_pages_release':
kernel/memremap.c:230:54: error: expected ')' before '__func__'
   dev_WARN(dev, "%s: page mapping is still live!\n", __func__);
                                                      ^
include/asm-generic/bug.h:74:69: note: in definition of macro '__WARN_printf'
 #define __WARN_printf(arg...) warn_slowpath_fmt(__FILE__, __LINE__, arg)
                                                                     ^
include/linux/device.h:1312:2: note: in expansion of macro 'WARN'
  WARN(condition, "%s %s: " format,   \
  ^
kernel/memremap.c:230:3: note: in expansion of macro 'dev_WARN'
   dev_WARN(dev, "%s: page mapping is still live!\n", __func__);
   ^
include/linux/device.h:1312:18: warning: format '%s' expects a matching 'char *' argument [-Wformat=]
  WARN(condition, "%s %s: " format,   \
                  ^
include/asm-generic/bug.h:74:69: note: in definition of macro '__WARN_printf'
 #define __WARN_printf(arg...) warn_slowpath_fmt(__FILE__, __LINE__, arg)
                                                                     ^
include/linux/device.h:1312:2: note: in expansion of macro 'WARN'
  WARN(condition, "%s %s: " format,   \
  ^
kernel/memremap.c:230:3: note: in expansion of macro 'dev_WARN'
   dev_WARN(dev, "%s: page mapping is still live!\n", __func__);
   ^

Probably exposed by commit

  27ffb3827ac7 ("mm: CONFIG_NR_ZONES_EXTENDED")

originally caused by commit

  5c2c2587b132 ("mm, dax, pmem: introduce {get|put}_dev_pagemap() for dax-gup")

which was added in v4.5-rc1.

I added the below patch for today but then discovered the waiting patch
in the akpm tree ("kernel/memremap.c: add new arg to dev_WARN") which
should be sent to Linus ASAP (and should have appeared much earlier in
the series).

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 10 Feb 2016 16:42:47 +1100
Subject: [PATCH] kernel/memremap: fix up dev_WARN invocation

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 kernel/memremap.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/kernel/memremap.c b/kernel/memremap.c
index 76fa01cee76b..ba845c368876 100644
--- a/kernel/memremap.c
+++ b/kernel/memremap.c
@@ -226,10 +226,9 @@ static void devm_memremap_pages_release(struct device *dev, void *data)
 	resource_size_t align_start, align_size;
 	struct dev_pagemap *pgmap = &page_map->pgmap;
 
-	if (percpu_ref_tryget_live(pgmap->ref)) {
-		dev_WARN(dev, "%s: page mapping is still live!\n", __func__);
+	if (dev_WARN(dev, percpu_ref_tryget_live(pgmap->ref),
+		     "%s: page mapping is still live!\n", __func__))
 		percpu_ref_put(pgmap->ref);
-	}
 
 	/* pages are dead and unused, undo the arch mapping */
 	align_start = res->start & ~(SECTION_SIZE - 1);
-- 
2.7.0

-- 
Cheers,
Stephen Rothwell

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

* linux-next: build failure after merge of the akpm-current tree
@ 2016-02-08  4:51 Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2016-02-08  4:51 UTC (permalink / raw)
  To: Andrew Morton
  Cc: linux-next, linux-kernel, Joonsoo Kim, David Rientjes,
	Benjamin Herrenschmidt

Hi Andrew,

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

arch/powerpc/mm/hash_utils_64.c: In function 'htab_bolt_mapping':
arch/powerpc/mm/hash_utils_64.c:260:28: error: 'linear_map_hash_count' undeclared (first use in this function)
    (paddr >> PAGE_SHIFT) < linear_map_hash_count)
                            ^
arch/powerpc/mm/hash_utils_64.c:260:28: note: each undeclared identifier is reported only once for each function it appears in
arch/powerpc/mm/hash_utils_64.c:261:4: error: 'linear_map_hash_slots' undeclared (first use in this function)
    linear_map_hash_slots[paddr >> PAGE_SHIFT] = ret | 0x80;
    ^
arch/powerpc/mm/hash_utils_64.c: In function 'htab_initialize':
arch/powerpc/mm/hash_utils_64.c:724:3: error: 'linear_map_hash_count' undeclared (first use in this function)
   linear_map_hash_count = memblock_end_of_DRAM() >> PAGE_SHIFT;
   ^
arch/powerpc/mm/hash_utils_64.c:725:3: error: 'linear_map_hash_slots' undeclared (first use in this function)
   linear_map_hash_slots = __va(memblock_alloc_base(
   ^

Caused by commit

  79581c9f284e ("powerpc: query dynamic DEBUG_PAGEALLOC setting")

The CONFIG_DEBUG_PAGEALLOC stuff in this file depends on extra data
being kept which was left under CONFIG_DEBUG_PAGEALLOC protection.

I just reverted this commit for today.

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2016-02-03  5:36 Stephen Rothwell
@ 2016-02-03 21:36 ` Andrew Morton
  0 siblings, 0 replies; 330+ messages in thread
From: Andrew Morton @ 2016-02-03 21:36 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Joonsoo Kim

On Wed, 3 Feb 2016 16:36:13 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Andrew,
> 
> After merging the akpm-current tree, today's linux-next build (arm
> ep93xx_defconfig) failed like this:
> 
> mm/slab.c: In function 'is_debug_pagealloc_cache':
> mm/slab.c:1608:2: error: implicit declaration of function 'debug_pagealloc_enabled' [-Werror=implicit-function-declaration]
> 
> Caused by commit
> 
>   0a244aea1a61 ("mm/slab: clean up DEBUG_PAGEALLOC processing code")
> 
> CONFIG_DEBUG_PAGEALLOC is not enabled in this build.
> 
> Discovered after the linux-next release.

This works for me.

--- a/include/linux/mm.h~mm-slab-clean-up-debug_pagealloc-processing-code-fix
+++ a/include/linux/mm.h
@@ -2194,14 +2194,18 @@ kernel_map_pages(struct page *page, int
 }
 #ifdef CONFIG_HIBERNATION
 extern bool kernel_page_present(struct page *page);
-#endif /* CONFIG_HIBERNATION */
-#else
+#endif	/* CONFIG_HIBERNATION */
+#else	/* CONFIG_DEBUG_PAGEALLOC */
 static inline void
 kernel_map_pages(struct page *page, int numpages, int enable) {}
 #ifdef CONFIG_HIBERNATION
 static inline bool kernel_page_present(struct page *page) { return true; }
-#endif /* CONFIG_HIBERNATION */
-#endif
+#endif	/* CONFIG_HIBERNATION */
+static inline bool debug_pagealloc_enabled(void)
+{
+	return false;
+}
+#endif	/* CONFIG_DEBUG_PAGEALLOC */
 
 #ifdef __HAVE_ARCH_GATE_AREA
 extern struct vm_area_struct *get_gate_vma(struct mm_struct *mm);
_

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2016-02-03  5:27 Stephen Rothwell
@ 2016-02-03  7:08 ` Sergey Senozhatsky
  0 siblings, 0 replies; 330+ messages in thread
From: Sergey Senozhatsky @ 2016-02-03  7:08 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Andrew Morton, linux-next, linux-kernel, Matthew Wilcox

Hello,

On (02/03/16 16:27), Stephen Rothwell wrote:
> Hi Andrew,
> 
> After merging the akpm-current tree, today's linux-next build (arm
> allnoconfig) failed like this:
> 
> In file included from kernel/memremap.c:17:0:
> include/linux/pfn_t.h:108:7: error: 'pud_mkdevmap' declared as function returning an array
> 
> Caused by commit
> 
>   a27da20ed50e ("mm: add support for PUD-sized transparent hugepages")
> 
> Discovered after the linux-next release.


.config

  CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD=y
# CONFIG_TRANSPARENT_HUGEPAGE is not set


makes the build unhappy

fs/proc/task_mmu.c: In function ‘smaps_pud_range’:
fs/proc/task_mmu.c:596:6: error: implicit declaration of function ‘is_huge_zero_pud’ [-Werror=implicit-function-declaration]
  if (is_huge_zero_pud(*pud))
      ^


seems there is no ‘is_huge_zero_pud’ for !CONFIG_TRANSPARENT_HUGEPAGE.


and a bunch of other errors as a result


In file included from include/asm-generic/bug.h:4:0,
                 from ./arch/x86/include/asm/bug.h:35,
                 from include/linux/bug.h:4,
                 from include/linux/mmdebug.h:4,
                 from include/linux/mm.h:8,
                 from fs/proc/task_mmu.c:1:
include/linux/compiler.h:505:38: error: call to ‘__compiletime_assert_599’ declared with attribute error: BUILD_BUG failed
  _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
                                      ^
include/linux/compiler.h:488:4: note: in definition of macro ‘__compiletime_assert’
    prefix ## suffix();    \
    ^
include/linux/compiler.h:505:2: note: in expansion of macro ‘_compiletime_assert’
  _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
  ^
include/linux/bug.h:50:37: note: in expansion of macro ‘compiletime_assert’
 #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
                                     ^
include/linux/bug.h:84:21: note: in expansion of macro ‘BUILD_BUG_ON_MSG’
 #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
                     ^
include/linux/huge_mm.h:221:27: note: in expansion of macro ‘BUILD_BUG’
 #define HPAGE_PUD_SIZE ({ BUILD_BUG(); 0; })
                           ^
fs/proc/task_mmu.c:599:19: note: in expansion of macro ‘HPAGE_PUD_SIZE’
  mss->resident += HPAGE_PUD_SIZE;
                   ^
In function ‘smaps_pud_range.part.10’,
    inlined from ‘smaps_pud_range’:
include/linux/compiler.h:505:38: error: call to ‘__compiletime_assert_602’ declared with attribute error: BUILD_BUG failed
  _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
                                      ^
include/linux/compiler.h:488:4: note: in definition of macro ‘__compiletime_assert’
    prefix ## suffix();    \
    ^
include/linux/compiler.h:505:2: note: in expansion of macro ‘_compiletime_assert’
  _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
  ^
include/linux/bug.h:50:37: note: in expansion of macro ‘compiletime_assert’
 #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
                                     ^
include/linux/bug.h:84:21: note: in expansion of macro ‘BUILD_BUG_ON_MSG’
 #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
                     ^
include/linux/huge_mm.h:221:27: note: in expansion of macro ‘BUILD_BUG’
 #define HPAGE_PUD_SIZE ({ BUILD_BUG(); 0; })
                           ^
fs/proc/task_mmu.c:602:25: note: in expansion of macro ‘HPAGE_PUD_SIZE’
    mss->shared_dirty += HPAGE_PUD_SIZE;
                         ^
include/linux/compiler.h:505:38: error: call to ‘__compiletime_assert_604’ declared with attribute error: BUILD_BUG failed
  _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
                                      ^
include/linux/compiler.h:488:4: note: in definition of macro ‘__compiletime_assert’
    prefix ## suffix();    \
    ^
include/linux/compiler.h:505:2: note: in expansion of macro ‘_compiletime_assert’
  _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
  ^
include/linux/bug.h:50:37: note: in expansion of macro ‘compiletime_assert’
 #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
                                     ^
include/linux/bug.h:84:21: note: in expansion of macro ‘BUILD_BUG_ON_MSG’
 #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
                     ^
include/linux/huge_mm.h:221:27: note: in expansion of macro ‘BUILD_BUG’
 #define HPAGE_PUD_SIZE ({ BUILD_BUG(); 0; })
                           ^
fs/proc/task_mmu.c:604:25: note: in expansion of macro ‘HPAGE_PUD_SIZE’
    mss->shared_clean += HPAGE_PUD_SIZE;
                         ^
fs/proc/task_mmu.c: In function ‘smaps_pud_range’:
include/linux/compiler.h:505:38: error: call to ‘__compiletime_assert_607’ declared with attribute error: BUILD_BUG failed
  _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
                                      ^
include/linux/compiler.h:488:4: note: in definition of macro ‘__compiletime_assert’
    prefix ## suffix();    \
    ^
include/linux/compiler.h:505:2: note: in expansion of macro ‘_compiletime_assert’
  _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
  ^
include/linux/bug.h:50:37: note: in expansion of macro ‘compiletime_assert’
 #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
                                     ^
include/linux/bug.h:84:21: note: in expansion of macro ‘BUILD_BUG_ON_MSG’
 #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
                     ^
include/linux/huge_mm.h:221:27: note: in expansion of macro ‘BUILD_BUG’
 #define HPAGE_PUD_SIZE ({ BUILD_BUG(); 0; })
                           ^
fs/proc/task_mmu.c:607:26: note: in expansion of macro ‘HPAGE_PUD_SIZE’
    mss->private_dirty += HPAGE_PUD_SIZE;
                          ^
include/linux/compiler.h:505:38: error: call to ‘__compiletime_assert_609’ declared with attribute error: BUILD_BUG failed
  _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
                                      ^
include/linux/compiler.h:488:4: note: in definition of macro ‘__compiletime_assert’
    prefix ## suffix();    \
    ^
include/linux/compiler.h:505:2: note: in expansion of macro ‘_compiletime_assert’
  _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
  ^
include/linux/bug.h:50:37: note: in expansion of macro ‘compiletime_assert’
 #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
                                     ^
include/linux/bug.h:84:21: note: in expansion of macro ‘BUILD_BUG_ON_MSG’
 #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
                     ^
include/linux/huge_mm.h:221:27: note: in expansion of macro ‘BUILD_BUG’
 #define HPAGE_PUD_SIZE ({ BUILD_BUG(); 0; })
                           ^
fs/proc/task_mmu.c:609:26: note: in expansion of macro ‘HPAGE_PUD_SIZE’
    mss->private_clean += HPAGE_PUD_SIZE;
                          ^
cc1: some warnings being treated as errors
scripts/Makefile.build:258: recipe for target 'fs/proc/task_mmu.o' failed
make[2]: *** [fs/proc/task_mmu.o] Error 1
scripts/Makefile.build:407: recipe for target 'fs/proc' failed
make[1]: *** [fs/proc] Error 2
make[1]: *** Waiting for unfinished jobs....


	-ss

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2016-02-03  5:10 Stephen Rothwell
@ 2016-02-03  5:58 ` Sudip Mukherjee
  0 siblings, 0 replies; 330+ messages in thread
From: Sudip Mukherjee @ 2016-02-03  5:58 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Andrew Morton, linux-next, linux-kernel, Matthew Wilcox

On Wed, Feb 03, 2016 at 04:10:30PM +1100, Stephen Rothwell wrote:
> Hi Andrew,
> 
> After merging the akpm-current tree, today's linux-next build (i386
> defconfig) failed like this:
> 
> In file included from include/linux/mm.h:67:0,
>                  from include/linux/suspend.h:8,
>                  from arch/x86/kernel/asm-offsets.c:12:
> arch/x86/include/asm/pgtable.h:212:24: error: redefinition of 'pud_trans_huge'
>  #define pud_trans_huge pud_trans_huge
>                         ^
> include/asm-generic/pgtable.h:696:19: note: in expansion of macro 'pud_trans_huge'
>  static inline int pud_trans_huge(pud_t pud)
>                    ^
> arch/x86/include/asm/pgtable.h:208:19: note: previous definition of 'pud_trans_huge' was here
>  static inline int pud_trans_huge(pud_t pud)
>                    ^
> 
> Caused by commit
> 
>   42416e8d1a10 ("x86-add-support-for-pud-sized-transparent-hugepages-fix")
> 
> Which, it turns out, is "wrong/hacky" :-)
> 
> I have reverted that patch for today and added this (also maybe
> wrong/hacky) patch:

And x86_64 defconfig also fails with:
../fs/proc/task_mmu.c: In function ‘smaps_pud_range’:
../fs/proc/task_mmu.c:596:2: error: implicit declaration of function
	‘is_huge_zero_pud’ [-Werror=implicit-function-declaration]

regards
sudip

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

* linux-next: build failure after merge of the akpm-current tree
@ 2016-02-03  5:36 Stephen Rothwell
  2016-02-03 21:36 ` Andrew Morton
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2016-02-03  5:36 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Joonsoo Kim

Hi Andrew,

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

mm/slab.c: In function 'is_debug_pagealloc_cache':
mm/slab.c:1608:2: error: implicit declaration of function 'debug_pagealloc_enabled' [-Werror=implicit-function-declaration]

Caused by commit

  0a244aea1a61 ("mm/slab: clean up DEBUG_PAGEALLOC processing code")

CONFIG_DEBUG_PAGEALLOC is not enabled in this build.

Discovered after the linux-next release.
-- 
Cheers,
Stephen Rothwell

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

* linux-next: build failure after merge of the akpm-current tree
@ 2016-02-03  5:27 Stephen Rothwell
  2016-02-03  7:08 ` Sergey Senozhatsky
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2016-02-03  5:27 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Matthew Wilcox

Hi Andrew,

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

In file included from kernel/memremap.c:17:0:
include/linux/pfn_t.h:108:7: error: 'pud_mkdevmap' declared as function returning an array

Caused by commit

  a27da20ed50e ("mm: add support for PUD-sized transparent hugepages")

Discovered after the linux-next release.

-- 
Cheers,
Stephen Rothwell

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

* linux-next: build failure after merge of the akpm-current tree
@ 2016-02-03  5:10 Stephen Rothwell
  2016-02-03  5:58 ` Sudip Mukherjee
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2016-02-03  5:10 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Matthew Wilcox

Hi Andrew,

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

In file included from include/linux/mm.h:67:0,
                 from include/linux/suspend.h:8,
                 from arch/x86/kernel/asm-offsets.c:12:
arch/x86/include/asm/pgtable.h:212:24: error: redefinition of 'pud_trans_huge'
 #define pud_trans_huge pud_trans_huge
                        ^
include/asm-generic/pgtable.h:696:19: note: in expansion of macro 'pud_trans_huge'
 static inline int pud_trans_huge(pud_t pud)
                   ^
arch/x86/include/asm/pgtable.h:208:19: note: previous definition of 'pud_trans_huge' was here
 static inline int pud_trans_huge(pud_t pud)
                   ^

Caused by commit

  42416e8d1a10 ("x86-add-support-for-pud-sized-transparent-hugepages-fix")

Which, it turns out, is "wrong/hacky" :-)

I have reverted that patch for today and added this (also maybe
wrong/hacky) patch:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 3 Feb 2016 15:48:49 +1100
Subject: [PATCH] mm: fix 2 for add support for PUD-sized transparent hugepages

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 include/asm-generic/pgtable.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
index 52c91858c194..7a2a969e7dea 100644
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -692,7 +692,7 @@ static inline int pmd_write(pmd_t pmd)
 #endif /* __HAVE_ARCH_PMD_WRITE */
 #endif /* CONFIG_TRANSPARENT_HUGEPAGE */
 
-#ifndef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
+#if !defined(CONFIG_TRANSPARENT_HUGEPAGE) || !defined(CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD)
 static inline int pud_trans_huge(pud_t pud)
 {
 	return 0;
-- 
2.6.4

-- 
Cheers,
Stephen Rothwell

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

* linux-next: build failure after merge of the akpm-current tree
@ 2016-02-03  4:13 Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2016-02-03  4:13 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Matthew Wilcox

Hi Andrew,

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

mm/huge_memory.c:1089:9: error: implicit declaration of function 'pud_mkyoung' [-Werror=implicit-function-declaration]
  _pud = pud_mkyoung(pud_mkdirty(*pud));
         ^
mm/huge_memory.c:1089:21: error: implicit declaration of function 'pud_mkdirty' [-Werror=implicit-function-declaration]
  _pud = pud_mkyoung(pud_mkdirty(*pud));
                     ^
mm/huge_memory.c:1089:7: error: incompatible types when assigning to type 'pud_t {aka struct <anonymous>}' from type 'int'
  _pud = pud_mkyoung(pud_mkdirty(*pud));
       ^
mm/huge_memory.c:1090:6: error: implicit declaration of function 'pudp_set_access_flags' [-Werror=implicit-function-declaration]
  if (pudp_set_access_flags(vma, addr & HPAGE_PUD_MASK,
      ^
mm/huge_memory.c:1092:3: error: implicit declaration of function 'update_mmu_cache_pud' [-Werror=implicit-function-declaration]
   update_mmu_cache_pud(vma, addr, pud);
   ^
mm/huge_memory.c: In function 'follow_devmap_pud':
mm/huge_memory.c:1137:22: error: implicit declaration of function 'pud_pfn' [-Werror=implicit-function-declaration]
  unsigned long pfn = pud_pfn(*pud);
                      ^

Caused by commit

  a27da20ed50e ("mm: add support for PUD-sized transparent hugepages")

Some bit have not been protected with
CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD ...

I added the following (ugly) patch:


From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 3 Feb 2016 15:07:54 +1100
Subject: [PATCH] mm: add support for PUD-sized transparent hugepages fix

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 mm/huge_memory.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 1632e02f859c..bad79b236ede 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -1074,6 +1074,7 @@ static void touch_pmd(struct vm_area_struct *vma, unsigned long addr,
 		update_mmu_cache_pmd(vma, addr, pmd);
 }
 
+#ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
 static void touch_pud(struct vm_area_struct *vma, unsigned long addr,
 		pud_t *pud)
 {
@@ -1091,6 +1092,7 @@ static void touch_pud(struct vm_area_struct *vma, unsigned long addr,
 				pud, _pud,  1))
 		update_mmu_cache_pud(vma, addr, pud);
 }
+#endif	/* CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD */
 
 struct page *follow_devmap_pmd(struct vm_area_struct *vma, unsigned long addr,
 		pmd_t *pmd, int flags)
@@ -1131,6 +1133,7 @@ struct page *follow_devmap_pmd(struct vm_area_struct *vma, unsigned long addr,
 	return page;
 }
 
+#ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
 struct page *follow_devmap_pud(struct vm_area_struct *vma, unsigned long addr,
 		pud_t *pud, int flags)
 {
@@ -1169,6 +1172,7 @@ struct page *follow_devmap_pud(struct vm_area_struct *vma, unsigned long addr,
 
 	return page;
 }
+#endif	/* CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD */
 
 int copy_huge_pmd(struct mm_struct *dst_mm, struct mm_struct *src_mm,
 		  pmd_t *dst_pmd, pmd_t *src_pmd, unsigned long addr,
@@ -1974,6 +1978,7 @@ spinlock_t *__pmd_trans_huge_lock(pmd_t *pmd, struct vm_area_struct *vma)
 	return NULL;
 }
 
+#ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
 /*
  * Returns true if a given pud maps a thp, false otherwise.
  *
@@ -1989,6 +1994,7 @@ spinlock_t *__pud_trans_huge_lock(pud_t *pud, struct vm_area_struct *vma)
 	spin_unlock(ptl);
 	return NULL;
 }
+#endif	/* CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD */
 
 #define VM_NO_THP (VM_SPECIAL | VM_HUGETLB | VM_SHARED | VM_MAYSHARE)
 
-- 
2.6.4

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2016-01-21  5:47     ` Sudip Mukherjee
@ 2016-01-21 20:37       ` Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2016-01-21 20:37 UTC (permalink / raw)
  To: Sudip Mukherjee; +Cc: Andrew Morton, linux-next, linux-kernel, Johannes Weiner

Hi Sudip,

On Thu, 21 Jan 2016 11:17:05 +0530 Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote:
>
> Adding that will uncover one more build failure, and the patch for that
> is at:
> https://patchwork.kernel.org/patch/8077891/

Looks like Dave Miller has picked that up.

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

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2016-01-21  5:25   ` Stephen Rothwell
@ 2016-01-21  5:47     ` Sudip Mukherjee
  2016-01-21 20:37       ` Stephen Rothwell
  0 siblings, 1 reply; 330+ messages in thread
From: Sudip Mukherjee @ 2016-01-21  5:47 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Andrew Morton, linux-next, linux-kernel, Johannes Weiner

Hi Stephen,

On Thu, Jan 21, 2016 at 04:25:45PM +1100, Stephen Rothwell wrote:
> Hi Sudip,
> 
> On Thu, 21 Jan 2016 10:47:09 +0530 Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote:
> >
> > On Thu, Jan 21, 2016 at 04:11:56PM +1100, Stephen Rothwell wrote:
> > > Hi Andrew,
> > > 
> > > After merging the akpm-current tree, today's linux-next build (arm
> > > efm32_defconfig) failed like this:
> > > 
> > > fs/proc/task_nommu.c:132:28: error: 'mm' undeclared (first use in this function)
> > > 
> > > Caused by commit
> > > 
> > >   e87d4fd02f40 ("proc: revert /proc/<pid>/maps [stack:TID] annotation")  
> > 
> > posted a patch for it few minutes ago.
> > https://patchwork.kernel.org/patch/8077421/
> 
> Thanks, I have added that to the akpm-current tree for tomorrow in case
> Andrew does not get around to it.

Adding that will uncover one more build failure, and the patch for that
is at:
https://patchwork.kernel.org/patch/8077891/

regards
sudip

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2016-01-21  5:17 ` Sudip Mukherjee
@ 2016-01-21  5:25   ` Stephen Rothwell
  2016-01-21  5:47     ` Sudip Mukherjee
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2016-01-21  5:25 UTC (permalink / raw)
  To: Sudip Mukherjee; +Cc: Andrew Morton, linux-next, linux-kernel, Johannes Weiner

Hi Sudip,

On Thu, 21 Jan 2016 10:47:09 +0530 Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote:
>
> On Thu, Jan 21, 2016 at 04:11:56PM +1100, Stephen Rothwell wrote:
> > Hi Andrew,
> > 
> > After merging the akpm-current tree, today's linux-next build (arm
> > efm32_defconfig) failed like this:
> > 
> > fs/proc/task_nommu.c:132:28: error: 'mm' undeclared (first use in this function)
> > 
> > Caused by commit
> > 
> >   e87d4fd02f40 ("proc: revert /proc/<pid>/maps [stack:TID] annotation")  
> 
> posted a patch for it few minutes ago.
> https://patchwork.kernel.org/patch/8077421/

Thanks, I have added that to the akpm-current tree for tomorrow in case
Andrew does not get around to it.

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

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2016-01-21  5:11 Stephen Rothwell
@ 2016-01-21  5:17 ` Sudip Mukherjee
  2016-01-21  5:25   ` Stephen Rothwell
  0 siblings, 1 reply; 330+ messages in thread
From: Sudip Mukherjee @ 2016-01-21  5:17 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Andrew Morton, linux-next, linux-kernel, Johannes Weiner

On Thu, Jan 21, 2016 at 04:11:56PM +1100, Stephen Rothwell wrote:
> Hi Andrew,
> 
> After merging the akpm-current tree, today's linux-next build (arm
> efm32_defconfig) failed like this:
> 
> fs/proc/task_nommu.c:132:28: error: 'mm' undeclared (first use in this function)
> 
> Caused by commit
> 
>   e87d4fd02f40 ("proc: revert /proc/<pid>/maps [stack:TID] annotation")

posted a patch for it few minutes ago.
https://patchwork.kernel.org/patch/8077421/

regards
sudip

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

* linux-next: build failure after merge of the akpm-current tree
@ 2016-01-21  5:11 Stephen Rothwell
  2016-01-21  5:17 ` Sudip Mukherjee
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2016-01-21  5:11 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Johannes Weiner

Hi Andrew,

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

fs/proc/task_nommu.c:132:28: error: 'mm' undeclared (first use in this function)

Caused by commit

  e87d4fd02f40 ("proc: revert /proc/<pid>/maps [stack:TID] annotation")

# CONFIG_MMU is not set

Discovered after today's linux-next release.

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

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2016-01-13  6:18 Stephen Rothwell
@ 2016-01-13  6:31 ` Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2016-01-13  6:31 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Tetsuo Handa, David Rientjes

Hi Andrew,

On Wed, 13 Jan 2016 17:18:30 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the akpm-current tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> mm/vmalloc.c: In function '__vunmap':
> mm/vmalloc.c:1482:21: error: 'VM_VPAGES' undeclared (first use in this function)
>    if (area->flags & VM_VPAGES)
>                      ^
> 
> Caused by commit
> 
>   7ab2843f2735 ("mm, vmalloc: remove VM_VPAGES")
> 
> Yesterday, there was a previous commit (which seems to have been
> removed)
> 
>   "tree wide: use kvfree() than conditional kfree()/vfree()"

I see that this patch is now in the akpm tree i.e. later on.  So I
guess you need to move the above patch as well.

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

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

* linux-next: build failure after merge of the akpm-current tree
@ 2016-01-13  6:18 Stephen Rothwell
  2016-01-13  6:31 ` Stephen Rothwell
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2016-01-13  6:18 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Tetsuo Handa, David Rientjes

Hi Andrew,

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

mm/vmalloc.c: In function '__vunmap':
mm/vmalloc.c:1482:21: error: 'VM_VPAGES' undeclared (first use in this function)
   if (area->flags & VM_VPAGES)
                     ^

Caused by commit

  7ab2843f2735 ("mm, vmalloc: remove VM_VPAGES")

Yesterday, there was a previous commit (which seems to have been
removed)

  "tree wide: use kvfree() than conditional kfree()/vfree()"

that removed this use of the VM_VPAGES flag.

I have reverted this commit for today.

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

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2015-12-31 11:15 Stephen Rothwell
@ 2016-01-11 11:39 ` Ingo Molnar
  0 siblings, 0 replies; 330+ messages in thread
From: Ingo Molnar @ 2016-01-11 11:39 UTC (permalink / raw)
  To: Stephen Rothwell, Arnaldo Carvalho de Melo, Jiri Olsa
  Cc: Andrew Morton, linux-next, linux-kernel, Thomas Gleixner,
	Ingo Molnar, H. Peter Anvin, Peter Zijlstra, Dan Williams


[Cc:-ed perf tooling guys as well.]

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

> Hi Andrew,
> 
> After merging the akpm-current tree, today's linux-next build (perf)
> failed like this:
> 
> In file included from /home/sfr/next/next/tools/include/linux/list.h:5:0,
>                  from arch/../util/map.h:6,
>                  from arch/../util/event.h:8,
>                  from arch/../util/debug.h:7,
>                  from arch/common.c:4:
> /home/sfr/next/next/tools/include/linux/../../../include/linux/list.h: In function 'list_force_poison':
> /home/sfr/next/next/tools/include/linux/../../../include/linux/list.h:123:56: error: unused parameter 'entry' [-Werror=unused-parameter]
>  static inline void list_force_poison(struct list_head *entry)
>                                                         ^
> 
> and many more like that.
> 
> Caused by commit
> 
>   a471eb786598 ("mm, dax, pmem: introduce {get|put}_dev_pagemap() for dax-gup")
> 
> I just left the perf build broken for today.

So I think it's time to create a tooling copy of list.h as well, to decouple 
tooling and kernel side uses of list.h.

We could do the same trick as with tools/lib/rbtree.c and 
tools/include/linux/rbtree.h: create a copy, and use 'diff' during tools build to 
generate a (non-fatal) warning if the two versions diverge.

This makes sure that tooling always syncs up with kernel side changes - without 
creating hard build failure dependencies.

Thanks,

	Ingo

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

* linux-next: build failure after merge of the akpm-current tree
@ 2015-12-31 11:15 Stephen Rothwell
  2016-01-11 11:39 ` Ingo Molnar
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2015-12-31 11:15 UTC (permalink / raw)
  To: Andrew Morton
  Cc: linux-next, linux-kernel, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra, Dan Williams

Hi Andrew,

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

In file included from /home/sfr/next/next/tools/include/linux/list.h:5:0,
                 from arch/../util/map.h:6,
                 from arch/../util/event.h:8,
                 from arch/../util/debug.h:7,
                 from arch/common.c:4:
/home/sfr/next/next/tools/include/linux/../../../include/linux/list.h: In function 'list_force_poison':
/home/sfr/next/next/tools/include/linux/../../../include/linux/list.h:123:56: error: unused parameter 'entry' [-Werror=unused-parameter]
 static inline void list_force_poison(struct list_head *entry)
                                                        ^

and many more like that.

Caused by commit

  a471eb786598 ("mm, dax, pmem: introduce {get|put}_dev_pagemap() for dax-gup")

I just left the perf build broken for today.

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

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

* linux-next: build failure after merge of the akpm-current tree
@ 2015-12-18  7:45 Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2015-12-18  7:45 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Dan Williams

Hi Andrew,

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

mm/huge_memory.c: In function 'insert_pfn_pmd':
mm/huge_memory.c:970:21: error: implicit declaration of func
tion 'pfn_t_pmd' [-Werror=implicit-function-declaration]
  entry = pmd_mkhuge(pfn_t_pmd(pfn, prot));
                     ^

Caused by commit

  e6cf6e9a2686 ("mm, dax: convert vmf_insert_pfn_pmd() to pfn_t")

I added this patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 18 Dec 2015 17:37:30 +1100
Subject: [PATCH] mm, dax: convert vmf_insert_pfn_pmd() to pfn_t fix

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/powerpc/include/asm/book3s/64/pgtable.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h b/arch/powerpc/include/asm/book3s/64/pgtable.h
index 03c1a5a21c0c..835fb5ec1de1 100644
--- a/arch/powerpc/include/asm/book3s/64/pgtable.h
+++ b/arch/powerpc/include/asm/book3s/64/pgtable.h
@@ -186,6 +186,7 @@ void pgtable_cache_init(void);
 struct page *realmode_pfn_to_page(unsigned long pfn);
 
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
+#define pfn_pmd pfn_pmd
 extern pmd_t pfn_pmd(unsigned long pfn, pgprot_t pgprot);
 extern pmd_t mk_pmd(struct page *page, pgprot_t pgprot);
 extern pmd_t pmd_modify(pmd_t pmd, pgprot_t newprot);
-- 
2.6.2

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

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

* linux-next: build failure after merge of the akpm-current tree
@ 2015-12-15  9:55 Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2015-12-15  9:55 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Minchan Kim

Hi Andrew,

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

mm/huge_memory.c: In function 'madvise_free_huge_pmd':
mm/huge_memory.c:1592:14: error: implicit declaration of function 'pmd_mkclean' [-Werror=implicit-function-declaration]
   orig_pmd = pmd_mkclean(orig_pmd);
              ^

Caused by me screwing up the merge resolution :-(

So I readded the definition of pmd_mkclean to
arch/powerpc/include/asm/book3s/64/pgtable.h

BTW, patch "arch/powerpc/include/asm/pgtable-ppc64.h: add
pmd_[dirty|mkclean] for THP" adds a second identical definition of
pmd_dirty() ...

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

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2015-12-08 10:51 Stephen Rothwell
@ 2015-12-08 23:03 ` Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2015-12-08 23:03 UTC (permalink / raw)
  To: Andrew Morton
  Cc: linux-next, linux-kernel, Daniel Cashman, Mark Brown,
	kernel-build-reports, linaro-kernel

Hi Andrew,

On Tue, 8 Dec 2015 21:51:40 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the akpm-current tree, today's linux-next build (arm64
> allnoconfig and others) failed like this:
> 
> arch/arm64/mm/mmap.c:54:1: error: unknown type name 'ifdef'
> arch/arm64/mm/mmap.c:55:2: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'if'
> arch/arm64/mm/mmap.c:57:2: error: 'else' without a previous 'if'
> arch/arm64/mm/mmap.c:58:2: error: #endif without #if
> 
> Caused by commit
> 
>   2e4614190421 ("arm64-mm-support-arch_mmap_rnd_bits-v4")
> 
> An obvious typo :-(
> 
> I will add the missing '#' tomorrow if it si not fixed by then.
> 
> Reported by Mark's build bot.

I have added this commit for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 9 Dec 2015 10:00:16 +1100
Subject: [PATCH] arm64-mm-support-arch_mmap_rnd_bits-v4-fix

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/arm64/mm/mmap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/mm/mmap.c b/arch/arm64/mm/mmap.c
index af461b935137..e59a75a308bc 100644
--- a/arch/arm64/mm/mmap.c
+++ b/arch/arm64/mm/mmap.c
@@ -51,7 +51,7 @@ unsigned long arch_mmap_rnd(void)
 {
 	unsigned long rnd;
 
-ifdef CONFIG_COMPAT
+#ifdef CONFIG_COMPAT
 	if (test_thread_flag(TIF_32BIT))
 		rnd = (unsigned long)get_random_int() % (1 << mmap_rnd_compat_bits);
 	else
-- 
2.6.2

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

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

* linux-next: build failure after merge of the akpm-current tree
@ 2015-12-08 10:51 Stephen Rothwell
  2015-12-08 23:03 ` Stephen Rothwell
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2015-12-08 10:51 UTC (permalink / raw)
  To: Andrew Morton
  Cc: linux-next, linux-kernel, Daniel Cashman, Mark Brown,
	kernel-build-reports, linaro-kernel

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (arm64
allnoconfig and others) failed like this:

arch/arm64/mm/mmap.c:54:1: error: unknown type name 'ifdef'
arch/arm64/mm/mmap.c:55:2: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'if'
arch/arm64/mm/mmap.c:57:2: error: 'else' without a previous 'if'
arch/arm64/mm/mmap.c:58:2: error: #endif without #if

Caused by commit

  2e4614190421 ("arm64-mm-support-arch_mmap_rnd_bits-v4")

An obvious typo :-(

I will add the missing '#' tomorrow if it si not fixed by then.

Reported by Mark's build bot.

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

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2015-11-01 18:26 ` Oleg Nesterov
@ 2015-11-01 21:48   ` Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2015-11-01 21:48 UTC (permalink / raw)
  To: Oleg Nesterov
  Cc: Andrew Morton, linux-next, linux-kernel, Markus Pargmann, Jens Axboe

Hi Oleg,

On Sun, 1 Nov 2015 19:26:46 +0100 Oleg Nesterov <oleg@redhat.com> wrote:
>
> On 11/02, Stephen Rothwell wrote:
> >
> > After merging the akpm-current tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > drivers/block/nbd.c: In function 'nbd_thread_send':
> > drivers/block/nbd.c:592:3: error: implicit declaration of function 'dequeue_signal_lock' [-Werror=implicit-function-declaration]
> >    dequeue_signal_lock(current, &current->blocked, &info);
> >    ^
> >
> > Caused by commit
> >
> >   ffcb8dc55a97 ("signal: turn dequeue_signal_lock() into kernel_dequeue_signal()")
> >
> > interacting with commit
> >
> >   dcc909d90ccd ("nbd: Add locking for tasks")
> >
> > from Linus' tree.  
> 
> Yes, thanks, this should be fixed by
> 
> 	signal-turn-dequeue_signal_lock-into-kernel_dequeue_signal-fix.patch

But not published yet ... but thanks for the confirmation.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2015-11-01 16:28 ` kbuild test robot
@ 2015-11-01 18:37   ` Oleg Nesterov
  0 siblings, 0 replies; 330+ messages in thread
From: Oleg Nesterov @ 2015-11-01 18:37 UTC (permalink / raw)
  To: kbuild test robot
  Cc: Stephen Rothwell, kbuild-all, Andrew Morton, linux-next,
	linux-kernel, Markus Pargmann, Jens Axboe

On 11/02, kbuild test robot wrote:
>
> Hi Stephen,
>
> [auto build test ERROR on v4.3-rc7 -- if it's inappropriate base, please suggest rules for selecting the more suitable base]
>
> url:    https://github.com/0day-ci/linux/commits/Stephen-Rothwell/linux-next-build-failure-after-merge-of-the-akpm-current-tree/20151102-001657
> config: i386-randconfig-x004-11010709 (attached as .config)
> reproduce:
>         # save the attached .config to linux build tree
>         make ARCH=i386
>
> All errors (new ones prefixed by >>):
>
>    drivers/block/nbd.c: In function 'nbd_thread_send':
> >> drivers/block/nbd.c:596:3: error: implicit declaration of function 'kernel_dequeue_signal' [-Werror=implicit-function-declaration]
>       kernel_dequeue_signal(NULL);
>       ^
>    cc1: some warnings being treated as errors
>
> vim +/kernel_dequeue_signal +596 drivers/block/nbd.c
>
>    590		spin_lock_irqsave(&nbd->tasks_lock, flags);
>    591		nbd->task_send = NULL;
>    592		spin_unlock_irqrestore(&nbd->tasks_lock, flags);
>    593
>    594		/* Clear maybe pending signals */
>    595		if (signal_pending(current))
>  > 596			kernel_dequeue_signal(NULL);
>    597
>    598		return 0;
>    599	}

Yes, de90fc653be60b4cec1a4d40f0e82164ec79f077 ("linux-next: build failure
after merge of the akpm-current tree") should be applied on top of -mm.

Hopefully this all was fixed by
signal-turn-dequeue_signal_lock-into-kernel_dequeue_signal-fix.patch
already in -mm.

Oleg.

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2015-11-01 16:15 Stephen Rothwell
  2015-11-01 16:28 ` kbuild test robot
@ 2015-11-01 18:26 ` Oleg Nesterov
  2015-11-01 21:48   ` Stephen Rothwell
  1 sibling, 1 reply; 330+ messages in thread
From: Oleg Nesterov @ 2015-11-01 18:26 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, linux-next, linux-kernel, Markus Pargmann, Jens Axboe

On 11/02, Stephen Rothwell wrote:
>
> Hi Andrew,
>
> After merging the akpm-current tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> drivers/block/nbd.c: In function 'nbd_thread_send':
> drivers/block/nbd.c:592:3: error: implicit declaration of function 'dequeue_signal_lock' [-Werror=implicit-function-declaration]
>    dequeue_signal_lock(current, &current->blocked, &info);
>    ^
>
> Caused by commit
>
>   ffcb8dc55a97 ("signal: turn dequeue_signal_lock() into kernel_dequeue_signal()")
>
> interacting with commit
>
>   dcc909d90ccd ("nbd: Add locking for tasks")
>
> from Linus' tree.

Yes, thanks, this should be fixed by

	signal-turn-dequeue_signal_lock-into-kernel_dequeue_signal-fix.patch

in -mm tree,

> I added this merge fix patch:

the same as the patch above, thanks.

> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 2 Nov 2015 03:04:27 +1100
> Subject: [PATCH] ndb: fix up for dequeue_signal_lock API change
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  drivers/block/nbd.c | 6 ++----
>  1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
> index 5101fd2aca77..93b3f99b6865 100644
> --- a/drivers/block/nbd.c
> +++ b/drivers/block/nbd.c
> @@ -587,10 +587,8 @@ static int nbd_thread_send(void *data)
>  	spin_unlock_irqrestore(&nbd->tasks_lock, flags);
>
>  	/* Clear maybe pending signals */
> -	if (signal_pending(current)) {
> -		siginfo_t info;
> -		dequeue_signal_lock(current, &current->blocked, &info);
> -	}
> +	if (signal_pending(current))
> +		kernel_dequeue_signal(NULL);
>
>  	return 0;
>  }
> --
> 2.6.1
>
> --
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2015-11-01 16:15 Stephen Rothwell
@ 2015-11-01 16:28 ` kbuild test robot
  2015-11-01 18:37   ` Oleg Nesterov
  2015-11-01 18:26 ` Oleg Nesterov
  1 sibling, 1 reply; 330+ messages in thread
From: kbuild test robot @ 2015-11-01 16:28 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: kbuild-all, Andrew Morton, linux-next, linux-kernel,
	Oleg Nesterov, Markus Pargmann, Jens Axboe

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

Hi Stephen,

[auto build test ERROR on v4.3-rc7 -- if it's inappropriate base, please suggest rules for selecting the more suitable base]

url:    https://github.com/0day-ci/linux/commits/Stephen-Rothwell/linux-next-build-failure-after-merge-of-the-akpm-current-tree/20151102-001657
config: i386-randconfig-x004-11010709 (attached as .config)
reproduce:
        # save the attached .config to linux build tree
        make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/block/nbd.c: In function 'nbd_thread_send':
>> drivers/block/nbd.c:596:3: error: implicit declaration of function 'kernel_dequeue_signal' [-Werror=implicit-function-declaration]
      kernel_dequeue_signal(NULL);
      ^
   cc1: some warnings being treated as errors

vim +/kernel_dequeue_signal +596 drivers/block/nbd.c

   590		spin_lock_irqsave(&nbd->tasks_lock, flags);
   591		nbd->task_send = NULL;
   592		spin_unlock_irqrestore(&nbd->tasks_lock, flags);
   593	
   594		/* Clear maybe pending signals */
   595		if (signal_pending(current))
 > 596			kernel_dequeue_signal(NULL);
   597	
   598		return 0;
   599	}

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/octet-stream, Size: 25552 bytes --]

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

* linux-next: build failure after merge of the akpm-current tree
@ 2015-11-01 16:15 Stephen Rothwell
  2015-11-01 16:28 ` kbuild test robot
  2015-11-01 18:26 ` Oleg Nesterov
  0 siblings, 2 replies; 330+ messages in thread
From: Stephen Rothwell @ 2015-11-01 16:15 UTC (permalink / raw)
  To: Andrew Morton
  Cc: linux-next, linux-kernel, Oleg Nesterov, Markus Pargmann, Jens Axboe

Hi Andrew,

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

drivers/block/nbd.c: In function 'nbd_thread_send':
drivers/block/nbd.c:592:3: error: implicit declaration of function 'dequeue_signal_lock' [-Werror=implicit-function-declaration]
   dequeue_signal_lock(current, &current->blocked, &info);
   ^

Caused by commit

  ffcb8dc55a97 ("signal: turn dequeue_signal_lock() into kernel_dequeue_signal()")

interacting with commit

  dcc909d90ccd ("nbd: Add locking for tasks")

from Linus' tree.

I added this merge fix patch:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 2 Nov 2015 03:04:27 +1100
Subject: [PATCH] ndb: fix up for dequeue_signal_lock API change

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/block/nbd.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index 5101fd2aca77..93b3f99b6865 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -587,10 +587,8 @@ static int nbd_thread_send(void *data)
 	spin_unlock_irqrestore(&nbd->tasks_lock, flags);
 
 	/* Clear maybe pending signals */
-	if (signal_pending(current)) {
-		siginfo_t info;
-		dequeue_signal_lock(current, &current->blocked, &info);
-	}
+	if (signal_pending(current))
+		kernel_dequeue_signal(NULL);
 
 	return 0;
 }
-- 
2.6.1

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

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2015-10-26 16:00   ` Laurent Dufour
@ 2015-10-27  0:45     ` Michael Ellerman
  0 siblings, 0 replies; 330+ messages in thread
From: Michael Ellerman @ 2015-10-27  0:45 UTC (permalink / raw)
  To: Laurent Dufour, Stephen Rothwell, Andrew Morton
  Cc: linux-next, linux-kernel, Aneesh Kumar K.V, Pavel Emelyanov,
	Benjamin Herrenschmidt, Paul Mackerras

On Mon, 2015-10-26 at 17:00 +0100, Laurent Dufour wrote:
> On 21/10/2015 12:08, Michael Ellerman wrote:
> > On Wed, 2015-10-21 at 16:59 +1100, Stephen Rothwell wrote:
> > > Hi Andrew,
> > > 
> > > After merging the akpm-current tree, today's linux-next build (powerpc
> > > allnoconfig) failed like this:
> > 
> > > arch/powerpc/include/asm/pgtable.h: In function 'pte_pgprot':
> > > arch/powerpc/include/asm/pte-common.h:104:18: error: '_PAGE_SOFT_DIRTY' undeclared (first use in this function)
> > >      _PAGE_EXEC | _PAGE_SOFT_DIRTY)
> > 
> > That's probably my fault, Andrew asked if we wanted to take it via powerpc and
> > I thought "yes" but never actually replied.
> 
> I apologize, that's my mistake, I forgot to test with allnoconfig.
> 
> Michael, should I propose a new version of this patch on linuxppc-dev or
> should I wait for Aneesh's series to be in your next branch ?

Please send an updated version to linuxppc-dev, I probably won't merge it until
Aneesh's series go in but it's still good to have an updated version on the
list.

cheers

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2015-10-21 10:08 ` Michael Ellerman
  2015-10-21 14:14   ` Aneesh Kumar K.V
  2015-10-26  8:18   ` Laurent Dufour
@ 2015-10-26 16:00   ` Laurent Dufour
  2015-10-27  0:45     ` Michael Ellerman
  2 siblings, 1 reply; 330+ messages in thread
From: Laurent Dufour @ 2015-10-26 16:00 UTC (permalink / raw)
  To: Michael Ellerman, Stephen Rothwell, Andrew Morton
  Cc: linux-next, linux-kernel, Aneesh Kumar K.V, Pavel Emelyanov,
	Benjamin Herrenschmidt, Paul Mackerras

On 21/10/2015 12:08, Michael Ellerman wrote:
> On Wed, 2015-10-21 at 16:59 +1100, Stephen Rothwell wrote:
>> Hi Andrew,
>>
>> After merging the akpm-current tree, today's linux-next build (powerpc
>> allnoconfig) failed like this:
> 
>> arch/powerpc/include/asm/pgtable.h: In function 'pte_pgprot':
>> arch/powerpc/include/asm/pte-common.h:104:18: error: '_PAGE_SOFT_DIRTY' undeclared (first use in this function)
>>      _PAGE_EXEC | _PAGE_SOFT_DIRTY)
> 
> That's probably my fault, Andrew asked if we wanted to take it via powerpc and
> I thought "yes" but never actually replied.

I apologize, that's my mistake, I forgot to test with allnoconfig.

Michael, should I propose a new version of this patch on linuxppc-dev or
should I wait for Aneesh's series to be in your next branch ?

Cheers,
Laurent.

> 
> Andrew can you drop this one and we'll take it via powerpc?
> 
> It might take a while to actually hit the powerpc tree because Aneesh is doing
> a lot of work in this area at the moment.
> 
> Without knowing the code, the change logs make me think we probably also need
> to take the other two from Laurent for it to make sense. Laurent?
> 
> cheers
> 

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2015-10-21 10:08 ` Michael Ellerman
  2015-10-21 14:14   ` Aneesh Kumar K.V
@ 2015-10-26  8:18   ` Laurent Dufour
  2015-10-26 16:00   ` Laurent Dufour
  2 siblings, 0 replies; 330+ messages in thread
From: Laurent Dufour @ 2015-10-26  8:18 UTC (permalink / raw)
  To: Michael Ellerman, Stephen Rothwell, Andrew Morton
  Cc: linux-next, linux-kernel, Aneesh Kumar K.V, Pavel Emelyanov,
	Benjamin Herrenschmidt, Paul Mackerras

On 21/10/2015 12:08, Michael Ellerman wrote:
> On Wed, 2015-10-21 at 16:59 +1100, Stephen Rothwell wrote:
>> Hi Andrew,
>>
>> After merging the akpm-current tree, today's linux-next build (powerpc
>> allnoconfig) failed like this:
> 
>> arch/powerpc/include/asm/pgtable.h: In function 'pte_pgprot':
>> arch/powerpc/include/asm/pte-common.h:104:18: error: '_PAGE_SOFT_DIRTY' undeclared (first use in this function)
>>      _PAGE_EXEC | _PAGE_SOFT_DIRTY)
> 
> That's probably my fault, Andrew asked if we wanted to take it via powerpc and
> I thought "yes" but never actually replied.
> 
> Andrew can you drop this one and we'll take it via powerpc?
> 
> It might take a while to actually hit the powerpc tree because Aneesh is doing
> a lot of work in this area at the moment.
> 
> Without knowing the code, the change logs make me think we probably also need
> to take the other two from Laurent for it to make sense. Laurent?

Hi Michael,

Sorry for the late answer, I was off a couple of days last week.

The other two patches are not specific to powerpc and, as mentioned by
Aneesh, they can go to the -mm tree.

Cheers,
Laurent.

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2015-10-21 10:08 ` Michael Ellerman
@ 2015-10-21 14:14   ` Aneesh Kumar K.V
  2015-10-26  8:18   ` Laurent Dufour
  2015-10-26 16:00   ` Laurent Dufour
  2 siblings, 0 replies; 330+ messages in thread
From: Aneesh Kumar K.V @ 2015-10-21 14:14 UTC (permalink / raw)
  To: Michael Ellerman, Stephen Rothwell, Andrew Morton
  Cc: linux-next, linux-kernel, Laurent Dufour, Pavel Emelyanov,
	Benjamin Herrenschmidt, Paul Mackerras

Michael Ellerman <mpe@ellerman.id.au> writes:

> On Wed, 2015-10-21 at 16:59 +1100, Stephen Rothwell wrote:
>> Hi Andrew,
>> 
>> After merging the akpm-current tree, today's linux-next build (powerpc
>> allnoconfig) failed like this:
>
>> arch/powerpc/include/asm/pgtable.h: In function 'pte_pgprot':
>> arch/powerpc/include/asm/pte-common.h:104:18: error: '_PAGE_SOFT_DIRTY' undeclared (first use in this function)
>>      _PAGE_EXEC | _PAGE_SOFT_DIRTY)
>
> That's probably my fault, Andrew asked if we wanted to take it via powerpc and
> I thought "yes" but never actually replied.
>
> Andrew can you drop this one and we'll take it via powerpc?
>
> It might take a while to actually hit the powerpc tree because Aneesh is doing
> a lot of work in this area at the moment.
>
> Without knowing the code, the change logs make me think we probably also need
> to take the other two from Laurent for it to make sense. Laurent?
>

The other two patches are fixes for core soft dirty tracking code and
they are valid even without powerpc bits. So they can go via -mm tree

-aneesh

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2015-10-21  5:59 Stephen Rothwell
@ 2015-10-21 10:08 ` Michael Ellerman
  2015-10-21 14:14   ` Aneesh Kumar K.V
                     ` (2 more replies)
  0 siblings, 3 replies; 330+ messages in thread
From: Michael Ellerman @ 2015-10-21 10:08 UTC (permalink / raw)
  To: Stephen Rothwell, Andrew Morton
  Cc: linux-next, linux-kernel, Laurent Dufour, Aneesh Kumar K.V,
	Pavel Emelyanov, Benjamin Herrenschmidt, Paul Mackerras

On Wed, 2015-10-21 at 16:59 +1100, Stephen Rothwell wrote:
> Hi Andrew,
> 
> After merging the akpm-current tree, today's linux-next build (powerpc
> allnoconfig) failed like this:
 
> arch/powerpc/include/asm/pgtable.h: In function 'pte_pgprot':
> arch/powerpc/include/asm/pte-common.h:104:18: error: '_PAGE_SOFT_DIRTY' undeclared (first use in this function)
>      _PAGE_EXEC | _PAGE_SOFT_DIRTY)

That's probably my fault, Andrew asked if we wanted to take it via powerpc and
I thought "yes" but never actually replied.

Andrew can you drop this one and we'll take it via powerpc?

It might take a while to actually hit the powerpc tree because Aneesh is doing
a lot of work in this area at the moment.

Without knowing the code, the change logs make me think we probably also need
to take the other two from Laurent for it to make sense. Laurent?

cheers

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2015-10-21  6:34 Stephen Rothwell
  2015-10-21  6:47 ` Minchan Kim
@ 2015-10-21  6:48 ` Andrew Morton
  1 sibling, 0 replies; 330+ messages in thread
From: Andrew Morton @ 2015-10-21  6:48 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Minchan Kim

On Wed, 21 Oct 2015 17:34:38 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Andrew,
> 
> After merging the akpm-current tree, today's linux-next build (arm
> allnoconfig and others) failed like this:
> 
> In file included from init/main.c:50:0:
> include/linux/rmap.h:274:1: error: expected declaration specifiers or '...' before '{' token
> 
> Caused by commit
> 
>   e4f28388eb72 ("mm: simplify reclaim path for MADV_FREE")
> 
> Discovered after the linux-next release.

argh, we broke nommu.

--- a/include/linux/rmap.h~mm-dont-split-thp-page-when-syscall-is-called-fix-6-fix
+++ a/include/linux/rmap.h
@@ -270,7 +270,7 @@ int rmap_walk(struct page *page, struct 
 
 static inline int page_referenced(struct page *page, int is_locked,
 				  struct mem_cgroup *memcg,
-				  unsigned long *vm_flags,
+				  unsigned long *vm_flags)
 {
 	*vm_flags = 0;
 	return 0;

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2015-10-21  6:34 Stephen Rothwell
@ 2015-10-21  6:47 ` Minchan Kim
  2015-10-21  6:48 ` Andrew Morton
  1 sibling, 0 replies; 330+ messages in thread
From: Minchan Kim @ 2015-10-21  6:47 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Andrew Morton, linux-next, linux-kernel

Hello,

On Wed, Oct 21, 2015 at 05:34:38PM +1100, Stephen Rothwell wrote:
> Hi Andrew,
> 
> After merging the akpm-current tree, today's linux-next build (arm
> allnoconfig and others) failed like this:
> 
> In file included from init/main.c:50:0:
> include/linux/rmap.h:274:1: error: expected declaration specifiers or '...' before '{' token
> 
> Caused by commit
> 
>   e4f28388eb72 ("mm: simplify reclaim path for MADV_FREE")
> 
> Discovered after the linux-next release.

It was my bad. Sorry about that.
Here patch goes. Maybe Andrew want to fold it to e4f28388eb72.

Thanks.

>From 1062bfcfcc65b4a019666ada3786e95e4b299df6 Mon Sep 17 00:00:00 2001
From: Minchan Kim <minchan@kernel.org>
Date: Wed, 21 Oct 2015 15:41:49 +0900
Subject: [PATCH] mm: fix compile error caused omitting parentheses

This patch fixes build error introudced by
e4f28388eb72 ("mm: simplify reclaim path for MADV_FREE").

Signed-off-by: Minchan Kim <minchan@kernel.org>
---
 include/linux/rmap.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/rmap.h b/include/linux/rmap.h
index 978f65066fd5..853f4f3c6742 100644
--- a/include/linux/rmap.h
+++ b/include/linux/rmap.h
@@ -270,7 +270,7 @@ int rmap_walk(struct page *page, struct rmap_walk_control *rwc);
 
 static inline int page_referenced(struct page *page, int is_locked,
 				  struct mem_cgroup *memcg,
-				  unsigned long *vm_flags,
+				  unsigned long *vm_flags)
 {
 	*vm_flags = 0;
 	return 0;
-- 
1.9.1


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

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

* linux-next: build failure after merge of the akpm-current tree
@ 2015-10-21  6:34 Stephen Rothwell
  2015-10-21  6:47 ` Minchan Kim
  2015-10-21  6:48 ` Andrew Morton
  0 siblings, 2 replies; 330+ messages in thread
From: Stephen Rothwell @ 2015-10-21  6:34 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Minchan Kim

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (arm
allnoconfig and others) failed like this:

In file included from init/main.c:50:0:
include/linux/rmap.h:274:1: error: expected declaration specifiers or '...' before '{' token

Caused by commit

  e4f28388eb72 ("mm: simplify reclaim path for MADV_FREE")

Discovered after the linux-next release.

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

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

* linux-next: build failure after merge of the akpm-current tree
@ 2015-10-21  5:59 Stephen Rothwell
  2015-10-21 10:08 ` Michael Ellerman
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2015-10-21  5:59 UTC (permalink / raw)
  To: Andrew Morton
  Cc: linux-next, linux-kernel, Laurent Dufour, Aneesh Kumar K.V,
	Pavel Emelyanov, Michael Ellerman, Benjamin Herrenschmidt,
	Paul Mackerras

Hi Andrew,

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

In file included from arch/powerpc/include/asm/thread_info.h:34:0,
                 from include/linux/thread_info.h:54,
                 from include/asm-generic/preempt.h:4,
                 from arch/powerpc/include/generated/asm/preempt.h:1,
                 from include/linux/preempt.h:59,
                 from include/linux/spinlock.h:50,
                 from include/linux/seqlock.h:35,
                 from include/linux/time.h:5,
                 from include/uapi/linux/timex.h:56,
                 from include/linux/timex.h:56,
                 from include/linux/sched.h:19,
                 from arch/powerpc/kernel/asm-offsets.c:17:
arch/powerpc/include/asm/pgtable.h: In function 'pte_pgprot':
arch/powerpc/include/asm/pte-common.h:104:18: error: '_PAGE_SOFT_DIRTY' undeclared (first use in this function)
     _PAGE_EXEC | _PAGE_SOFT_DIRTY)
                  ^
arch/powerpc/include/asm/page.h:359:22: note: in definition of macro '__pgprot'
 #define __pgprot(x) (x)
                      ^
arch/powerpc/include/asm/pgtable.h:39:79: note: in expansion of macro 'PAGE_PROT_BITS'
 static inline pgprot_t pte_pgprot(pte_t pte) { return __pgprot(pte_val(pte) & PAGE_PROT_BITS); }
                                                                               ^
arch/powerpc/include/asm/pte-common.h:104:18: note: each undeclared identifier is reported only once for each function it appears in
     _PAGE_EXEC | _PAGE_SOFT_DIRTY) 
                  ^
arch/powerpc/include/asm/page.h:359:22: note: in definition of macro '__pgprot'
 #define __pgprot(x) (x)
                      ^
arch/powerpc/include/asm/pgtable.h:39:79: note: in expansion of macro 'PAGE_PROT_BITS'
 static inline pgprot_t pte_pgprot(pte_t pte) { return __pgprot(pte_val(pte) & PAGE_PROT_BITS); }
                                                                               ^
In file included from include/linux/mm.h:55:0,
                 from include/linux/mman.h:4,
                 from arch/powerpc/kernel/asm-offsets.c:22:
arch/powerpc/include/asm/pgtable.h: In function 'pte_mkdirty':
arch/powerpc/include/asm/pgtable.h:130:32: error: '_PAGE_SOFT_DIRTY' undeclared (first use in this function)
  pte_val(pte) |= _PAGE_DIRTY | _PAGE_SOFT_DIRTY; return pte; }
                                ^   
In file included from arch/powerpc/include/asm/pgtable-ppc32.h:123:0,
                 from arch/powerpc/include/asm/pgtable.h:19,
                 from include/linux/mm.h:55,
                 from include/linux/mman.h:4,
                 from arch/powerpc/kernel/asm-offsets.c:22:
arch/powerpc/include/asm/pgtable.h: In function 'pte_modify':
arch/powerpc/include/asm/pte-common.h:97:38: error: '_PAGE_SOFT_DIRTY' undeclared (first use in this function)
     _PAGE_ACCESSED | _PAGE_SPECIAL | _PAGE_SOFT_DIRTY)
                                      ^
arch/powerpc/include/asm/pgtable.h:139:33: note: in expansion of macro '_PAGE_CHG_MASK'
  pte_val(pte) = (pte_val(pte) & _PAGE_CHG_MASK) | pgprot_val(newprot);
                                 ^  
./Kbuild:80: recipe for target 'arch/powerpc/kernel/asm-offsets.s' failed

Caused by commit

  8bd232790748 ("powerpc/mm: add page soft dirty tracking")

I have reverted that commit for today.

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

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2015-09-21  4:18 Stephen Rothwell
@ 2015-09-21 16:24 ` Dmitry Torokhov
  0 siblings, 0 replies; 330+ messages in thread
From: Dmitry Torokhov @ 2015-09-21 16:24 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Andrew Morton, linux-next, linux-kernel

On Mon, Sep 21, 2015 at 02:18:10PM +1000, Stephen Rothwell wrote:
> Hi Andrew,
> 
> After merging the akpm-current tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/input/joystick/walkera0701.c:153:4: error: implicit declaration of function 'abs64' [-Werror=implicit-function-declaration]
>     if (abs64(pulse_time - SYNC_PULSE) < RESERVE) /* new frame sync */
>     ^
> 
> Caused by commit
> 
>   ea91f9c72512 ("Remove abs64()")
> 
> interacting with commit
> 
>   46b018fa9500 ("Input: walkera0701 - fix abs() calculations on 64 bit values")
> 
> from the input-current tree.
> 
> I just reverted 46b018fa9500 as ti will no longer be needed.

Hmm, I plan on sending it to Linus in 4.3 merge window. I saw more
patches switching to abs64 flying by so I guess removal will have to add
walkera to the list needing adjusting.

Thanks.

-- 
Dmitry

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2015-09-21  7:58 ` Michal Hocko
@ 2015-09-21 10:10   ` Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2015-09-21 10:10 UTC (permalink / raw)
  To: Michal Hocko, Vladimir Davydov
  Cc: Andrew Morton, Tejun Heo, linux-next, linux-kernel

Hi Michal, Vladimir,

On Mon, 21 Sep 2015 09:58:53 +0200 Michal Hocko <mhocko@kernel.org> wrote:
>
> AFAIU your fix is correct but using
> cgroup_subsys_on_dfl(memory_cgrp_subsys) is more appropriate:
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index d62924ee8022..c3df03add73e 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -176,7 +176,7 @@ static bool sane_reclaim(struct scan_control *sc)
>  	if (!memcg)
>  		return true;
>  #ifdef CONFIG_CGROUP_WRITEBACK
> -	if (cgroup_on_dfl(memcg->css.cgroup))
> +	if (cgroup_subsys_on_dfl(memory_cgrp_subsys))
>  		return true;
>  #endif
>  	return false;

Thanks, I will do that from tomorrow.

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

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2015-09-21  4:10 Stephen Rothwell
  2015-09-21  7:58 ` Michal Hocko
@ 2015-09-21  7:58 ` Vladimir Davydov
  1 sibling, 0 replies; 330+ messages in thread
From: Vladimir Davydov @ 2015-09-21  7:58 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Andrew Morton, Tejun Heo, linux-next, linux-kernel

On Mon, Sep 21, 2015 at 02:10:39PM +1000, Stephen Rothwell wrote:
> After merging the akpm-current tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> mm/vmscan.c: In function 'sane_reclaim':
> mm/vmscan.c:178:2: error: implicit declaration of function 'cgroup_on_dfl' [-Werror=implicit-function-declaration]
>   if (cgroup_on_dfl(memcg->css.cgroup))
>   ^
> 
> Caused by commit
> 
>   d08255ab4d66 ("vmscan: fix sane_reclaim helper for legacy memcg")
> 
> interacting with commit
> 
>   9e10a130d9b6 ("cgroup: replace cgroup_on_dfl() tests in controllers with cgroup_subsys_on_dfl()")
> 
> from the cgroup tree.
> 
> I don't know what the correct firx is here (help, please) so I have just
> open coded the cgroup_on_dfl() call for now:

Quoting Tejun (http://www.spinics.net/lists/linux-mm/msg94556.html):

: Just a heads-up.  I'm applying a patch which replaces cgroup_on_dfl()
: with cgroup_subsys_on_dfl() to cgroup/for-4.4, so this patch would
: need to be adjusted to do cgroup_subsys_on_dfl(memory_cgrp_subsys)
: instead.

Thanks,
Vladimir

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2015-09-21  4:10 Stephen Rothwell
@ 2015-09-21  7:58 ` Michal Hocko
  2015-09-21 10:10   ` Stephen Rothwell
  2015-09-21  7:58 ` Vladimir Davydov
  1 sibling, 1 reply; 330+ messages in thread
From: Michal Hocko @ 2015-09-21  7:58 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Tejun Heo, linux-next, linux-kernel, Vladimir Davydov

On Mon 21-09-15 14:10:39, Stephen Rothwell wrote:
> Hi Andrew,
> 
> After merging the akpm-current tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> mm/vmscan.c: In function 'sane_reclaim':
> mm/vmscan.c:178:2: error: implicit declaration of function 'cgroup_on_dfl' [-Werror=implicit-function-declaration]
>   if (cgroup_on_dfl(memcg->css.cgroup))
>   ^
> 
> Caused by commit
> 
>   d08255ab4d66 ("vmscan: fix sane_reclaim helper for legacy memcg")
> 
> interacting with commit
> 
>   9e10a130d9b6 ("cgroup: replace cgroup_on_dfl() tests in controllers with cgroup_subsys_on_dfl()")
> 
> from the cgroup tree.
> 
> I don't know what the correct firx is here (help, please) so I have just
> open coded the cgroup_on_dfl() call for now:

AFAIU your fix is correct but using
cgroup_subsys_on_dfl(memory_cgrp_subsys) is more appropriate:
diff --git a/mm/vmscan.c b/mm/vmscan.c
index d62924ee8022..c3df03add73e 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -176,7 +176,7 @@ static bool sane_reclaim(struct scan_control *sc)
 	if (!memcg)
 		return true;
 #ifdef CONFIG_CGROUP_WRITEBACK
-	if (cgroup_on_dfl(memcg->css.cgroup))
+	if (cgroup_subsys_on_dfl(memory_cgrp_subsys))
 		return true;
 #endif
 	return false;

-- 
Michal Hocko
SUSE Labs

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

* linux-next: build failure after merge of the akpm-current tree
@ 2015-09-21  4:18 Stephen Rothwell
  2015-09-21 16:24 ` Dmitry Torokhov
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2015-09-21  4:18 UTC (permalink / raw)
  To: Andrew Morton, Dmitry Torokhov; +Cc: linux-next, linux-kernel

Hi Andrew,

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

drivers/input/joystick/walkera0701.c:153:4: error: implicit declaration of function 'abs64' [-Werror=implicit-function-declaration]
    if (abs64(pulse_time - SYNC_PULSE) < RESERVE) /* new frame sync */
    ^

Caused by commit

  ea91f9c72512 ("Remove abs64()")

interacting with commit

  46b018fa9500 ("Input: walkera0701 - fix abs() calculations on 64 bit values")

from the input-current tree.

I just reverted 46b018fa9500 as ti will no longer be needed.

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

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

* linux-next: build failure after merge of the akpm-current tree
@ 2015-09-21  4:10 Stephen Rothwell
  2015-09-21  7:58 ` Michal Hocko
  2015-09-21  7:58 ` Vladimir Davydov
  0 siblings, 2 replies; 330+ messages in thread
From: Stephen Rothwell @ 2015-09-21  4:10 UTC (permalink / raw)
  To: Andrew Morton, Tejun Heo; +Cc: linux-next, linux-kernel, Vladimir Davydov

Hi Andrew,

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

mm/vmscan.c: In function 'sane_reclaim':
mm/vmscan.c:178:2: error: implicit declaration of function 'cgroup_on_dfl' [-Werror=implicit-function-declaration]
  if (cgroup_on_dfl(memcg->css.cgroup))
  ^

Caused by commit

  d08255ab4d66 ("vmscan: fix sane_reclaim helper for legacy memcg")

interacting with commit

  9e10a130d9b6 ("cgroup: replace cgroup_on_dfl() tests in controllers with cgroup_subsys_on_dfl()")

from the cgroup tree.

I don't know what the correct firx is here (help, please) so I have just
open coded the cgroup_on_dfl() call for now:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 21 Sep 2015 14:06:17 +1000
Subject: [PATCH] vmscan-fix-sane_reclaim-helper-for-legacy-memcg-fix

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 mm/vmscan.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 6ad68edbd260..8c7b1f5c6a6d 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -175,7 +175,7 @@ static bool sane_reclaim(struct scan_control *sc)
 	if (!memcg)
 		return true;
 #ifdef CONFIG_CGROUP_WRITEBACK
-	if (cgroup_on_dfl(memcg->css.cgroup))
+	if (memcg->css.cgroup->root == &cgrp_dfl_root)
 		return true;
 #endif
 	return false;
-- 
2.5.1

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

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

* linux-next: build failure after merge of the akpm-current tree
@ 2015-09-17  2:15 Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2015-09-17  2:15 UTC (permalink / raw)
  To: Andrew Morton
  Cc: linux-next, linux-kernel, Kirill A. Shutemov, Michal Hocko,
	Vlastimil Babka, Andrea Arcangeli

Hi Andrew,

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

mm/page_alloc.c:184:14: error: conflicting types for 'pageblock_order'
 unsigned int pageblock_order __read_mostly;
              ^
In file included from include/linux/mmzone.h:17:0,
                 from include/linux/gfp.h:5,
                 from include/linux/mm.h:9,
                 from mm/page_alloc.c:18:
include/linux/pageblock-flags.h:47:12: note: previous declaration of 'pageblock_order' was here
 extern int pageblock_order; 
            ^

Caused by commit

  b3c625d32a04 ("mm: use 'unsigned int' for page order")

I assume that this was never built with CONFIG_HUGETLB_PAGE_SIZE_VARIABLE
set (or the hunk that updated include/linux/pageblock-flags.h was missed).

I have added the following fix patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 17 Sep 2015 11:58:50 +1000
Subject: [PATCH] mm-use-unsigned-int-for-page-order-fix

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 include/linux/pageblock-flags.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/pageblock-flags.h b/include/linux/pageblock-flags.h
index 2baeee12f48e..e942558b3585 100644
--- a/include/linux/pageblock-flags.h
+++ b/include/linux/pageblock-flags.h
@@ -44,7 +44,7 @@ enum pageblock_bits {
 #ifdef CONFIG_HUGETLB_PAGE_SIZE_VARIABLE
 
 /* Huge page sizes are variable */
-extern int pageblock_order;
+extern unsigned int pageblock_order;
 
 #else /* CONFIG_HUGETLB_PAGE_SIZE_VARIABLE */
 
-- 
2.5.1

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

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

* linux-next: build failure after merge of the akpm-current tree
@ 2015-09-12  4:34 Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2015-09-12  4:34 UTC (permalink / raw)
  To: Andrew Morton
  Cc: linux-next, linux-kernel, Vladimir Davydov, Kirill A. Shutemov

Hi Andrew,

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

In file included from include/linux/mm.h:318:0,
                 from include/linux/highmem.h:7,
                 from include/linux/bio.h:23,
                 from include/linux/writeback.h:192,
                 from include/linux/memcontrol.h:30,
                 from include/linux/swap.h:8,
                 from include/linux/suspend.h:4,
                 from arch/x86/kernel/asm-offsets.c:12:
include/linux/page-flags.h:371:26: error: macro "TESTPAGEFLAG" requires 3 arguments, but only 2 given
 TESTPAGEFLAG(Young, young)
                          ^  
include/linux/page-flags.h:372:25: error: macro "SETPAGEFLAG" requires 3 arguments, but only 2 given
 SETPAGEFLAG(Young, young)   
                         ^   
include/linux/page-flags.h:371:1: error: unknown type name 'TESTPAGEFLAG'
 TESTPAGEFLAG(Young, young)  
 ^
include/linux/page-flags.h:373:27: error: macro "TESTCLEARFLAG" requires 3 arguments, but only 2 given
 TESTCLEARFLAG(Young, young) 
                           ^ 
include/linux/page-flags.h:373:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'TESTCLEARFLAG'
 TESTCLEARFLAG(Young, young) 
 ^
include/linux/page-flags.h:374:20: error: macro "PAGEFLAG" requires 3 arguments, but only 2 given
 PAGEFLAG(Idle, idle)
                    ^
include/linux/page-flags.h:373:1: error: unknown type name 'TESTCLEARFLAG'
 TESTCLEARFLAG(Young, young) 
 ^
In file included from include/linux/highmem.h:7:0,
                 from include/linux/bio.h:23,
                 from include/linux/writeback.h:192,
                 from include/linux/memcontrol.h:30,
                 from include/linux/swap.h:8,
                 from include/linux/suspend.h:4,
                 from arch/x86/kernel/asm-offsets.c:12:
include/linux/mm.h: In function '__compound_tail_refcounted':
include/linux/mm.h:453:2: error: implicit declaration of function 'PageAnon' [-Werror=implicit-function-declaration]
  return PageAnon(page) && !PageSlab(page) && !PageHeadHuge(page);
  ^

Caused by commit

  33c3fc71c8cf ("mm: introduce idle page tracking")

from Linus' tree interacting with commit

  3b1670dad702 ("page-flags: introduce page flags policies wrt compound pages")

from the akpm-current tree (and presumably others).

I have just dropped the akpm-current tree for today.  I am sorry I
rushed you to put out a cleaned up mmotm yesterday :-(

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

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2015-08-14  8:47 Stephen Rothwell
@ 2015-08-14  9:01 ` Naoya Horiguchi
  0 siblings, 0 replies; 330+ messages in thread
From: Naoya Horiguchi @ 2015-08-14  9:01 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Andrew Morton, linux-next, linux-kernel

On Fri, Aug 14, 2015 at 06:47:53PM +1000, Stephen Rothwell wrote:
> Hi Andrew,
> 
> After merging the akpm tree, today's linux-next build (sparc64 defconfig)
> failed like this:
> 
> In file included from include/linux/sched.h:27:0,
>                  from arch/sparc/kernel/asm-offsets.c:13:
> include/linux/mm_types.h:371:22: error: 'HUGE_MAX_HSTATE' undeclared here (not in a function)
>   atomic_long_t count[HUGE_MAX_HSTATE];
>                       ^

Thank you for the report,

I'm suggesting the following diff as a fix. And I'm fine for these patches
to be excluded until the fix is merged to mmotm.

Thanks,
Naoya Horiguchi
---
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 64aa4db01f48..99ea2c651106 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -330,10 +330,6 @@ int __init alloc_bootmem_huge_page(struct hstate *h);
 void __init hugetlb_add_hstate(unsigned order);
 struct hstate *size_to_hstate(unsigned long size);
 
-#ifndef HUGE_MAX_HSTATE
-#define HUGE_MAX_HSTATE 1
-#endif
-
 extern struct hstate hstates[HUGE_MAX_HSTATE];
 extern unsigned int default_hstate_idx;
 
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index e95c5fe1eb7d..27333cdb8b46 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -365,6 +365,10 @@ struct mm_rss_stat {
 };
 
 #ifdef CONFIG_HUGETLB_PAGE
+
+#ifndef HUGE_MAX_HSTATE
+#define HUGE_MAX_HSTATE	1
+#endif
 struct hugetlb_usage {
 	atomic_long_t count[HUGE_MAX_HSTATE];
 };



> 
> Caused by commit
> 
>   04f4eaa95082 ("mm: hugetlb: proc: add HugetlbPages field to /proc/PID/status")
> 
> I have reverted that patch (and the following fix patch:
> 
>   f26cf7b29291 ("mm-hugetlb-proc-add-hugetlbpages-field-to-proc-pid-status-fix")

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

* linux-next: build failure after merge of the akpm-current tree
@ 2015-08-14  8:47 Stephen Rothwell
  2015-08-14  9:01 ` Naoya Horiguchi
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2015-08-14  8:47 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Naoya Horiguchi

Hi Andrew,

After merging the akpm tree, today's linux-next build (sparc64 defconfig)
failed like this:

In file included from include/linux/sched.h:27:0,
                 from arch/sparc/kernel/asm-offsets.c:13:
include/linux/mm_types.h:371:22: error: 'HUGE_MAX_HSTATE' undeclared here (not in a function)
  atomic_long_t count[HUGE_MAX_HSTATE];
                      ^

Caused by commit

  04f4eaa95082 ("mm: hugetlb: proc: add HugetlbPages field to /proc/PID/status")

I have reverted that patch (and the following fix patch:

  f26cf7b29291 ("mm-hugetlb-proc-add-hugetlbpages-field-to-proc-pid-status-fix")

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

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

* linux-next: build failure after merge of the akpm-current tree
@ 2015-08-06  7:24 Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2015-08-06  7:24 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, James Hogan, Kees Cook

Hi Andrew,

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

lib/test_user_copy.c: In function 'test_user_copy_init':
lib/test_user_copy.c:111:2: error: implicit declaration of function 'csum_partial_copy_from_user' [-Werror=implicit-function-declaration]
  csum_partial_copy_from_user(usermem, kmem, PAGE_SIZE, 0, &err);
  ^

Caused by commit

  0b6e2917b6fc ("lib/test_user_copy.c: check user checksum functions")

It looks like PowerPC 64 bit has an implementation of
csum_and_copy_from_user() that does not use csum_partial_copy_from_user()
and so this latter does not exist.  You need to check for
_HAVE_ARCH_COPY_AND_CSUM_FROM_USER.

I have reverted that commit for today.

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

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2015-07-29  7:03 Stephen Rothwell
@ 2015-07-29  7:08 ` Guenter Roeck
  0 siblings, 0 replies; 330+ messages in thread
From: Guenter Roeck @ 2015-07-29  7:08 UTC (permalink / raw)
  To: Stephen Rothwell, Andrew Morton; +Cc: linux-next, linux-kernel

On 07/29/2015 12:03 AM, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm-current tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> kernel/watchdog.c:654:6: error: redefinition of 'watchdog_nmi_enable_all'
>   void watchdog_nmi_enable_all(void) {}
>        ^
> In file included from kernel/watchdog.c:16:0:
> include/linux/nmi.h:34:20: note: previous definition of 'watchdog_nmi_enable_all' was here
>   static inline void watchdog_nmi_enable_all(void) {}
>                      ^
> kernel/watchdog.c:655:6: error: redefinition of 'watchdog_nmi_disable_all'
>   void watchdog_nmi_disable_all(void) {}
>        ^
> In file included from kernel/watchdog.c:16:0:
> include/linux/nmi.h:33:20: note: previous definition of 'watchdog_nmi_disable_all' was here
>   static inline void watchdog_nmi_disable_all(void) {}
>                      ^
>
> Caused by commit
>
>    7e6e3bfa2820 ("kernel/watchdog: move NMI function header declarations from watchdog.h to nmi.h")
>
> I have reverted that commit for today.
>


v2 with a fix submitted already, after the zero day build bots alerted me.

Sorry for the trouble; I didn't expect that there would be two sets of dummy functions.
No excuse, of course :-(.

Guenter

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

* linux-next: build failure after merge of the akpm-current tree
@ 2015-07-29  7:03 Stephen Rothwell
  2015-07-29  7:08 ` Guenter Roeck
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2015-07-29  7:03 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Guenter Roeck

Hi Andrew,

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

kernel/watchdog.c:654:6: error: redefinition of 'watchdog_nmi_enable_all'
 void watchdog_nmi_enable_all(void) {}
      ^
In file included from kernel/watchdog.c:16:0:
include/linux/nmi.h:34:20: note: previous definition of 'watchdog_nmi_enable_all' was here
 static inline void watchdog_nmi_enable_all(void) {}
                    ^
kernel/watchdog.c:655:6: error: redefinition of 'watchdog_nmi_disable_all'
 void watchdog_nmi_disable_all(void) {}
      ^
In file included from kernel/watchdog.c:16:0:
include/linux/nmi.h:33:20: note: previous definition of 'watchdog_nmi_disable_all' was here
 static inline void watchdog_nmi_disable_all(void) {}
                    ^

Caused by commit

  7e6e3bfa2820 ("kernel/watchdog: move NMI function header declarations from watchdog.h to nmi.h")

I have reverted that commit for today.

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

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2015-07-28 18:14                 ` Davidlohr Bueso
@ 2015-07-28 18:32                   ` josh
  0 siblings, 0 replies; 330+ messages in thread
From: josh @ 2015-07-28 18:32 UTC (permalink / raw)
  To: Davidlohr Bueso
  Cc: Andrew Morton, Paul E. McKenney, Stephen Rothwell, linux-next,
	linux-kernel

On Tue, Jul 28, 2015 at 11:14:40AM -0700, Davidlohr Bueso wrote:
> On Mon, 2015-07-27 at 13:31 -0700, josh@joshtriplett.org wrote:
> > That sounds interesting!  mmap_sem is definitely a performance
> > bottleneck.  How do you handle writes versus reads?
> 
> The idea is to make vmas srcu aware, such that their lookups in the
> vmacache are lockless and can survive the entire fault path, among
> others we have ->vm_file. We simply handle cases when the
> vma/page-tables have changed between when the lookup was done and when
> we grab the pte lock with mmap_sem. These invalidations are a pain,
> albeit non fatal in some cases.

SOunds promising.

> > > Yes, you can argue that they're not published all you want,
> > > but I'm talking beyond my specific use case. Linux VM is known to scale,
> > > why should we hide a core scalability tool from it?
> > 
> > In the case of mmap_sem, does it help at all if tiny kernels were 1)
> > non-preemptible and 2) non-SMP?  Tiny kernels don't necessarily care
> > about scaling.
> 
> Yes, I believe it would! I actually assumed tiny kernels were already
> UP. I don't think it makes much sense to have it at that level. Same
> with preemption.

OK.  So, would you consider making it possible to compile out SRCU in
that specific case, while depending on SRCU if either SMP or PREEMPT?
Because that's also the case that allows tiny RCU rather than full RCU.

- Josh Triplett

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2015-07-27 20:31               ` josh
@ 2015-07-28 18:14                 ` Davidlohr Bueso
  2015-07-28 18:32                   ` josh
  0 siblings, 1 reply; 330+ messages in thread
From: Davidlohr Bueso @ 2015-07-28 18:14 UTC (permalink / raw)
  To: josh
  Cc: Andrew Morton, Paul E. McKenney, Stephen Rothwell, linux-next,
	linux-kernel

On Mon, 2015-07-27 at 13:31 -0700, josh@joshtriplett.org wrote:
> That sounds interesting!  mmap_sem is definitely a performance
> bottleneck.  How do you handle writes versus reads?

The idea is to make vmas srcu aware, such that their lookups in the
vmacache are lockless and can survive the entire fault path, among
others we have ->vm_file. We simply handle cases when the
vma/page-tables have changed between when the lookup was done and when
we grab the pte lock with mmap_sem. These invalidations are a pain,
albeit non fatal in some cases.

> 
> > Yes, you can argue that they're not published all you want,
> > but I'm talking beyond my specific use case. Linux VM is known to scale,
> > why should we hide a core scalability tool from it?
> 
> In the case of mmap_sem, does it help at all if tiny kernels were 1)
> non-preemptible and 2) non-SMP?  Tiny kernels don't necessarily care
> about scaling.

Yes, I believe it would! I actually assumed tiny kernels were already
UP. I don't think it makes much sense to have it at that level. Same
with preemption.

Thanks,
Davidlohr

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2015-07-27 20:31               ` Andrew Morton
@ 2015-07-27 22:10                 ` Josh Triplett
  0 siblings, 0 replies; 330+ messages in thread
From: Josh Triplett @ 2015-07-27 22:10 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Davidlohr Bueso, Paul E. McKenney, Stephen Rothwell, linux-next,
	linux-kernel

On Mon, Jul 27, 2015 at 01:31:33PM -0700, Andrew Morton wrote:
> On Mon, 27 Jul 2015 13:27:58 -0700 josh@joshtriplett.org wrote:
> 
> > I agree with that.  I'm wondering if, rather than making the
> > SRCU-ification optional, shrinkers themselves could just be optional.
> > Unless I'm badly misunderstanding what shrinkers do, they seem like a
> > perfect example of something that could be omitted with little to no
> > impact.  (Stub them out, make them never called, and if you run out of
> > memory just be unhappy.  Ditto for the oom-killer, which really ought to
> > be optional.)
> 
> The shrinkers do important stuff ;) "find /" will consume large amounts
> of memory for inode and dentry caches.  The shrinkers are how we free
> that up again.

*Ah*, I see.  I misunderstood their purpose, and I didn't realize that
was one of the cases they covered.  While that might be possible to
reduce, it doesn't sound like it can go away entirely. :)

- Josh Triplett

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2015-07-27 20:27             ` josh
@ 2015-07-27 20:31               ` Andrew Morton
  2015-07-27 22:10                 ` Josh Triplett
  0 siblings, 1 reply; 330+ messages in thread
From: Andrew Morton @ 2015-07-27 20:31 UTC (permalink / raw)
  To: josh
  Cc: Davidlohr Bueso, Paul E. McKenney, Stephen Rothwell, linux-next,
	linux-kernel

On Mon, 27 Jul 2015 13:27:58 -0700 josh@joshtriplett.org wrote:

> I agree with that.  I'm wondering if, rather than making the
> SRCU-ification optional, shrinkers themselves could just be optional.
> Unless I'm badly misunderstanding what shrinkers do, they seem like a
> perfect example of something that could be omitted with little to no
> impact.  (Stub them out, make them never called, and if you run out of
> memory just be unhappy.  Ditto for the oom-killer, which really ought to
> be optional.)

The shrinkers do important stuff ;) "find /" will consume large amounts
of memory for inode and dentry caches.  The shrinkers are how we free
that up again.

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2015-07-27 20:20             ` Davidlohr Bueso
@ 2015-07-27 20:31               ` josh
  2015-07-28 18:14                 ` Davidlohr Bueso
  0 siblings, 1 reply; 330+ messages in thread
From: josh @ 2015-07-27 20:31 UTC (permalink / raw)
  To: Davidlohr Bueso
  Cc: Andrew Morton, Paul E. McKenney, Stephen Rothwell, linux-next,
	linux-kernel

On Mon, Jul 27, 2015 at 01:20:02PM -0700, Davidlohr Bueso wrote:
> On Mon, 2015-07-27 at 13:03 -0700, Andrew Morton wrote:
> > On Sat, 25 Jul 2015 15:35:24 -0700 Josh Triplett <josh@joshtriplett.org> wrote:
> > 
> > > > Some mm functionality might very possibly rely on srcu in the future if
> > > > we expect any chances of scaling, ie: faults. So I'd rather not take a
> > > > short term solution here, as we'll probably be discussing this again
> > > > otherwise.
> > > 
> > > What other mm functionality plans to use SRCU?
> 
> Right now I have (unpublished) patches that use srcu as a way to avoid
> mmap_sem when faulting across the entire path. Previous alternatives
> also use it, as ie, can involve IO and lots of other sleeping
> operations.

That sounds interesting!  mmap_sem is definitely a performance
bottleneck.  How do you handle writes versus reads?

> Yes, you can argue that they're not published all you want,
> but I'm talking beyond my specific use case. Linux VM is known to scale,
> why should we hide a core scalability tool from it?

In the case of mmap_sem, does it help at all if tiny kernels were 1)
non-preemptible and 2) non-SMP?  Tiny kernels don't necessarily care
about scaling.

> > > Among other things, no-mmu builds might still be able to omit it.
> > 
> > Yup.
> 
> Makes sense.

Thanks.

- Josh Triplett

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2015-07-27 20:03           ` Andrew Morton
  2015-07-27 20:20             ` Davidlohr Bueso
@ 2015-07-27 20:27             ` josh
  2015-07-27 20:31               ` Andrew Morton
  1 sibling, 1 reply; 330+ messages in thread
From: josh @ 2015-07-27 20:27 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Davidlohr Bueso, Paul E. McKenney, Stephen Rothwell, linux-next,
	linux-kernel

On Mon, Jul 27, 2015 at 01:03:12PM -0700, Andrew Morton wrote:
> On Sat, 25 Jul 2015 15:35:24 -0700 Josh Triplett <josh@joshtriplett.org> wrote:
> 
> > > Some mm functionality might very possibly rely on srcu in the future if
> > > we expect any chances of scaling, ie: faults. So I'd rather not take a
> > > short term solution here, as we'll probably be discussing this again
> > > otherwise.
> > 
> > What other mm functionality plans to use SRCU?
> > 
> > Among other things, no-mmu builds might still be able to omit it.
> 
> Yup.
> 
> It's pretty trivial to make the shrinker srcuification be a
> Kconfigurable thing.  A few little helper functions and we're done. 
> That way, non-SMP kernels can use the plain old rwsem if so desired.
> 
> otoh it's better to use the same mechanism on all kernels for reasons
> of testing coverage, maintenance cost, etc.

I agree with that.  I'm wondering if, rather than making the
SRCU-ification optional, shrinkers themselves could just be optional.
Unless I'm badly misunderstanding what shrinkers do, they seem like a
perfect example of something that could be omitted with little to no
impact.  (Stub them out, make them never called, and if you run out of
memory just be unhappy.  Ditto for the oom-killer, which really ought to
be optional.)

- Josh Triplett

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2015-07-27 20:03           ` Andrew Morton
@ 2015-07-27 20:20             ` Davidlohr Bueso
  2015-07-27 20:31               ` josh
  2015-07-27 20:27             ` josh
  1 sibling, 1 reply; 330+ messages in thread
From: Davidlohr Bueso @ 2015-07-27 20:20 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Josh Triplett, Paul E. McKenney, Stephen Rothwell, linux-next,
	linux-kernel

On Mon, 2015-07-27 at 13:03 -0700, Andrew Morton wrote:
> On Sat, 25 Jul 2015 15:35:24 -0700 Josh Triplett <josh@joshtriplett.org> wrote:
> 
> > > Some mm functionality might very possibly rely on srcu in the future if
> > > we expect any chances of scaling, ie: faults. So I'd rather not take a
> > > short term solution here, as we'll probably be discussing this again
> > > otherwise.
> > 
> > What other mm functionality plans to use SRCU?

Right now I have (unpublished) patches that use srcu as a way to avoid
mmap_sem when faulting across the entire path. Previous alternatives
also use it, as ie, can involve IO and lots of other sleeping
operations. Yes, you can argue that they're not published all you want,
but I'm talking beyond my specific use case. Linux VM is known to scale,
why should we hide a core scalability tool from it?

> > Among other things, no-mmu builds might still be able to omit it.
> 
> Yup.

Makes sense.

> 
> It's pretty trivial to make the shrinker srcuification be a
> Kconfigurable thing.  A few little helper functions and we're done. 
> That way, non-SMP kernels can use the plain old rwsem if so desired.
> 
> otoh it's better to use the same mechanism on all kernels for reasons
> of testing coverage, maintenance cost, etc.
> 
> The mm-srcu-ify-shrinkers.patch changelog is suspiciously lacking in
> evidence-of-benefit.  We could just drop it?

That's up to you, but I feel we should have srcu available in mm.
Dropping this particular patch is only a band-aid, imo.

Thanks,
Davidlohr

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2015-07-25 22:35         ` Josh Triplett
@ 2015-07-27 20:03           ` Andrew Morton
  2015-07-27 20:20             ` Davidlohr Bueso
  2015-07-27 20:27             ` josh
  0 siblings, 2 replies; 330+ messages in thread
From: Andrew Morton @ 2015-07-27 20:03 UTC (permalink / raw)
  To: Josh Triplett
  Cc: Davidlohr Bueso, Paul E. McKenney, Stephen Rothwell, linux-next,
	linux-kernel

On Sat, 25 Jul 2015 15:35:24 -0700 Josh Triplett <josh@joshtriplett.org> wrote:

> > Some mm functionality might very possibly rely on srcu in the future if
> > we expect any chances of scaling, ie: faults. So I'd rather not take a
> > short term solution here, as we'll probably be discussing this again
> > otherwise.
> 
> What other mm functionality plans to use SRCU?
> 
> Among other things, no-mmu builds might still be able to omit it.

Yup.

It's pretty trivial to make the shrinker srcuification be a
Kconfigurable thing.  A few little helper functions and we're done. 
That way, non-SMP kernels can use the plain old rwsem if so desired.

otoh it's better to use the same mechanism on all kernels for reasons
of testing coverage, maintenance cost, etc.

The mm-srcu-ify-shrinkers.patch changelog is suspiciously lacking in
evidence-of-benefit.  We could just drop it?

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2015-07-25 21:24       ` Davidlohr Bueso
@ 2015-07-25 22:35         ` Josh Triplett
  2015-07-27 20:03           ` Andrew Morton
  0 siblings, 1 reply; 330+ messages in thread
From: Josh Triplett @ 2015-07-25 22:35 UTC (permalink / raw)
  To: Davidlohr Bueso
  Cc: Paul E. McKenney, Stephen Rothwell, Andrew Morton, linux-next,
	linux-kernel

On Sat, Jul 25, 2015 at 02:24:02PM -0700, Davidlohr Bueso wrote:
> On Sat, 2015-07-25 at 12:47 -0700, Josh Triplett wrote:
> > I certainly agree that it doesn't make sense to make all architectures
> > select SRCU, if an unremovable core kernel feature uses SRCU.  If
> > possible, I'd really like to avoid seeing SRCU become mandatory again,
> > though.
> 
> I find it very strange that srcu is not taken for granted like rcu is,
> or even regular locking primitives. How much overhead does srcu add?

About 2k.  (For scale, note that a tinyconfig kernel is currently on the
order of 700-800k, so that's an appreciable fraction of the kernel.)

> > Is there any chance at all of the shrinker mechanism becoming optional?
> > At first glance, it seems reasonably separate from the rest of mm, in
> > that if it didn't exist and shrinking didn't happen, the rest of mm
> > still works.  If that happened, MM_SHRINKER could select SRCU.
> 
> Some mm functionality might very possibly rely on srcu in the future if
> we expect any chances of scaling, ie: faults. So I'd rather not take a
> short term solution here, as we'll probably be discussing this again
> otherwise.

What other mm functionality plans to use SRCU?

Among other things, no-mmu builds might still be able to omit it.

> > If that's not possible, then for the moment, I'd suggest making a hidden
> > symbol MM_SHRINKER that's always y and does "select SRCU", to preserve
> > SRCU's modularity for the moment while not forcing every architecture to
> > select it.
> 
> This is _very_ hacking. While tinyfication has its uses and
> applications, I'd rather not have it in the way of normal kernels.

Thinking about it further, the better alternative if SRCU can't be kept
optional CONFIG_SRCU "default y" and hidden, so that it doesn't get
disabled by tinyconfig.

- Josh Triplett

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2015-07-25 19:47     ` Josh Triplett
@ 2015-07-25 21:24       ` Davidlohr Bueso
  2015-07-25 22:35         ` Josh Triplett
  0 siblings, 1 reply; 330+ messages in thread
From: Davidlohr Bueso @ 2015-07-25 21:24 UTC (permalink / raw)
  To: Josh Triplett
  Cc: Paul E. McKenney, Stephen Rothwell, Andrew Morton, linux-next,
	linux-kernel

On Sat, 2015-07-25 at 12:47 -0700, Josh Triplett wrote:
> I certainly agree that it doesn't make sense to make all architectures
> select SRCU, if an unremovable core kernel feature uses SRCU.  If
> possible, I'd really like to avoid seeing SRCU become mandatory again,
> though.

I find it very strange that srcu is not taken for granted like rcu is,
or even regular locking primitives. How much overhead does srcu add?

> Is there any chance at all of the shrinker mechanism becoming optional?
> At first glance, it seems reasonably separate from the rest of mm, in
> that if it didn't exist and shrinking didn't happen, the rest of mm
> still works.  If that happened, MM_SHRINKER could select SRCU.

Some mm functionality might very possibly rely on srcu in the future if
we expect any chances of scaling, ie: faults. So I'd rather not take a
short term solution here, as we'll probably be discussing this again
otherwise.

> If that's not possible, then for the moment, I'd suggest making a hidden
> symbol MM_SHRINKER that's always y and does "select SRCU", to preserve
> SRCU's modularity for the moment while not forcing every architecture to
> select it.

This is _very_ hacking. While tinyfication has its uses and
applications, I'd rather not have it in the way of normal kernels.

Thanks,
Davidlohr

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2015-07-24 23:09   ` Paul E. McKenney
@ 2015-07-25 19:47     ` Josh Triplett
  2015-07-25 21:24       ` Davidlohr Bueso
  0 siblings, 1 reply; 330+ messages in thread
From: Josh Triplett @ 2015-07-25 19:47 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: Davidlohr Bueso, Stephen Rothwell, Andrew Morton, linux-next,
	linux-kernel

On Fri, Jul 24, 2015 at 04:09:02PM -0700, Paul E. McKenney wrote:
> On Fri, Jul 24, 2015 at 01:16:05PM -0700, Davidlohr Bueso wrote:
> > On Fri, 2015-07-24 at 15:33 +1000, Stephen Rothwell wrote:
> > > Hi Andrew,
> > > 
> > > After merging the akpm-current tree, today's linux-next build (powerpc
> > > allnoconfig) failed like this:
> > > 
> > > mm/built-in.o: In function `shrink_slab.part.73.constprop.83':
> > > vmscan.c:(.text+0xf760): undefined reference to `__srcu_read_lock'
> > > vmscan.c:(.text+0xf924): undefined reference to `__srcu_read_unlock'
> > > mm/built-in.o: In function `unregister_shrinker':
> > > (.text+0xfa60): undefined reference to `synchronize_srcu'
> > > mm/built-in.o:(.data+0x1e8): undefined reference to `process_srcu'
> > > 
> > > Caused by commit
> > > 
> > >   dab937da82f9 ("mm: srcu-ify shrinkers")
> > > 
> > > I have reverted that commit for today.
> > 
> > Adding paulmck.
> > 
> > I'm not entirely sure what is the fix here. Paul G also reported it
> > failing for arm. I was able to reproduce with powerpc, and the following
> > fixes the issue, but I doubt it is the correct way to address this. The
> > idea was based on how we do it for x86.
> > 
> > Also, having SRCU in mm is, lets say, more than convenient, beyond
> > MMU_NOTIFIERS which explicitly selects SRCU.
> > 
> > Paul?
> 
> SRCU was made optional as part of the kernel tinification project,
> so adding Josh on CC.  The hope would be that the feature needing SRCU
> could add the "select" rather than having major architectures doing so.
> 
> I guess if SRCU is needed everywhere, it is needed everywhere, but...

I certainly agree that it doesn't make sense to make all architectures
select SRCU, if an unremovable core kernel feature uses SRCU.  If
possible, I'd really like to avoid seeing SRCU become mandatory again,
though.

Is there any chance at all of the shrinker mechanism becoming optional?
At first glance, it seems reasonably separate from the rest of mm, in
that if it didn't exist and shrinking didn't happen, the rest of mm
still works.  If that happened, MM_SHRINKER could select SRCU.

If that's not possible, then for the moment, I'd suggest making a hidden
symbol MM_SHRINKER that's always y and does "select SRCU", to preserve
SRCU's modularity for the moment while not forcing every architecture to
select it.

- Josh Triplett

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2015-07-24 20:16 ` Davidlohr Bueso
@ 2015-07-24 23:09   ` Paul E. McKenney
  2015-07-25 19:47     ` Josh Triplett
  0 siblings, 1 reply; 330+ messages in thread
From: Paul E. McKenney @ 2015-07-24 23:09 UTC (permalink / raw)
  To: Davidlohr Bueso
  Cc: Stephen Rothwell, Andrew Morton, linux-next, linux-kernel, josh

On Fri, Jul 24, 2015 at 01:16:05PM -0700, Davidlohr Bueso wrote:
> On Fri, 2015-07-24 at 15:33 +1000, Stephen Rothwell wrote:
> > Hi Andrew,
> > 
> > After merging the akpm-current tree, today's linux-next build (powerpc
> > allnoconfig) failed like this:
> > 
> > mm/built-in.o: In function `shrink_slab.part.73.constprop.83':
> > vmscan.c:(.text+0xf760): undefined reference to `__srcu_read_lock'
> > vmscan.c:(.text+0xf924): undefined reference to `__srcu_read_unlock'
> > mm/built-in.o: In function `unregister_shrinker':
> > (.text+0xfa60): undefined reference to `synchronize_srcu'
> > mm/built-in.o:(.data+0x1e8): undefined reference to `process_srcu'
> > 
> > Caused by commit
> > 
> >   dab937da82f9 ("mm: srcu-ify shrinkers")
> > 
> > I have reverted that commit for today.
> 
> Adding paulmck.
> 
> I'm not entirely sure what is the fix here. Paul G also reported it
> failing for arm. I was able to reproduce with powerpc, and the following
> fixes the issue, but I doubt it is the correct way to address this. The
> idea was based on how we do it for x86.
> 
> Also, having SRCU in mm is, lets say, more than convenient, beyond
> MMU_NOTIFIERS which explicitly selects SRCU.
> 
> Paul?

SRCU was made optional as part of the kernel tinification project,
so adding Josh on CC.  The hope would be that the feature needing SRCU
could add the "select" rather than having major architectures doing so.

I guess if SRCU is needed everywhere, it is needed everywhere, but...

							Thanx, Paul

> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 5ef2711..774207e 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -124,6 +124,7 @@ config PPC
>         select GENERIC_IRQ_SHOW
>         select GENERIC_IRQ_SHOW_LEVEL
>         select IRQ_FORCED_THREADING
> +       select SRCU
>         select HAVE_RCU_TABLE_FREE if SMP
>         select HAVE_SYSCALL_TRACEPOINTS
>         select HAVE_BPF_JIT
> 
> Thanks,
> Davidlohr
> 

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2015-07-24  5:33 Stephen Rothwell
@ 2015-07-24 20:16 ` Davidlohr Bueso
  2015-07-24 23:09   ` Paul E. McKenney
  0 siblings, 1 reply; 330+ messages in thread
From: Davidlohr Bueso @ 2015-07-24 20:16 UTC (permalink / raw)
  To: Stephen Rothwell, Paul E. McKenney
  Cc: Andrew Morton, linux-next, linux-kernel

On Fri, 2015-07-24 at 15:33 +1000, Stephen Rothwell wrote:
> Hi Andrew,
> 
> After merging the akpm-current tree, today's linux-next build (powerpc
> allnoconfig) failed like this:
> 
> mm/built-in.o: In function `shrink_slab.part.73.constprop.83':
> vmscan.c:(.text+0xf760): undefined reference to `__srcu_read_lock'
> vmscan.c:(.text+0xf924): undefined reference to `__srcu_read_unlock'
> mm/built-in.o: In function `unregister_shrinker':
> (.text+0xfa60): undefined reference to `synchronize_srcu'
> mm/built-in.o:(.data+0x1e8): undefined reference to `process_srcu'
> 
> Caused by commit
> 
>   dab937da82f9 ("mm: srcu-ify shrinkers")
> 
> I have reverted that commit for today.

Adding paulmck.

I'm not entirely sure what is the fix here. Paul G also reported it
failing for arm. I was able to reproduce with powerpc, and the following
fixes the issue, but I doubt it is the correct way to address this. The
idea was based on how we do it for x86.

Also, having SRCU in mm is, lets say, more than convenient, beyond
MMU_NOTIFIERS which explicitly selects SRCU.

Paul?

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 5ef2711..774207e 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -124,6 +124,7 @@ config PPC
        select GENERIC_IRQ_SHOW
        select GENERIC_IRQ_SHOW_LEVEL
        select IRQ_FORCED_THREADING
+       select SRCU
        select HAVE_RCU_TABLE_FREE if SMP
        select HAVE_SYSCALL_TRACEPOINTS
        select HAVE_BPF_JIT

Thanks,
Davidlohr

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

* linux-next: build failure after merge of the akpm-current tree
@ 2015-07-24  5:50 Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2015-07-24  5:50 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Mike Kravetz

Hi Andrew,

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

fs/hugetlbfs/inode.c: In function 'hugetlbfs_fallocate':
fs/hugetlbfs/inode.c:578:13: error: 'struct vm_area_struct' has no member named 'vm_policy'
   pseudo_vma.vm_policy =
             ^
fs/hugetlbfs/inode.c:579:4: error: implicit declaration of function 'mpol_shared_policy_lookup' [-Werror=implicit-function-declaration]
    mpol_shared_policy_lookup(&HUGETLBFS_I(inode)->policy,
    ^
fs/hugetlbfs/inode.c:595:28: error: 'struct vm_area_struct' has no member named 'vm_policy'
    mpol_cond_put(pseudo_vma.vm_policy);
                            ^
fs/hugetlbfs/inode.c:601:27: error: 'struct vm_area_struct' has no member named 'vm_policy'
   mpol_cond_put(pseudo_vma.vm_policy);
                           ^
Caused by commit

  6b2ac4455b3d ("hugetlbfs: add hugetlbfs_fallocate()")

vm_policy and mpol_shared_policy_lookup are only defined when CONFIG_NUMA
is set.

I have reverted that commit for today.

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

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

* linux-next: build failure after merge of the akpm-current tree
@ 2015-07-24  5:33 Stephen Rothwell
  2015-07-24 20:16 ` Davidlohr Bueso
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2015-07-24  5:33 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Davidlohr Bueso

Hi Andrew,

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

mm/built-in.o: In function `shrink_slab.part.73.constprop.83':
vmscan.c:(.text+0xf760): undefined reference to `__srcu_read_lock'
vmscan.c:(.text+0xf924): undefined reference to `__srcu_read_unlock'
mm/built-in.o: In function `unregister_shrinker':
(.text+0xfa60): undefined reference to `synchronize_srcu'
mm/built-in.o:(.data+0x1e8): undefined reference to `process_srcu'

Caused by commit

  dab937da82f9 ("mm: srcu-ify shrinkers")

I have reverted that commit for today.

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

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2015-07-16 21:52   ` Stephen Rothwell
@ 2015-07-20 14:57     ` Eric B Munson
  0 siblings, 0 replies; 330+ messages in thread
From: Eric B Munson @ 2015-07-20 14:57 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Andrew Morton, linux-next, linux-kernel

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

On Fri, 17 Jul 2015, Stephen Rothwell wrote:

> Hi Eric,
> 
> On Thu, 16 Jul 2015 10:36:59 -0400 Eric B Munson <emunson@akamai.com> wrote:
> >
> > > From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Thu, 16 Jul
> > > 2015 14:58:53 +1000 Subject: [PATCH] mm: mlock: fix for add new
> > > mlock, munlock, and munlockall system calls
> > > 
> > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- 
> > > arch/arm/include/asm/unistd.h | 2 +- arch/arm/kernel/calls.S
> > > | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/arch/arm/include/asm/unistd.h
> > > b/arch/arm/include/asm/unistd.h index 32640c431a08..2516c09d65d7
> > > 100644 --- a/arch/arm/include/asm/unistd.h +++
> > > b/arch/arm/include/asm/unistd.h @@ -19,7 +19,7 @@ * This may need
> > > to be greater than __NR_last_syscall+1 in order to * account for
> > > the padding in the syscall table */ -#define __NR_syscalls  (388) 
> > > +#define __NR_syscalls  (392)
> > 
> > IIUC, this should be 391.
> 
> Read the comment above - it has to be 392 for padding.  (I actually
> tried 391 and it fails to build.)

I saw the comment but it wasn't clear to me what that padding value
should be (does __NR_syscalls need to be even, %4, %8, etc).  Is there
somewhere that I missed that describes what the padding needs to be and
when it should be present?

> 
> BTW, what mail client are you using - it really made a mess :-(
> 

That was thunderbird, which has started acting up on me, not sure why it
mangled everything.  Back to mutt now that I have my laptop back.
Hopefully this one is in better shape.


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

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2015-07-16 22:08 Stephen Rothwell
@ 2015-07-16 22:17 ` Oleg Nesterov
  0 siblings, 0 replies; 330+ messages in thread
From: Oleg Nesterov @ 2015-07-16 22:17 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Andrew Morton, linux-next, linux-kernel

On 07/17, Stephen Rothwell wrote:
>
> Hi Andrew,
>
> After merging the akpm-current tree, today's linux-next build (lots with
> CONFIG_MMU not set) failed like this:
>
> fs/built-in.o:(.rodata+0x1060): undefined reference to `filemap_page_mkwrite'
>
> Caused by commit
>
>   fb416a02f75c ("mm: move ->mremap() from file_operations to vm_operations_struct").

Yes, please see

	[mmotm:master 140/321] fs/built-in.o:undefined reference to `filemap_page_mkwrite'
	http://marc.info/?t=143700878100001

sorry. I'll send the fix soon.

> filemap_page_mkwrite only exists when CONFIG_MMU is set.

Yes, and I still think CONFGI_AIO makes no sense in this case.

Oleg.

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

* linux-next: build failure after merge of the akpm-current tree
@ 2015-07-16 22:08 Stephen Rothwell
  2015-07-16 22:17 ` Oleg Nesterov
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2015-07-16 22:08 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Oleg Nesterov

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (lots with
CONFIG_MMU not set) failed like this:

fs/built-in.o:(.rodata+0x1060): undefined reference to `filemap_page_mkwrite'

Caused by commit

  fb416a02f75c ("mm: move ->mremap() from file_operations to vm_operations_struct").

filemap_page_mkwrite only exists when CONFIG_MMU is set.

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

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2015-07-16 14:36 ` Eric B Munson
  2015-07-16 18:59   ` Andrew Morton
@ 2015-07-16 21:52   ` Stephen Rothwell
  2015-07-20 14:57     ` Eric B Munson
  1 sibling, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2015-07-16 21:52 UTC (permalink / raw)
  To: Eric B Munson; +Cc: Andrew Morton, linux-next, linux-kernel

Hi Eric,

On Thu, 16 Jul 2015 10:36:59 -0400 Eric B Munson <emunson@akamai.com> wrote:
>
> > From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Thu, 16 Jul
> > 2015 14:58:53 +1000 Subject: [PATCH] mm: mlock: fix for add new
> > mlock, munlock, and munlockall system calls
> > 
> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- 
> > arch/arm/include/asm/unistd.h | 2 +- arch/arm/kernel/calls.S
> > | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/arm/include/asm/unistd.h
> > b/arch/arm/include/asm/unistd.h index 32640c431a08..2516c09d65d7
> > 100644 --- a/arch/arm/include/asm/unistd.h +++
> > b/arch/arm/include/asm/unistd.h @@ -19,7 +19,7 @@ * This may need
> > to be greater than __NR_last_syscall+1 in order to * account for
> > the padding in the syscall table */ -#define __NR_syscalls  (388) 
> > +#define __NR_syscalls  (392)
> 
> IIUC, this should be 391.

Read the comment above - it has to be 392 for padding.  (I actually
tried 391 and it fails to build.)

BTW, what mail client are you using - it really made a mess :-(

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

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2015-07-16 14:36 ` Eric B Munson
@ 2015-07-16 18:59   ` Andrew Morton
  2015-07-16 21:52   ` Stephen Rothwell
  1 sibling, 0 replies; 330+ messages in thread
From: Andrew Morton @ 2015-07-16 18:59 UTC (permalink / raw)
  To: Eric B Munson; +Cc: Stephen Rothwell, linux-next, linux-kernel

On Thu, 16 Jul 2015 10:36:59 -0400 Eric B Munson <emunson@akamai.com> wrote:

> I have an updated set that addresses the build failures by completing
> the system call additions.  It does not yet address Jon's concern
> about applying MLOCK_ONFAULT to a region with pages that are already
> present (this is in progress).
> 
> Do you want the updated syscalls now or wait until the whole thing is
> ready?

When it's ready, please.

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2015-07-16  5:20 Stephen Rothwell
@ 2015-07-16 14:36 ` Eric B Munson
  2015-07-16 18:59   ` Andrew Morton
  2015-07-16 21:52   ` Stephen Rothwell
  0 siblings, 2 replies; 330+ messages in thread
From: Eric B Munson @ 2015-07-16 14:36 UTC (permalink / raw)
  To: Stephen Rothwell, Andrew Morton; +Cc: linux-next, linux-kernel

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

On 07/16/2015 01:20 AM, Stephen Rothwell wrote:
> Hi Andrew,
> 
> After merging the akpm-current tree, today's linux-next build (arm 
> multi_v7_defconfig) failed like this:
> 
> arch/arm/kernel/entry-common.S: Assembler messages: 
> arch/arm/kernel/entry-common.S:108: Error: __NR_syscalls is not
> equal to the size of the syscall table
> 
> Caused by commit
> 
> d221fc1f0f25 ("mm: mlock: add new mlock, munlock, and munlockall
> system calls")
> 
> I have added the following fix patch for today:

Andrew,

I have an updated set that addresses the build failures by completing
the system call additions.  It does not yet address Jon's concern
about applying MLOCK_ONFAULT to a region with pages that are already
present (this is in progress).

Do you want the updated syscalls now or wait until the whole thing is
ready?

> 
> From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Thu, 16 Jul
> 2015 14:58:53 +1000 Subject: [PATCH] mm: mlock: fix for add new
> mlock, munlock, and munlockall system calls
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- 
> arch/arm/include/asm/unistd.h | 2 +- arch/arm/kernel/calls.S
> | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/include/asm/unistd.h
> b/arch/arm/include/asm/unistd.h index 32640c431a08..2516c09d65d7
> 100644 --- a/arch/arm/include/asm/unistd.h +++
> b/arch/arm/include/asm/unistd.h @@ -19,7 +19,7 @@ * This may need
> to be greater than __NR_last_syscall+1 in order to * account for
> the padding in the syscall table */ -#define __NR_syscalls  (388) 
> +#define __NR_syscalls  (392)

IIUC, this should be 391.

> 
> /* * *NOTE*: This is a ghost syscall private to the kernel.  Only
> the diff --git a/arch/arm/kernel/calls.S b/arch/arm/kernel/calls.S 
> index 514e77b26414..88808221383b 100644 ---
> a/arch/arm/kernel/calls.S +++ b/arch/arm/kernel/calls.S @@ -399,7
> +399,7 @@ CALL(sys_execveat) CALL(sys_mlock2) CALL(sys_munlock2) 
> -/* 400 */	CALL(sys_munlockall2) +/* 390 */	CALL(sys_munlockall2) 
> #ifndef syscalls_counted .equ syscalls_padding, ((NR_syscalls + 3)
> & ~3) - NR_syscalls #define syscalls_counted
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJVp8GLAAoJELbVsDOpoOa9D7AQAIzPHDWeQwR5wDBBo1OyrY8N
vczsi8h9P4HlTfXH3jv6TYkcTdRRgLJN5ExIcFXUj3dRC+foYjLg+WvSszpJBuBT
ACc8jjuR+TdcDBSPrQ52QJiGwjKmQZ061HtWyCglveHl6fcAdgVq0/VLjjuEKGGj
uOFUNNjzWxCkGViOUzTdAsUsY/G6MlDMDERHUsdKkQYF4lofcaQB31L3EvcNBFHU
r9XIgzyiLDgJ22BgNs0tHBrv3JuQgrf3cEYIhYfwXj8JyrrCHo3IvcfkafGYCrIT
cTTPpnfTjPKWD2P14R4OAuLViB3GLGeKc//aSS3UZh3y0m1Bzw157BXGCQawqrUu
xRH+Ft0+gwcmI6Ez/trqu25NTq1KnOsot9XZFK2l3R0CYfYMwNOOUiNRk2+3PElk
gLu8nhGCF+f4OE7S5zQjcnnZ9rCAEprg/9ewMdRQXlT4719msDuQdzgequrzl55+
bQJQCPGIvyZhiP+Eh3LgvhJky/XY2xacs5FaHOgTYIeuHd794VQhncEbrbthMS3S
t94JjTAWssi7nHvau0ASZ3iR5R7iw0WJrvAARUiqkoZxMXQiOW5Tb3KQ+C9gp4KZ
l6w23L7MhdAMGrY5yLX1o+itet6o3nUksi4DK3qFNcr1gKVYwkXsEIkk6Bv3lRyx
rAFP155JAY6t3kyTso+I
=276b
-----END PGP SIGNATURE-----

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

* linux-next: build failure after merge of the akpm-current tree
@ 2015-07-16  5:32 Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2015-07-16  5:32 UTC (permalink / raw)
  To: Andrew Morton
  Cc: linux-next, linux-kernel, Frederic Weisbecker, Chris Metcalf,
	Thomas Gleixner

Hi Andrew,

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

ERROR: ".smpboot_register_percpu_thread_cpumask" [drivers/infiniband/hw/ehca/ib_ehca.ko] undefined!

Caused by commit

  2b07b4da35a9 ("smpboot: allow passing the cpumask on per-cpu thread registration")

I have added the following build faix for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 16 Jul 2015 15:30:05 +1000
Subject: [PATCH] smpboot: fix for allow passing the cpumask on per-cpu thread registration

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 kernel/smpboot.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/smpboot.c b/kernel/smpboot.c
index d99a41d25b0c..a818cbc73e14 100644
--- a/kernel/smpboot.c
+++ b/kernel/smpboot.c
@@ -308,7 +308,7 @@ out:
 	put_online_cpus();
 	return ret;
 }
-EXPORT_SYMBOL_GPL(smpboot_register_percpu_thread);
+EXPORT_SYMBOL_GPL(smpboot_register_percpu_thread_cpumask);
 
 /**
  * smpboot_unregister_percpu_thread - Unregister a per_cpu thread related to hotplug
-- 
2.1.4

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

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

* linux-next: build failure after merge of the akpm-current tree
@ 2015-07-16  5:20 Stephen Rothwell
  2015-07-16 14:36 ` Eric B Munson
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2015-07-16  5:20 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Eric B Munson

Hi Andrew,

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

arch/arm/kernel/entry-common.S: Assembler messages:
arch/arm/kernel/entry-common.S:108: Error: __NR_syscalls is not equal to the size of the syscall table

Caused by commit

  d221fc1f0f25 ("mm: mlock: add new mlock, munlock, and munlockall system calls")

I have added the following fix patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 16 Jul 2015 14:58:53 +1000
Subject: [PATCH] mm: mlock: fix for add new mlock, munlock, and munlockall system calls

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/arm/include/asm/unistd.h | 2 +-
 arch/arm/kernel/calls.S       | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/unistd.h b/arch/arm/include/asm/unistd.h
index 32640c431a08..2516c09d65d7 100644
--- a/arch/arm/include/asm/unistd.h
+++ b/arch/arm/include/asm/unistd.h
@@ -19,7 +19,7 @@
  * This may need to be greater than __NR_last_syscall+1 in order to
  * account for the padding in the syscall table
  */
-#define __NR_syscalls  (388)
+#define __NR_syscalls  (392)
 
 /*
  * *NOTE*: This is a ghost syscall private to the kernel.  Only the
diff --git a/arch/arm/kernel/calls.S b/arch/arm/kernel/calls.S
index 514e77b26414..88808221383b 100644
--- a/arch/arm/kernel/calls.S
+++ b/arch/arm/kernel/calls.S
@@ -399,7 +399,7 @@
 		CALL(sys_execveat)
 		CALL(sys_mlock2)
 		CALL(sys_munlock2)
-/* 400 */	CALL(sys_munlockall2)
+/* 390 */	CALL(sys_munlockall2)
 #ifndef syscalls_counted
 .equ syscalls_padding, ((NR_syscalls + 3) & ~3) - NR_syscalls
 #define syscalls_counted
-- 
2.1.4

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

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2015-05-25 14:03 ` Andrea Arcangeli
@ 2015-05-26 22:16   ` Andrew Morton
  0 siblings, 0 replies; 330+ messages in thread
From: Andrew Morton @ 2015-05-26 22:16 UTC (permalink / raw)
  To: Andrea Arcangeli; +Cc: Stephen Rothwell, linux-next, linux-kernel

On Mon, 25 May 2015 16:03:15 +0200 Andrea Arcangeli <aarcange@redhat.com> wrote:

> On Mon, May 25, 2015 at 09:18:01PM +1000, Stephen Rothwell wrote:
> > Hi Andrew,
> > 
> > After merging the akpm-current tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> > 
> > __NR_syscalls (364) is not one more than the last syscall (364)
> > 
> > Caused by commit d7766613717b ("userfaultfd: activate syscall").  (BTW,
> > I notice that this patch was not cc'd to any ppc maintainers :-()
> > 
> > I have added this fix patch for today:
> 
> So another option is to just drop the arch/powerpc part of the patch
> from -mm. It's up to you, there's no arch dependent code in the
> syscall though and the config option is not specific to x86 either. I
> enabled the syscall on powerpc in my tree to facilitate the testing so
> the patchset included that change to arch/powerpc, but it would be ok
> to enable the syscall only later upstream, after it has been tested.

Yes, it would be prudent to avoid enabling it until the feature has
been appropriately runtime tested on powerpc.  How's that
tools/testing/selftests/ test harness coming along ;)

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2015-05-25 11:18 Stephen Rothwell
@ 2015-05-25 14:03 ` Andrea Arcangeli
  2015-05-26 22:16   ` Andrew Morton
  0 siblings, 1 reply; 330+ messages in thread
From: Andrea Arcangeli @ 2015-05-25 14:03 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Andrew Morton, linux-next, linux-kernel

Hello,

On Mon, May 25, 2015 at 09:18:01PM +1000, Stephen Rothwell wrote:
> Hi Andrew,
> 
> After merging the akpm-current tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> __NR_syscalls (364) is not one more than the last syscall (364)
> 
> Caused by commit d7766613717b ("userfaultfd: activate syscall").  (BTW,
> I notice that this patch was not cc'd to any ppc maintainers :-()
> 
> I have added this fix patch for today:

So another option is to just drop the arch/powerpc part of the patch
from -mm. It's up to you, there's no arch dependent code in the
syscall though and the config option is not specific to x86 either. I
enabled the syscall on powerpc in my tree to facilitate the testing so
the patchset included that change to arch/powerpc, but it would be ok
to enable the syscall only later upstream, after it has been tested.

Thanks,
Andrea

> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 25 May 2015 21:13:40 +1000
> Subject: [PATCH] userfaultfd: activate syscall fix
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  arch/powerpc/include/asm/unistd.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/include/asm/unistd.h b/arch/powerpc/include/asm/unistd.h
> index f4f8b667d75b..4a055b6c2a64 100644
> --- a/arch/powerpc/include/asm/unistd.h
> +++ b/arch/powerpc/include/asm/unistd.h
> @@ -12,7 +12,7 @@
>  #include <uapi/asm/unistd.h>
>  
>  
> -#define __NR_syscalls		364
> +#define __NR_syscalls		365
>  
>  #define __NR__exit __NR_exit
>  #define NR_syscalls	__NR_syscalls
> -- 
> 2.1.4
> 
> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au

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

* linux-next: build failure after merge of the akpm-current tree
@ 2015-05-25 11:18 Stephen Rothwell
  2015-05-25 14:03 ` Andrea Arcangeli
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2015-05-25 11:18 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Andrea Arcangeli

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

Hi Andrew,

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

__NR_syscalls (364) is not one more than the last syscall (364)

Caused by commit d7766613717b ("userfaultfd: activate syscall").  (BTW,
I notice that this patch was not cc'd to any ppc maintainers :-()

I have added this fix patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 25 May 2015 21:13:40 +1000
Subject: [PATCH] userfaultfd: activate syscall fix

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/powerpc/include/asm/unistd.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/unistd.h b/arch/powerpc/include/asm/unistd.h
index f4f8b667d75b..4a055b6c2a64 100644
--- a/arch/powerpc/include/asm/unistd.h
+++ b/arch/powerpc/include/asm/unistd.h
@@ -12,7 +12,7 @@
 #include <uapi/asm/unistd.h>
 
 
-#define __NR_syscalls		364
+#define __NR_syscalls		365
 
 #define __NR__exit __NR_exit
 #define NR_syscalls	__NR_syscalls
-- 
2.1.4

-- 
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] 330+ messages in thread

* Re: linux-next: build failure after merge of the akpm-current tree
  2015-05-14  8:21 Stephen Rothwell
@ 2015-05-14 15:09 ` Aneesh Kumar K.V
  0 siblings, 0 replies; 330+ messages in thread
From: Aneesh Kumar K.V @ 2015-05-14 15:09 UTC (permalink / raw)
  To: Stephen Rothwell, Andrew Morton
  Cc: linux-next, linux-kernel, David Miller, Kirill A. Shutemov

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

> Hi Andrew,
>
> After merging the akpm-current tree, today's linux-next build (sparc
> defconfig) failed like this:
>
> In file included from arch/sparc/include/asm/pgtable_32.h:437:0,
>                  from arch/sparc/include/asm/pgtable.h:6,
>                  from include/linux/mm.h:53,
>                  from include/linux/ring_buffer.h:5,
>                  from include/linux/ftrace_event.h:5,
>                  from include/trace/syscall.h:6,
>                  from include/linux/syscalls.h:81,
>                  from init/initramfs.c:19:
> include/asm-generic/pgtable.h: In function 'pmdp_collapse_flush':
> include/asm-generic/pgtable.h:211:2: error: implicit declaration of function '__pmd' [-Werror=implicit-function-declaration]
>   return __pmd(0);
>   ^
> include/asm-generic/pgtable.h:211:2: error: incompatible types when returning type 'int' but 'pmd_t' was expected
>
> Caused by commit b0593c13d7f6 ("mm/thp: split out pmd collapse/flush
> into separate functions").
>
> sparc 32 has no __pmd().  I applied this temporary fix for today just
> to get it building:


The change in question is

diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
index 39f1d6a2b04d..9e200e55a52b 100644
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -189,6 +189,26 @@ extern void pmdp_splitting_flush(struct vm_area_struct *vma,
 				 unsigned long address, pmd_t *pmdp);
 #endif
 
+#ifndef pmdp_collapse_flush
+#define pmdp_collapse_flush pmdp_collapse_flush
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+static inline pmd_t pmdp_collapse_flush(struct vm_area_struct *vma,
+					unsigned long address,
+					pmd_t *pmdp)
+{
+	return pmdp_clear_flush(vma, address, pmdp);
+}
+#else
+static inline pmd_t pmdp_collapse_flush(struct vm_area_struct *vma,
+					unsigned long address,
+					pmd_t *pmdp)
+{
+	BUILD_BUG();
+	return __pmd(0);
+}
+#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
+#endif
+
 #ifndef __HAVE_ARCH_PGTABLE_DEPOSIT
 extern void pgtable_trans_huge_deposit(struct mm_struct *mm, pmd_t *pmdp,
 				       pgtable_t pgtable);


This also introduced warnings for frv and m68k.  May be we should drop
the #else part and let the build fail during linking ? ie, do

+#ifndef pmdp_collapse_flush
+#define pmdp_collapse_flush pmdp_collapse_flush
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+static inline pmd_t pmdp_collapse_flush(struct vm_area_struct *vma,
+					unsigned long address,
+					pmd_t *pmdp)
+{
+	return pmdp_clear_flush(vma, address, pmdp);
+}
+#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
+#endif


-aneesh

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

* linux-next: build failure after merge of the akpm-current tree
@ 2015-05-14  8:21 Stephen Rothwell
  2015-05-14 15:09 ` Aneesh Kumar K.V
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2015-05-14  8:21 UTC (permalink / raw)
  To: Andrew Morton
  Cc: linux-next, linux-kernel, David Miller, Aneesh Kumar K.V,
	Kirill A. Shutemov

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

Hi Andrew,

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

In file included from arch/sparc/include/asm/pgtable_32.h:437:0,
                 from arch/sparc/include/asm/pgtable.h:6,
                 from include/linux/mm.h:53,
                 from include/linux/ring_buffer.h:5,
                 from include/linux/ftrace_event.h:5,
                 from include/trace/syscall.h:6,
                 from include/linux/syscalls.h:81,
                 from init/initramfs.c:19:
include/asm-generic/pgtable.h: In function 'pmdp_collapse_flush':
include/asm-generic/pgtable.h:211:2: error: implicit declaration of function '__pmd' [-Werror=implicit-function-declaration]
  return __pmd(0);
  ^
include/asm-generic/pgtable.h:211:2: error: incompatible types when returning type 'int' but 'pmd_t' was expected

Caused by commit b0593c13d7f6 ("mm/thp: split out pmd collapse/flush
into separate functions").

sparc 32 has no __pmd().  I applied this temporary fix for today just
to get it building:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 14 May 2015 18:06:06 +1000
Subject: [PATCH] temporary fix for sparc 32 no having __pmd()

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/sparc/include/asm/page_32.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/sparc/include/asm/page_32.h b/arch/sparc/include/asm/page_32.h
index f82a1f36b655..b2881f326e8e 100644
--- a/arch/sparc/include/asm/page_32.h
+++ b/arch/sparc/include/asm/page_32.h
@@ -69,7 +69,7 @@ typedef struct { unsigned long iopgprot; } iopgprot_t;
 
 #define __pte(x)	((pte_t) { (x) } )
 #define __iopte(x)	((iopte_t) { (x) } )
-/* #define __pmd(x)        ((pmd_t) { (x) } ) */ /* XXX procedure with loop */
+#define __pmd(x)        ((pmd_t) { { (x) } } ) /* XXX procedure with loop */
 #define __pgd(x)	((pgd_t) { (x) } )
 #define __ctxd(x)	((ctxd_t) { (x) } )
 #define __pgprot(x)	((pgprot_t) { (x) } )
@@ -97,7 +97,7 @@ typedef unsigned long iopgprot_t;
 
 #define __pte(x)	(x)
 #define __iopte(x)	(x)
-/* #define __pmd(x)        (x) */ /* XXX later */
+#define __pmd(x)        ((pmd_t) { { (x) } } ) /* XXX procedure with loop */
 #define __pgd(x)	(x)
 #define __ctxd(x)	(x)
 #define __pgprot(x)	(x)
-- 
2.1.4

-- 
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] 330+ messages in thread

* linux-next: build failure after merge of the akpm-current tree
@ 2015-05-01  4:25 Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2015-05-01  4:25 UTC (permalink / raw)
  To: Andrew Morton
  Cc: linux-next, linux-kernel, Mel Gorman, Nate Zimmer, Waiman Long,
	Pekka Enberg

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

Hi Andrew,

After merging the akpm tree, today's linux-next build (sparc defconfig)
failed like this:

mm/bootmem.c: In function 'free_all_bootmem_core':
mm/bootmem.c:237:32: error: 'cur' undeclared (first use in this function)
   __free_pages_bootmem(page++, cur++, 0);
                                ^

Caused by commit "mm: page_alloc: pass PFN to __free_pages_bootmem".
This only happens because CONFIG_NO_BOOTMEM is *not* set (it is set on
powerpc, x86, arm and sparc64).  Clearly it was never built for this
config.  :-(

Reverting would be a real pain, so I added this (probably incorrect)
patch to make it build:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 1 May 2015 14:21:08 +1000
Subject: [PATCH] mm: page_alloc: pass PFN to __free_pages_bootmem fix

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 mm/bootmem.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/mm/bootmem.c b/mm/bootmem.c
index daf956bb4782..0a0eb62b1c92 100644
--- a/mm/bootmem.c
+++ b/mm/bootmem.c
@@ -173,6 +173,7 @@ static unsigned long __init free_all_bootmem_core(bootmem_data_t *bdata)
 {
 	struct page *page;
 	unsigned long *map, start, end, pages, count = 0;
+	unsigned long cur;
 
 	if (!bdata->node_bootmem_map)
 		return 0;
@@ -214,7 +215,7 @@ static unsigned long __init free_all_bootmem_core(bootmem_data_t *bdata)
 			count += BITS_PER_LONG;
 			start += BITS_PER_LONG;
 		} else {
-			unsigned long cur = start;
+			cur = start;
 
 			start = ALIGN(start + 1, BITS_PER_LONG);
 			while (vec && cur != start) {
@@ -233,6 +234,7 @@ static unsigned long __init free_all_bootmem_core(bootmem_data_t *bdata)
 	pages = bdata->node_low_pfn - bdata->node_min_pfn;
 	pages = bootmem_bootmap_pages(pages);
 	count += pages;
+	cur = bdata->node_min_pfn;
 	while (pages--)
 		__free_pages_bootmem(page++, cur++, 0);
 
-- 
2.1.4

-- 
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] 330+ messages in thread

* linux-next: build failure after merge of the akpm-current tree
@ 2015-04-13 11:20 Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2015-04-13 11:20 UTC (permalink / raw)
  To: Andrew Morton, Michael Ellerman, Benjamin Herrenschmidt, linuxppc-dev
  Cc: linux-next, linux-kernel, Ulrich Obergfell, Anton Blanchard

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

Hi Andrew,

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

arch/powerpc/kernel/setup_64.c: In function 'disable_hardlockup_detector':
arch/powerpc/kernel/setup_64.c:796:2: error: implicit declaration of function 'watchdog_enable_hardlockup_detector' [-Werror=implicit-function-declaration]
  watchdog_enable_hardlockup_detector(false);
  ^

Caused by commit 069bb95b9e38 ("watchdog: introduce the
hardlockup_detector_disable() function") interacting with commit
c54b2bf1b5e9 ("powerpc: Add ppc64 hard lockup detector support") from
the powerpc-mpe tree.

I applied the following merge fix patch (hopefully that is all that is
required):

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 13 Apr 2015 21:18:01 +1000
Subject: [PATCH] powerpc: merge fix for watchdog_enable_hardlockup_detector API change

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/powerpc/kernel/setup_64.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 7551e5692597..c69671c03c3b 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -793,7 +793,7 @@ u64 hw_nmi_get_sample_period(int watchdog_thresh)
  */
 static int __init disable_hardlockup_detector(void)
 {
-	watchdog_enable_hardlockup_detector(false);
+	hardlockup_detector_disable();
 
 	return 0;
 }
-- 
2.1.4

-- 
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] 330+ messages in thread

* linux-next: build failure after merge of the akpm-current tree
@ 2015-03-13  6:07 Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2015-03-13  6:07 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Alexander Kuleshov

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

Hi Andrew,

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

fs/fat/inode.c: In function 'fat_direct_IO':
fs/fat/inode.c:252:2: error: implicit declaration of function 'iov_iter_count' [-Werror=implicit-function-declaration]
  size_t count = iov_iter_count(iter);
  ^

Caused by commit be33247df543 ("fs/fat: remove unnecessary includes").
Removing include files deemed "unnecessary" is fraught.  Please see
Rule 1 in Documentation/SubmitChecklist.

I have added the following fix patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 13 Mar 2015 17:00:15 +1100
Subject: [PATCH] fs/fat: put one actually necessary include file back

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/fat/inode.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/fat/inode.c b/fs/fat/inode.c
index 2c99d01a7018..c71b00fbca28 100644
--- a/fs/fat/inode.c
+++ b/fs/fat/inode.c
@@ -16,6 +16,7 @@
 #include <linux/vfs.h>
 #include <linux/seq_file.h>
 #include <linux/parser.h>
+#include <linux/uio.h>
 #include <linux/blkdev.h>
 #include <asm/unaligned.h>
 #include "fat.h"
-- 
2.1.4

-- 
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] 330+ messages in thread

* Re: linux-next: build failure after merge of the akpm-current tree
  2015-03-05  4:47 Stephen Rothwell
@ 2015-03-05 15:22 ` Toshi Kani
  0 siblings, 0 replies; 330+ messages in thread
From: Toshi Kani @ 2015-03-05 15:22 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Andrew Morton, linux-next, linux-kernel

On Thu, 2015-03-05 at 15:47 +1100, Stephen Rothwell wrote:
> Hi Andrew,
> 
> After merging the akpm-current tree, today's linux-next build (bfin
> TCM-BF537_defconfig and many others) failed like this:
> 
> (.init.text+0x5f8): undefined reference to `ioremap_huge_init'
> 
> Caused by commit 45eaed3ec431 ("lib/ioremap.c: add huge I/O map
> capability interfaces"). lib/ioremp.o is only built if CONFIG_MMU is
> set ...

My apology.  I am sending the fix shortly.

Thanks,
-Toshi

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

* linux-next: build failure after merge of the akpm-current tree
@ 2015-03-05  4:47 Stephen Rothwell
  2015-03-05 15:22 ` Toshi Kani
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2015-03-05  4:47 UTC (permalink / raw)
  To: Andrew Morton, Toshi Kani; +Cc: linux-next, linux-kernel

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

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (bfin
TCM-BF537_defconfig and many others) failed like this:

(.init.text+0x5f8): undefined reference to `ioremap_huge_init'

Caused by commit 45eaed3ec431 ("lib/ioremap.c: add huge I/O map
capability interfaces"). lib/ioremp.o is only built if CONFIG_MMU is
set ...

-- 
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] 330+ messages in thread

* linux-next: build failure after merge of the akpm-current tree
@ 2015-02-04  7:53 Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2015-02-04  7:53 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Andrey Ryabinin

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

Hi Andrew,

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

scripts/Makefile.kasan:21: CONFIG_KASAN: compiler does not support all options. Trying minimal configuration
scripts/Makefile.kasan:21: CONFIG_KASAN: compiler does not support all options. Trying minimal configuration
x86_64-linux-gcc: warning: unrecognized argument to -fsanitize= option: 'kernel-address'

lots and lots of this last message ...

Caused by the commits that added the kernel address sanitizer.

gcc version 4.9.0 cross compiling from Powerpc64.

I have added the following patch for today (after which I only got one
of the "compiler does not support all options" messages).

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 4 Feb 2015 18:43:52 +1100
Subject: [PATCH] disable CONFIG_KASAN for now

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 lib/Kconfig.kasan | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
index 4fecaedc80a2..4301bb56e3ce 100644
--- a/lib/Kconfig.kasan
+++ b/lib/Kconfig.kasan
@@ -1,7 +1,7 @@
 config HAVE_ARCH_KASAN
 	bool
 
-if HAVE_ARCH_KASAN
+if HAVE_ARCH_KASAN && BROKEN
 
 config KASAN
 	bool "KASan: runtime memory debugger"
-- 
2.1.4

-- 
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] 330+ messages in thread

* linux-next: build failure after merge of the akpm-current tree
@ 2015-01-22  7:33 Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2015-01-22  7:33 UTC (permalink / raw)
  To: Andrew Morton, Jens Axboe
  Cc: linux-next, linux-kernel, Weiwei Wang, Martin K. Petersen

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

Hi Andrew,

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

fs/ocfs2/aops.c: In function 'ocfs2_direct_IO_write':
fs/ocfs2/aops.c:784:9: error: too few arguments to function 'blkdev_issue_zeroout'
   ret = blkdev_issue_zeroout(osb->sb->s_bdev,
         ^
In file included from fs/ocfs2/aops.c:31:0:
include/linux/blkdev.h:1165:12: note: declared here
 extern int blkdev_issue_zeroout(struct block_device *bdev, sector_t sector,
            ^

Caused by commit e95f8b5356c4 ("ocfs2: implement
ocfs2_direct_IO_write") interacting with commit d93ba7a5a97c ("block:
Add discard flag to blkdev_issue_zeroout() function") from the block
tree.

I have added this merge fix patch:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 22 Jan 2015 18:28:21 +1100
Subject: [PATCH] ocfs2: implement ocfs2_direct_IO_write fix

update for an API change

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/ocfs2/aops.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/ocfs2/aops.c b/fs/ocfs2/aops.c
index 89f43dc7e440..af22615afd35 100644
--- a/fs/ocfs2/aops.c
+++ b/fs/ocfs2/aops.c
@@ -784,7 +784,7 @@ static ssize_t ocfs2_direct_IO_write(struct kiocb *iocb,
 		ret = blkdev_issue_zeroout(osb->sb->s_bdev,
 				p_cpos << (osb->s_clustersize_bits - 9),
 				zero_len >> 9,
-				GFP_KERNEL);
+				GFP_KERNEL, false);
 		if (ret < 0)
 			mlog_errno(ret);
 	}
-- 
2.1.4

-- 
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] 330+ messages in thread

* Re: linux-next: build failure after merge of the akpm-current tree
  2015-01-21  8:39 ` Konstantin Khlebnikov
@ 2015-01-21  9:06   ` Konstantin Khlebnikov
  0 siblings, 0 replies; 330+ messages in thread
From: Konstantin Khlebnikov @ 2015-01-21  9:06 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Jens Axboe, linux-next, Linux Kernel Mailing List,
	Konstantin Khebnikov, Christoph Hellwig

On Wed, Jan 21, 2015 at 11:39 AM, Konstantin Khlebnikov
<koct9i@gmail.com> wrote:
> On Wed, Jan 21, 2015 at 10:29 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> Hi Andrew,
>>
>> After merging the akpm-current tree, today's linux-next build (powerpc
>> ppc64_defconfig) failed like this:
>>
>> mm/page-writeback.c: In function 'account_page_cleared':
>> mm/page-writeback.c:2122:23: error: 'struct address_space' has no member named 'backing_dev_info'
>>    dec_bdi_stat(mapping->backing_dev_info,
>>                        ^
>>
>> Caused by commit d475bc581640 ("page_writeback: cleanup mess around
>> cancel_dirty_page()") (hmm, that commit has no Signed-off-by from
>> Andrew?) interacting with commit b83ae6d42143 ("fs: remove
>> mapping->backing_dev_info") from the block tree.
>
> Andrew, please drop it. I'll rebase and send it again when the dust settles.

Also I've found potential race with mark_buffer_dirty() and I'm not sure if
everything right in remove_from_page_cache phase. Probably it's better to
make it bullet-proof and put the final account_page_cleaned under ->tree_lock.

>
>>
>> I have applied the following fix patch:
>>
>> From: Stephen Rothwell <sfr@canb.auug.org.au>
>> Date: Wed, 21 Jan 2015 18:23:41 +1100
>> Subject: [PATCH] fs: remove mapping->backing_dev_info fix
>>
>> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
>> ---
>>  mm/page-writeback.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/mm/page-writeback.c b/mm/page-writeback.c
>> index a8397a6923be..ab922616e522 100644
>> --- a/mm/page-writeback.c
>> +++ b/mm/page-writeback.c
>> @@ -2119,7 +2119,7 @@ void account_page_cleared(struct page *page, struct address_space *mapping)
>>  {
>>         if (mapping_cap_account_dirty(mapping)) {
>>                 dec_zone_page_state(page, NR_FILE_DIRTY);
>> -               dec_bdi_stat(mapping->backing_dev_info,
>> +               dec_bdi_stat(inode_to_bdi(mapping->host),
>>                                 BDI_RECLAIMABLE);
>>                 task_io_account_cancelled_write(PAGE_CACHE_SIZE);
>>         }
>> --
>> 2.1.4
>>
>> --
>> Cheers,
>> Stephen Rothwell                    sfr@canb.auug.org.au

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2015-01-21  7:29 Stephen Rothwell
@ 2015-01-21  8:39 ` Konstantin Khlebnikov
  2015-01-21  9:06   ` Konstantin Khlebnikov
  0 siblings, 1 reply; 330+ messages in thread
From: Konstantin Khlebnikov @ 2015-01-21  8:39 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Jens Axboe, linux-next, Linux Kernel Mailing List,
	Konstantin Khebnikov, Christoph Hellwig

On Wed, Jan 21, 2015 at 10:29 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Andrew,
>
> After merging the akpm-current tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> mm/page-writeback.c: In function 'account_page_cleared':
> mm/page-writeback.c:2122:23: error: 'struct address_space' has no member named 'backing_dev_info'
>    dec_bdi_stat(mapping->backing_dev_info,
>                        ^
>
> Caused by commit d475bc581640 ("page_writeback: cleanup mess around
> cancel_dirty_page()") (hmm, that commit has no Signed-off-by from
> Andrew?) interacting with commit b83ae6d42143 ("fs: remove
> mapping->backing_dev_info") from the block tree.

Andrew, please drop it. I'll rebase and send it again when the dust settles.

>
> I have applied the following fix patch:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 21 Jan 2015 18:23:41 +1100
> Subject: [PATCH] fs: remove mapping->backing_dev_info fix
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  mm/page-writeback.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/page-writeback.c b/mm/page-writeback.c
> index a8397a6923be..ab922616e522 100644
> --- a/mm/page-writeback.c
> +++ b/mm/page-writeback.c
> @@ -2119,7 +2119,7 @@ void account_page_cleared(struct page *page, struct address_space *mapping)
>  {
>         if (mapping_cap_account_dirty(mapping)) {
>                 dec_zone_page_state(page, NR_FILE_DIRTY);
> -               dec_bdi_stat(mapping->backing_dev_info,
> +               dec_bdi_stat(inode_to_bdi(mapping->host),
>                                 BDI_RECLAIMABLE);
>                 task_io_account_cancelled_write(PAGE_CACHE_SIZE);
>         }
> --
> 2.1.4
>
> --
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au

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

* linux-next: build failure after merge of the akpm-current tree
@ 2015-01-21  7:29 Stephen Rothwell
  2015-01-21  8:39 ` Konstantin Khlebnikov
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2015-01-21  7:29 UTC (permalink / raw)
  To: Andrew Morton, Jens Axboe
  Cc: linux-next, linux-kernel, Konstantin Khebnikov, Christoph Hellwig

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

Hi Andrew,

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

mm/page-writeback.c: In function 'account_page_cleared':
mm/page-writeback.c:2122:23: error: 'struct address_space' has no member named 'backing_dev_info'
   dec_bdi_stat(mapping->backing_dev_info,
                       ^

Caused by commit d475bc581640 ("page_writeback: cleanup mess around
cancel_dirty_page()") (hmm, that commit has no Signed-off-by from
Andrew?) interacting with commit b83ae6d42143 ("fs: remove
mapping->backing_dev_info") from the block tree.

I have applied the following fix patch:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 21 Jan 2015 18:23:41 +1100
Subject: [PATCH] fs: remove mapping->backing_dev_info fix

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 mm/page-writeback.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/page-writeback.c b/mm/page-writeback.c
index a8397a6923be..ab922616e522 100644
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@ -2119,7 +2119,7 @@ void account_page_cleared(struct page *page, struct address_space *mapping)
 {
 	if (mapping_cap_account_dirty(mapping)) {
 		dec_zone_page_state(page, NR_FILE_DIRTY);
-		dec_bdi_stat(mapping->backing_dev_info,
+		dec_bdi_stat(inode_to_bdi(mapping->host),
 				BDI_RECLAIMABLE);
 		task_io_account_cancelled_write(PAGE_CACHE_SIZE);
 	}
-- 
2.1.4

-- 
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] 330+ messages in thread

* Re: linux-next: build failure after merge of the akpm-current tree
  2015-01-19  8:38 ` Cyrill Gorcunov
@ 2015-01-19  9:45   ` Kirill A. Shutemov
  0 siblings, 0 replies; 330+ messages in thread
From: Kirill A. Shutemov @ 2015-01-19  9:45 UTC (permalink / raw)
  To: Cyrill Gorcunov
  Cc: Stephen Rothwell, Andrew Morton, linux-next, linux-kernel,
	Kirill A. Shutemov, David S. Miller

On Mon, Jan 19, 2015 at 11:38:17AM +0300, Cyrill Gorcunov wrote:
> On Mon, Jan 19, 2015 at 07:17:18PM +1100, Stephen Rothwell wrote:
> > Hi Andrew,
> > 
> > After merging the akpm tree, today's linux-next build (sparc defconfig)
> > failed like this:
> > 
> > In file included from arch/sparc/include/asm/bug.h:20:0,
> >                  from include/linux/bug.h:4,
> >                  from include/linux/thread_info.h:11,
> >                  from include/asm-generic/preempt.h:4,
> >                  from arch/sparc/include/generated/asm/preempt.h:1,
> >                  from include/linux/preempt.h:18,
> >                  from include/linux/spinlock.h:50,
> >                  from include/linux/mmzone.h:7,
> >                  from include/linux/gfp.h:5,
> >                  from include/linux/slab.h:14,
> >                  from mm/mmap.c:12:
> > mm/mmap.c: In function 'exit_mmap':
> > mm/mmap.c:2858:46: error: 'PUD_SHIFT' undeclared (first use in this function)
> >     round_up(FIRST_USER_ADDRESS, PUD_SIZE) >> PUD_SHIFT);
> >                                               ^
> > include/asm-generic/bug.h:86:25: note: in definition of macro 'WARN_ON'
> >   int __ret_warn_on = !!(condition);    \
> >                          ^
> > mm/mmap.c:2858:46: note: each undeclared identifier is reported only once for each function it appears in
> >     round_up(FIRST_USER_ADDRESS, PUD_SIZE) >> PUD_SHIFT);
> >                                               ^
> > include/asm-generic/bug.h:86:25: note: in definition of macro 'WARN_ON'
> >   int __ret_warn_on = !!(condition);    \
> >                          ^
> > 
> > Caused by commit b316feb3c37f ("mm: account pmd page tables to the
> > process").  32 bit sparc does not seem to define PUD_SHIFT ...
> > 
> > I am not sure what the correct fix is here, so I just did the following
> > patch for today.
> > 
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Date: Mon, 19 Jan 2015 19:10:53 +1100
> > Subject: [PATCH] mm: account pmd page tables to the process fix
> > 
> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > ---
> >  mm/mmap.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/mm/mmap.c b/mm/mmap.c
> > index 6a7d36d133fb..25271805ab39 100644
> > --- a/mm/mmap.c
> > +++ b/mm/mmap.c
> > @@ -2854,8 +2854,10 @@ void exit_mmap(struct mm_struct *mm)
> >  
> >  	WARN_ON(atomic_long_read(&mm->nr_ptes) >
> >  			round_up(FIRST_USER_ADDRESS, PMD_SIZE) >> PMD_SHIFT);
> > +#ifdef PUD_SHIFT
> >  	WARN_ON(mm_nr_pmds(mm) >
> >  			round_up(FIRST_USER_ADDRESS, PUD_SIZE) >> PUD_SHIFT);
> > +#endif
> >  }
> >  
> >  /* Insert vm structure into process list sorted by address
> 
> Looks like it should be #ifdef CONFIG_MMU, Kirill?

No. The problem is that <asm-generic/4level-fixup.h> doesn't define
PUD_SHIFT. The fix is proposed:

http://www.spinics.net/lists/linux-mm/msg83249.html

-- 
 Kirill A. Shutemov

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2015-01-19  8:17 Stephen Rothwell
@ 2015-01-19  8:38 ` Cyrill Gorcunov
  2015-01-19  9:45   ` Kirill A. Shutemov
  0 siblings, 1 reply; 330+ messages in thread
From: Cyrill Gorcunov @ 2015-01-19  8:38 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, linux-next, linux-kernel, Kirill A. Shutemov,
	David S. Miller

On Mon, Jan 19, 2015 at 07:17:18PM +1100, Stephen Rothwell wrote:
> Hi Andrew,
> 
> After merging the akpm tree, today's linux-next build (sparc defconfig)
> failed like this:
> 
> In file included from arch/sparc/include/asm/bug.h:20:0,
>                  from include/linux/bug.h:4,
>                  from include/linux/thread_info.h:11,
>                  from include/asm-generic/preempt.h:4,
>                  from arch/sparc/include/generated/asm/preempt.h:1,
>                  from include/linux/preempt.h:18,
>                  from include/linux/spinlock.h:50,
>                  from include/linux/mmzone.h:7,
>                  from include/linux/gfp.h:5,
>                  from include/linux/slab.h:14,
>                  from mm/mmap.c:12:
> mm/mmap.c: In function 'exit_mmap':
> mm/mmap.c:2858:46: error: 'PUD_SHIFT' undeclared (first use in this function)
>     round_up(FIRST_USER_ADDRESS, PUD_SIZE) >> PUD_SHIFT);
>                                               ^
> include/asm-generic/bug.h:86:25: note: in definition of macro 'WARN_ON'
>   int __ret_warn_on = !!(condition);    \
>                          ^
> mm/mmap.c:2858:46: note: each undeclared identifier is reported only once for each function it appears in
>     round_up(FIRST_USER_ADDRESS, PUD_SIZE) >> PUD_SHIFT);
>                                               ^
> include/asm-generic/bug.h:86:25: note: in definition of macro 'WARN_ON'
>   int __ret_warn_on = !!(condition);    \
>                          ^
> 
> Caused by commit b316feb3c37f ("mm: account pmd page tables to the
> process").  32 bit sparc does not seem to define PUD_SHIFT ...
> 
> I am not sure what the correct fix is here, so I just did the following
> patch for today.
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 19 Jan 2015 19:10:53 +1100
> Subject: [PATCH] mm: account pmd page tables to the process fix
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  mm/mmap.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 6a7d36d133fb..25271805ab39 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -2854,8 +2854,10 @@ void exit_mmap(struct mm_struct *mm)
>  
>  	WARN_ON(atomic_long_read(&mm->nr_ptes) >
>  			round_up(FIRST_USER_ADDRESS, PMD_SIZE) >> PMD_SHIFT);
> +#ifdef PUD_SHIFT
>  	WARN_ON(mm_nr_pmds(mm) >
>  			round_up(FIRST_USER_ADDRESS, PUD_SIZE) >> PUD_SHIFT);
> +#endif
>  }
>  
>  /* Insert vm structure into process list sorted by address

Looks like it should be #ifdef CONFIG_MMU, Kirill?

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

* linux-next: build failure after merge of the akpm-current tree
@ 2015-01-19  8:17 Stephen Rothwell
  2015-01-19  8:38 ` Cyrill Gorcunov
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2015-01-19  8:17 UTC (permalink / raw)
  To: Andrew Morton
  Cc: linux-next, linux-kernel, Kirill A. Shutemov, Cyrill Gorcunov,
	David S. Miller

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

Hi Andrew,

After merging the akpm tree, today's linux-next build (sparc defconfig)
failed like this:

In file included from arch/sparc/include/asm/bug.h:20:0,
                 from include/linux/bug.h:4,
                 from include/linux/thread_info.h:11,
                 from include/asm-generic/preempt.h:4,
                 from arch/sparc/include/generated/asm/preempt.h:1,
                 from include/linux/preempt.h:18,
                 from include/linux/spinlock.h:50,
                 from include/linux/mmzone.h:7,
                 from include/linux/gfp.h:5,
                 from include/linux/slab.h:14,
                 from mm/mmap.c:12:
mm/mmap.c: In function 'exit_mmap':
mm/mmap.c:2858:46: error: 'PUD_SHIFT' undeclared (first use in this function)
    round_up(FIRST_USER_ADDRESS, PUD_SIZE) >> PUD_SHIFT);
                                              ^
include/asm-generic/bug.h:86:25: note: in definition of macro 'WARN_ON'
  int __ret_warn_on = !!(condition);    \
                         ^
mm/mmap.c:2858:46: note: each undeclared identifier is reported only once for each function it appears in
    round_up(FIRST_USER_ADDRESS, PUD_SIZE) >> PUD_SHIFT);
                                              ^
include/asm-generic/bug.h:86:25: note: in definition of macro 'WARN_ON'
  int __ret_warn_on = !!(condition);    \
                         ^

Caused by commit b316feb3c37f ("mm: account pmd page tables to the
process").  32 bit sparc does not seem to define PUD_SHIFT ...

I am not sure what the correct fix is here, so I just did the following
patch for today.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 19 Jan 2015 19:10:53 +1100
Subject: [PATCH] mm: account pmd page tables to the process fix

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 mm/mmap.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/mm/mmap.c b/mm/mmap.c
index 6a7d36d133fb..25271805ab39 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2854,8 +2854,10 @@ void exit_mmap(struct mm_struct *mm)
 
 	WARN_ON(atomic_long_read(&mm->nr_ptes) >
 			round_up(FIRST_USER_ADDRESS, PMD_SIZE) >> PMD_SHIFT);
+#ifdef PUD_SHIFT
 	WARN_ON(mm_nr_pmds(mm) >
 			round_up(FIRST_USER_ADDRESS, PUD_SIZE) >> PUD_SHIFT);
+#endif
 }
 
 /* Insert vm structure into process list sorted by address
-- 
2.1.4

-- 
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] 330+ messages in thread

* Re: linux-next: build failure after merge of the akpm-current tree
  2015-01-19  7:28 Stephen Rothwell
@ 2015-01-19  7:35 ` Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2015-01-19  7:35 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Kirill A. Shutemov

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

Hi Andrew,

On Mon, 19 Jan 2015 18:28:53 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the akpm-current tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> mm/filemap_xip.c:304:2: error: unknown field 'remap_pages' specified in initializer
>   .remap_pages = generic_file_remap_pages,
>   ^
> mm/filemap_xip.c:304:17: error: 'generic_file_remap_pages' undeclared here (not in a function)
>   .remap_pages = generic_file_remap_pages,
>                  ^
> 
> Caused by commit 76f0255272b6 ("mm: drop vm_ops->remap_pages and
> generic_file_remap_pages() stub").  Looks like one was missed - grep is
> your friend.
> 
> I have added this patch for today:
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 19 Jan 2015 18:16:15 +1100
> Subject: [PATCH] mm: drop vm_ops->remap_pages and generic_file_remap_pages() stub fix
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  mm/filemap_xip.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/mm/filemap_xip.c b/mm/filemap_xip.c
> index 0d105aeff82f..70c09da1a419 100644
> --- a/mm/filemap_xip.c
> +++ b/mm/filemap_xip.c
> @@ -301,7 +301,6 @@ out:
>  static const struct vm_operations_struct xip_file_vm_ops = {
>  	.fault	= xip_file_fault,
>  	.page_mkwrite	= filemap_page_mkwrite,
> -	.remap_pages = generic_file_remap_pages,
>  };
>  
>  int xip_file_mmap(struct file * file, struct vm_area_struct * vma)
> -- 
> 2.1.4

I then had to fix up the later patch "dax,ext2: replace the XIP page
fault handler with the DAX page fault handler" because the above line
was already removed.

-- 
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] 330+ messages in thread

* linux-next: build failure after merge of the akpm-current tree
@ 2015-01-19  7:28 Stephen Rothwell
  2015-01-19  7:35 ` Stephen Rothwell
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2015-01-19  7:28 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Kirill A. Shutemov

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

Hi Andrew,

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


mm/filemap_xip.c:304:2: error: unknown field 'remap_pages' specified in initializer
  .remap_pages = generic_file_remap_pages,
  ^
mm/filemap_xip.c:304:17: error: 'generic_file_remap_pages' undeclared here (not in a function)
  .remap_pages = generic_file_remap_pages,
                 ^

Caused by commit 76f0255272b6 ("mm: drop vm_ops->remap_pages and
generic_file_remap_pages() stub").  Looks like one was missed - grep is
your friend.

I have added this patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 19 Jan 2015 18:16:15 +1100
Subject: [PATCH] mm: drop vm_ops->remap_pages and generic_file_remap_pages() stub fix

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 mm/filemap_xip.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/mm/filemap_xip.c b/mm/filemap_xip.c
index 0d105aeff82f..70c09da1a419 100644
--- a/mm/filemap_xip.c
+++ b/mm/filemap_xip.c
@@ -301,7 +301,6 @@ out:
 static const struct vm_operations_struct xip_file_vm_ops = {
 	.fault	= xip_file_fault,
 	.page_mkwrite	= filemap_page_mkwrite,
-	.remap_pages = generic_file_remap_pages,
 };
 
 int xip_file_mmap(struct file * file, struct vm_area_struct * vma)
-- 
2.1.4

-- 
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] 330+ messages in thread

* linux-next: build failure after merge of the akpm-current tree
@ 2014-12-15  6:30 Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2014-12-15  6:30 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Oleg Nesterov, Linus

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

Hi Andrew,

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

mm/oom_kill.c:257:20: error: redefinition of 'task_will_free_mem'
 static inline bool task_will_free_mem(struct task_struct *task)
                    ^
In file included from /scratch/sfr/next/mm/oom_kill.c:20:0:
include/linux/oom.h:90:20: note: previous definition of 'task_will_free_mem' was here
 static inline bool task_will_free_mem(struct task_struct *task)
                    ^

Caused by commit 4bf284e597a4 ("oom: don't assume that a coredumping
thread will exit soon") from the akpm-current tree interacting with the
version that finally went into Linus' tree (commit d003f371b270 ("oom:
don't assume that a coredumping thread will exit soon")).

I removed the definition of task_will_free_mem() from the akpm-current
tree version.

Andrew: this sort of thing could be avoided if the actual set of
patches that you send to Linus were present in linux-next (even for a
day). :-(
-- 
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] 330+ messages in thread

* Re: linux-next: build failure after merge of the akpm-current tree
  2014-11-06  9:09 ` Davidlohr Bueso
@ 2014-11-06 10:18   ` Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2014-11-06 10:18 UTC (permalink / raw)
  To: Davidlohr Bueso; +Cc: Andrew Morton, linux-next, linux-kernel

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

Hi,

On Thu, 06 Nov 2014 01:09:41 -0800 Davidlohr Bueso <dave@stgolabs.net> wrote:
>
> On Thu, 2014-11-06 at 16:44 +1100, Stephen Rothwell wrote:
> > 
> > After merging the akpm-current tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> > 
> > mm/fremap.c: In function 'SYSC_remap_file_pages':
> > mm/fremap.c:241:22: error: 'struct address_space' has no member named 'i_mmap_mutex'
> >    mutex_lock(&mapping->i_mmap_mutex);
> >                       ^
> > mm/fremap.c:247:24: error: 'struct address_space' has no member named 'i_mmap_mutex'
> >    mutex_unlock(&mapping->i_mmap_mutex);
> >                         ^
> > 
> > Caused by commit 1f8c97e79f66 ("mm: convert i_mmap_mutex to rwsem").
> > 
> > I applied this patch for today (not sure if there is a better way):
> > 
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Date: Thu, 6 Nov 2014 16:26:41 +1100
> > Subject: [PATCH] mm: convert i_mmap_mutex to rwsem fix
> > 
> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > ---
> >  mm/fremap.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/mm/fremap.c b/mm/fremap.c
> > index 9129013732d7..2805d71cf476 100644
> > --- a/mm/fremap.c
> > +++ b/mm/fremap.c
> > @@ -238,13 +238,13 @@ get_write_lock:
> >  			}
> >  			goto out_freed;
> >  		}
> > -		mutex_lock(&mapping->i_mmap_mutex);
> > +		i_mmap_lock_write(mapping);
> 
> That's the correct fix, thanks. However, I had particularly dropped that
> modification because linux-next no longer even has mm/fremap.c so I'm
> not sure what went wrong here...

Andrew's tree gets added in two sections and he put your patch in the
first part but the patch that removes this file is in the second part,
so all that really needs to happen is for the patches to be reordered.

-- 
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] 330+ messages in thread

* Re: linux-next: build failure after merge of the akpm-current tree
  2014-11-06  5:44 Stephen Rothwell
@ 2014-11-06  9:09 ` Davidlohr Bueso
  2014-11-06 10:18   ` Stephen Rothwell
  0 siblings, 1 reply; 330+ messages in thread
From: Davidlohr Bueso @ 2014-11-06  9:09 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Andrew Morton, linux-next, linux-kernel

On Thu, 2014-11-06 at 16:44 +1100, Stephen Rothwell wrote:
> Hi Andrew,
> 
> After merging the akpm-current tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> mm/fremap.c: In function 'SYSC_remap_file_pages':
> mm/fremap.c:241:22: error: 'struct address_space' has no member named 'i_mmap_mutex'
>    mutex_lock(&mapping->i_mmap_mutex);
>                       ^
> mm/fremap.c:247:24: error: 'struct address_space' has no member named 'i_mmap_mutex'
>    mutex_unlock(&mapping->i_mmap_mutex);
>                         ^
> 
> Caused by commit 1f8c97e79f66 ("mm: convert i_mmap_mutex to rwsem").
> 
> I applied this patch for today (not sure if there is a better way):
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 6 Nov 2014 16:26:41 +1100
> Subject: [PATCH] mm: convert i_mmap_mutex to rwsem fix
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  mm/fremap.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/mm/fremap.c b/mm/fremap.c
> index 9129013732d7..2805d71cf476 100644
> --- a/mm/fremap.c
> +++ b/mm/fremap.c
> @@ -238,13 +238,13 @@ get_write_lock:
>  			}
>  			goto out_freed;
>  		}
> -		mutex_lock(&mapping->i_mmap_mutex);
> +		i_mmap_lock_write(mapping);

That's the correct fix, thanks. However, I had particularly dropped that
modification because linux-next no longer even has mm/fremap.c so I'm
not sure what went wrong here...

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

* linux-next: build failure after merge of the akpm-current tree
@ 2014-11-06  5:44 Stephen Rothwell
  2014-11-06  9:09 ` Davidlohr Bueso
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2014-11-06  5:44 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Davidlohr Bueso

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

Hi Andrew,

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

mm/fremap.c: In function 'SYSC_remap_file_pages':
mm/fremap.c:241:22: error: 'struct address_space' has no member named 'i_mmap_mutex'
   mutex_lock(&mapping->i_mmap_mutex);
                      ^
mm/fremap.c:247:24: error: 'struct address_space' has no member named 'i_mmap_mutex'
   mutex_unlock(&mapping->i_mmap_mutex);
                        ^

Caused by commit 1f8c97e79f66 ("mm: convert i_mmap_mutex to rwsem").

I applied this patch for today (not sure if there is a better way):

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 6 Nov 2014 16:26:41 +1100
Subject: [PATCH] mm: convert i_mmap_mutex to rwsem fix

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 mm/fremap.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mm/fremap.c b/mm/fremap.c
index 9129013732d7..2805d71cf476 100644
--- a/mm/fremap.c
+++ b/mm/fremap.c
@@ -238,13 +238,13 @@ get_write_lock:
 			}
 			goto out_freed;
 		}
-		mutex_lock(&mapping->i_mmap_mutex);
+		i_mmap_lock_write(mapping);
 		flush_dcache_mmap_lock(mapping);
 		vma->vm_flags |= VM_NONLINEAR;
 		vma_interval_tree_remove(vma, &mapping->i_mmap);
 		vma_nonlinear_insert(vma, &mapping->i_mmap_nonlinear);
 		flush_dcache_mmap_unlock(mapping);
-		mutex_unlock(&mapping->i_mmap_mutex);
+		i_mmap_unlock_write(mapping);
 	}
 
 	if (vma->vm_flags & VM_LOCKED) {
-- 
2.1.1

-- 
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] 330+ messages in thread

* linux-next: build failure after merge of the akpm-current tree
@ 2014-10-30  4:03 Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2014-10-30  4:03 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Vishnu Pratap Singh

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

Hi Andrew,

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

lib/show_mem.c: In function 'show_mem':
lib/show_mem.c:43:45: error: 'totalcma_pages' undeclared (first use in this function)
  printk("%lu pages reserved\n", (reserved - totalcma_pages));
                                             ^

Caused by commit b4e3647bb59d ("lib/show_mem.c: adds cma reserved
information").  totalcma_pages exists nowhere except these added lines.

I have reverted that commit (and its following fix) for today.
-- 
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] 330+ messages in thread

* linux-next: build failure after merge of the akpm-current tree
@ 2014-10-27  4:30 Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2014-10-27  4:30 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Thierry Reding

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

Hi Andrew,

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

mm/cma.c: In function 'cma_declare_contiguous':
mm/cma.c:288:4: error: implicit declaration of function 'phys_to_virt' [-Werror=implicit-function-declaration]
    kmemleak_ignore(phys_to_virt(addr));
    ^

Caused by commit 2a70e5a78672 ("mm/cma: ake kmemleak ignore CMA regions").

I added the following fix patch:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 27 Oct 2014 15:25:09 +1100
Subject: [PATCH] mm/cma: include linux/io.h for phys_to_virt()

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 mm/cma.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/mm/cma.c b/mm/cma.c
index 471fcfef043b..c22d7a8e0e3b 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -33,6 +33,7 @@
 #include <linux/log2.h>
 #include <linux/cma.h>
 #include <linux/highmem.h>
+#include <linux/io.h>
 
 struct cma {
 	unsigned long	base_pfn;

-- 
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] 330+ messages in thread

* Re: linux-next: build failure after merge of the akpm-current tree
  2014-10-16  4:56 Stephen Rothwell
@ 2014-10-16 13:40 ` Johannes Weiner
  0 siblings, 0 replies; 330+ messages in thread
From: Johannes Weiner @ 2014-10-16 13:40 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Andrew Morton, linux-next, linux-kernel

On Thu, Oct 16, 2014 at 03:56:57PM +1100, Stephen Rothwell wrote:
> Hi Andrew,
> 
> After merging the akpm tree, today's linux-next build (powerpc
> allyesconfig) failed like this:

[...]

> include/linux/page_counter.h:19:27: error: 'LONG_MAX' undeclared (first use in this function)
> include/linux/page_counter.h:19:38: error: 'PAGE_SIZE' undeclared (first use in this function)

[...]

> Caused by commit 36a1bfb2a772 ("mm: memcontrol: lockless page
> counters").  See Rule 1 in Documentation/SubmitChecklist.

I'll be in the corner.

> I have added the following patch for today:
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 16 Oct 2014 15:49:08 +1100
> Subject: [PATCH] mm: memcontrol: add includes for page_counter.h
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

Thanks, Stephen.  I just sent a similar patch in reply to Fengguang's
build bot, either version should do.

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

* linux-next: build failure after merge of the akpm-current tree
@ 2014-10-16  4:56 Stephen Rothwell
  2014-10-16 13:40 ` Johannes Weiner
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2014-10-16  4:56 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Johannes Weiner

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

Hi Andrew,

After merging the akpm tree, today's linux-next build (powerpc
allyesconfig) failed like this:

In file included from mm/memcontrol.c:28:0:
include/linux/page_counter.h: In function 'page_counter_init':
include/linux/page_counter.h:19:27: error: 'LONG_MAX' undeclared (first use in this function)
 #define PAGE_COUNTER_MAX (LONG_MAX / PAGE_SIZE)
                           ^
include/linux/page_counter.h:26:19: note: in expansion of macro 'PAGE_COUNTER_MAX'
  counter->limit = PAGE_COUNTER_MAX;
                   ^
include/linux/page_counter.h:19:27: note: each undeclared identifier is reported only once for each function it appears in
 #define PAGE_COUNTER_MAX (LONG_MAX / PAGE_SIZE)
                           ^
include/linux/page_counter.h:26:19: note: in expansion of macro 'PAGE_COUNTER_MAX'
  counter->limit = PAGE_COUNTER_MAX;
                   ^
include/linux/page_counter.h:19:38: error: 'PAGE_SIZE' undeclared (first use in this function)
 #define PAGE_COUNTER_MAX (LONG_MAX / PAGE_SIZE)
                                      ^
include/linux/page_counter.h:26:19: note: in expansion of macro 'PAGE_COUNTER_MAX'
  counter->limit = PAGE_COUNTER_MAX;
                   ^
In file included from mm/page_counter.c:7:0:
include/linux/page_counter.h: In function 'page_counter_init':
include/linux/page_counter.h:19:27: error: 'LONG_MAX' undeclared (first use in this function)
 #define PAGE_COUNTER_MAX (LONG_MAX / PAGE_SIZE)
                           ^
include/linux/page_counter.h:26:19: note: in expansion of macro 'PAGE_COUNTER_MAX'
  counter->limit = PAGE_COUNTER_MAX;
                   ^
include/linux/page_counter.h:19:27: note: each undeclared identifier is reported only once for each function it appears in
 #define PAGE_COUNTER_MAX (LONG_MAX / PAGE_SIZE)
                           ^
include/linux/page_counter.h:26:19: note: in expansion of macro 'PAGE_COUNTER_MAX'
  counter->limit = PAGE_COUNTER_MAX;
                   ^
include/linux/page_counter.h:19:38: error: 'PAGE_SIZE' undeclared (first use in this function)
 #define PAGE_COUNTER_MAX (LONG_MAX / PAGE_SIZE)
                                      ^
include/linux/page_counter.h:26:19: note: in expansion of macro 'PAGE_COUNTER_MAX'
  counter->limit = PAGE_COUNTER_MAX;
                   ^

Caused by commit 36a1bfb2a772 ("mm: memcontrol: lockless page
counters").  See Rule 1 in Documentation/SubmitChecklist.

I have added the following patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 16 Oct 2014 15:49:08 +1100
Subject: [PATCH] mm: memcontrol: add includes for page_counter.h

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 include/linux/page_counter.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/linux/page_counter.h b/include/linux/page_counter.h
index a878ef61d073..785640e4efec 100644
--- a/include/linux/page_counter.h
+++ b/include/linux/page_counter.h
@@ -2,6 +2,9 @@
 #define _LINUX_PAGE_COUNTER_H
 
 #include <linux/atomic.h>
+#include <linux/kernel.h>
+
+#include <asm/page.h>
 
 struct page_counter {
 	atomic_long_t count;
-- 
2.1.1


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

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

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

* linux-next: build failure after merge of the akpm-current tree
@ 2014-09-26 10:17 Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2014-09-26 10:17 UTC (permalink / raw)
  To: Andrew Morton
  Cc: linux-next, linux-kernel, Guenter Roeck, Oleg Nesterov, Josh Triplett

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

Hi Andrew,

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

In file included from arch/powerpc/kernel/asm-offsets.c:16:0:
include/linux/signal.h: In function 'sigisemptyset':
include/linux/signal.h:79:3: error: implicit declaration of function 'BUILD_BUG' [-Werror=implicit-function-declaration]
   BUILD_BUG();
   ^

Caused by commit 7e52cdba7e69 ("signal: use BUILD_BUG() instead of
_NSIG_WORDS_is_unsupported_size()").

See Rule 1 in Documentation/SubmitChecklist.

Thanks to Guenter for the heads up.

I have added the following patch for today (hopefully it does not cause
more problems).

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 26 Sep 2014 20:08:12 +1000
Subject: [PATCH] signal.h: using BUILD_BUG requires including bug.h

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 include/linux/signal.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/signal.h b/include/linux/signal.h
index 14acfd59ed1b..ab1e0392b5ac 100644
--- a/include/linux/signal.h
+++ b/include/linux/signal.h
@@ -2,6 +2,7 @@
 #define _LINUX_SIGNAL_H
 
 #include <linux/list.h>
+#include <linux/bug.h>
 #include <uapi/linux/signal.h>
 
 struct task_struct;
-- 
2.1.1

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

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

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

* linux-next: build failure after merge of the akpm-current tree
@ 2014-09-08  9:45 Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2014-09-08  9:45 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Sasha Levin

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

Hi Andrew,

After merging the akpm tree, today's linux-next build (powerpc
allyesconfig) failed like this:

mm/page_alloc.c: In function 'dump_vma':
mm/page_alloc.c:6742:46: error: request for member 'pgprot' in something not a structure or union
   vma->vm_prev, vma->vm_mm, vma->vm_page_prot.pgprot,
                                              ^

Caused by commit d1305f0fa17f ("mm: introduce dump_vma").  pgprot_t on
PPC is normally (i.e. unless STRICT_MM_TYPECHECKS is explicitly
defined) just an "unsigned long" (see
arch/powerpc/include/asm/page.h).  This is true for several other
architectures as well.

I added this fix patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 8 Sep 2014 19:41:54 +1000
Subject: [PATCH] mm: introduce dump_vma fix 2

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 mm/page_alloc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index cb510c08073b..0de60769bcf6 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -6739,7 +6739,7 @@ void dump_vma(const struct vm_area_struct *vma)
 		"prot %lx anon_vma %p vm_ops %p\n"
 		"pgoff %lx file %p private_data %p\n",
 		vma, (void *)vma->vm_start, (void *)vma->vm_end, vma->vm_next,
-		vma->vm_prev, vma->vm_mm, vma->vm_page_prot.pgprot,
+		vma->vm_prev, vma->vm_mm, pgprot_val(vma->vm_page_prot),
 		vma->anon_vma, vma->vm_ops, vma->vm_pgoff,
 		vma->vm_file, vma->vm_private_data);
 	dump_flags(vma->vm_flags, vmaflags_names, ARRAY_SIZE(vmaflags_names));
-- 
2.1.0


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

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

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2014-08-26  6:35 Stephen Rothwell
@ 2014-08-26  6:40 ` Cyrill Gorcunov
  0 siblings, 0 replies; 330+ messages in thread
From: Cyrill Gorcunov @ 2014-08-26  6:40 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, linux-next, linux-kernel, Andrew Vagin, Serge Hallyn

On Tue, Aug 26, 2014 at 04:35:02PM +1000, Stephen Rothwell wrote:
> Hi Andrew,
> 
> After merging the akpm-current tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> ./usr/include/linux/prctl.h:132: found __[us]{8,16,32,64} type without #include <linux/types.h>
> In file included from /usr/include/x86_64-linux-gnu/sys/prctl.h:23:0,
>                  from Documentation/prctl/disable-tsc-test.c:14:
> ./usr/include/linux/prctl.h:132:2: error: unknown type name '__u64'
...

Thanks for report, Stephen! I'll fix.

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

* linux-next: build failure after merge of the akpm-current tree
@ 2014-08-26  6:35 Stephen Rothwell
  2014-08-26  6:40 ` Cyrill Gorcunov
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2014-08-26  6:35 UTC (permalink / raw)
  To: Andrew Morton
  Cc: linux-next, linux-kernel, Cyrill Gorcunov, Andrew Vagin, Serge Hallyn

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

Hi Andrew,

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

./usr/include/linux/prctl.h:132: found __[us]{8,16,32,64} type without #include <linux/types.h>
In file included from /usr/include/x86_64-linux-gnu/sys/prctl.h:23:0,
                 from Documentation/prctl/disable-tsc-test.c:14:
./usr/include/linux/prctl.h:132:2: error: unknown type name '__u64'
./usr/include/linux/prctl.h:133:2: error: unknown type name '__u64'
./usr/include/linux/prctl.h:134:2: error: unknown type name '__u64'
./usr/include/linux/prctl.h:135:2: error: unknown type name '__u64'
./usr/include/linux/prctl.h:136:2: error: unknown type name '__u64'
./usr/include/linux/prctl.h:137:2: error: unknown type name '__u64'
./usr/include/linux/prctl.h:138:2: error: unknown type name '__u64'
./usr/include/linux/prctl.h:139:2: error: unknown type name '__u64'
./usr/include/linux/prctl.h:140:2: error: unknown type name '__u64'
./usr/include/linux/prctl.h:141:2: error: unknown type name '__u64'
./usr/include/linux/prctl.h:142:2: error: unknown type name '__u64'
./usr/include/linux/prctl.h:143:2: error: unknown type name '__u64'
./usr/include/linux/prctl.h:144:2: error: unknown type name '__u32'
./usr/include/linux/prctl.h:145:2: error: unknown type name '__u32'
In file included from /usr/include/x86_64-linux-gnu/sys/prctl.h:23:0,
                 from Documentation/prctl/disable-tsc-ctxt-sw-stress-test.c:19:
./usr/include/linux/prctl.h:132:2: error: unknown type name '__u64'
./usr/include/linux/prctl.h:133:2: error: unknown type name '__u64'
./usr/include/linux/prctl.h:134:2: error: unknown type name '__u64'
./usr/include/linux/prctl.h:135:2: error: unknown type name '__u64'
./usr/include/linux/prctl.h:136:2: error: unknown type name '__u64'
./usr/include/linux/prctl.h:137:2: error: unknown type name '__u64'
./usr/include/linux/prctl.h:138:2: error: unknown type name '__u64'
./usr/include/linux/prctl.h:139:2: error: unknown type name '__u64'
./usr/include/linux/prctl.h:140:2: error: unknown type name '__u64'
./usr/include/linux/prctl.h:141:2: error: unknown type name '__u64'
./usr/include/linux/prctl.h:142:2: error: unknown type name '__u64'
./usr/include/linux/prctl.h:143:2: error: unknown type name '__u64'
./usr/include/linux/prctl.h:144:2: error: unknown type name '__u32'
./usr/include/linux/prctl.h:145:2: error: unknown type name '__u32'
make[3]: *** [Documentation/prctl/disable-tsc-test] Error 1
make[3]: *** [Documentation/prctl/disable-tsc-ctxt-sw-stress-test] Error 1
In file included from /usr/include/x86_64-linux-gnu/sys/prctl.h:23:0,
                 from Documentation/prctl/disable-tsc-on-off-stress-test.c:19:
./usr/include/linux/prctl.h:132:2: error: unknown type name '__u64'
./usr/include/linux/prctl.h:133:2: error: unknown type name '__u64'
./usr/include/linux/prctl.h:134:2: error: unknown type name '__u64'
./usr/include/linux/prctl.h:135:2: error: unknown type name '__u64'
./usr/include/linux/prctl.h:136:2: error: unknown type name '__u64'
./usr/include/linux/prctl.h:137:2: error: unknown type name '__u64'
./usr/include/linux/prctl.h:138:2: error: unknown type name '__u64'
./usr/include/linux/prctl.h:139:2: error: unknown type name '__u64'
./usr/include/linux/prctl.h:140:2: error: unknown type name '__u64'
./usr/include/linux/prctl.h:141:2: error: unknown type name '__u64'
./usr/include/linux/prctl.h:142:2: error: unknown type name '__u64'
./usr/include/linux/prctl.h:143:2: error: unknown type name '__u64'
./usr/include/linux/prctl.h:144:2: error: unknown type name '__u32'
./usr/include/linux/prctl.h:145:2: error: unknown type name '__u32'
make[3]: *** [Documentation/prctl/disable-tsc-on-off-stress-test] Error 1
make[2]: *** [Documentation/prctl] Error 2

Caused by commit 802d335c0f7f ("prctl: PR_SET_MM -- introduce
PR_SET_MM_MAP operation").

I have reverted that commit (and commit c2e04b241d40
("prctl-pr_set_mm-introduce-pr_set_mm_map-operation-v3-fix") that
follows it) for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

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

* linux-next: build failure after merge of the akpm-current tree
@ 2014-07-31 10:25 Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2014-07-31 10:25 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Michal Hocko, Atsushi Kumagai

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

Hi Andrew,

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

In file included from kernel/kexec.c:14:0:
kernel/kexec.c: In function 'crash_save_vmcoreinfo_init':
kernel/kexec.c:1623:20: error: 'free_huge_page' undeclared (first use in this function)
  VMCOREINFO_SYMBOL(free_huge_page);
                    ^

Caused by commit "kexec-export-free_huge_page-to-vmcoreinfo".

I applied the patch "kexec-export-free_huge_page-to-vmcoreinfo-fix"
from Michal Hocko <mhocko@suse.cz>.

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

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

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2014-07-03  4:59 Stephen Rothwell
@ 2014-07-03 12:24 ` Vivek Goyal
  0 siblings, 0 replies; 330+ messages in thread
From: Vivek Goyal @ 2014-07-03 12:24 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Andrew Morton, linux-next, linux-kernel

On Thu, Jul 03, 2014 at 02:59:40PM +1000, Stephen Rothwell wrote:
> Hi Andrew,
> 
> After merging the akpm-current tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> /bin/sh: /scratch/sfr/next/scripts/basic/bin2c: No such file or directory
> 
> Presumably caused by commit 572a8e0147f8 ("bin2c: move bin2c in
> scripts/basic") and commit 1b4c30351f49 ("purgatory: core purgatory
> functionality").  Note that the directory above is the *source*
> directory (I build with O=...).  bin2c is in my object directory (in
> scripts/basicbin2c).
> 
> I have added the following patch for today:

Thanks Stephen. Yes, it should have been objtree instead of srctree. I
do not compile with O=, hence I did not catch it during my testing.

Again, thanks for taking care of this.

Vivek

> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 3 Jul 2014 14:56:25 +1000
> Subject: [PATCH] purgatory: run host built programs from objtree
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  arch/x86/purgatory/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/purgatory/Makefile b/arch/x86/purgatory/Makefile
> index e5829ddbca2b..7fde9ee438a4 100644
> --- a/arch/x86/purgatory/Makefile
> +++ b/arch/x86/purgatory/Makefile
> @@ -18,7 +18,7 @@ $(obj)/purgatory.ro: $(PURGATORY_OBJS) FORCE
>  targets += kexec-purgatory.c
>  
>  quiet_cmd_bin2c = BIN2C   $@
> -      cmd_bin2c = cat $(obj)/purgatory.ro | $(srctree)/scripts/basic/bin2c kexec_purgatory > $(obj)/kexec-purgatory.c
> +      cmd_bin2c = cat $(obj)/purgatory.ro | $(objtree)/scripts/basic/bin2c kexec_purgatory > $(obj)/kexec-purgatory.c
>  
>  $(obj)/kexec-purgatory.c: $(obj)/purgatory.ro FORCE
>  	$(call if_changed,bin2c)
> -- 
> 2.0.0
> 
> 
> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au

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

* linux-next: build failure after merge of the akpm-current tree
@ 2014-07-03  4:59 Stephen Rothwell
  2014-07-03 12:24 ` Vivek Goyal
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2014-07-03  4:59 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Vivek Goyal

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

Hi Andrew,

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

/bin/sh: /scratch/sfr/next/scripts/basic/bin2c: No such file or directory

Presumably caused by commit 572a8e0147f8 ("bin2c: move bin2c in
scripts/basic") and commit 1b4c30351f49 ("purgatory: core purgatory
functionality").  Note that the directory above is the *source*
directory (I build with O=...).  bin2c is in my object directory (in
scripts/basicbin2c).

I have added the following patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 3 Jul 2014 14:56:25 +1000
Subject: [PATCH] purgatory: run host built programs from objtree

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/x86/purgatory/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/purgatory/Makefile b/arch/x86/purgatory/Makefile
index e5829ddbca2b..7fde9ee438a4 100644
--- a/arch/x86/purgatory/Makefile
+++ b/arch/x86/purgatory/Makefile
@@ -18,7 +18,7 @@ $(obj)/purgatory.ro: $(PURGATORY_OBJS) FORCE
 targets += kexec-purgatory.c
 
 quiet_cmd_bin2c = BIN2C   $@
-      cmd_bin2c = cat $(obj)/purgatory.ro | $(srctree)/scripts/basic/bin2c kexec_purgatory > $(obj)/kexec-purgatory.c
+      cmd_bin2c = cat $(obj)/purgatory.ro | $(objtree)/scripts/basic/bin2c kexec_purgatory > $(obj)/kexec-purgatory.c
 
 $(obj)/kexec-purgatory.c: $(obj)/purgatory.ro FORCE
 	$(call if_changed,bin2c)
-- 
2.0.0


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

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

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2014-06-26 11:45   ` Petr Mládek
@ 2014-06-26 17:36     ` Luis R. Rodriguez
  0 siblings, 0 replies; 330+ messages in thread
From: Luis R. Rodriguez @ 2014-06-26 17:36 UTC (permalink / raw)
  To: Petr Mládek
  Cc: Stephen Rothwell, Andrew Morton, linux-next, linux-kernel

On Thu, Jun 26, 2014 at 01:45:13PM +0200, Petr Mládek wrote:
> On Thu 2014-06-26 10:29:40, Luis R. Rodriguez wrote:
> > On Thu, Jun 26, 2014 at 04:22:57PM +1000, Stephen Rothwell wrote:
> > > Hi Andrew,
> > > 
> > > After merging the akpm tree, today's linux-next build (powerpc
> > > ppc44x_defconfig) failed like this:
> > > 
> > > kernel/printk/printk.c: In function 'log_buf_add_cpu':
> > > kernel/printk/printk.c:269:37: error: 'CONFIG_LOG_CPU_MAX_BUF_SHIFT' undeclared (first use in this function)
> > >  #define __LOG_CPU_MAX_BUF_LEN (1 << CONFIG_LOG_CPU_MAX_BUF_SHIFT)
> > >                                      ^
> > > kernel/printk/printk.c:864:42: note: in expansion of macro '__LOG_CPU_MAX_BUF_LEN'
> > >   cpu_extra = (num_possible_cpus() - 1) * __LOG_CPU_MAX_BUF_LEN;
> > >                                           ^
> > > kernel/printk/printk.c:269:37: note: each undeclared identifier is reported only once for each function it appears in
> > >  #define __LOG_CPU_MAX_BUF_LEN (1 << CONFIG_LOG_CPU_MAX_BUF_SHIFT)
> > >                                      ^
> > > kernel/printk/printk.c:864:42: note: in expansion of macro '__LOG_CPU_MAX_BUF_LEN'
> > >   cpu_extra = (num_possible_cpus() - 1) * __LOG_CPU_MAX_BUF_LEN;
> > >                                           ^
> > > 
> > > Caused by commit 58209adf633e ("printk: allow increasing the ring
> > > buffer depending on the number of CPUs").  CONFIG_LOG_CPU_MAX_BUF_SHIFT
> > > is not defined for this configuration.
> > 
> > diff --git a/init/Kconfig b/init/Kconfig
> > index 573d3f6..2339118 100644
> > --- a/init/Kconfig
> > +++ b/init/Kconfig
> > @@ -822,10 +822,9 @@ config LOG_BUF_SHIFT
> >  
> >  config LOG_CPU_MAX_BUF_SHIFT
> >  	int "CPU kernel log buffer size contribution (13 => 8 KB, 17 => 128KB)"
> > -	range 0 21
> > -	default 12
> > -	depends on SMP
> > -	depends on !BASE_SMALL
> > +	range 0 21 if SMP && !BASE_SMALL
> > +	default 12 if SMP && !BASE_SMALL
> > +	default 0 if !SMP || BASE_SMALL
> 
> There are situations when the default value is not defined, for
> example, when both SMP and BASE_SMALL are set.
> 
> I would ignore SMP. It is handled in the code. If SMP is not defined,
> num_possible_cpus() returns 1 and "cpu_extra" is always 0. Then we
> could have:
> 
>        range 0 21
>        default 12 if !BASE_SMALL
>        default 0 if BASE_SMALL
> 
> 
> What about the following patch? It does the above change. Plus
> it tries to make the help text better readable. It says the basic
> details first. Then it says other useful information in
> separate paragraphs. Also I removed the computation example. It was
> not easy to parse. Interested people might want to look into sources.
> 
> It could be merged into
> printk-allow-increasing-the-ring-buffer-depending-on-the-number-of-cpus.patch

Looks good to me, Andrew let me know how you prefer to amend queued up patches
on your end.

  Luis

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2014-06-26  8:29 ` Luis R. Rodriguez
@ 2014-06-26 11:45   ` Petr Mládek
  2014-06-26 17:36     ` Luis R. Rodriguez
  0 siblings, 1 reply; 330+ messages in thread
From: Petr Mládek @ 2014-06-26 11:45 UTC (permalink / raw)
  To: Luis R. Rodriguez
  Cc: Stephen Rothwell, Andrew Morton, linux-next, linux-kernel

On Thu 2014-06-26 10:29:40, Luis R. Rodriguez wrote:
> On Thu, Jun 26, 2014 at 04:22:57PM +1000, Stephen Rothwell wrote:
> > Hi Andrew,
> > 
> > After merging the akpm tree, today's linux-next build (powerpc
> > ppc44x_defconfig) failed like this:
> > 
> > kernel/printk/printk.c: In function 'log_buf_add_cpu':
> > kernel/printk/printk.c:269:37: error: 'CONFIG_LOG_CPU_MAX_BUF_SHIFT' undeclared (first use in this function)
> >  #define __LOG_CPU_MAX_BUF_LEN (1 << CONFIG_LOG_CPU_MAX_BUF_SHIFT)
> >                                      ^
> > kernel/printk/printk.c:864:42: note: in expansion of macro '__LOG_CPU_MAX_BUF_LEN'
> >   cpu_extra = (num_possible_cpus() - 1) * __LOG_CPU_MAX_BUF_LEN;
> >                                           ^
> > kernel/printk/printk.c:269:37: note: each undeclared identifier is reported only once for each function it appears in
> >  #define __LOG_CPU_MAX_BUF_LEN (1 << CONFIG_LOG_CPU_MAX_BUF_SHIFT)
> >                                      ^
> > kernel/printk/printk.c:864:42: note: in expansion of macro '__LOG_CPU_MAX_BUF_LEN'
> >   cpu_extra = (num_possible_cpus() - 1) * __LOG_CPU_MAX_BUF_LEN;
> >                                           ^
> > 
> > Caused by commit 58209adf633e ("printk: allow increasing the ring
> > buffer depending on the number of CPUs").  CONFIG_LOG_CPU_MAX_BUF_SHIFT
> > is not defined for this configuration.
> 
> diff --git a/init/Kconfig b/init/Kconfig
> index 573d3f6..2339118 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -822,10 +822,9 @@ config LOG_BUF_SHIFT
>  
>  config LOG_CPU_MAX_BUF_SHIFT
>  	int "CPU kernel log buffer size contribution (13 => 8 KB, 17 => 128KB)"
> -	range 0 21
> -	default 12
> -	depends on SMP
> -	depends on !BASE_SMALL
> +	range 0 21 if SMP && !BASE_SMALL
> +	default 12 if SMP && !BASE_SMALL
> +	default 0 if !SMP || BASE_SMALL

There are situations when the default value is not defined, for
example, when both SMP and BASE_SMALL are set.

I would ignore SMP. It is handled in the code. If SMP is not defined,
num_possible_cpus() returns 1 and "cpu_extra" is always 0. Then we
could have:

       range 0 21
       default 12 if !BASE_SMALL
       default 0 if BASE_SMALL


What about the following patch? It does the above change. Plus
it tries to make the help text better readable. It says the basic
details first. Then it says other useful information in
separate paragraphs. Also I removed the computation example. It was
not easy to parse. Interested people might want to look into sources.

It could be merged into
printk-allow-increasing-the-ring-buffer-depending-on-the-number-of-cpus.patch

diff --git a/init/Kconfig b/init/Kconfig
index 7ec22f19df29..b0b2e95641e2 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -813,47 +813,34 @@ config LOG_BUF_SHIFT
 	  by "log_buf_len" boot parameter.
 
 	  Examples:
-	  	     17 => 128 KB
+		     17 => 128 KB
 		     16 => 64 KB
-	             15 => 32 KB
-	             14 => 16 KB
+		     15 => 32 KB
+		     14 => 16 KB
 		     13 =>  8 KB
 		     12 =>  4 KB
 
 config LOG_CPU_MAX_BUF_SHIFT
 	int "CPU kernel log buffer size contribution (13 => 8 KB, 17 => 128KB)"
 	range 0 21
-	default 12
-	depends on SMP
-	depends on !BASE_SMALL
-	help
-	  The kernel ring buffer will get additional data logged onto it
-	  when multiple CPUs are supported. Typically the contributions are
-	  only a few lines when idle however under under load this can vary
-	  and in the worst case it can mean losing logging information. You
-	  can use this to set the maximum expected amount of logging
-	  contribution under load by each CPU in the worst case scenario, as
-	  a power of 2. The total sum amount of contributions made by all CPUs
-	  must be greater than half of the default kernel ring buffer size
-	  ((1 << LOG_BUF_SHIFT / 2 bytes)) in order to trigger an increase upon
-	  bootup. If an increase is required the ring buffer is increased to
-	  the next power of 2 that can fit both the minimum kernel ring buffer
-	  (LOG_BUF_SHIFT) plus the additional worst case CPU contributions.
-	  For example if LOG_BUF_SHIFT is 18 (256 KB) you'd require at laest
-	  128 KB contributions by other CPUs in order to trigger an increase.
-	  With a LOG_CPU_BUF_SHIFT of 12 (4 KB) you'd require at least anything
-	  over > 64 possible CPUs to trigger an increase. If you had 128
-	  possible CPUs the new minimum required kernel ring buffer size
-	  would be:
-
-	     ((1 << 18) + ((128 - 1) * (1 << 12))) / 1024 = 764 KB
-
-	  Since we only allow powers of two for the kernel ring buffer size the
-	  new kernel ring buffer size would be 1024 KB.
-
-	  CPU contributions are ignored when "log_buf_len" kernel parameter is
-	  used as it forces an exact (power of two) size of the ring buffer to
-	  an expected value.
+	default 12 if !BASE_SMALL
+	default 0 if BASE_SMALL
+	help
+	  This option allows to increase the default ring buffer size
+	  according to the number of CPUs. The value defines the contribution
+	  of each CPU as a power of 2. The used space is typically only few
+	  lines however it might be much more when problems are reported,
+	  e.g. backtraces.
+
+	  The increased size means that a new buffer has to be allocated and
+	  the original static one is unused. It makes sense only on systems
+	  with more CPUs. Therefore this value is used only when the sum of
+	  contributions is greater than the half of the default kernel ring
+	  buffer as defined by LOG_BUF_SHIFT. The default values are set
+	  so that more than 64 CPUs are needed to trigger the allocation.
+
+	  Also this option is ignored when "log_buf_len" kernel parameter is
+	  used as it forces an exact (power of two) size of the ring buffer.
 
 	  The number of possible CPUs is used for this computation ignoring
 	  hotplugging making the compuation optimal for the the worst case
-- 
1.8.4

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2014-06-26  6:22 Stephen Rothwell
@ 2014-06-26  8:29 ` Luis R. Rodriguez
  2014-06-26 11:45   ` Petr Mládek
  0 siblings, 1 reply; 330+ messages in thread
From: Luis R. Rodriguez @ 2014-06-26  8:29 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Andrew Morton, linux-next, linux-kernel, Petr Mladek

On Thu, Jun 26, 2014 at 04:22:57PM +1000, Stephen Rothwell wrote:
> Hi Andrew,
> 
> After merging the akpm tree, today's linux-next build (powerpc
> ppc44x_defconfig) failed like this:
> 
> kernel/printk/printk.c: In function 'log_buf_add_cpu':
> kernel/printk/printk.c:269:37: error: 'CONFIG_LOG_CPU_MAX_BUF_SHIFT' undeclared (first use in this function)
>  #define __LOG_CPU_MAX_BUF_LEN (1 << CONFIG_LOG_CPU_MAX_BUF_SHIFT)
>                                      ^
> kernel/printk/printk.c:864:42: note: in expansion of macro '__LOG_CPU_MAX_BUF_LEN'
>   cpu_extra = (num_possible_cpus() - 1) * __LOG_CPU_MAX_BUF_LEN;
>                                           ^
> kernel/printk/printk.c:269:37: note: each undeclared identifier is reported only once for each function it appears in
>  #define __LOG_CPU_MAX_BUF_LEN (1 << CONFIG_LOG_CPU_MAX_BUF_SHIFT)
>                                      ^
> kernel/printk/printk.c:864:42: note: in expansion of macro '__LOG_CPU_MAX_BUF_LEN'
>   cpu_extra = (num_possible_cpus() - 1) * __LOG_CPU_MAX_BUF_LEN;
>                                           ^
> 
> Caused by commit 58209adf633e ("printk: allow increasing the ring
> buffer depending on the number of CPUs").  CONFIG_LOG_CPU_MAX_BUF_SHIFT
> is not defined for this configuration.

diff --git a/init/Kconfig b/init/Kconfig
index 573d3f6..2339118 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -822,10 +822,9 @@ config LOG_BUF_SHIFT
 
 config LOG_CPU_MAX_BUF_SHIFT
 	int "CPU kernel log buffer size contribution (13 => 8 KB, 17 => 128KB)"
-	range 0 21
-	default 12
-	depends on SMP
-	depends on !BASE_SMALL
+	range 0 21 if SMP && !BASE_SMALL
+	default 12 if SMP && !BASE_SMALL
+	default 0 if !SMP || BASE_SMALL
 	help
 	  The kernel ring buffer will get additional data logged onto it
 	  when multiple CPUs are supported. Typically the contributions are

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

* linux-next: build failure after merge of the akpm-current tree
@ 2014-06-26  6:22 Stephen Rothwell
  2014-06-26  8:29 ` Luis R. Rodriguez
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2014-06-26  6:22 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Luis R. Rodriguez, Petr Mladek

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

Hi Andrew,

After merging the akpm tree, today's linux-next build (powerpc
ppc44x_defconfig) failed like this:

kernel/printk/printk.c: In function 'log_buf_add_cpu':
kernel/printk/printk.c:269:37: error: 'CONFIG_LOG_CPU_MAX_BUF_SHIFT' undeclared (first use in this function)
 #define __LOG_CPU_MAX_BUF_LEN (1 << CONFIG_LOG_CPU_MAX_BUF_SHIFT)
                                     ^
kernel/printk/printk.c:864:42: note: in expansion of macro '__LOG_CPU_MAX_BUF_LEN'
  cpu_extra = (num_possible_cpus() - 1) * __LOG_CPU_MAX_BUF_LEN;
                                          ^
kernel/printk/printk.c:269:37: note: each undeclared identifier is reported only once for each function it appears in
 #define __LOG_CPU_MAX_BUF_LEN (1 << CONFIG_LOG_CPU_MAX_BUF_SHIFT)
                                     ^
kernel/printk/printk.c:864:42: note: in expansion of macro '__LOG_CPU_MAX_BUF_LEN'
  cpu_extra = (num_possible_cpus() - 1) * __LOG_CPU_MAX_BUF_LEN;
                                          ^

Caused by commit 58209adf633e ("printk: allow increasing the ring
buffer depending on the number of CPUs").  CONFIG_LOG_CPU_MAX_BUF_SHIFT
is not defined for this configuration.

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

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

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2014-06-20  5:27 Stephen Rothwell
@ 2014-06-20  5:50 ` Joonsoo Kim
  0 siblings, 0 replies; 330+ messages in thread
From: Joonsoo Kim @ 2014-06-20  5:50 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Andrew Morton, linux-next, linux-kernel

On Fri, Jun 20, 2014 at 03:27:15PM +1000, Stephen Rothwell wrote:
> Hi Andrew,
> 
> After merging the akpm-current tree, today's linux-next build (arm
> defconfig) failed like this:
> 
> In file included from /scratch/sfr/next/arch/arm/mm/dma-mapping.c:29:0:
> /scratch/sfr/next/include/linux/cma.h:8:28: error: 'CONFIG_CMA_AREAS' undeclared here (not in a function)
>  #define MAX_CMA_AREAS (1 + CONFIG_CMA_AREAS)
>                             ^
> /scratch/sfr/next/arch/arm/mm/dma-mapping.c:434:54: note: in expansion of macro 'MAX_CMA_AREAS'
>  static struct dma_contig_early_reserve dma_mmu_remap[MAX_CMA_AREAS] __initdata;
>                                                       ^
> 
> Caused by commit f495d267b2e0 ("CMA: generalize CMA reserved area
> management functionality").
> 
> I have reverted that commit and these commits that depend on it
> 
> 57d551e70a38 ("mm, CMA: clean-up log message")
> d75ab106aef5 ("mm, CMA: change cma_declare_contiguous() to obey coding convention")
> f693a5424631 ("mm, CMA: clean-up CMA allocation error path")
> e58e263e5254 ("PPC, KVM, CMA: use general CMA reserved area management framework")
> 

Hello,

If below patch fixes above problem, is it possible to retain above patches
in linux-next?

Thanks.

---------8<----------------
>From e5c519c4b74914067e43cb55e232f19de9967324 Mon Sep 17 00:00:00 2001
From: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Date: Fri, 20 Jun 2014 13:30:56 +0900
Subject: [PATCH] CMA: fix ARM build failure related to MAX_CMA_AREAS
 definition

If CMA is disabled, CONFIG_CMA_AREAS isn't defined so compile error
happens. To fix it, define MAX_CMA_AREAS if CONFIG_CMA_AREAS
isn't defined.

Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>

diff --git a/include/linux/cma.h b/include/linux/cma.h
index 32cab7a..371b930 100644
--- a/include/linux/cma.h
+++ b/include/linux/cma.h
@@ -5,8 +5,14 @@
  * There is always at least global CMA area and a few optional
  * areas configured in kernel .config.
  */
+#ifdef CONFIG_CMA_AREAS
 #define MAX_CMA_AREAS	(1 + CONFIG_CMA_AREAS)
 
+#else
+#define MAX_CMA_AREAS	(0)
+
+#endif
+
 struct cma;
 
 extern phys_addr_t cma_get_base(struct cma *cma);
-- 
1.7.9.5

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

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

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

Hi Andrew,

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

In file included from /scratch/sfr/next/arch/arm/mm/dma-mapping.c:29:0:
/scratch/sfr/next/include/linux/cma.h:8:28: error: 'CONFIG_CMA_AREAS' undeclared here (not in a function)
 #define MAX_CMA_AREAS (1 + CONFIG_CMA_AREAS)
                            ^
/scratch/sfr/next/arch/arm/mm/dma-mapping.c:434:54: note: in expansion of macro 'MAX_CMA_AREAS'
 static struct dma_contig_early_reserve dma_mmu_remap[MAX_CMA_AREAS] __initdata;
                                                      ^

Caused by commit f495d267b2e0 ("CMA: generalize CMA reserved area
management functionality").

I have reverted that commit and these commits that depend on it

57d551e70a38 ("mm, CMA: clean-up log message")
d75ab106aef5 ("mm, CMA: change cma_declare_contiguous() to obey coding convention")
f693a5424631 ("mm, CMA: clean-up CMA allocation error path")
e58e263e5254 ("PPC, KVM, CMA: use general CMA reserved area management framework")

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

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

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2014-06-13  5:16 Stephen Rothwell
@ 2014-06-16 23:31 ` Andrew Morton
  0 siblings, 0 replies; 330+ messages in thread
From: Andrew Morton @ 2014-06-16 23:31 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Naoya Horiguchi, linux-mm

On Fri, 13 Jun 2014 15:16:52 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> At this point I got fed up and just dropped the akpm trees completely for today.
> 
> Was this stuff really meant for v3.16?

3.14 actually.  Then 3.15.  Now 3.16.

It's been quiet a burden and seems to have been hitting more problems
lately.  It's unclear than it does much for efficiency and while the
end result may be clearer to a newcomer, there's a cost to existing
developers in churning the code around.

So...  I think I'll drop this version of the patchset.  Naoya, please
grab all the patches as they fly past and ensure that nothing gets lost
in any future version, thanks.

I'll retain 

mm-hugetlbfs-fix-rmapping-for-anonymous-hugepages-with-page_pgoff.patch
mm-hugetlbfs-fix-rmapping-for-anonymous-hugepages-with-page_pgoff-v2.patch
mm-hugetlbfs-fix-rmapping-for-anonymous-hugepages-with-page_pgoff-v3.patch
mm-hugetlbfs-fix-rmapping-for-anonymous-hugepages-with-page_pgoff-v3-fix.patch

and shall drop

pagewalk-update-page-table-walker-core.patch
pagewalk-update-page-table-walker-core-fix-end-address-calculation-in-walk_page_range.patch
pagewalk-update-page-table-walker-core-fix-end-address-calculation-in-walk_page_range-fix.patch
pagewalk-update-page-table-walker-core-fix.patch
pagewalk-add-walk_page_vma.patch
smaps-redefine-callback-functions-for-page-table-walker.patch
clear_refs-redefine-callback-functions-for-page-table-walker.patch
pagemap-redefine-callback-functions-for-page-table-walker.patch
pagemap-redefine-callback-functions-for-page-table-walker-fix.patch
numa_maps-redefine-callback-functions-for-page-table-walker.patch
memcg-redefine-callback-functions-for-page-table-walker.patch
arch-powerpc-mm-subpage-protc-use-walk_page_vma-instead-of-walk_page_range.patch
pagewalk-remove-argument-hmask-from-hugetlb_entry.patch
pagewalk-remove-argument-hmask-from-hugetlb_entry-fix.patch
pagewalk-remove-argument-hmask-from-hugetlb_entry-fix-fix.patch
mempolicy-apply-page-table-walker-on-queue_pages_range.patch
mm-pagewalkc-move-pte-null-check.patch
mm-prom-pid-clear_refs-avoid-split_huge_page.patch
mm-pagewalk-remove-pgd_entry-and-pud_entry.patch
mm-pagewalk-replace-mm_walk-skip-with-more-general-mm_walk-control.patch
mm-pagewalk-replace-mm_walk-skip-with-more-general-mm_walk-control-fix.patch
madvise-cleanup-swapin_walk_pmd_entry.patch
madvise-cleanup-swapin_walk_pmd_entry-fix.patch
memcg-separate-mem_cgroup_move_charge_pte_range.patch
memcg-separate-mem_cgroup_move_charge_pte_range-checkpatch-fixes.patch
arch-powerpc-mm-subpage-protc-cleanup-subpage_walk_pmd_entry.patch
mm-pagewalk-move-pmd_trans_huge_lock-from-callbacks-to-common-code.patch
mm-pagewalk-move-pmd_trans_huge_lock-from-callbacks-to-common-code-checkpatch-fixes.patch
mincore-apply-page-table-walker-on-do_mincore.patch
mincore-apply-page-table-walker-on-do_mincore-fix.patch

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

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

* Re: linux-next: build failure after merge of the akpm-current tree
       [not found] ` <1402672324-io6h33kn@n-horiguchi@ah.jp.nec.com>
@ 2014-06-16  2:01   ` Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2014-06-16  2:01 UTC (permalink / raw)
  To: Naoya Horiguchi; +Cc: Andrew Morton, linux-next, linux-kernel, linux-mm

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

Hi Naoya,

On Fri, 13 Jun 2014 11:12:06 -0400 Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> wrote:
>
> On Fri, Jun 13, 2014 at 03:05:50PM +1000, Stephen Rothwell wrote:
> > 
> > After merging the akpm-current tree, today's linux-next build (powerpc ppc64_defconfig)
> > failed like this:
> > 
> > fs/proc/task_mmu.c: In function 'smaps_pmd':
> > include/linux/compiler.h:363:38: error: call to '__compiletime_assert_505' declared with attribute error: BUILD_BUG failed
> >   _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
> >                                       ^
> > include/linux/compiler.h:346:4: note: in definition of macro '__compiletime_assert'
> >     prefix ## suffix();    \
> >     ^
> > include/linux/compiler.h:363:2: note: in expansion of macro '_compiletime_assert'
> >   _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
> >   ^
> > include/linux/bug.h:50:37: note: in expansion of macro 'compiletime_assert'
> >  #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
> >                                      ^
> > include/linux/bug.h:84:21: note: in expansion of macro 'BUILD_BUG_ON_MSG'
> >  #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
> >                      ^
> > include/linux/huge_mm.h:167:27: note: in expansion of macro 'BUILD_BUG'
> >  #define HPAGE_PMD_SIZE ({ BUILD_BUG(); 0; })
> >                            ^
> > fs/proc/task_mmu.c:505:39: note: in expansion of macro 'HPAGE_PMD_SIZE'
> >   smaps_pte((pte_t *)pmd, addr, addr + HPAGE_PMD_SIZE, walk);
> >                                        ^
> > 
> > Caused by commit b0e08c526179 ("mm/pagewalk: move pmd_trans_huge_lock()
> > from callbacks to common code").
> > 
> > The reference to HPAGE_PMD_SIZE (which contains a BUILD_BUG() when
> > CONFIG_TRANSPARENT_HUGEPAGE is not defined) used to be protected by a
> > call to pmd_trans_huge_lock() (a static inline function that was
> > contact 0 when CONFIG_TRANSPARENT_HUGEPAGE is not defined) so gcc did
> > not see the reference and the BUG_ON.  That protection has been
> > removed ...
> > 
> > I have reverted that commit and commit 2dc554765dd1
> > ("mm-pagewalk-move-pmd_trans_huge_lock-from-callbacks-to-common-code-checkpatch-fixes")
> > that depend on it for today.
> 
> Sorry about that, this build failure happens because I moved the
> pmd_trans_huge_lock() into the common pagewalk code,
> clearly this makes mm_walk->pmd_entry handle only transparent hugepage,
> so the additional patch below explicitly declare it with #ifdef
> CONFIG_TRANSPARENT_HUGEPAGE.
> 
> I'll merge this in the next version of my series, but this will help
> linux-next for a quick solution.
> 
> Thanks,
> Naoya Horiguchi
> ---
> From da0850cd03baa3d50c8e353976b5b9edbfbd4413 Mon Sep 17 00:00:00 2001
> Date: Fri, 13 Jun 2014 10:33:26 -0400
> Subject: [PATCH] fix build error of v3.15-mmotm-2014-06-12-16-38
> 
> Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>

I added that to the akpm-current tree in linux-next today and the build
failures went away.

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


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

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2014-06-13  5:05 Stephen Rothwell
  2014-06-13  5:28 ` Stephen Rothwell
@ 2014-06-13 15:12 ` Naoya Horiguchi
       [not found] ` <1402672324-io6h33kn@n-horiguchi@ah.jp.nec.com>
  2 siblings, 0 replies; 330+ messages in thread
From: Naoya Horiguchi @ 2014-06-13 15:12 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Andrew Morton, linux-next, linux-kernel, linux-mm

# cced: linux-mm

Hi Stephen,

On Fri, Jun 13, 2014 at 03:05:50PM +1000, Stephen Rothwell wrote:
> Hi Andrew,
> 
> After merging the akpm-current tree, today's linux-next build (powerpc ppc64_defconfig)
> failed like this:
> 
> fs/proc/task_mmu.c: In function 'smaps_pmd':
> include/linux/compiler.h:363:38: error: call to '__compiletime_assert_505' declared with attribute error: BUILD_BUG failed
>   _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
>                                       ^
> include/linux/compiler.h:346:4: note: in definition of macro '__compiletime_assert'
>     prefix ## suffix();    \
>     ^
> include/linux/compiler.h:363:2: note: in expansion of macro '_compiletime_assert'
>   _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
>   ^
> include/linux/bug.h:50:37: note: in expansion of macro 'compiletime_assert'
>  #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
>                                      ^
> include/linux/bug.h:84:21: note: in expansion of macro 'BUILD_BUG_ON_MSG'
>  #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
>                      ^
> include/linux/huge_mm.h:167:27: note: in expansion of macro 'BUILD_BUG'
>  #define HPAGE_PMD_SIZE ({ BUILD_BUG(); 0; })
>                            ^
> fs/proc/task_mmu.c:505:39: note: in expansion of macro 'HPAGE_PMD_SIZE'
>   smaps_pte((pte_t *)pmd, addr, addr + HPAGE_PMD_SIZE, walk);
>                                        ^
> 
> Caused by commit b0e08c526179 ("mm/pagewalk: move pmd_trans_huge_lock()
> from callbacks to common code").
> 
> The reference to HPAGE_PMD_SIZE (which contains a BUILD_BUG() when
> CONFIG_TRANSPARENT_HUGEPAGE is not defined) used to be protected by a
> call to pmd_trans_huge_lock() (a static inline function that was
> contact 0 when CONFIG_TRANSPARENT_HUGEPAGE is not defined) so gcc did
> not see the reference and the BUG_ON.  That protection has been
> removed ...
> 
> I have reverted that commit and commit 2dc554765dd1
> ("mm-pagewalk-move-pmd_trans_huge_lock-from-callbacks-to-common-code-checkpatch-fixes")
> that depend on it for today.

Sorry about that, this build failure happens because I moved the
pmd_trans_huge_lock() into the common pagewalk code,
clearly this makes mm_walk->pmd_entry handle only transparent hugepage,
so the additional patch below explicitly declare it with #ifdef
CONFIG_TRANSPARENT_HUGEPAGE.

I'll merge this in the next version of my series, but this will help
linux-next for a quick solution.

Thanks,
Naoya Horiguchi
---
>From da0850cd03baa3d50c8e353976b5b9edbfbd4413 Mon Sep 17 00:00:00 2001
Date: Fri, 13 Jun 2014 10:33:26 -0400
Subject: [PATCH] fix build error of v3.15-mmotm-2014-06-12-16-38

Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
---
 fs/proc/task_mmu.c | 17 +++++++++++++++++
 mm/memcontrol.c    |  8 ++++++++
 mm/mincore.c       |  4 ++++
 3 files changed, 29 insertions(+)

diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index f42f658640cd..60ce441ee103 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -498,6 +498,7 @@ static int smaps_pte(pte_t *pte, unsigned long addr, unsigned long end,
 	return 0;
 }
 
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
 static int smaps_pmd(pmd_t *pmd, unsigned long addr, unsigned long end,
 			struct mm_walk *walk)
 {
@@ -506,6 +507,7 @@ static int smaps_pmd(pmd_t *pmd, unsigned long addr, unsigned long end,
 	mss->anonymous_thp += HPAGE_PMD_SIZE;
 	return 0;
 }
+#endif
 
 static void show_smap_vma_flags(struct seq_file *m, struct vm_area_struct *vma)
 {
@@ -568,7 +570,9 @@ static int show_smap(struct seq_file *m, void *v, int is_pid)
 	struct vm_area_struct *vma = v;
 	struct mem_size_stats mss;
 	struct mm_walk smaps_walk = {
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
 		.pmd_entry = smaps_pmd,
+#endif
 		.pte_entry = smaps_pte,
 		.mm = vma->vm_mm,
 		.vma = vma,
@@ -774,6 +778,7 @@ static int clear_refs_pte(pte_t *pte, unsigned long addr,
 	return 0;
 }
 
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
 static int clear_refs_pmd(pmd_t *pmd, unsigned long addr,
 				unsigned long end, struct mm_walk *walk)
 {
@@ -800,6 +805,7 @@ static int clear_refs_pmd(pmd_t *pmd, unsigned long addr,
 	walk->control = PTWALK_DOWN;
 	return 0;
 }
+#endif
 
 static int clear_refs_test_walk(unsigned long start, unsigned long end,
 				struct mm_walk *walk)
@@ -865,7 +871,9 @@ static ssize_t clear_refs_write(struct file *file, const char __user *buf,
 		};
 		struct mm_walk clear_refs_walk = {
 			.pte_entry = clear_refs_pte,
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
 			.pmd_entry = clear_refs_pmd,
+#endif
 			.test_walk = clear_refs_test_walk,
 			.mm = mm,
 			.private = &cp,
@@ -1030,6 +1038,7 @@ static int pagemap_pte(pte_t *pte, unsigned long addr, unsigned long end,
 	return add_to_pagemap(addr, &pme, pm);
 }
 
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
 static int pagemap_pmd(pmd_t *pmd, unsigned long addr, unsigned long end,
 			     struct mm_walk *walk)
 {
@@ -1055,6 +1064,7 @@ static int pagemap_pmd(pmd_t *pmd, unsigned long addr, unsigned long end,
 	}
 	return err;
 }
+#endif
 
 #ifdef CONFIG_HUGETLB_PAGE
 static void huge_pte_to_pagemap_entry(pagemap_entry_t *pme, struct pagemapread *pm,
@@ -1160,7 +1170,9 @@ static ssize_t pagemap_read(struct file *file, char __user *buf,
 		goto out_free;
 
 	pagemap_walk.pte_entry = pagemap_pte;
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
 	pagemap_walk.pmd_entry = pagemap_pmd;
+#endif
 	pagemap_walk.pte_hole = pagemap_pte_hole;
 #ifdef CONFIG_HUGETLB_PAGE
 	pagemap_walk.hugetlb_entry = pagemap_hugetlb;
@@ -1316,6 +1328,7 @@ static int gather_pte_stats(pte_t *pte, unsigned long addr,
 	return 0;
 }
 
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
 static int gather_pmd_stats(pmd_t *pmd, unsigned long addr,
 		unsigned long end, struct mm_walk *walk)
 {
@@ -1330,6 +1343,8 @@ static int gather_pmd_stats(pmd_t *pmd, unsigned long addr,
 			     HPAGE_PMD_SIZE/PAGE_SIZE);
 	return 0;
 }
+#endif
+
 #ifdef CONFIG_HUGETLB_PAGE
 static int gather_hugetlb_stats(pte_t *pte, unsigned long addr,
 				unsigned long end, struct mm_walk *walk)
@@ -1381,7 +1396,9 @@ static int show_numa_map(struct seq_file *m, void *v, int is_pid)
 	memset(md, 0, sizeof(*md));
 
 	walk.hugetlb_entry = gather_hugetlb_stats;
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
 	walk.pmd_entry = gather_pmd_stats;
+#endif
 	walk.pte_entry = gather_pte_stats;
 	walk.private = md;
 	walk.mm = mm;
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index cb11c74f2a5a..2a18af6d9cf4 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -6729,6 +6729,7 @@ static int mem_cgroup_count_precharge_pte(pte_t *pte,
 	return 0;
 }
 
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
 static int mem_cgroup_count_precharge_pmd(pmd_t *pmd,
 					unsigned long addr, unsigned long end,
 					struct mm_walk *walk)
@@ -6739,6 +6740,7 @@ static int mem_cgroup_count_precharge_pmd(pmd_t *pmd,
 		mc.precharge += HPAGE_PMD_NR;
 	return 0;
 }
+#endif
 
 static unsigned long mem_cgroup_count_precharge(struct mm_struct *mm)
 {
@@ -6746,7 +6748,9 @@ static unsigned long mem_cgroup_count_precharge(struct mm_struct *mm)
 	struct vm_area_struct *vma;
 
 	struct mm_walk mem_cgroup_count_precharge_walk = {
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
 		.pmd_entry = mem_cgroup_count_precharge_pmd,
+#endif
 		.pte_entry = mem_cgroup_count_precharge_pte,
 		.mm = mm,
 	};
@@ -6948,6 +6952,7 @@ put:		/* get_mctgt_type() gets the page */
 	return 0;
 }
 
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
 static int mem_cgroup_move_charge_pmd(pmd_t *pmd,
 				unsigned long addr, unsigned long end,
 				struct mm_walk *walk)
@@ -6976,12 +6981,15 @@ static int mem_cgroup_move_charge_pmd(pmd_t *pmd,
 	}
 	return 0;
 }
+#endif
 
 static void mem_cgroup_move_charge(struct mm_struct *mm)
 {
 	struct vm_area_struct *vma;
 	struct mm_walk mem_cgroup_move_charge_walk = {
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
 		.pmd_entry = mem_cgroup_move_charge_pmd,
+#endif
 		.pte_entry = mem_cgroup_move_charge_pte,
 		.mm = mm,
 	};
diff --git a/mm/mincore.c b/mm/mincore.c
index 9f89c34303ec..d8a5e9f62268 100644
--- a/mm/mincore.c
+++ b/mm/mincore.c
@@ -138,6 +138,7 @@ static int mincore_pte(pte_t *pte, unsigned long addr, unsigned long end,
 	return 0;
 }
 
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
 static int mincore_pmd(pmd_t *pmd, unsigned long addr, unsigned long end,
 			struct mm_walk *walk)
 {
@@ -145,6 +146,7 @@ static int mincore_pmd(pmd_t *pmd, unsigned long addr, unsigned long end,
 	walk->private += (end - addr) >> PAGE_SHIFT;
 	return 0;
 }
+#endif
 
 /*
  * Do a chunk of "sys_mincore()". We've already checked
@@ -157,7 +159,9 @@ static long do_mincore(unsigned long addr, unsigned long pages,
 	struct vm_area_struct *vma;
 	int err;
 	struct mm_walk mincore_walk = {
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
 		.pmd_entry = mincore_pmd,
+#endif
 		.pte_entry = mincore_pte,
 		.pte_hole = mincore_hole,
 		.hugetlb_entry = mincore_hugetlb,
-- 
1.9.3

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2014-06-13  5:05 Stephen Rothwell
@ 2014-06-13  5:28 ` Stephen Rothwell
  2014-06-13 15:12 ` Naoya Horiguchi
       [not found] ` <1402672324-io6h33kn@n-horiguchi@ah.jp.nec.com>
  2 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2014-06-13  5:28 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Naoya Horiguchi

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

On Fri, 13 Jun 2014 15:05:50 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> The reference to HPAGE_PMD_SIZE (which contains a BUILD_BUG() when
> CONFIG_TRANSPARENT_HUGEPAGE is not defined) used to be protected by a
> call to pmd_trans_huge_lock() (a static inline function that was
> contact 0 when CONFIG_TRANSPARENT_HUGEPAGE is not defined) so gcc did
  ^^^^^^^
constant

> not see the reference and the BUG_ON.  That protection has been
> removed ...

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

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

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

* linux-next: build failure after merge of the akpm-current tree
@ 2014-06-13  5:16 Stephen Rothwell
  2014-06-16 23:31 ` Andrew Morton
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2014-06-13  5:16 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Naoya Horiguchi

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

Hi Andrew,

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

mm/memcontrol.c:6674:3: note: each undeclared identifier is reported only once for each function it appears in
mm/memcontrol.c: In function 'mem_cgroup_move_charge_pmd':
mm/memcontrol.c:6906:37: error: 'ptl' undeclared (first use in this function)
  if (pmd_trans_huge_lock(pmd, vma, &ptl) == 1) {
                                     ^

Caused by commit ce1c26c7ca47 ("memcg: separate
mem_cgroup_move_charge_pte_range()") - uncovered by my previous reverts.

I have reverted that commit and commit 2fba70f78e45
("memcg-separate-mem_cgroup_move_charge_pte_range-checkpatch-fixes")
that depends on it for today.

Which lead to:

mm/memcontrol.c: In function 'mem_cgroup_count_precharge_pmd':
mm/memcontrol.c:6674:3: error: 'skip' undeclared (first use in this function)
   skip->control = PTWALK_DOWN;
   ^

Caused by commit 7170d5e9623b ("mm/pagewalk: replace mm_walk->skip with
more general mm_walk->control").

At this point I got fed up and just dropped the akpm trees completely for today.

Was this stuff really meant for v3.16?
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

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

* linux-next: build failure after merge of the akpm-current tree
@ 2014-06-13  5:05 Stephen Rothwell
  2014-06-13  5:28 ` Stephen Rothwell
                   ` (2 more replies)
  0 siblings, 3 replies; 330+ messages in thread
From: Stephen Rothwell @ 2014-06-13  5:05 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Naoya Horiguchi

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

Hi Andrew,

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

fs/proc/task_mmu.c: In function 'smaps_pmd':
include/linux/compiler.h:363:38: error: call to '__compiletime_assert_505' declared with attribute error: BUILD_BUG failed
  _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
                                      ^
include/linux/compiler.h:346:4: note: in definition of macro '__compiletime_assert'
    prefix ## suffix();    \
    ^
include/linux/compiler.h:363:2: note: in expansion of macro '_compiletime_assert'
  _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
  ^
include/linux/bug.h:50:37: note: in expansion of macro 'compiletime_assert'
 #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
                                     ^
include/linux/bug.h:84:21: note: in expansion of macro 'BUILD_BUG_ON_MSG'
 #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
                     ^
include/linux/huge_mm.h:167:27: note: in expansion of macro 'BUILD_BUG'
 #define HPAGE_PMD_SIZE ({ BUILD_BUG(); 0; })
                           ^
fs/proc/task_mmu.c:505:39: note: in expansion of macro 'HPAGE_PMD_SIZE'
  smaps_pte((pte_t *)pmd, addr, addr + HPAGE_PMD_SIZE, walk);
                                       ^

Caused by commit b0e08c526179 ("mm/pagewalk: move pmd_trans_huge_lock()
from callbacks to common code").

The reference to HPAGE_PMD_SIZE (which contains a BUILD_BUG() when
CONFIG_TRANSPARENT_HUGEPAGE is not defined) used to be protected by a
call to pmd_trans_huge_lock() (a static inline function that was
contact 0 when CONFIG_TRANSPARENT_HUGEPAGE is not defined) so gcc did
not see the reference and the BUG_ON.  That protection has been
removed ...

I have reverted that commit and commit 2dc554765dd1
("mm-pagewalk-move-pmd_trans_huge_lock-from-callbacks-to-common-code-checkpatch-fixes")
that depend on it for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2014-05-14 21:55 ` Andrew Morton
@ 2014-05-14 21:57   ` Tejun Heo
  0 siblings, 0 replies; 330+ messages in thread
From: Tejun Heo @ 2014-05-14 21:57 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Stephen Rothwell, linux-next, linux-kernel, Michal Hocko

Hello,

On Wed, May 14, 2014 at 02:55:20PM -0700, Andrew Morton wrote:
> > @@ -6026,7 +6026,7 @@ static struct cftype mem_cgroup_files[] = {
> >  	{
> >  		.name = "low_limit_in_bytes",
> >  		.private = MEMFILE_PRIVATE(_MEM, RES_LOW_LIMIT),
> > -		.write_string = mem_cgroup_write,
> > +		.write = mem_cgroup_write,
> >  		.read_u64 = mem_cgroup_read_u64,
> >  	},
> 
> Renaming buffer to buf was rather unneeded.
> 
> I have 24 patches here against mm/memcontrol.c.  Go gently, please.

Yeah, sorry about that.  That conflict wasn't necessary.

Thanks.

-- 
tejun

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2014-05-14  7:47 Stephen Rothwell
@ 2014-05-14 21:55 ` Andrew Morton
  2014-05-14 21:57   ` Tejun Heo
  0 siblings, 1 reply; 330+ messages in thread
From: Andrew Morton @ 2014-05-14 21:55 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Tejun Heo, linux-next, linux-kernel, Michal Hocko

On Wed, 14 May 2014 17:47:49 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Andrew,
> 
> After merging the akpm-current tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> mm/memcontrol.c: In function 'mem_cgroup_write':
> mm/memcontrol.c:5088:45: error: 'buffer' undeclared (first use in this function)
>    ret = res_counter_memparse_write_strategy(buffer, &val);
>                                              ^
> mm/memcontrol.c: At top level:
> /scratch/sfr/next/mm/memcontrol.c:6029:3: error: unknown field 'write_string' specified in initializer
>    .write_string = mem_cgroup_write,
>    ^
> 
> Caused by commit a4bf584ed8c2 ("memcg: allow setting low_limit")
> interacting with commit 451af504df0c ("cgroup: replace
> cftype->write_string() with cftype->write()") from the cgroup tree.
> (I love API changes and unnecessary variable renaming :-()
> 
> ...
>
> @@ -6026,7 +6026,7 @@ static struct cftype mem_cgroup_files[] = {
>  	{
>  		.name = "low_limit_in_bytes",
>  		.private = MEMFILE_PRIVATE(_MEM, RES_LOW_LIMIT),
> -		.write_string = mem_cgroup_write,
> +		.write = mem_cgroup_write,
>  		.read_u64 = mem_cgroup_read_u64,
>  	},

Renaming buffer to buf was rather unneeded.

I have 24 patches here against mm/memcontrol.c.  Go gently, please.

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

* linux-next: build failure after merge of the akpm-current tree
@ 2014-05-14  7:47 Stephen Rothwell
  2014-05-14 21:55 ` Andrew Morton
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2014-05-14  7:47 UTC (permalink / raw)
  To: Andrew Morton, Tejun Heo; +Cc: linux-next, linux-kernel, Michal Hocko

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

Hi Andrew,

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

mm/memcontrol.c: In function 'mem_cgroup_write':
mm/memcontrol.c:5088:45: error: 'buffer' undeclared (first use in this function)
   ret = res_counter_memparse_write_strategy(buffer, &val);
                                             ^
mm/memcontrol.c: At top level:
/scratch/sfr/next/mm/memcontrol.c:6029:3: error: unknown field 'write_string' specified in initializer
   .write_string = mem_cgroup_write,
   ^

Caused by commit a4bf584ed8c2 ("memcg: allow setting low_limit")
interacting with commit 451af504df0c ("cgroup: replace
cftype->write_string() with cftype->write()") from the cgroup tree.
(I love API changes and unnecessary variable renaming :-()

I applied the following merge fix patch and can carry it as necessary:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 14 May 2014 17:42:00 +1000
Subject: [PATCH] memcg: update for change from write_string() to write()

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 mm/memcontrol.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 493175e616e3..98e38b50cc82 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -5085,7 +5085,7 @@ static ssize_t mem_cgroup_write(struct kernfs_open_file *of,
 			ret = -EINVAL;
 			break;
 		}
-		ret = res_counter_memparse_write_strategy(buffer, &val);
+		ret = res_counter_memparse_write_strategy(buf, &val);
 		if (ret)
 			break;
 		if (type == _MEM) {
@@ -6026,7 +6026,7 @@ static struct cftype mem_cgroup_files[] = {
 	{
 		.name = "low_limit_in_bytes",
 		.private = MEMFILE_PRIVATE(_MEM, RES_LOW_LIMIT),
-		.write_string = mem_cgroup_write,
+		.write = mem_cgroup_write,
 		.read_u64 = mem_cgroup_read_u64,
 	},
 	{
-- 
2.0.0.rc2

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

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

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

* linux-next: build failure after merge of the akpm-current tree
@ 2014-05-14  7:30 Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2014-05-14  7:30 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Mel Gorman, Rik van Riel

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

Hi Andrew,

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

In file included from arch/powerpc/mm/numa.c:23:0:
include/linux/cpuset.h: In function 'cpusets_enabled':
include/linux/cpuset.h:21:2: error: implicit declaration of function 'static_key_false' [-Werror=implicit-function-declaration]
  return static_key_false(&cpusets_enabled_key);
  ^
include/linux/cpuset.h: In function 'nr_cpusets':
include/linux/cpuset.h:27:2: error: implicit declaration of function 'static_key_count' [-Werror=implicit-function-declaration]
  return static_key_count(&cpusets_enabled_key) + 1;
  ^
include/linux/cpuset.h: In function 'cpuset_inc':
include/linux/cpuset.h:32:2: error: implicit declaration of function 'static_key_slow_inc' [-Werror=implicit-function-declaration]
  static_key_slow_inc(&cpusets_enabled_key);
  ^
include/linux/cpuset.h: In function 'cpuset_dec':
include/linux/cpuset.h:37:2: error: implicit declaration of function 'static_key_slow_dec' [-Werror=implicit-function-declaration]
  static_key_slow_dec(&cpusets_enabled_key);
  ^

And lots more - you get the idea.

Caused by commit 95d217015fd3 ("mm: page_alloc: use jump labels to
avoid checking number_of_cpusets").  See Rule 1 in
Documentation/SubmitChecklist :-(

I have reverted that commit for today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2014-04-29  7:13 Stephen Rothwell
@ 2014-04-29 13:09 ` Don Zickus
  0 siblings, 0 replies; 330+ messages in thread
From: Don Zickus @ 2014-04-29 13:09 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Andrew Morton, linux-next, linux-kernel, Aaron Tomlin

On Tue, Apr 29, 2014 at 05:13:21PM +1000, Stephen Rothwell wrote:
> Hi Andrew,
> 
> After merging the akpm tree, today's linux-next build (sparc64 defconfig)
> failed like this:
> 
> arch/sparc/kernel/process_64.c: In function 'arch_trigger_all_cpu_backtrace':
> arch/sparc/kernel/process_64.c:267:3: error: ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement]
> cc1: all warnings being treated as errors
> 
> Caused by commit dd0063a16aa1 ("nmi: provide the option to issue an NMI
> back trace to every cpu but current").
> 
> I have no idea why I did not see this yesterday.
> 
> I applied the following fix up patch:

I apologize for that.  The downsides of making changes without having a
cross compiler.  Thanks for the fixup!

Cheers,
Don

> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 29 Apr 2014 17:10:00 +1000
> Subject: [PATCH] nmi-provide-the-option-to-issue-an-nmi-back-trace-to-every-cpu-but-current-fix
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  arch/sparc/kernel/process_64.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/sparc/kernel/process_64.c b/arch/sparc/kernel/process_64.c
> index 65b405c36421..9975a6dbca0a 100644
> --- a/arch/sparc/kernel/process_64.c
> +++ b/arch/sparc/kernel/process_64.c
> @@ -261,10 +261,12 @@ void arch_trigger_all_cpu_backtrace(bool include_self)
>  	smp_fetch_global_regs();
>  
>  	for_each_online_cpu(cpu) {
> +		struct global_reg_snapshot *gp;
> +
>  		if (!include_self && cpu == this_cpu)
>  			continue;
>  
> -		struct global_reg_snapshot *gp = &global_cpu_snapshot[cpu].reg;
> +		gp = &global_cpu_snapshot[cpu].reg;
>  
>  		__global_reg_poll(gp);
>  
> -- 
> 2.0.0.rc0
> 
> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au

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

* linux-next: build failure after merge of the akpm-current tree
@ 2014-04-29  7:13 Stephen Rothwell
  2014-04-29 13:09 ` Don Zickus
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2014-04-29  7:13 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Aaron Tomlin, Don Zickus

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

Hi Andrew,

After merging the akpm tree, today's linux-next build (sparc64 defconfig)
failed like this:

arch/sparc/kernel/process_64.c: In function 'arch_trigger_all_cpu_backtrace':
arch/sparc/kernel/process_64.c:267:3: error: ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement]
cc1: all warnings being treated as errors

Caused by commit dd0063a16aa1 ("nmi: provide the option to issue an NMI
back trace to every cpu but current").

I have no idea why I did not see this yesterday.

I applied the following fix up patch:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 29 Apr 2014 17:10:00 +1000
Subject: [PATCH] nmi-provide-the-option-to-issue-an-nmi-back-trace-to-every-cpu-but-current-fix

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/sparc/kernel/process_64.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/sparc/kernel/process_64.c b/arch/sparc/kernel/process_64.c
index 65b405c36421..9975a6dbca0a 100644
--- a/arch/sparc/kernel/process_64.c
+++ b/arch/sparc/kernel/process_64.c
@@ -261,10 +261,12 @@ void arch_trigger_all_cpu_backtrace(bool include_self)
 	smp_fetch_global_regs();
 
 	for_each_online_cpu(cpu) {
+		struct global_reg_snapshot *gp;
+
 		if (!include_self && cpu == this_cpu)
 			continue;
 
-		struct global_reg_snapshot *gp = &global_cpu_snapshot[cpu].reg;
+		gp = &global_cpu_snapshot[cpu].reg;
 
 		__global_reg_poll(gp);
 
-- 
2.0.0.rc0

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

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* linux-next: build failure after merge of the akpm-current tree
@ 2014-04-23  4:17 Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2014-04-23  4:17 UTC (permalink / raw)
  To: Andrew Morton
  Cc: linux-next, linux-kernel, Nishanth Aravamudan, Aneesh Kumar K.V,
	Mel Gorman

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

Hi Andrew,

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

In file included from arch/arm/mm/flush.c:20:0:
include/linux/hugetlb.h: In function 'hugepages_supported':
include/linux/hugetlb.h:468:9: error: 'HPAGE_SHIFT' undeclared (first use in this function)

And a few more similarly.

Caused by commit c669debfbf05 ("hugetlb: ensure hugepage access is denied
if hugepages are not supported").

I added the following fix patch:

From 91e29eff2be1b6bc0c9ea33b1ee901dd4877e924 Mon Sep 17 00:00:00 2001
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 23 Apr 2014 14:12:56 +1000
Subject: [PATCH] hugetlb: ensure hugepage access is denied if hugepages are
 not supported -fix

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 include/linux/hugetlb.h | 19 +++++++++----------
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 4eace5e94117..cbee9847e425 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -214,6 +214,15 @@ static inline int is_file_hugepages(struct file *file)
 	return 0;
 }
 
+static inline bool hugepages_supported(void)
+{
+	/*
+	 * Some platform decide whether they support huge pages at boot
+	 * time. On these, such as powerpc, HPAGE_SHIFT is set to 0 when
+	 * there is no such support
+	 */
+	return HPAGE_SHIFT != 0;
+}
 
 #else /* !CONFIG_HUGETLBFS */
 
@@ -458,14 +467,4 @@ static inline spinlock_t *huge_pte_lock(struct hstate *h,
 	return ptl;
 }
 
-static inline bool hugepages_supported(void)
-{
-	/*
-	 * Some platform decide whether they support huge pages at boot
-	 * time. On these, such as powerpc, HPAGE_SHIFT is set to 0 when
-	 * there is no such support
-	 */
-	return HPAGE_SHIFT != 0;
-}
-
 #endif /* _LINUX_HUGETLB_H */
-- 
1.9.2

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2014-04-17  7:08 Stephen Rothwell
@ 2014-04-17  9:56 ` Mel Gorman
  0 siblings, 0 replies; 330+ messages in thread
From: Mel Gorman @ 2014-04-17  9:56 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Andrew Morton, linux-next, linux-kernel

On Thu, Apr 17, 2014 at 05:08:31PM +1000, Stephen Rothwell wrote:
> Hi Andrew,
> 
> After merging the akpm-current tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> In file included from mm/shmem.c:61:0:
> include/linux/swapops.h: In function 'is_swap_pte':
> include/linux/swapops.h:57:2: error: implicit declaration of function 'pte_present_nonuma' [-Werror=implicit-function-declaration]
> 
> And a couple more similar.
> 
> Caused by commit 851fe3337768 ("x86: define _PAGE_NUMA by reusing
> software bits on the PMD and PTE levels").
> 
> I have reverted this commit (and 7cb1c1eb682e "x86: define _PAGE_NUMA by
> reusing software bits on the PMD and PTE levels -fix") for today and
> wonder how many other architectures would be broken by this?  Everything
> else with CONFIG_MMU set?
> 

/me slaps self

Andrew, can you replace the broken fix with this version please?

---8<---
x86: define _PAGE_NUMA by reusing software bits on the PMD and PTE levels -fix

powerpc has NUMA_BALANCING and non-NUMA_BALANCING versions of pte_present
and I missed that when testing cross-compiling. This patch replaces
x86-define-_page_numa-by-reusing-software-bits-on-the-pmd-and-pte-levels-fix.patch

Signed-off-by: Mel Gorman <mgorman@suse.de>
---
 arch/powerpc/include/asm/pgtable.h | 1 +
 arch/x86/include/asm/pgtable.h     | 1 +
 include/asm-generic/pgtable.h      | 4 ++++
 3 files changed, 6 insertions(+)

diff --git a/arch/powerpc/include/asm/pgtable.h b/arch/powerpc/include/asm/pgtable.h
index cdf6679..d98c1ec 100644
--- a/arch/powerpc/include/asm/pgtable.h
+++ b/arch/powerpc/include/asm/pgtable.h
@@ -44,6 +44,7 @@ static inline int pte_present(pte_t pte)
 	return pte_val(pte) & (_PAGE_PRESENT | _PAGE_NUMA);
 }
 
+#define pte_present_nonuma pte_present_nonuma
 static inline int pte_present_nonuma(pte_t pte)
 {
 	return pte_val(pte) & (_PAGE_PRESENT);
diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
index 611dd32..d772c9c 100644
--- a/arch/x86/include/asm/pgtable.h
+++ b/arch/x86/include/asm/pgtable.h
@@ -452,6 +452,7 @@ static inline int pte_present(pte_t a)
 			       _PAGE_NUMA);
 }
 
+#define pte_present_nonuma pte_present_nonuma
 static inline int pte_present_nonuma(pte_t a)
 {
 	return pte_flags(a) & (_PAGE_PRESENT | _PAGE_PROTNONE);
diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
index d2b92be..8916a76 100644
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -220,6 +220,10 @@ static inline int pmd_same(pmd_t pmd_a, pmd_t pmd_b)
 # define pte_accessible(mm, pte)	((void)(pte), 1)
 #endif
 
+#ifndef pte_present_nonuma
+#define pte_present_nonuma(pte) pte_present(pte)
+#endif
+
 #ifndef flush_tlb_fix_spurious_fault
 #define flush_tlb_fix_spurious_fault(vma, address) flush_tlb_page(vma, address)
 #endif

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

* linux-next: build failure after merge of the akpm-current tree
@ 2014-04-17  7:08 Stephen Rothwell
  2014-04-17  9:56 ` Mel Gorman
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2014-04-17  7:08 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Mel Gorman

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

Hi Andrew,

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

In file included from mm/shmem.c:61:0:
include/linux/swapops.h: In function 'is_swap_pte':
include/linux/swapops.h:57:2: error: implicit declaration of function 'pte_present_nonuma' [-Werror=implicit-function-declaration]

And a couple more similar.

Caused by commit 851fe3337768 ("x86: define _PAGE_NUMA by reusing
software bits on the PMD and PTE levels").

I have reverted this commit (and 7cb1c1eb682e "x86: define _PAGE_NUMA by
reusing software bits on the PMD and PTE levels -fix") for today and
wonder how many other architectures would be broken by this?  Everything
else with CONFIG_MMU set?

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

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2014-04-16 19:21 ` Mel Gorman
@ 2014-04-16 23:54   ` Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2014-04-16 23:54 UTC (permalink / raw)
  To: Mel Gorman; +Cc: Andrew Morton, linux-next, linux-kernel

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

Hi Mel, Andrew,

On Wed, 16 Apr 2014 20:21:35 +0100 Mel Gorman <mgorman@suse.de> wrote:
>
> On Wed, Apr 16, 2014 at 03:19:56PM +1000, Stephen Rothwell wrote:
> > 
> > After merging the akpm-current tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> > 
> > In file included from mm/vmscan.c:50:0:
> > include/linux/swapops.h: In function 'is_swap_pte':
> > include/linux/swapops.h:57:2: error: implicit declaration of function 'pte_present_nonuma' [-Werror=implicit-function-declaration]
> >   return !pte_none(pte) && !pte_present_nonuma(pte) && !pte_file(pte);
> >   ^
> > 
> > Caused by commit 851fe3337768 ("x86: define _PAGE_NUMA by reusing
> > software bits on the PMD and PTE levels").  This build does not have
> > CONFIG_NUMA_BALANCING set.
> > 
> > I have reverted that commit for today.
> 
> Thanks Stephen. A patch that should address the problem is on its way to
> Andrew.

I grabbed it out of mmots and added it to linux-next for today (in case a
new mmotm does not appear in time).
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2014-04-16  5:19 Stephen Rothwell
@ 2014-04-16 19:21 ` Mel Gorman
  2014-04-16 23:54   ` Stephen Rothwell
  0 siblings, 1 reply; 330+ messages in thread
From: Mel Gorman @ 2014-04-16 19:21 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Andrew Morton, linux-next, linux-kernel

On Wed, Apr 16, 2014 at 03:19:56PM +1000, Stephen Rothwell wrote:
> Hi Andrew,
> 
> After merging the akpm-current tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> In file included from mm/vmscan.c:50:0:
> include/linux/swapops.h: In function 'is_swap_pte':
> include/linux/swapops.h:57:2: error: implicit declaration of function 'pte_present_nonuma' [-Werror=implicit-function-declaration]
>   return !pte_none(pte) && !pte_present_nonuma(pte) && !pte_file(pte);
>   ^
> 
> Caused by commit 851fe3337768 ("x86: define _PAGE_NUMA by reusing
> software bits on the PMD and PTE levels").  This build does not have
> CONFIG_NUMA_BALANCING set.
> 
> I have reverted that commit for today.

Thanks Stephen. A patch that should address the problem is on its way to
Andrew.

-- 
Mel Gorman
SUSE Labs

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2014-04-16  6:06 Stephen Rothwell
@ 2014-04-16  6:42 ` Benjamin Herrenschmidt
  0 siblings, 0 replies; 330+ messages in thread
From: Benjamin Herrenschmidt @ 2014-04-16  6:42 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Andrew Morton, linux-next, linux-kernel, Laura Abbott

On Wed, 2014-04-16 at 16:06 +1000, Stephen Rothwell wrote:
> Hi Andrew,
> 
> After merging the akpm tree, today's linux-next build (powerpc
> ppc44x_defconfig) failed like this:
> 
> arch/powerpc/platforms/44x/warp.c: In function 'warp_probe':
> arch/powerpc/platforms/44x/warp.c:52:2: error: 'ISA_DMA_THRESHOLD' undeclared (first use in this function)
> arch/powerpc/mm/dma-noncoherent.c: In function '__dma_alloc_coherent':
> arch/powerpc/mm/dma-noncoherent.c:159:13: error: 'ISA_DMA_THRESHOLD' undeclared (first use in this function)
> 
> Probably caused by commit ff35bd54456e ("lib/scatterlist: make
> ARCH_HAS_SG_CHAIN an actual Kconfig") which removed an implicit include
> of <asm/dma.h> with the removal of the arch specific scatterlist.h.
> 
> I have added the following patch for today:

Patch looks good, poke me next week when I'm back and I'll apply it

or send it to Linus or akpm with my

Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

Cheers,
Ben.

> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 16 Apr 2014 16:03:01 +1000
> Subject: [PATCH] lib/scatterlist: make ARCH_HAS_SG_CHAIN an actual Kconfig fix
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  arch/powerpc/mm/dma-noncoherent.c | 1 +
>  arch/powerpc/platforms/44x/warp.c | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/arch/powerpc/mm/dma-noncoherent.c b/arch/powerpc/mm/dma-noncoherent.c
> index 7b6c10750179..d85e86aac7fb 100644
> --- a/arch/powerpc/mm/dma-noncoherent.c
> +++ b/arch/powerpc/mm/dma-noncoherent.c
> @@ -33,6 +33,7 @@
>  #include <linux/export.h>
>  
>  #include <asm/tlbflush.h>
> +#include <asm/dma.h>
>  
>  #include "mmu_decl.h"
>  
> diff --git a/arch/powerpc/platforms/44x/warp.c b/arch/powerpc/platforms/44x/warp.c
> index 534574a97ec9..3a104284b338 100644
> --- a/arch/powerpc/platforms/44x/warp.c
> +++ b/arch/powerpc/platforms/44x/warp.c
> @@ -25,6 +25,7 @@
>  #include <asm/time.h>
>  #include <asm/uic.h>
>  #include <asm/ppc4xx.h>
> +#include <asm/dma.h>
>  
> 
>  static __initdata struct of_device_id warp_of_bus[] = {
> -- 
> 1.9.2
> 

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

* linux-next: build failure after merge of the akpm-current tree
@ 2014-04-16  6:06 Stephen Rothwell
  2014-04-16  6:42 ` Benjamin Herrenschmidt
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2014-04-16  6:06 UTC (permalink / raw)
  To: Andrew Morton, Benjamin Herrenschmidt
  Cc: linux-next, linux-kernel, Laura Abbott

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

Hi Andrew,

After merging the akpm tree, today's linux-next build (powerpc
ppc44x_defconfig) failed like this:

arch/powerpc/platforms/44x/warp.c: In function 'warp_probe':
arch/powerpc/platforms/44x/warp.c:52:2: error: 'ISA_DMA_THRESHOLD' undeclared (first use in this function)
arch/powerpc/mm/dma-noncoherent.c: In function '__dma_alloc_coherent':
arch/powerpc/mm/dma-noncoherent.c:159:13: error: 'ISA_DMA_THRESHOLD' undeclared (first use in this function)

Probably caused by commit ff35bd54456e ("lib/scatterlist: make
ARCH_HAS_SG_CHAIN an actual Kconfig") which removed an implicit include
of <asm/dma.h> with the removal of the arch specific scatterlist.h.

I have added the following patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 16 Apr 2014 16:03:01 +1000
Subject: [PATCH] lib/scatterlist: make ARCH_HAS_SG_CHAIN an actual Kconfig fix

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/powerpc/mm/dma-noncoherent.c | 1 +
 arch/powerpc/platforms/44x/warp.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/powerpc/mm/dma-noncoherent.c b/arch/powerpc/mm/dma-noncoherent.c
index 7b6c10750179..d85e86aac7fb 100644
--- a/arch/powerpc/mm/dma-noncoherent.c
+++ b/arch/powerpc/mm/dma-noncoherent.c
@@ -33,6 +33,7 @@
 #include <linux/export.h>
 
 #include <asm/tlbflush.h>
+#include <asm/dma.h>
 
 #include "mmu_decl.h"
 
diff --git a/arch/powerpc/platforms/44x/warp.c b/arch/powerpc/platforms/44x/warp.c
index 534574a97ec9..3a104284b338 100644
--- a/arch/powerpc/platforms/44x/warp.c
+++ b/arch/powerpc/platforms/44x/warp.c
@@ -25,6 +25,7 @@
 #include <asm/time.h>
 #include <asm/uic.h>
 #include <asm/ppc4xx.h>
+#include <asm/dma.h>
 
 
 static __initdata struct of_device_id warp_of_bus[] = {
-- 
1.9.2

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

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* linux-next: build failure after merge of the akpm-current tree
@ 2014-04-16  5:38 Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2014-04-16  5:38 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Vladimir Davydov

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

Hi Andrew,

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

ERROR: "kmalloc_order" [drivers/net/wireless/brcm80211/brcmfmac/brcmfmac.ko] undefined!

Caused by commit a3ed1ed24850 ("mm: get rid of __GFP_KMEMCG").

I added the following patch:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 16 Apr 2014 15:32:54 +1000
Subject: [PATCH] mm: get rid of __GFP_KMEMCG fix

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 mm/slab_common.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/mm/slab_common.c b/mm/slab_common.c
index cab4c49b3e8c..edd10a8af69e 100644
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -584,6 +584,7 @@ void *kmalloc_order(size_t size, gfp_t flags, unsigned int order)
 	kmemleak_alloc(ret, size, 1, flags);
 	return ret;
 }
+EXPORT_SYMBOL(kmalloc_order);
 
 #ifdef CONFIG_TRACING
 void *kmalloc_order_trace(size_t size, gfp_t flags, unsigned int order)
-- 
1.9.2

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

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* linux-next: build failure after merge of the akpm-current tree
@ 2014-04-16  5:19 Stephen Rothwell
  2014-04-16 19:21 ` Mel Gorman
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2014-04-16  5:19 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Mel Gorman

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

Hi Andrew,

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

In file included from mm/vmscan.c:50:0:
include/linux/swapops.h: In function 'is_swap_pte':
include/linux/swapops.h:57:2: error: implicit declaration of function 'pte_present_nonuma' [-Werror=implicit-function-declaration]
  return !pte_none(pte) && !pte_present_nonuma(pte) && !pte_file(pte);
  ^

Caused by commit 851fe3337768 ("x86: define _PAGE_NUMA by reusing
software bits on the PMD and PTE levels").  This build does not have
CONFIG_NUMA_BALANCING set.

I have reverted that commit for today.

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

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* linux-next: build failure after merge of the akpm-current tree
@ 2014-03-25  7:44 Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2014-03-25  7:44 UTC (permalink / raw)
  To: Andrew Morton, Rusty Russell; +Cc: linux-next, linux-kernel, Goldwyn Rodrigues

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

Hi Andrew,

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

In file included from include/linux/thread_info.h:11:0,
                 from arch/x86/include/asm/preempt.h:6,
                 from include/linux/preempt.h:18,
                 from include/linux/spinlock.h:50,
                 from fs/ocfs2/stackglue.c:22:
include/linux/bug.h:33:45: error: negative width in bit-field '<anonymous>'
 #define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
                                             ^
include/linux/kernel.h:848:3: note: in expansion of macro 'BUILD_BUG_ON_ZERO'
   BUILD_BUG_ON_ZERO((perms) > 0777) +    \
   ^
include/linux/sysfs.h:75:12: note: in expansion of macro 'VERIFY_OCTAL_PERMISSIONS'
    .mode = VERIFY_OCTAL_PERMISSIONS(_mode) },  \
            ^
fs/ocfs2/stackglue.c:614:2: note: in expansion of macro '__ATTR'
  __ATTR(dlm_recover_callback_support, S_IFREG | S_IRUGO,
  ^

Caused by commit 88991182643c ("ocfs2: add dlm_recover_callback_support
in sysfs") interacting with commit 58f86cc89c33
("VERIFY_OCTAL_PERMISSIONS: stricter checking for sysfs perms") from the
modules tree.

I applied this fix up patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 25 Mar 2014 18:39:49 +1100
Subject: [PATCH] ocfs2: VERIFY_OCTAL_PERMISSIONS fix up

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 fs/ocfs2/stackglue.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/ocfs2/stackglue.c b/fs/ocfs2/stackglue.c
index c8c9d54dabc5..5e4d314c854d 100644
--- a/fs/ocfs2/stackglue.c
+++ b/fs/ocfs2/stackglue.c
@@ -611,7 +611,7 @@ static ssize_t ocfs2_dlm_recover_show(struct kobject *kobj,
 }
 
 static struct kobj_attribute ocfs2_attr_dlm_recover_support =
-	__ATTR(dlm_recover_callback_support, S_IFREG | S_IRUGO,
+	__ATTR(dlm_recover_callback_support, S_IRUGO,
 	       ocfs2_dlm_recover_show, NULL);
 
 static struct attribute *ocfs2_attrs[] = {
-- 
1.9.1

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2014-03-24  6:23 Stephen Rothwell
@ 2014-03-24  6:35 ` Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2014-03-24  6:35 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Christoph Lameter

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

Hi Andrew,

On Mon, 24 Mar 2014 17:23:27 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the akpm-current tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> In file included from include/linux/mm.h:897:0,
>                  from include/linux/mman.h:4,
>                  from arch/powerpc/kernel/asm-offsets.c:22:
> include/linux/vmstat.h: In function '__count_vm_event':
> include/linux/vmstat.h:36:2: error: implicit declaration of function 'raw_cpu_inc' [-Werror=implicit-function-declaration]
>   raw_cpu_inc(vm_event_states.event[item]);
>   ^
> include/linux/vmstat.h: In function '__count_vm_events':
> include/linux/vmstat.h:46:2: error: implicit declaration of function 'raw_cpu_add' [-Werror=implicit-function-declaration]
>   raw_cpu_add(vm_event_states.event[item], delta);
>   ^
> 
> Caused by commit "vmstat: use raw_cpu_ops to avoid false positives on
> preemption checks".
> 
> My kernel (even going back to v3.13) has no reference to
> raw_cpu_inc/add ... missed patch?  Ah, ha percpu-add-raw_cpu_ops.patch
> etc are in the later part of the series :-(
> 
> I just reverted "vmstat: use raw_cpu_ops to avoid false positives on
> preemption checks" and
> "vmstat-use-raw_cpu_ops-to-avoid-false-positives-on-preemption-checks-fix"
> for today.

I added them back at the end of the akpm tree (as part of the merge
commit, so you can't easily see them :-().

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

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* linux-next: build failure after merge of the akpm-current tree
@ 2014-03-24  6:23 Stephen Rothwell
  2014-03-24  6:35 ` Stephen Rothwell
  0 siblings, 1 reply; 330+ messages in thread
From: Stephen Rothwell @ 2014-03-24  6:23 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Christoph Lameter

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

Hi Andrew,

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

In file included from include/linux/mm.h:897:0,
                 from include/linux/mman.h:4,
                 from arch/powerpc/kernel/asm-offsets.c:22:
include/linux/vmstat.h: In function '__count_vm_event':
include/linux/vmstat.h:36:2: error: implicit declaration of function 'raw_cpu_inc' [-Werror=implicit-function-declaration]
  raw_cpu_inc(vm_event_states.event[item]);
  ^
include/linux/vmstat.h: In function '__count_vm_events':
include/linux/vmstat.h:46:2: error: implicit declaration of function 'raw_cpu_add' [-Werror=implicit-function-declaration]
  raw_cpu_add(vm_event_states.event[item], delta);
  ^

Caused by commit "vmstat: use raw_cpu_ops to avoid false positives on
preemption checks".

My kernel (even going back to v3.13) has no reference to
raw_cpu_inc/add ... missed patch?  Ah, ha percpu-add-raw_cpu_ops.patch
etc are in the later part of the series :-(

I just reverted "vmstat: use raw_cpu_ops to avoid false positives on
preemption checks" and
"vmstat-use-raw_cpu_ops-to-avoid-false-positives-on-preemption-checks-fix"
for today.

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

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2014-03-06 22:58 ` Andrew Morton
@ 2014-03-07  0:42   ` Stephen Rothwell
  0 siblings, 0 replies; 330+ messages in thread
From: Stephen Rothwell @ 2014-03-07  0:42 UTC (permalink / raw)
  To: Andrew Morton
  Cc: linux-next, linux-kernel, Davidlohr Bueso, Rik van Riel,
	Linus Torvalds, Michel Lespinasse

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

Hi Andrew,

On Thu, 6 Mar 2014 14:58:26 -0800 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Thu, 6 Mar 2014 18:08:52 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > After merging the akpm-current tree, today's linux-next build (arm
> > multi_v7_defconfig) failed like this:
> > 
> > ...
> >
> > and on and on ...
> > 
> > Caused by commit 0d9ad4220e6d ("mm: per-thread vma caching") which adds
> > the include of linux/vmacache.h (which includes linux/mm.h) into
> > linux/sched.h ... There is a reason that we did not include linux/mm.h
> > into sched.h.
> 
> Yeah.
> 
> > --- /dev/null
> > +++ b/include/linux/vmacachedefs.h
> > @@ -0,0 +1,9 @@
> > +
> > +#ifndef __LINUX_VMACACHEDEFS_H
> > +#define __LINUX_VMACACHEDEFS_H
> > +
> > +#define VMACACHE_BITS 2
> > +#define VMACACHE_SIZE (1U << VMACACHE_BITS)
> > +#define VMACACHE_MASK (VMACACHE_SIZE - 1)
> > +
> > +#endif /* __LINUX_VMACACHEDEFS_H */
> 
> I just did pretty much the same thing:
> 
> 
> From: Andrew Morton <akpm@linux-foundation.org>
> Subject: mm-per-thread-vma-caching-fix-3

I will replace my patch with this today.

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

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2014-03-06  7:08 Stephen Rothwell
  2014-03-06  7:20 ` Davidlohr Bueso
@ 2014-03-06 22:58 ` Andrew Morton
  2014-03-07  0:42   ` Stephen Rothwell
  1 sibling, 1 reply; 330+ messages in thread
From: Andrew Morton @ 2014-03-06 22:58 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: linux-next, linux-kernel, Davidlohr Bueso, Rik van Riel,
	Linus Torvalds, Michel Lespinasse

On Thu, 6 Mar 2014 18:08:52 +1100 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) failed like this:
> 
> ...
>
> and on and on ...
> 
> Caused by commit 0d9ad4220e6d ("mm: per-thread vma caching") which adds
> the include of linux/vmacache.h (which includes linux/mm.h) into
> linux/sched.h ... There is a reason that we did not include linux/mm.h
> into sched.h.

Yeah.

> --- /dev/null
> +++ b/include/linux/vmacachedefs.h
> @@ -0,0 +1,9 @@
> +
> +#ifndef __LINUX_VMACACHEDEFS_H
> +#define __LINUX_VMACACHEDEFS_H
> +
> +#define VMACACHE_BITS 2
> +#define VMACACHE_SIZE (1U << VMACACHE_BITS)
> +#define VMACACHE_MASK (VMACACHE_SIZE - 1)
> +
> +#endif /* __LINUX_VMACACHEDEFS_H */

I just did pretty much the same thing:


From: Andrew Morton <akpm@linux-foundation.org>
Subject: mm-per-thread-vma-caching-fix-3

Attempt to untangle header files.

Prior to this patch:

mm.h does not require sched.h
sched.h does not require mm.h
sched.h requires vmacache.h
vmacache.h requires mm.h

After this patch:

mm.h still does not require sched.h
sched.h still does not require mm.h
sched.h does not require vmacache.h
mm.h does not require vmacache.h
vmacache.h requires (and includes) mm.h
vmacache.h requires (and includes) sched.h

To do all this, the three "#define VMACACHE_foo" lines were moved to
sched.h.

The inclusions of sched.h and mm.h into vmacache.h are actually unrequired
because the .c files include mm.h and sched.h directly, but I put them in
there for cargo-cult reasons.

vmacache_flush() no longer needs to be implemented in cpp - make it so.

Cc: Davidlohr Bueso <davidlohr@hp.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Michel Lespinasse <walken@google.com>
Cc: Rik van Riel <riel@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 arch/unicore32/include/asm/mmu_context.h |    2 ++
 fs/exec.c                                |    1 +
 fs/proc/task_mmu.c                       |    1 +
 include/linux/sched.h                    |    5 ++++-
 include/linux/vmacache.h                 |   12 +++++-------
 kernel/debug/debug_core.c                |    1 +
 kernel/fork.c                            |    2 ++
 mm/mmap.c                                |    1 +
 mm/nommu.c                               |    1 +
 mm/vmacache.c                            |    1 +
 10 files changed, 19 insertions(+), 8 deletions(-)

diff -puN arch/unicore32/include/asm/mmu_context.h~mm-per-thread-vma-caching-fix-3 arch/unicore32/include/asm/mmu_context.h
--- a/arch/unicore32/include/asm/mmu_context.h~mm-per-thread-vma-caching-fix-3
+++ a/arch/unicore32/include/asm/mmu_context.h
@@ -14,6 +14,8 @@
 
 #include <linux/compiler.h>
 #include <linux/sched.h>
+#include <linux/mm.h>
+#include <linux/vmacache.h>
 #include <linux/io.h>
 
 #include <asm/cacheflush.h>
diff -puN fs/exec.c~mm-per-thread-vma-caching-fix-3 fs/exec.c
--- a/fs/exec.c~mm-per-thread-vma-caching-fix-3
+++ a/fs/exec.c
@@ -26,6 +26,7 @@
 #include <linux/file.h>
 #include <linux/fdtable.h>
 #include <linux/mm.h>
+#include <linux/vmacache.h>
 #include <linux/stat.h>
 #include <linux/fcntl.h>
 #include <linux/swap.h>
diff -puN fs/proc/task_mmu.c~mm-per-thread-vma-caching-fix-3 fs/proc/task_mmu.c
--- a/fs/proc/task_mmu.c~mm-per-thread-vma-caching-fix-3
+++ a/fs/proc/task_mmu.c
@@ -1,4 +1,5 @@
 #include <linux/mm.h>
+#include <linux/vmacache.h>
 #include <linux/hugetlb.h>
 #include <linux/huge_mm.h>
 #include <linux/mount.h>
diff -puN include/linux/mm_types.h~mm-per-thread-vma-caching-fix-3 include/linux/mm_types.h
diff -puN include/linux/sched.h~mm-per-thread-vma-caching-fix-3 include/linux/sched.h
--- a/include/linux/sched.h~mm-per-thread-vma-caching-fix-3
+++ a/include/linux/sched.h
@@ -23,7 +23,6 @@ struct sched_param {
 #include <linux/errno.h>
 #include <linux/nodemask.h>
 #include <linux/mm_types.h>
-#include <linux/vmacache.h>
 #include <linux/preempt_mask.h>
 
 #include <asm/page.h>
@@ -131,6 +130,10 @@ struct perf_event_context;
 struct blk_plug;
 struct filename;
 
+#define VMACACHE_BITS 2
+#define VMACACHE_SIZE (1U << VMACACHE_BITS)
+#define VMACACHE_MASK (VMACACHE_SIZE - 1)
+
 /*
  * List of flags we want to share for kernel threads,
  * if only because they are not used by them anyway.
diff -puN include/linux/vmacache.h~mm-per-thread-vma-caching-fix-3 include/linux/vmacache.h
--- a/include/linux/vmacache.h~mm-per-thread-vma-caching-fix-3
+++ a/include/linux/vmacache.h
@@ -1,21 +1,19 @@
 #ifndef __LINUX_VMACACHE_H
 #define __LINUX_VMACACHE_H
 
+#include <linux/sched.h>
 #include <linux/mm.h>
 
-#define VMACACHE_BITS 2
-#define VMACACHE_SIZE (1U << VMACACHE_BITS)
-#define VMACACHE_MASK (VMACACHE_SIZE - 1)
 /*
  * Hash based on the page number. Provides a good hit rate for
  * workloads with good locality and those with random accesses as well.
  */
 #define VMACACHE_HASH(addr) ((addr >> PAGE_SHIFT) & VMACACHE_MASK)
 
-#define vmacache_flush(tsk)					 \
-	do {							 \
-		memset(tsk->vmacache, 0, sizeof(tsk->vmacache)); \
-	} while (0)
+static inline void vmacache_flush(struct task_struct *tsk)
+{
+	memset(tsk->vmacache, 0, sizeof(tsk->vmacache));
+}
 
 extern void vmacache_flush_all(struct mm_struct *mm);
 extern void vmacache_update(unsigned long addr, struct vm_area_struct *newvma);
diff -puN kernel/debug/debug_core.c~mm-per-thread-vma-caching-fix-3 kernel/debug/debug_core.c
--- a/kernel/debug/debug_core.c~mm-per-thread-vma-caching-fix-3
+++ a/kernel/debug/debug_core.c
@@ -49,6 +49,7 @@
 #include <linux/pid.h>
 #include <linux/smp.h>
 #include <linux/mm.h>
+#include <linux/vmacache.h>
 #include <linux/rcupdate.h>
 
 #include <asm/cacheflush.h>
diff -puN kernel/fork.c~mm-per-thread-vma-caching-fix-3 kernel/fork.c
--- a/kernel/fork.c~mm-per-thread-vma-caching-fix-3
+++ a/kernel/fork.c
@@ -28,6 +28,8 @@
 #include <linux/mman.h>
 #include <linux/mmu_notifier.h>
 #include <linux/fs.h>
+#include <linux/mm.h>
+#include <linux/vmacache.h>
 #include <linux/nsproxy.h>
 #include <linux/capability.h>
 #include <linux/cpu.h>
diff -puN mm/Makefile~mm-per-thread-vma-caching-fix-3 mm/Makefile
diff -puN mm/mmap.c~mm-per-thread-vma-caching-fix-3 mm/mmap.c
--- a/mm/mmap.c~mm-per-thread-vma-caching-fix-3
+++ a/mm/mmap.c
@@ -10,6 +10,7 @@
 #include <linux/slab.h>
 #include <linux/backing-dev.h>
 #include <linux/mm.h>
+#include <linux/vmacache.h>
 #include <linux/shm.h>
 #include <linux/mman.h>
 #include <linux/pagemap.h>
diff -puN mm/nommu.c~mm-per-thread-vma-caching-fix-3 mm/nommu.c
--- a/mm/nommu.c~mm-per-thread-vma-caching-fix-3
+++ a/mm/nommu.c
@@ -15,6 +15,7 @@
 
 #include <linux/export.h>
 #include <linux/mm.h>
+#include <linux/vmacache.h>
 #include <linux/mman.h>
 #include <linux/swap.h>
 #include <linux/file.h>
diff -puN mm/vmacache.c~mm-per-thread-vma-caching-fix-3 mm/vmacache.c
--- a/mm/vmacache.c~mm-per-thread-vma-caching-fix-3
+++ a/mm/vmacache.c
@@ -2,6 +2,7 @@
  * Copyright (C) 2014 Davidlohr Bueso.
  */
 #include <linux/sched.h>
+#include <linux/mm.h>
 #include <linux/vmacache.h>
 
 /*
_

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

* Re: linux-next: build failure after merge of the akpm-current tree
  2014-03-06  7:08 Stephen Rothwell
@ 2014-03-06  7:20 ` Davidlohr Bueso
  2014-03-06 22:58 ` Andrew Morton
  1 sibling, 0 replies; 330+ messages in thread
From: Davidlohr Bueso @ 2014-03-06  7:20 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, linux-next, linux-kernel, Rik van Riel,
	Linus Torvalds, Michel Lespinasse

On Thu, 2014-03-06 at 18:08 +1100, Stephen Rothwell wrote:
> Hi Andrew,
> 
> After merging the akpm-current tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> In file included from include/linux/vmacache.h:4:0,
>                  from include/linux/sched.h:28,
>                  from arch/arm/include/asm/tlbflush.h:204,
>                  from arch/arm/include/asm/pgtable.h:28,
>                  from arch/arm/include/asm/idmap.h:5,
>                  from arch/arm/mm/idmap.c:6:
> include/linux/mm.h: In function 'is_vmalloc_addr':
> include/linux/mm.h:359:17: error: 'VMALLOC_START' undeclared (first use in this function)
> include/linux/mm.h:359:41: error: 'VMALLOC_END' undeclared (first use in this function)
> include/linux/mm.h: In function 'maybe_mkwrite':
> include/linux/mm.h:589:3: error: implicit declaration of function 'pte_mkwrite' [-Werror=implicit-function-declaration]
> In file included from include/linux/vmacache.h:4:0,
>                  from include/linux/sched.h:28,
>                  from arch/arm/include/asm/tlbflush.h:204,
>                  from arch/arm/include/asm/pgtable.h:28,
>                  from arch/arm/include/asm/idmap.h:5,
>                  from arch/arm/mm/idmap.c:6:
> include/linux/mm.h: In function 'pmd_alloc':
> include/linux/mm.h:1396:2: error: implicit declaration of function 'pud_none' [-Werror=implicit-function-declaration]
> include/linux/mm.h:1397:3: error: implicit declaration of function 'pmd_offset' [-Werror=implicit-function-declaration]
> include/linux/mm.h:1397:7: warning: pointer/integer type mismatch in conditional expression [enabled by default]
> include/linux/mm.h: In function 'pte_lockptr':
> include/linux/mm.h:1433:2: error: implicit declaration of function 'pmd_page' [-Werror=implicit-function-declaration]
> include/linux/mm.h:1433:2: warning: passing argument 1 of 'ptlock_ptr' makes pointer from integer without a cast [enabled by default]
> include/linux/mm.h:1425:27: note: expected 'struct page *' but argument is of type 'int'
> include/linux/mm.h: In function 'pgtable_init':
> include/linux/mm.h:1476:2: error: implicit declaration