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

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

[Stephen Rothwell]

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

Hi all,

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

arch/arm64/include/asm/neon-intrinsics.h:33:10: fatal error: arm_neon.h: No such file or directory

Also, the nds32 defconfig build failed like this;

arch/nds32/include/asm/nds32.h:13:10: fatal error: nds32_intrinsic.h: No such file or directory

Presumably caused by commit

  6f4266a78a4e ("kbuild: decouple build from userspace headers")

-- 
Cheers,
Stephen Rothwell

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

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

[Andrew Morton]

On Tue, 20 Jul 2021 18:23:39 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> After merging the akpm-current tree, today's linux-next build (arm64
> randconfig) failed like this:
> 
> arch/arm64/include/asm/neon-intrinsics.h:33:10: fatal error: arm_neon.h: No such file or directory
> 
> Also, the nds32 defconfig build failed like this;
> 
> arch/nds32/include/asm/nds32.h:13:10: fatal error: nds32_intrinsic.h: No such file or directory
> 
> Presumably caused by commit
> 
>   6f4266a78a4e ("kbuild: decouple build from userspace headers")

I'm seeing several reports against that patch so I dropped it for now.

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

[Stephen Rothwell]

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

Hi Andrew,

On Tue, 20 Jul 2021 14:03:39 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Tue, 20 Jul 2021 18:23:39 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > Hi all,
> > 
> > After merging the akpm-current tree, today's linux-next build (arm64
> > randconfig) failed like this:
> > 
> > arch/arm64/include/asm/neon-intrinsics.h:33:10: fatal error: arm_neon.h: No such file or directory
> > 
> > Also, the nds32 defconfig build failed like this;
> > 
> > arch/nds32/include/asm/nds32.h:13:10: fatal error: nds32_intrinsic.h: No such file or directory
> > 
> > Presumably caused by commit
> > 
> >   6f4266a78a4e ("kbuild: decouple build from userspace headers")  
> 
> I'm seeing several reports against that patch so I dropped it for now.

I have removed it from linux-next today.

-- 
Cheers,
Stephen Rothwell

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

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

[Stephen Rothwell]

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

Hi all,

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

In file included from include/asm-generic/percpu.h:7,
                 from arch/arm64/include/asm/percpu.h:248,
                 from include/linux/irqflags.h:17,
                 from include/linux/spinlock.h:58,
                 from include/linux/irq.h:14,
                 from arch/arm64/kernel/irq.c:13:
arch/arm64/kernel/irq.c: In function 'init_irq_scs':
arch/arm64/kernel/irq.c:44:25: error: 'irq_shadow_call_stack_ptr' undeclared (first use in this function)
   44 |                 per_cpu(irq_shadow_call_stack_ptr, cpu) =
      |                         ^~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/percpu-defs.h:219:54: note: in definition of macro '__verify_pcpu_ptr'
  219 |         const void __percpu *__vpp_verify = (typeof((ptr) + 0))NULL;    \
      |                                                      ^~~
include/linux/percpu-defs.h:269:35: note: in expansion of macro 'per_cpu_ptr'
  269 | #define per_cpu(var, cpu)       (*per_cpu_ptr(&(var), cpu))
      |                                   ^~~~~~~~~~~
arch/arm64/kernel/irq.c:44:17: note: in expansion of macro 'per_cpu'
   44 |                 per_cpu(irq_shadow_call_stack_ptr, cpu) =
      |                 ^~~~~~~
arch/arm64/kernel/irq.c:44:25: note: each undeclared identifier is reported only once for each function it appears in
   44 |                 per_cpu(irq_shadow_call_stack_ptr, cpu) =
      |                         ^~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/percpu-defs.h:219:54: note: in definition of macro '__verify_pcpu_ptr'
  219 |         const void __percpu *__vpp_verify = (typeof((ptr) + 0))NULL;    \
      |                                                      ^~~
include/linux/percpu-defs.h:269:35: note: in expansion of macro 'per_cpu_ptr'
  269 | #define per_cpu(var, cpu)       (*per_cpu_ptr(&(var), cpu))
      |                                   ^~~~~~~~~~~
arch/arm64/kernel/irq.c:44:17: note: in expansion of macro 'per_cpu'
   44 |                 per_cpu(irq_shadow_call_stack_ptr, cpu) =
      |                 ^~~~~~~

Caused by commit

  aa0120feb340 ("arm64, scs: save scs_sp values per-cpu when switching stacks")

I have applied the following patch for today.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 31 Mar 2022 13:33:55 +1100
Subject: [PATCH] fix up for "arm64, scs: save scs_sp values per-cpu when switching stacks"

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

diff --git a/arch/arm64/kernel/irq.c b/arch/arm64/kernel/irq.c
index 4199f900714a..5a15e6a42cbf 100644
--- a/arch/arm64/kernel/irq.c
+++ b/arch/arm64/kernel/irq.c
@@ -22,6 +22,7 @@
 #include <linux/vmalloc.h>
 #include <asm/daifflags.h>
 #include <asm/vmap_stack.h>
+#include <asm/scs.h>
 
 /* Only access this in an NMI enter/exit */
 DEFINE_PER_CPU(struct nmi_ctx, nmi_contexts);
-- 
2.35.1

This then produced the following:

arch/arm64/kernel/stacktrace.c: In function 'arch_stack_walk_shadow':
arch/arm64/kernel/stacktrace.c:289:20: error: implicit declaration of function 'task_scs'; did you mean 'task_lock'? [-Werror=implicit-function-declaration]
  289 |         scs_base = task_scs(current);
      |                    ^~~~~~~~
      |                    task_lock
arch/arm64/kernel/stacktrace.c:289:18: warning: assignment to 'long unsigned int *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
  289 |         scs_base = task_scs(current);
      |                  ^

I assume this has never been compiled with CONFIG_SHADOW_CALL_STACK not
set :-(

I have reverted these commits for today:

5c6df774c321 kasan: use stack_trace_save_shadow
0f63d30c44d6 arm64: implement stack_trace_save_shadow
aa0120feb340 arm64, scs: save scs_sp values per-cpu when switching stacks
636fecb8f05e stacktrace: add interface based on shadow call stack

-- 
Cheers,
Stephen Rothwell

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

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

[Stephen Rothwell]

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

Hi all,

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

mm/mmap.c: In function 'vm_get_page_prot':
mm/mmap.c:122:16: error: implicit declaration of function 'arch_filter_pgprot' [-Werror=implicit-function-declaration]
  122 |         return arch_filter_pgprot(ret);
      |                ^~~~~~~~~~~~~~~~~~
mm/mmap.c:122:16: error: incompatible types when returning type 'int' but 'pgprot_t' was expected
  122 |         return arch_filter_pgprot(ret);
      |                ^~~~~~~~~~~~~~~~~~~~~~~
mm/mmap.c:123:1: error: control reaches end of non-void function [-Werror=return-type]
  123 | }
      | ^

Caused by commit

  e25ff72a53b9 ("mm: generalize ARCH_HAS_FILTER_PGPROT")

interacting with commit

  6e2edd6371a4 ("arm64: Ensure execute-only permissions are not allowed without EPAN")

from Linus' tree (today).

I have applied the following merg fix patch for today.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 10 Mar 2022 19:50:30 +1100
Subject: [PATCH] fixup for "mm: generalize ARCH_HAS_FILTER_PGPROT"

Semantic conflict with commit

  6e2edd6371a4 ("arm64: Ensure execute-only permissions are not allowed without EPAN")

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/arm64/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 0b8f9328cd95..962c84952c98 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -25,7 +25,6 @@ config ARM64
 	select ARCH_HAS_DMA_PREP_COHERENT
 	select ARCH_HAS_ACPI_TABLE_UPGRADE if ACPI
 	select ARCH_HAS_FAST_MULTIPLIER
-	select ARCH_HAS_FILTER_PGPROT
 	select ARCH_HAS_FORTIFY_SOURCE
 	select ARCH_HAS_GCOV_PROFILE_ALL
 	select ARCH_HAS_GIGANTIC_PAGE
-- 
2.34.1

-- 
Cheers,
Stephen Rothwell

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

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

[Andrew Morton]

On Tue, 1 Mar 2022 01:33:08 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> After merging the akpm-current tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> mm/rmap.c: In function 'try_to_migrate_one':
> mm/rmap.c:1870:64: error: 'page' undeclared (first use in this function)
>  1870 |                                                 compound_order(page));
>       |                                                                ^~~~
> mm/rmap.c:1870:64: note: each undeclared identifier is reported only once for each function it appears in
> 
> Caused by commit
> 
>   e05239e90b65 ("mm/migration: add trace events for base page and HugeTLB migrations")
> 
> inertacting with commit
> 
>   efe8a99f35f6 ("mm/rmap: Convert rmap_walk() to take a folio")
> 
> from the folio tree.
> 
> I have reverted commit e05239e90b65 for today.

Thanks, I've moved yet more things into the post-linux-next queue and
fixed things up.

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

[Stephen Rothwell]

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

Hi all,

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

mm/rmap.c: In function 'try_to_migrate_one':
mm/rmap.c:1870:64: error: 'page' undeclared (first use in this function)
 1870 |                                                 compound_order(page));
      |                                                                ^~~~
mm/rmap.c:1870:64: note: each undeclared identifier is reported only once for each function it appears in

Caused by commit

  e05239e90b65 ("mm/migration: add trace events for base page and HugeTLB migrations")

inertacting with commit

  efe8a99f35f6 ("mm/rmap: Convert rmap_walk() to take a folio")

from the folio tree.

I have reverted commit e05239e90b65 for today.

-- 
Cheers,
Stephen Rothwell

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

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

[Christoph Hellwig]

On Mon, Feb 14, 2022 at 06:00:40PM +1100, Stephen Rothwell wrote:
> Presumably caused by commit
> 
>   5ba71dc7727a ("mm: don't include <linux/memremap.h> in <linux/mm.h>")
> 
> I applied the following patch:

Thanks,

the fixup looks good to me.

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

[Stephen Rothwell]

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

Hi all,

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

arch/powerpc/kvm/book3s_hv_uvmem.c: In function 'kvmppc_uvmem_get_page':
arch/powerpc/kvm/book3s_hv_uvmem.c:691:39: error: invalid use of undefined type 'struct dev_pagemap'
  691 |         pfn_first = kvmppc_uvmem_pgmap.range.start >> PAGE_SHIFT;
      |                                       ^
arch/powerpc/kvm/book3s_hv_uvmem.c:693:50: error: invalid use of undefined type 'struct dev_pagemap'
  693 |                    (range_len(&kvmppc_uvmem_pgmap.range) >> PAGE_SHIFT);
      |                                                  ^
arch/powerpc/kvm/book3s_hv_uvmem.c: In function 'kvmppc_uvmem_page_free':
arch/powerpc/kvm/book3s_hv_uvmem.c:1010:44: error: invalid use of undefined type 'struct dev_pagemap'
 1010 |                         (kvmppc_uvmem_pgmap.range.start >> PAGE_SHIFT);
      |                                            ^
arch/powerpc/kvm/book3s_hv_uvmem.c: At top level:
arch/powerpc/kvm/book3s_hv_uvmem.c:1026:21: error: variable 'kvmppc_uvmem_ops' has initializer but incomplete type
 1026 | static const struct dev_pagemap_ops kvmppc_uvmem_ops = {
      |                     ^~~~~~~~~~~~~~~
arch/powerpc/kvm/book3s_hv_uvmem.c:1027:10: error: 'const struct dev_pagemap_ops' has no member named 'page_free'
 1027 |         .page_free = kvmppc_uvmem_page_free,
      |          ^~~~~~~~~
arch/powerpc/kvm/book3s_hv_uvmem.c:1027:22: error: excess elements in struct initializer [-Werror]
 1027 |         .page_free = kvmppc_uvmem_page_free,
      |                      ^~~~~~~~~~~~~~~~~~~~~~
arch/powerpc/kvm/book3s_hv_uvmem.c:1027:22: note: (near initialization for 'kvmppc_uvmem_ops')
arch/powerpc/kvm/book3s_hv_uvmem.c:1028:10: error: 'const struct dev_pagemap_ops' has no member named 'migrate_to_ram'
 1028 |         .migrate_to_ram = kvmppc_uvmem_migrate_to_ram,
      |          ^~~~~~~~~~~~~~
arch/powerpc/kvm/book3s_hv_uvmem.c:1028:27: error: excess elements in struct initializer [-Werror]
 1028 |         .migrate_to_ram = kvmppc_uvmem_migrate_to_ram,
      |                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/powerpc/kvm/book3s_hv_uvmem.c:1028:27: note: (near initialization for 'kvmppc_uvmem_ops')
arch/powerpc/kvm/book3s_hv_uvmem.c: In function 'kvmppc_uvmem_init':
arch/powerpc/kvm/book3s_hv_uvmem.c:1172:27: error: invalid use of undefined type 'struct dev_pagemap'
 1172 |         kvmppc_uvmem_pgmap.type = MEMORY_DEVICE_PRIVATE;
      |                           ^
arch/powerpc/kvm/book3s_hv_uvmem.c:1172:35: error: 'MEMORY_DEVICE_PRIVATE' undeclared (first use in this function); did you mean 'CONFIG_DEVICE_PRIVATE'?
 1172 |         kvmppc_uvmem_pgmap.type = MEMORY_DEVICE_PRIVATE;
      |                                   ^~~~~~~~~~~~~~~~~~~~~
      |                                   CONFIG_DEVICE_PRIVATE
arch/powerpc/kvm/book3s_hv_uvmem.c:1172:35: note: each undeclared identifier is reported only once for each function it appears in
arch/powerpc/kvm/book3s_hv_uvmem.c:1173:27: error: invalid use of undefined type 'struct dev_pagemap'
 1173 |         kvmppc_uvmem_pgmap.range.start = res->start;
      |                           ^
arch/powerpc/kvm/book3s_hv_uvmem.c:1174:27: error: invalid use of undefined type 'struct dev_pagemap'
 1174 |         kvmppc_uvmem_pgmap.range.end = res->end;
      |                           ^
arch/powerpc/kvm/book3s_hv_uvmem.c:1175:27: error: invalid use of undefined type 'struct dev_pagemap'
 1175 |         kvmppc_uvmem_pgmap.nr_range = 1;
      |                           ^
arch/powerpc/kvm/book3s_hv_uvmem.c:1176:27: error: invalid use of undefined type 'struct dev_pagemap'
 1176 |         kvmppc_uvmem_pgmap.ops = &kvmppc_uvmem_ops;
      |                           ^
arch/powerpc/kvm/book3s_hv_uvmem.c:1178:27: error: invalid use of undefined type 'struct dev_pagemap'
 1178 |         kvmppc_uvmem_pgmap.owner = &kvmppc_uvmem_pgmap;
      |                           ^
arch/powerpc/kvm/book3s_hv_uvmem.c:1179:16: error: implicit declaration of function 'memremap_pages'; did you mean 'memcmp_pages'? [-Werror=implicit-function-declaration]
 1179 |         addr = memremap_pages(&kvmppc_uvmem_pgmap, NUMA_NO_NODE);
      |                ^~~~~~~~~~~~~~
      |                memcmp_pages
arch/powerpc/kvm/book3s_hv_uvmem.c:1179:14: error: assignment to 'void *' from 'int' makes pointer from integer without a cast [-Werror=int-conversion]
 1179 |         addr = memremap_pages(&kvmppc_uvmem_pgmap, NUMA_NO_NODE);
      |              ^
arch/powerpc/kvm/book3s_hv_uvmem.c:1197:9: error: implicit declaration of function 'memunmap_pages'; did you mean 'memcmp_pages'? [-Werror=implicit-function-declaration]
 1197 |         memunmap_pages(&kvmppc_uvmem_pgmap);
      |         ^~~~~~~~~~~~~~
      |         memcmp_pages
In file included from include/linux/device.h:17,
                 from arch/powerpc/include/asm/io.h:27,
                 from include/linux/io.h:13,
                 from include/linux/irq.h:20,
                 from arch/powerpc/include/asm/hardirq.h:6,
                 from include/linux/hardirq.h:11,
                 from include/linux/highmem.h:11,
                 from include/linux/pagemap.h:11,
                 from arch/powerpc/kvm/book3s_hv_uvmem.c:89:
arch/powerpc/kvm/book3s_hv_uvmem.c: In function 'kvmppc_uvmem_free':
arch/powerpc/kvm/book3s_hv_uvmem.c:1210:46: error: invalid use of undefined type 'struct dev_pagemap'
 1210 |         release_mem_region(kvmppc_uvmem_pgmap.range.start,
      |                                              ^
include/linux/ioport.h:278:76: note: in definition of macro 'release_mem_region'
  278 | #define release_mem_region(start,n)     __release_region(&iomem_resource, (start), (n))
      |                                                                            ^~~~~
arch/powerpc/kvm/book3s_hv_uvmem.c:1211:57: error: invalid use of undefined type 'struct dev_pagemap'
 1211 |                            range_len(&kvmppc_uvmem_pgmap.range));
      |                                                         ^
include/linux/ioport.h:278:85: note: in definition of macro 'release_mem_region'
  278 | #define release_mem_region(start,n)     __release_region(&iomem_resource, (start), (n))
      |                                                                                     ^
arch/powerpc/kvm/book3s_hv_uvmem.c: At top level:
arch/powerpc/kvm/book3s_hv_uvmem.c:99:27: error: storage size of 'kvmppc_uvmem_pgmap' isn't known
   99 | static struct dev_pagemap kvmppc_uvmem_pgmap;
      |                           ^~~~~~~~~~~~~~~~~~
arch/powerpc/kvm/book3s_hv_uvmem.c:1026:37: error: storage size of 'kvmppc_uvmem_ops' isn't known
 1026 | static const struct dev_pagemap_ops kvmppc_uvmem_ops = {
      |                                     ^~~~~~~~~~~~~~~~

Presumably caused by commit

  5ba71dc7727a ("mm: don't include <linux/memremap.h> in <linux/mm.h>")

I applied the following patch:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 14 Feb 2022 17:47:53 +1100
Subject: [PATCH] fix for "mm: don't include <linux/memremap.h> in
 <linux/mm.h>"

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

diff --git a/arch/powerpc/kvm/book3s_hv_uvmem.c b/arch/powerpc/kvm/book3s_hv_uvmem.c
index 8b6438fa18fc..8cabdb39cbbc 100644
--- a/arch/powerpc/kvm/book3s_hv_uvmem.c
+++ b/arch/powerpc/kvm/book3s_hv_uvmem.c
@@ -91,6 +91,7 @@
 #include <linux/kvm_host.h>
 #include <linux/ksm.h>
 #include <linux/of.h>
+#include <linux/memremap.h>
 #include <asm/ultravisor.h>
 #include <asm/mman.h>
 #include <asm/kvm_ppc.h>
-- 
2.34.1

-- 
Cheers,
Stephen Rothwell

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

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

[Andrey Konovalov]

On Fri, Jan 28, 2022 at 4:48 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> After merging the akpm-current tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> lib/test_kasan.c: In function 'vmalloc_oob':
> lib/test_kasan.c:1113:71: error: array subscript 2035 is outside array bounds of 'char[2035]' [-Werror=array-bounds]
>  1113 |                 KUNIT_EXPECT_KASAN_FAIL(test, ((volatile char *)v_ptr)[size]);
>       |                                               ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~
> lib/test_kasan.c:96:9: note: in definition of macro 'KUNIT_EXPECT_KASAN_FAIL'
>    96 |         expression;                                                     \
>       |         ^~~~~~~~~~
> lib/test_kasan.c:1096:17: note: referencing an object of size 2035 allocated by 'vmalloc'
>  1096 |         v_ptr = vmalloc(size);
>       |                 ^~~~~~~~~~~~~
> lib/test_kasan.c:1116:63: error: array subscript 2040 is outside array bounds of 'char[2035]' [-Werror=array-bounds]
>  1116 |         KUNIT_EXPECT_KASAN_FAIL(test, ((volatile char *)v_ptr)[size + 5]);
>       |                                       ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~
> lib/test_kasan.c:96:9: note: in definition of macro 'KUNIT_EXPECT_KASAN_FAIL'
>    96 |         expression;                                                     \
>       |         ^~~~~~~~~~
> lib/test_kasan.c:1096:17: note: referencing an object of size 2035 allocated by 'vmalloc'
>  1096 |         v_ptr = vmalloc(size);
>       |                 ^~~~~~~~~~~~~
>
> Caused by commit
>
>   96304a5b9bff ("kasan: improve vmalloc tests")
>
> interacting with commit
>
>   d4e0dad4a0cd ("Makefile: Enable -Warray-bounds")
>
> from the kspp tree.
>
> Since the KASAN tests are doing this deliberately, I added the below
> hack for today.  Is there something better?

No, this looks good. I'll add this change into the next version of the
KASAN vmalloc patchset.

Thanks, Stephen!

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

[Stephen Rothwell]

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

Hi all,

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

lib/test_kasan.c: In function 'vmalloc_oob':
lib/test_kasan.c:1113:71: error: array subscript 2035 is outside array bounds of 'char[2035]' [-Werror=array-bounds]
 1113 |                 KUNIT_EXPECT_KASAN_FAIL(test, ((volatile char *)v_ptr)[size]);
      |                                               ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~
lib/test_kasan.c:96:9: note: in definition of macro 'KUNIT_EXPECT_KASAN_FAIL'
   96 |         expression;                                                     \
      |         ^~~~~~~~~~
lib/test_kasan.c:1096:17: note: referencing an object of size 2035 allocated by 'vmalloc'
 1096 |         v_ptr = vmalloc(size);
      |                 ^~~~~~~~~~~~~
lib/test_kasan.c:1116:63: error: array subscript 2040 is outside array bounds of 'char[2035]' [-Werror=array-bounds]
 1116 |         KUNIT_EXPECT_KASAN_FAIL(test, ((volatile char *)v_ptr)[size + 5]);
      |                                       ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~
lib/test_kasan.c:96:9: note: in definition of macro 'KUNIT_EXPECT_KASAN_FAIL'
   96 |         expression;                                                     \
      |         ^~~~~~~~~~
lib/test_kasan.c:1096:17: note: referencing an object of size 2035 allocated by 'vmalloc'
 1096 |         v_ptr = vmalloc(size);
      |                 ^~~~~~~~~~~~~

Caused by commit

  96304a5b9bff ("kasan: improve vmalloc tests")

interacting with commit

  d4e0dad4a0cd ("Makefile: Enable -Warray-bounds")

from the kspp tree.

Since the KASAN tests are doing this deliberately, I added the below
hack for today.  Is there something better?

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 28 Jan 2022 14:40:24 +1100
Subject: [PATCH] similar to "kasan: test: fix compatibility with
 FORTIFY_SOURCE"

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

diff --git a/lib/test_kasan.c b/lib/test_kasan.c
index 9dd767d05235..c07132c857e7 100644
--- a/lib/test_kasan.c
+++ b/lib/test_kasan.c
@@ -1096,6 +1096,8 @@ static void vmalloc_oob(struct kunit *test)
 	v_ptr = vmalloc(size);
 	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, v_ptr);
 
+	OPTIMIZER_HIDE_VAR(v_ptr);
+
 	/*
 	 * We have to be careful not to hit the guard page in vmalloc tests.
 	 * The MMU will catch that and crash us.
-- 
2.34.1

-- 
Cheers,
Stephen Rothwell

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

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

[Stephen Rothwell]

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

Hi all,

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

mm/vmalloc.c: In function '__vmalloc_area_node':
mm/vmalloc.c:2983:11: error: implicit declaration of function 'memalloc_nofs_save' [-Werror=implicit-function-declaration]
 2983 |   flags = memalloc_nofs_save();
      |           ^~~~~~~~~~~~~~~~~~
mm/vmalloc.c:2985:11: error: implicit declaration of function 'memalloc_noio_save' [-Werror=implicit-function-declaration]
 2985 |   flags = memalloc_noio_save();
      |           ^~~~~~~~~~~~~~~~~~
mm/vmalloc.c:2995:3: error: implicit declaration of function 'memalloc_nofs_restore' [-Werror=implicit-function-declaration]
 2995 |   memalloc_nofs_restore(flags);
      |   ^~~~~~~~~~~~~~~~~~~~~
mm/vmalloc.c:2997:3: error: implicit declaration of function 'memalloc_noio_restore' [-Werror=implicit-function-declaration]
 2997 |   memalloc_noio_restore(flags);
      |   ^~~~~~~~~~~~~~~~~~~~~

Caused by commit

  0256fe4b2ffb ("mm/vmalloc: alloc GFP_NO{FS,IO} for vmalloc")

I have applied the following fix patch.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 17 Dec 2021 23:15:05 +1100
Subject: [PATCH] mm/vmalloc: alloc GFP_NO{FS,IO} for vmalloc fix

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

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 01eabaf5417b..eb6e527a6b77 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -38,6 +38,7 @@
 #include <linux/pgtable.h>
 #include <linux/uaccess.h>
 #include <linux/hugetlb.h>
+#include <linux/sched/mm.h>
 #include <asm/tlbflush.h>
 #include <asm/shmparam.h>
 
-- 
2.33.0

-- 
Cheers,
Stephen Rothwell

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

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

[Andy Shevchenko]

On Mon, Oct 18, 2021 at 01:35:38PM +1100, Stephen Rothwell wrote:
> On Fri, 15 Oct 2021 16:14:56 +0300 Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:

...

> Like this (on top of my previous fix - which I assume Andrew will
> squash out of existence)?

Andrew, can you incorporate this one, please?

> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 18 Oct 2021 13:27:54 +1100
> Subject: [PATCH] kernel.h: split out instrcutions pointer accessors
> 
> botton_half.h needs _THIS_IP_ to be standalone, so split that and _RET_IP_
> out from kernel.h into the new instruction_pointer.h.  kernel.h directly
> needs them, so include it there and replace the include of kernel.h with
> this new file in bottom_half.h.
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  include/linux/bottom_half.h         | 2 +-
>  include/linux/instruction_pointer.h | 8 ++++++++
>  include/linux/kernel.h              | 4 +---
>  3 files changed, 10 insertions(+), 4 deletions(-)
>  create mode 100644 include/linux/instruction_pointer.h
> 
> diff --git a/include/linux/bottom_half.h b/include/linux/bottom_half.h
> index 11d107d88d03..fc53e0ad56d9 100644
> --- a/include/linux/bottom_half.h
> +++ b/include/linux/bottom_half.h
> @@ -2,7 +2,7 @@
>  #ifndef _LINUX_BH_H
>  #define _LINUX_BH_H
>  
> -#include <linux/kernel.h>
> +#include <linux/instruction_pointer.h>
>  #include <linux/preempt.h>
>  
>  #if defined(CONFIG_PREEMPT_RT) || defined(CONFIG_TRACE_IRQFLAGS)
> diff --git a/include/linux/instruction_pointer.h b/include/linux/instruction_pointer.h
> new file mode 100644
> index 000000000000..19e979425bda
> --- /dev/null
> +++ b/include/linux/instruction_pointer.h
> @@ -0,0 +1,8 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _LINUX_INSTRUCTION_POINTER_H
> +#define _LINUX_INSTRUCTION_POINTER_H
> +
> +#define _RET_IP_		(unsigned long)__builtin_return_address(0)
> +#define _THIS_IP_  ({ __label__ __here; __here: (unsigned long)&&__here; })
> +
> +#enfif /* _LINUX_INSTRUCTION_POINTER_H */
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index 973c61ff2ef9..be84ab369650 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -20,6 +20,7 @@
>  #include <linux/printk.h>
>  #include <linux/build_bug.h>
>  #include <linux/static_call_types.h>
> +#include <linux/instruction_pointer.h>
>  #include <asm/byteorder.h>
>  
>  #include <uapi/linux/kernel.h>
> @@ -53,9 +54,6 @@
>  }					\
>  )
>  
> -#define _RET_IP_		(unsigned long)__builtin_return_address(0)
> -#define _THIS_IP_  ({ __label__ __here; __here: (unsigned long)&&__here; })
> -
>  /**
>   * upper_32_bits - return bits 32-63 of a number
>   * @n: the number we're accessing
> -- 
> 2.33.0

-- 
With Best Regards,
Andy Shevchenko

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

[Joel Stanley]

On Mon, 25 Oct 2021 at 06:09, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi Joel,
>
> On Mon, 25 Oct 2021 05:58:37 +0000 Joel Stanley <joel@jms.id.au> wrote:
> >
> > If I apply this patch then the build fails in a tree that doesn't have
> > Willy's patch.
> >
> > Unless someone has a better suggestion I'll send a patch that includes
> > both headers for now, and make a note to remove the mm.h include down
> > the track.
>
> Don't apply anything.  Just remember to tell Linus (or whoever you
> merge this tree via) about this conflict and the resolution when you
> send the pull request.

Okay. It's not a conflict though, rather an ordering issue.

Greg has already merged this patch into his char-misc driver tree.

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

[Stephen Rothwell]

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

Hi Joel,

On Mon, 25 Oct 2021 05:58:37 +0000 Joel Stanley <joel@jms.id.au> wrote:
>
> If I apply this patch then the build fails in a tree that doesn't have
> Willy's patch.
> 
> Unless someone has a better suggestion I'll send a patch that includes
> both headers for now, and make a note to remove the mm.h include down
> the track.

Don't apply anything.  Just remember to tell Linus (or whoever you
merge this tree via) about this conflict and the resolution when you
send the pull request.

-- 
Cheers,
Stephen Rothwell

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

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

[Joel Stanley]

On Fri, 22 Oct 2021 at 08:39, 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:
>
> drivers/hwmon/occ/p9_sbe.c: In function 'p9_sbe_occ_save_ffdc':
> drivers/hwmon/occ/p9_sbe.c:58:5: error: implicit declaration of function 'kvfree' [-Werror=implicit-function-declaration]
>    58 |     kvfree(ctx->ffdc);
>       |     ^~~~~~
> drivers/hwmon/occ/p9_sbe.c:59:16: error: implicit declaration of function 'kvmalloc'; did you mean 'key_alloc'? [-Werror=implicit-function-declaration]
>    59 |    ctx->ffdc = kvmalloc(resp_len, GFP_KERNEL);
>       |                ^~~~~~~~
>       |                key_alloc
> drivers/hwmon/occ/p9_sbe.c:59:14: error: assignment to 'void *' from 'int' makes pointer from integer without a cast [-Werror=int-conversion]
>    59 |    ctx->ffdc = kvmalloc(resp_len, GFP_KERNEL);
>       |              ^
> cc1: all warnings being treated as errors
>
> Caused by commit
>
>   5027a34a575e ("hwmon: (occ) Provide the SBEFIFO FFDC in binary sysfs")
>
> from the fsi tree interacting with commit
>
>   9192e3be4cc2 ("mm: move kvmalloc-related functions to slab.h")
>
> from the akpm-current tree.

If I apply this patch then the build fails in a tree that doesn't have
Willy's patch.

Unless someone has a better suggestion I'll send a patch that includes
both headers for now, and make a note to remove the mm.h include down
the track.

Cheers,

Joel

>
> I have applied the following merge fix patch for today.
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 22 Oct 2021 19:32:54 +1100
> Subject: [PATCH] kvmalloc etc moved to slab.h
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  drivers/hwmon/occ/p9_sbe.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hwmon/occ/p9_sbe.c b/drivers/hwmon/occ/p9_sbe.c
> index e50243580269..bb082eb52243 100644
> --- a/drivers/hwmon/occ/p9_sbe.c
> +++ b/drivers/hwmon/occ/p9_sbe.c
> @@ -4,10 +4,10 @@
>  #include <linux/device.h>
>  #include <linux/errno.h>
>  #include <linux/fsi-occ.h>
> -#include <linux/mm.h>
>  #include <linux/module.h>
>  #include <linux/mutex.h>
>  #include <linux/platform_device.h>
> +#include <linux/slab.h>
>  #include <linux/string.h>
>  #include <linux/sysfs.h>
>
> --
> 2.33.0
>
> --
> Cheers,
> Stephen Rothwell

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

[Stephen Rothwell]

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

Hi all,

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

drivers/hwmon/occ/p9_sbe.c: In function 'p9_sbe_occ_save_ffdc':
drivers/hwmon/occ/p9_sbe.c:58:5: error: implicit declaration of function 'kvfree' [-Werror=implicit-function-declaration]
   58 |     kvfree(ctx->ffdc);
      |     ^~~~~~
drivers/hwmon/occ/p9_sbe.c:59:16: error: implicit declaration of function 'kvmalloc'; did you mean 'key_alloc'? [-Werror=implicit-function-declaration]
   59 |    ctx->ffdc = kvmalloc(resp_len, GFP_KERNEL);
      |                ^~~~~~~~
      |                key_alloc
drivers/hwmon/occ/p9_sbe.c:59:14: error: assignment to 'void *' from 'int' makes pointer from integer without a cast [-Werror=int-conversion]
   59 |    ctx->ffdc = kvmalloc(resp_len, GFP_KERNEL);
      |              ^
cc1: all warnings being treated as errors

Caused by commit

  5027a34a575e ("hwmon: (occ) Provide the SBEFIFO FFDC in binary sysfs")

from the fsi tree interacting with commit

  9192e3be4cc2 ("mm: move kvmalloc-related functions to slab.h")

from the akpm-current tree.

I have applied the following merge fix patch for today.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 22 Oct 2021 19:32:54 +1100
Subject: [PATCH] kvmalloc etc moved to slab.h

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

diff --git a/drivers/hwmon/occ/p9_sbe.c b/drivers/hwmon/occ/p9_sbe.c
index e50243580269..bb082eb52243 100644
--- a/drivers/hwmon/occ/p9_sbe.c
+++ b/drivers/hwmon/occ/p9_sbe.c
@@ -4,10 +4,10 @@
 #include <linux/device.h>
 #include <linux/errno.h>
 #include <linux/fsi-occ.h>
-#include <linux/mm.h>
 #include <linux/module.h>
 #include <linux/mutex.h>
 #include <linux/platform_device.h>
+#include <linux/slab.h>
 #include <linux/string.h>
 #include <linux/sysfs.h>
 
-- 
2.33.0

-- 
Cheers,
Stephen Rothwell

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

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

[Stephen Rothwell]

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

Hi all,

On Thu, 21 Oct 2021 17:43:03 +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/mmzone.h:22,
>                  from include/linux/gfp.h:6,
>                  from include/linux/xarray.h:14,
>                  from include/linux/radix-tree.h:19,
>                  from include/linux/fs.h:15,
>                  from include/linux/compat.h:17,
>                  from arch/powerpc/kernel/asm-offsets.c:12:
> include/linux/page-flags.h:806:29: error: macro "PAGEFLAG_FALSE" requires 2 arguments, but only 1 given
>   806 | PAGEFLAG_FALSE(HasHWPoisoned)
>       |                             ^
> include/linux/page-flags.h:411: note: macro "PAGEFLAG_FALSE" defined here
>   411 | #define PAGEFLAG_FALSE(uname, lname) TESTPAGEFLAG_FALSE(uname, lname) \
>       | 
> include/linux/page-flags.h:807:32: error: macro "TESTSCFLAG_FALSE" requires 2 arguments, but only 1 given
>   807 |  TESTSCFLAG_FALSE(HasHWPoisoned)
>       |                                ^
> include/linux/page-flags.h:414: note: macro "TESTSCFLAG_FALSE" defined here
>   414 | #define TESTSCFLAG_FALSE(uname, lname)     \
>       | 
> include/linux/page-flags.h:806:1: error: unknown type name 'PAGEFLAG_FALSE'
>   806 | PAGEFLAG_FALSE(HasHWPoisoned)
>       | ^~~~~~~~~~~~~~
> include/linux/page-flags.h:807:18: error: expected ';' before 'static'
>   807 |  TESTSCFLAG_FALSE(HasHWPoisoned)
>       |                  ^
>       |                  ;
> ......
>   815 | static inline bool is_page_hwpoison(struct page *page)
>       | ~~~~~~            
> 
> Caused by commit
> 
>   e95de3e8d811 ("mm: filemap: check if THP has hwpoisoned subpage for PMD page fault")
> 
> interacting with commit
> 
>   d389a4a81155 ("mm: Add folio flag manipulation functions")
> 
> from the folio tree.
> 
> I have applied the following merge fix patch for today.
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 21 Oct 2021 17:32:36 +1100
> Subject: [PATCH] fix up for "mm: Add folio flag manipulation functions"
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  include/linux/page-flags.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
> index 867b4bb3c336..80b33404ad1f 100644
> --- a/include/linux/page-flags.h
> +++ b/include/linux/page-flags.h
> @@ -803,8 +803,8 @@ PAGEFLAG_FALSE(DoubleMap, double_map)
>  PAGEFLAG(HasHWPoisoned, has_hwpoisoned, PF_SECOND)
>  	TESTSCFLAG(HasHWPoisoned, has_hwpoisoned, PF_SECOND)
>  #else
> -PAGEFLAG_FALSE(HasHWPoisoned)
> -	TESTSCFLAG_FALSE(HasHWPoisoned)
> +PAGEFLAG_FALSE(HasHWPoisoned, hashwpoisoned)
> +	TESTSCFLAG_FALSE(HasHWPoisoned, hashwpoisoned)
>  #endif
>  
>  /*
> -- 
> 2.33.0

So, I then discovered patch

mm-filemap-check-if-thp-has-hwpoisoned-subpage-for-pmd-page-fault-vs-folios.patch

which conflicted with my merge resolution.  I will use that tomorrow instead.

-- 
Cheers,
Stephen Rothwell

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

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

[Stephen Rothwell]

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

Hi all,

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

In file included from include/linux/mmzone.h:22,
                 from include/linux/gfp.h:6,
                 from include/linux/xarray.h:14,
                 from include/linux/radix-tree.h:19,
                 from include/linux/fs.h:15,
                 from include/linux/compat.h:17,
                 from arch/powerpc/kernel/asm-offsets.c:12:
include/linux/page-flags.h:806:29: error: macro "PAGEFLAG_FALSE" requires 2 arguments, but only 1 given
  806 | PAGEFLAG_FALSE(HasHWPoisoned)
      |                             ^
include/linux/page-flags.h:411: note: macro "PAGEFLAG_FALSE" defined here
  411 | #define PAGEFLAG_FALSE(uname, lname) TESTPAGEFLAG_FALSE(uname, lname) \
      | 
include/linux/page-flags.h:807:32: error: macro "TESTSCFLAG_FALSE" requires 2 arguments, but only 1 given
  807 |  TESTSCFLAG_FALSE(HasHWPoisoned)
      |                                ^
include/linux/page-flags.h:414: note: macro "TESTSCFLAG_FALSE" defined here
  414 | #define TESTSCFLAG_FALSE(uname, lname)     \
      | 
include/linux/page-flags.h:806:1: error: unknown type name 'PAGEFLAG_FALSE'
  806 | PAGEFLAG_FALSE(HasHWPoisoned)
      | ^~~~~~~~~~~~~~
include/linux/page-flags.h:807:18: error: expected ';' before 'static'
  807 |  TESTSCFLAG_FALSE(HasHWPoisoned)
      |                  ^
      |                  ;
......
  815 | static inline bool is_page_hwpoison(struct page *page)
      | ~~~~~~            

Caused by commit

  e95de3e8d811 ("mm: filemap: check if THP has hwpoisoned subpage for PMD page fault")

interacting with commit

  d389a4a81155 ("mm: Add folio flag manipulation functions")

from the folio tree.

I have applied the following merge fix patch for today.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 21 Oct 2021 17:32:36 +1100
Subject: [PATCH] fix up for "mm: Add folio flag manipulation functions"

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

diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
index 867b4bb3c336..80b33404ad1f 100644
--- a/include/linux/page-flags.h
+++ b/include/linux/page-flags.h
@@ -803,8 +803,8 @@ PAGEFLAG_FALSE(DoubleMap, double_map)
 PAGEFLAG(HasHWPoisoned, has_hwpoisoned, PF_SECOND)
 	TESTSCFLAG(HasHWPoisoned, has_hwpoisoned, PF_SECOND)
 #else
-PAGEFLAG_FALSE(HasHWPoisoned)
-	TESTSCFLAG_FALSE(HasHWPoisoned)
+PAGEFLAG_FALSE(HasHWPoisoned, hashwpoisoned)
+	TESTSCFLAG_FALSE(HasHWPoisoned, hashwpoisoned)
 #endif
 
 /*
-- 
2.33.0

-- 
Cheers,
Stephen Rothwell

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

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

[Mike Rapoport]

On Mon, Oct 18, 2021 at 07:29:40PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the akpm-current tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> init/main.c: In function 'xbc_make_cmdline':
> init/main.c:384:3: error: implicit declaration of function 'memblock_free_ptr'; did you mean 'memblock_free_late'? [-Werror=implicit-function-declaration]
>   384 |   memblock_free_ptr(new_cmdline, len + 1);
>       |   ^~~~~~~~~~~~~~~~~
>       |   memblock_free_late
> cc1: all warnings being treated as errors
> 
> Caused by commit
> 
>   d6e96e5e2e23 ("memblock: use memblock_free for freeing virtual pointers")
> 
> interacting with commit
> 
>   1ae43851b18a ("bootconfig: init: Fix memblock leak in xbc_make_cmdline()")
> 
> from Linus' tree.
> 
> I have applied the following merge fix patch.
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 18 Oct 2021 19:25:44 +1100
> Subject: [PATCH] fixup for "memblock: use memblock_free for freeing virtual
>  pointers"
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

Thanks!

Andrew, can you please add this as a fixup to "memblock: use memblock_free
for freeing virtual pointers"?

> ---
>  init/main.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/init/main.c b/init/main.c
> index 9b7fdd04e8cb..2851ebbe1985 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -381,7 +381,7 @@ static char * __init xbc_make_cmdline(const char *key)
>  	ret = xbc_snprint_cmdline(new_cmdline, len + 1, root);
>  	if (ret < 0 || ret > len) {
>  		pr_err("Failed to print extra kernel cmdline.\n");
> -		memblock_free_ptr(new_cmdline, len + 1);
> +		memblock_free(new_cmdline, len + 1);
>  		return NULL;
>  	}
>  
> -- 
> 2.33.0
> 
> -- 
> Cheers,
> Stephen Rothwell



-- 
Sincerely yours,
Mike.

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

[Andy Shevchenko]

On Mon, Oct 18, 2021 at 12:07 PM Rasmus Villemoes
<linux@rasmusvillemoes.dk> wrote:
> On 18/10/2021 10.45, Stephen Rothwell wrote:
> > On Mon, 18 Oct 2021 11:01:18 +0300 Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> >> On Mon, Oct 18, 2021 at 6:49 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:

...

> >> I thought that it makes sense to have STACK_MAGIC also in this header. Thoughts?
> >
> > You might want to think of a different name for the header file then.
>
> Eh, it seems more reasonable to leave it in kernel.h, then figure out
> how to get rid of it completely. AFAICT it's only used in one single
> place under arch/ (and I can't figure out how that magic value is
> supposed to get there in the first place... that arch was thrown out in
> 2013 and resurrected in 2015, but that particular line doesn't make
> sense), and then in some i915 code which might as well define their own
> cookie.

It's used in two places and probably we may just move it to these two
users, I don't believe will we ever have i915 together with h8300.

-- 
With Best Regards,
Andy Shevchenko

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

[Rasmus Villemoes]

On 18/10/2021 10.45, Stephen Rothwell wrote:
> Hi Andy,
> 
> On Mon, 18 Oct 2021 11:01:18 +0300 Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
>>
>> On Mon, Oct 18, 2021 at 6:49 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>> On Fri, 15 Oct 2021 16:14:56 +0300 Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:  
>>>>
>>>> Thanks! As a quick fix looks good, but I think we need a separate header for
>>>> those _*_IP_ macros.  
>>>
>>> Like this (on top of my previous fix - which I assume Andrew will
>>> squash out of existence)?  
>>
>> Yep, thanks!
>> I thought that it makes sense to have STACK_MAGIC also in this header. Thoughts?
> 
> You might want to think of a different name for the header file then.

Eh, it seems more reasonable to leave it in kernel.h, then figure out
how to get rid of it completely. AFAICT it's only used in one single
place under arch/ (and I can't figure out how that magic value is
supposed to get there in the first place... that arch was thrown out in
2013 and resurrected in 2015, but that particular line doesn't make
sense), and then in some i915 code which might as well define their own
cookie.

Rasmus

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

[Stephen Rothwell]

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

Hi Andy,

On Mon, 18 Oct 2021 11:01:18 +0300 Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
>
> On Mon, Oct 18, 2021 at 6:49 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > On Fri, 15 Oct 2021 16:14:56 +0300 Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:  
> > >
> > > Thanks! As a quick fix looks good, but I think we need a separate header for
> > > those _*_IP_ macros.  
> >
> > Like this (on top of my previous fix - which I assume Andrew will
> > squash out of existence)?  
> 
> Yep, thanks!
> I thought that it makes sense to have STACK_MAGIC also in this header. Thoughts?

You might want to think of a different name for the header file then.

> 
> One spelling correction below.
> 
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Date: Mon, 18 Oct 2021 13:27:54 +1100
> > Subject: [PATCH] kernel.h: split out instrcutions pointer accessors  
> 
> instructions

instruction ?  :-)

-- 
Cheers,
Stephen Rothwell

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

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

[Stephen Rothwell]

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

Hi all,

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

init/main.c: In function 'xbc_make_cmdline':
init/main.c:384:3: error: implicit declaration of function 'memblock_free_ptr'; did you mean 'memblock_free_late'? [-Werror=implicit-function-declaration]
  384 |   memblock_free_ptr(new_cmdline, len + 1);
      |   ^~~~~~~~~~~~~~~~~
      |   memblock_free_late
cc1: all warnings being treated as errors

Caused by commit

  d6e96e5e2e23 ("memblock: use memblock_free for freeing virtual pointers")

interacting with commit

  1ae43851b18a ("bootconfig: init: Fix memblock leak in xbc_make_cmdline()")

from Linus' tree.

I have applied the following merge fix patch.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 18 Oct 2021 19:25:44 +1100
Subject: [PATCH] fixup for "memblock: use memblock_free for freeing virtual
 pointers"

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

diff --git a/init/main.c b/init/main.c
index 9b7fdd04e8cb..2851ebbe1985 100644
--- a/init/main.c
+++ b/init/main.c
@@ -381,7 +381,7 @@ static char * __init xbc_make_cmdline(const char *key)
 	ret = xbc_snprint_cmdline(new_cmdline, len + 1, root);
 	if (ret < 0 || ret > len) {
 		pr_err("Failed to print extra kernel cmdline.\n");
-		memblock_free_ptr(new_cmdline, len + 1);
+		memblock_free(new_cmdline, len + 1);
 		return NULL;
 	}
 
-- 
2.33.0

-- 
Cheers,
Stephen Rothwell

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

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

[Andy Shevchenko]

On Mon, Oct 18, 2021 at 6:49 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> On Fri, 15 Oct 2021 16:14:56 +0300 Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> >
> > Thanks! As a quick fix looks good, but I think we need a separate header for
> > those _*_IP_ macros.
>
> Like this (on top of my previous fix - which I assume Andrew will
> squash out of existence)?

Yep, thanks!
I thought that it makes sense to have STACK_MAGIC also in this header. Thoughts?

One spelling correction below.

> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 18 Oct 2021 13:27:54 +1100
> Subject: [PATCH] kernel.h: split out instrcutions pointer accessors

instructions

> botton_half.h needs _THIS_IP_ to be standalone, so split that and _RET_IP_
> out from kernel.h into the new instruction_pointer.h.  kernel.h directly
> needs them, so include it there and replace the include of kernel.h with
> this new file in bottom_half.h.
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  include/linux/bottom_half.h         | 2 +-
>  include/linux/instruction_pointer.h | 8 ++++++++
>  include/linux/kernel.h              | 4 +---
>  3 files changed, 10 insertions(+), 4 deletions(-)
>  create mode 100644 include/linux/instruction_pointer.h
>
> diff --git a/include/linux/bottom_half.h b/include/linux/bottom_half.h
> index 11d107d88d03..fc53e0ad56d9 100644
> --- a/include/linux/bottom_half.h
> +++ b/include/linux/bottom_half.h
> @@ -2,7 +2,7 @@
>  #ifndef _LINUX_BH_H
>  #define _LINUX_BH_H
>
> -#include <linux/kernel.h>
> +#include <linux/instruction_pointer.h>
>  #include <linux/preempt.h>
>
>  #if defined(CONFIG_PREEMPT_RT) || defined(CONFIG_TRACE_IRQFLAGS)
> diff --git a/include/linux/instruction_pointer.h b/include/linux/instruction_pointer.h
> new file mode 100644
> index 000000000000..19e979425bda
> --- /dev/null
> +++ b/include/linux/instruction_pointer.h
> @@ -0,0 +1,8 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _LINUX_INSTRUCTION_POINTER_H
> +#define _LINUX_INSTRUCTION_POINTER_H
> +
> +#define _RET_IP_               (unsigned long)__builtin_return_address(0)
> +#define _THIS_IP_  ({ __label__ __here; __here: (unsigned long)&&__here; })
> +
> +#enfif /* _LINUX_INSTRUCTION_POINTER_H */
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index 973c61ff2ef9..be84ab369650 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -20,6 +20,7 @@
>  #include <linux/printk.h>
>  #include <linux/build_bug.h>
>  #include <linux/static_call_types.h>
> +#include <linux/instruction_pointer.h>
>  #include <asm/byteorder.h>
>
>  #include <uapi/linux/kernel.h>
> @@ -53,9 +54,6 @@
>  }                                      \
>  )
>
> -#define _RET_IP_               (unsigned long)__builtin_return_address(0)
> -#define _THIS_IP_  ({ __label__ __here; __here: (unsigned long)&&__here; })
> -
>  /**
>   * upper_32_bits - return bits 32-63 of a number
>   * @n: the number we're accessing
> --
> 2.33.0
>
> There are, presumably, other places this new file can be included ...
>
> --
> Cheers,
> Stephen Rothwell



-- 
With Best Regards,
Andy Shevchenko

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

[Stephen Rothwell]

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

Hi Andy,

On Fri, 15 Oct 2021 16:14:56 +0300 Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
>
> Thanks! As a quick fix looks good, but I think we need a separate header for
> those _*_IP_ macros.

Like this (on top of my previous fix - which I assume Andrew will
squash out of existence)?

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 18 Oct 2021 13:27:54 +1100
Subject: [PATCH] kernel.h: split out instrcutions pointer accessors

botton_half.h needs _THIS_IP_ to be standalone, so split that and _RET_IP_
out from kernel.h into the new instruction_pointer.h.  kernel.h directly
needs them, so include it there and replace the include of kernel.h with
this new file in bottom_half.h.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 include/linux/bottom_half.h         | 2 +-
 include/linux/instruction_pointer.h | 8 ++++++++
 include/linux/kernel.h              | 4 +---
 3 files changed, 10 insertions(+), 4 deletions(-)
 create mode 100644 include/linux/instruction_pointer.h

diff --git a/include/linux/bottom_half.h b/include/linux/bottom_half.h
index 11d107d88d03..fc53e0ad56d9 100644
--- a/include/linux/bottom_half.h
+++ b/include/linux/bottom_half.h
@@ -2,7 +2,7 @@
 #ifndef _LINUX_BH_H
 #define _LINUX_BH_H
 
-#include <linux/kernel.h>
+#include <linux/instruction_pointer.h>
 #include <linux/preempt.h>
 
 #if defined(CONFIG_PREEMPT_RT) || defined(CONFIG_TRACE_IRQFLAGS)
diff --git a/include/linux/instruction_pointer.h b/include/linux/instruction_pointer.h
new file mode 100644
index 000000000000..19e979425bda
--- /dev/null
+++ b/include/linux/instruction_pointer.h
@@ -0,0 +1,8 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _LINUX_INSTRUCTION_POINTER_H
+#define _LINUX_INSTRUCTION_POINTER_H
+
+#define _RET_IP_		(unsigned long)__builtin_return_address(0)
+#define _THIS_IP_  ({ __label__ __here; __here: (unsigned long)&&__here; })
+
+#enfif /* _LINUX_INSTRUCTION_POINTER_H */
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 973c61ff2ef9..be84ab369650 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -20,6 +20,7 @@
 #include <linux/printk.h>
 #include <linux/build_bug.h>
 #include <linux/static_call_types.h>
+#include <linux/instruction_pointer.h>
 #include <asm/byteorder.h>
 
 #include <uapi/linux/kernel.h>
@@ -53,9 +54,6 @@
 }					\
 )
 
-#define _RET_IP_		(unsigned long)__builtin_return_address(0)
-#define _THIS_IP_  ({ __label__ __here; __here: (unsigned long)&&__here; })
-
 /**
  * upper_32_bits - return bits 32-63 of a number
  * @n: the number we're accessing
-- 
2.33.0

There are, presumably, other places this new file can be included ...

-- 
Cheers,
Stephen Rothwell

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

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

[Andy Shevchenko]

+Cc: Rasmus

On Fri, Oct 15, 2021 at 08:29:08PM +1100, Stephen Rothwell 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/rcupdate.h:28,
>                  from include/linux/rculist.h:11,
>                  from include/linux/pid.h:5,
>                  from include/linux/sched.h:14,
>                  from arch/arm/kernel/asm-offsets.c:11:
> include/linux/bottom_half.h: In function 'local_bh_disable':
> include/linux/bottom_half.h:19:24: error: '_THIS_IP_' undeclared (first use in this function)
>    19 |  __local_bh_disable_ip(_THIS_IP_, SOFTIRQ_DISABLE_OFFSET);
>       |                        ^~~~~~~~~
> include/linux/bottom_half.h:19:24: note: each undeclared identifier is reported only once for each function it appears in
> include/linux/bottom_half.h: In function 'local_bh_enable':
> include/linux/bottom_half.h:32:23: error: '_THIS_IP_' undeclared (first use in this function)
>    32 |  __local_bh_enable_ip(_THIS_IP_, SOFTIRQ_DISABLE_OFFSET);
>       |                       ^~~~~~~~~
> 
> Presumably caused by a commit in the series that starts with
> 
>   dcaf7a5f413b ("kernel.h: drop unneeded <linux/kernel.h> inclusion from other headers")
> 
> I have applied the following patch for today (though there may be a
> better solution).

Thanks! As a quick fix looks good, but I think we need a separate header for
those _*_IP_ macros.

> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 15 Oct 2021 19:58:46 +1100
> Subject: [PATCH] bottom_half.h needs kernel.h
> 
> for _THIS_IP_ on arm at least
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  include/linux/bottom_half.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/linux/bottom_half.h b/include/linux/bottom_half.h
> index eed86eb0a1de..11d107d88d03 100644
> --- a/include/linux/bottom_half.h
> +++ b/include/linux/bottom_half.h
> @@ -2,6 +2,7 @@
>  #ifndef _LINUX_BH_H
>  #define _LINUX_BH_H
>  
> +#include <linux/kernel.h>
>  #include <linux/preempt.h>
>  
>  #if defined(CONFIG_PREEMPT_RT) || defined(CONFIG_TRACE_IRQFLAGS)

-- 
With Best Regards,
Andy Shevchenko

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1998 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/rcupdate.h:28,
                 from include/linux/rculist.h:11,
                 from include/linux/pid.h:5,
                 from include/linux/sched.h:14,
                 from arch/arm/kernel/asm-offsets.c:11:
include/linux/bottom_half.h: In function 'local_bh_disable':
include/linux/bottom_half.h:19:24: error: '_THIS_IP_' undeclared (first use in this function)
   19 |  __local_bh_disable_ip(_THIS_IP_, SOFTIRQ_DISABLE_OFFSET);
      |                        ^~~~~~~~~
include/linux/bottom_half.h:19:24: note: each undeclared identifier is reported only once for each function it appears in
include/linux/bottom_half.h: In function 'local_bh_enable':
include/linux/bottom_half.h:32:23: error: '_THIS_IP_' undeclared (first use in this function)
   32 |  __local_bh_enable_ip(_THIS_IP_, SOFTIRQ_DISABLE_OFFSET);
      |                       ^~~~~~~~~

Presumably caused by a commit in the series that starts with

  dcaf7a5f413b ("kernel.h: drop unneeded <linux/kernel.h> inclusion from other headers")

I have applied the following patch for today (though there may be a
better solution).

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 15 Oct 2021 19:58:46 +1100
Subject: [PATCH] bottom_half.h needs kernel.h

for _THIS_IP_ on arm at least

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

diff --git a/include/linux/bottom_half.h b/include/linux/bottom_half.h
index eed86eb0a1de..11d107d88d03 100644
--- a/include/linux/bottom_half.h
+++ b/include/linux/bottom_half.h
@@ -2,6 +2,7 @@
 #ifndef _LINUX_BH_H
 #define _LINUX_BH_H
 
+#include <linux/kernel.h>
 #include <linux/preempt.h>
 
 #if defined(CONFIG_PREEMPT_RT) || defined(CONFIG_TRACE_IRQFLAGS)
-- 
2.33.0

-- 
Cheers,
Stephen Rothwell

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

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

[Gavin Shan]

On 6/25/21 4:37 PM, Stephen Rothwell wrote:
> Hi all,
> 
> On Fri, 25 Jun 2021 16:34:42 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> On Fri, 25 Jun 2021 16:28:15 +1000 Gavin Shan <gshan@redhat.com> wrote:
>>>
>>> On 6/24/21 7:43 PM, Stephen Rothwell wrote:
>>>> Hi all,
>>>>
>>>> After merging the akpm-current tree, today's linux-next build (powerpc
>>>> ppc64_defconfig) failed like this:
>>>>
>>>> mm/page_reporting.c:14:37: error: initializer element is not constant
>>>>      14 | unsigned int page_reporting_order = pageblock_order;
>>>>         |                                     ^~~~~~~~~~~~~~~
>>>>
>>>> Caused by commit
>>>>
>>>>     223f64d9e679 ("mm/page_reporting: export reporting order as module parameter")
>>>>
>>>> pageblock_order is defined to be various things depending on CONFIG_
>>>> symbols.
>>>>
>>>> I have reverted that commit (and the following three) for today.
>>>>      
>>>
>>> Yes, Please drop this series for now.
>>>
>>> The v3 was applied and caused the build error. Actually, we need
>>> v5, which was posted couple of hours ago.
>>>
>>>      v5: https://lkml.org/lkml/2021/6/24/1137
>>
>> Which version is in today's mmotm?
> 
> hmm, looks like v4.  So do I drop these again today?
> 

Stephen, lets keep v4 and I will send patch to fill the gap between v4/v5
if no one objects. Sorry for the extra work.

Thanks,
Gavin

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

[Stephen Rothwell]

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

Hi all,

On Fri, 25 Jun 2021 16:34:42 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Fri, 25 Jun 2021 16:28:15 +1000 Gavin Shan <gshan@redhat.com> wrote:
> >
> > On 6/24/21 7:43 PM, Stephen Rothwell wrote:  
> > > Hi all,
> > > 
> > > After merging the akpm-current tree, today's linux-next build (powerpc
> > > ppc64_defconfig) failed like this:
> > > 
> > > mm/page_reporting.c:14:37: error: initializer element is not constant
> > >     14 | unsigned int page_reporting_order = pageblock_order;
> > >        |                                     ^~~~~~~~~~~~~~~
> > > 
> > > Caused by commit
> > > 
> > >    223f64d9e679 ("mm/page_reporting: export reporting order as module parameter")
> > > 
> > > pageblock_order is defined to be various things depending on CONFIG_
> > > symbols.
> > > 
> > > I have reverted that commit (and the following three) for today.
> > >     
> > 
> > Yes, Please drop this series for now.
> > 
> > The v3 was applied and caused the build error. Actually, we need
> > v5, which was posted couple of hours ago.
> > 
> >     v5: https://lkml.org/lkml/2021/6/24/1137  
> 
> Which version is in today's mmotm?

hmm, looks like v4.  So do I drop these again today?

-- 
Cheers,
Stephen Rothwell

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

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

[Stephen Rothwell]

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

Hi Andrew,

On Fri, 25 Jun 2021 16:28:15 +1000 Gavin Shan <gshan@redhat.com> wrote:
>
> On 6/24/21 7:43 PM, Stephen Rothwell wrote:
> > Hi all,
> > 
> > After merging the akpm-current tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> > 
> > mm/page_reporting.c:14:37: error: initializer element is not constant
> >     14 | unsigned int page_reporting_order = pageblock_order;
> >        |                                     ^~~~~~~~~~~~~~~
> > 
> > Caused by commit
> > 
> >    223f64d9e679 ("mm/page_reporting: export reporting order as module parameter")
> > 
> > pageblock_order is defined to be various things depending on CONFIG_
> > symbols.
> > 
> > I have reverted that commit (and the following three) for today.
> >   
> 
> Yes, Please drop this series for now.
> 
> The v3 was applied and caused the build error. Actually, we need
> v5, which was posted couple of hours ago.
> 
>     v5: https://lkml.org/lkml/2021/6/24/1137

Which version is in today's mmotm?

-- 
Cheers,
Stephen Rothwell

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

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

[Gavin Shan]

Hi Stephen,

On 6/24/21 7:43 PM, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the akpm-current tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> mm/page_reporting.c:14:37: error: initializer element is not constant
>     14 | unsigned int page_reporting_order = pageblock_order;
>        |                                     ^~~~~~~~~~~~~~~
> 
> Caused by commit
> 
>    223f64d9e679 ("mm/page_reporting: export reporting order as module parameter")
> 
> pageblock_order is defined to be various things depending on CONFIG_
> symbols.
> 
> I have reverted that commit (and the following three) for today.
> 

Yes, Please drop this series for now.

The v3 was applied and caused the build error. Actually, we need
v5, which was posted couple of hours ago.

    v5: https://lkml.org/lkml/2021/6/24/1137

Thanks,
Gavin

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

[Stephen Rothwell]

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

Hi all,

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

mm/page_reporting.c:14:37: error: initializer element is not constant
   14 | unsigned int page_reporting_order = pageblock_order;
      |                                     ^~~~~~~~~~~~~~~

Caused by commit

  223f64d9e679 ("mm/page_reporting: export reporting order as module parameter")

pageblock_order is defined to be various things depending on CONFIG_
symbols.

I have reverted that commit (and the following three) for today.

-- 
Cheers,
Stephen Rothwell

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

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

[Stephen Rothwell]

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

Hi all,

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

mm/migrate.c: In function 'unmap_and_move_huge_page':
mm/migrate.c:1295:6: error: implicit declaration of function 'hugetlb_page_subpool' [-Werror=implicit-function-declaration]
 1295 |  if (hugetlb_page_subpool(hpage) && !page_mapping(hpage)) {
      |      ^~~~~~~~~~~~~~~~~~~~

Caused by commit

  b63794a67ae2 ("mm: migrate: fix missing update page_private to hugetlb_page_subpool")

CONFIG_HUGETLB_PAGE is not defined 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 --]

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

[Waiman Long]

On 5/12/21 1:28 AM, Stephen Rothwell wrote:
> Hi all,
>
> As Randy also reported ...
>
> After merging the akpm-current tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> mm/slab_common.c:764:8: error: array index in initializer exceeds array bounds
>    764 |  .name[KMALLOC_RECLAIM] = "kmalloc-rcl-" #__short_size, \
>        |        ^~~~~~~~~~~~~~~
> mm/slab_common.c:776:2: note: in expansion of macro 'INIT_KMALLOC_INFO'
>    776 |  INIT_KMALLOC_INFO(0, 0),
>        |  ^~~~~~~~~~~~~~~~~
> mm/slab_common.c:756:39: error: array index in initializer exceeds array bounds
>    756 | #define KMALLOC_CGROUP_NAME(sz) .name[KMALLOC_CGROUP] = "kmalloc-cg-" #sz,
>        |                                       ^~~~~~~~~~~~~~
> mm/slab_common.c:765:2: note: in expansion of macro 'KMALLOC_CGROUP_NAME'
>    765 |  KMALLOC_CGROUP_NAME(__short_size)   \
>        |  ^~~~~~~~~~~~~~~~~~~
>
> and more
>
> Caused by commits
>
>    4d57437a3d3c ("mm: memcg/slab: create a new set of kmalloc-cg-<n> caches")
>    0727bf117622 ("mm: memcg/slab: don't create kmalloc-cg caches with cgroup.memory=nokmem")
>    d795c307bd3a ("mm: memcg/slab: disable cache merging for KMALLOC_NORMAL caches")
>
> At least they are the commits I have reverted to fix this.
>
Sorry about that. It turns out that construct like that below doesn't work.

enum kmalloc_cache_type {
         KMALLOC_NORMAL = 0,
#ifdef CONFIG_MEMCG_KMEM
         KMALLOC_CGROUP,
#else
         KMALLOC_CGROUP = KMALLOC_NORMAL,
#endif
         KMALLOC_RECLAIM,
#ifdef CONFIG_ZONE_DMA
         KMALLOC_DMA,
#else
         KMALLOC_DMA = KMALLOC_NORMAL,
#endif
         NR_KMALLOC_TYPES
};

The first ifdef is fine, but the second one will reset the enumeration 
count back to 0 if CONFIG_ZONE_DMA is not defined causing 
NR_KMALLOC_TYPES set to 1. Will send a new version to fix that.

Cheers,
Longman

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

[Christophe Leroy]

Nick,

Le 12/05/2021 à 07:33, Stephen Rothwell a écrit :
> Hi all,
> 
> After merging the akpm-current tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> In file included from arch/powerpc/include/asm/book3s/64/mmu-hash.h:20,
>                   from arch/powerpc/include/asm/book3s/64/mmu.h:31,
>                   from arch/powerpc/include/asm/mmu.h:402,
>                   from arch/powerpc/include/asm/lppaca.h:46,
>                   from arch/powerpc/include/asm/paca.h:17,
>                   from arch/powerpc/include/asm/current.h:13,
>                   from include/linux/thread_info.h:22,
>                   from include/asm-generic/preempt.h:5,
>                   from ./arch/powerpc/include/generated/asm/preempt.h:1,
>                   from include/linux/preempt.h:78,
>                   from include/linux/spinlock.h:51,
>                   from include/linux/vmalloc.h:5,
>                   from mm/ioremap.c:9:
> arch/powerpc/include/asm/book3s/64/pgtable.h:246:21: error: initializer element is not constant
>    246 | #define PGDIR_SHIFT (PUD_SHIFT + PUD_INDEX_SIZE)
>        |                     ^
> include/asm-generic/pgtable-nop4d.h:11:20: note: in expansion of macro 'PGDIR_SHIFT'
>     11 | #define P4D_SHIFT  PGDIR_SHIFT
>        |                    ^~~~~~~~~~~
> mm/ioremap.c:19:60: note: in expansion of macro 'P4D_SHIFT'
>     19 | static unsigned int __ro_after_init iomap_max_page_shift = P4D_SHIFT;
>        |                                                            ^~~~~~~~~

Argh ....

I'm still not used to CAPITAL_NAMES defines not being constant ....

So we need to initialise this from some init function that runs before parse_early_param()

Nick, any idea ?

> 
> Caused by commit
> 
>    9054fd6cce6c ("mm/ioremap: fix iomap_max_page_shift")
> 
> I have reverted that commit for today.
> 

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

[Stephen Rothwell]

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

Hi all,

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

In file included from arch/powerpc/include/asm/book3s/64/mmu-hash.h:20,
                 from arch/powerpc/include/asm/book3s/64/mmu.h:31,
                 from arch/powerpc/include/asm/mmu.h:402,
                 from arch/powerpc/include/asm/lppaca.h:46,
                 from arch/powerpc/include/asm/paca.h:17,
                 from arch/powerpc/include/asm/current.h:13,
                 from include/linux/thread_info.h:22,
                 from include/asm-generic/preempt.h:5,
                 from ./arch/powerpc/include/generated/asm/preempt.h:1,
                 from include/linux/preempt.h:78,
                 from include/linux/spinlock.h:51,
                 from include/linux/vmalloc.h:5,
                 from mm/ioremap.c:9:
arch/powerpc/include/asm/book3s/64/pgtable.h:246:21: error: initializer element is not constant
  246 | #define PGDIR_SHIFT (PUD_SHIFT + PUD_INDEX_SIZE)
      |                     ^
include/asm-generic/pgtable-nop4d.h:11:20: note: in expansion of macro 'PGDIR_SHIFT'
   11 | #define P4D_SHIFT  PGDIR_SHIFT
      |                    ^~~~~~~~~~~
mm/ioremap.c:19:60: note: in expansion of macro 'P4D_SHIFT'
   19 | static unsigned int __ro_after_init iomap_max_page_shift = P4D_SHIFT;
      |                                                            ^~~~~~~~~

Caused by commit

  9054fd6cce6c ("mm/ioremap: fix iomap_max_page_shift")

I have reverted that commit for today.

-- 
Cheers,
Stephen Rothwell

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

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

[Stephen Rothwell]

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

Hi all,

As Randy also reported ...

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

mm/slab_common.c:764:8: error: array index in initializer exceeds array bounds
  764 |  .name[KMALLOC_RECLAIM] = "kmalloc-rcl-" #__short_size, \
      |        ^~~~~~~~~~~~~~~
mm/slab_common.c:776:2: note: in expansion of macro 'INIT_KMALLOC_INFO'
  776 |  INIT_KMALLOC_INFO(0, 0),
      |  ^~~~~~~~~~~~~~~~~
mm/slab_common.c:756:39: error: array index in initializer exceeds array bounds
  756 | #define KMALLOC_CGROUP_NAME(sz) .name[KMALLOC_CGROUP] = "kmalloc-cg-" #sz,
      |                                       ^~~~~~~~~~~~~~
mm/slab_common.c:765:2: note: in expansion of macro 'KMALLOC_CGROUP_NAME'
  765 |  KMALLOC_CGROUP_NAME(__short_size)   \
      |  ^~~~~~~~~~~~~~~~~~~

and more

Caused by commits

  4d57437a3d3c ("mm: memcg/slab: create a new set of kmalloc-cg-<n> caches")
  0727bf117622 ("mm: memcg/slab: don't create kmalloc-cg caches with cgroup.memory=nokmem")
  d795c307bd3a ("mm: memcg/slab: disable cache merging for KMALLOC_NORMAL caches")

At least they are the commits I have reverted to fix this.

-- 
Cheers,
Stephen Rothwell

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

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

[Nicholas Piggin]

Excerpts from Stephen Rothwell's message of March 24, 2021 6:58 am:
> Hi all,
> 
> On Thu, 18 Mar 2021 20:56:07 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> 
>> 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:25:0,
>>                  from arch/sparc/include/asm/pgtable.h:7,
>>                  from include/linux/pgtable.h:6,
>>                  from include/linux/mm.h:33,
>>                  from mm/vmalloc.c:12:
>> mm/vmalloc.c: In function 'vmalloc_to_page':
>> include/asm-generic/pgtable-nopud.h:51:27: error: implicit declaration of function 'pud_page'; did you mean 'put_page'? [-Werror=implicit-function-declaration]
>>  #define p4d_page(p4d)    (pud_page((pud_t){ p4d }))
>>                            ^
>> mm/vmalloc.c:643:10: note: in expansion of macro 'p4d_page'
>>    return p4d_page(*p4d) + ((addr & ~P4D_MASK) >> PAGE_SHIFT);
>>           ^~~~~~~~
>> mm/vmalloc.c:643:25: warning: return makes pointer from integer without a cast [-Wint-conversion]
>>    return p4d_page(*p4d) + ((addr & ~P4D_MASK) >> PAGE_SHIFT);
>> mm/vmalloc.c:651:25: warning: return makes pointer from integer without a cast [-Wint-conversion]
>>    return pud_page(*pud) + ((addr & ~PUD_MASK) >> PAGE_SHIFT);
>>           ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> 
>> Caused by commit
>> 
>>   70d18d470920 ("mm/vmalloc: fix HUGE_VMAP regression by enabling huge pages in vmalloc_to_page")
>> 
>> I have applied the following hack path for today (hopefully someone can
>> come up with something better):
>> 
>> From: Stephen Rothwell <sfr@canb.auug.org.au>
>> Date: Thu, 18 Mar 2021 18:32:58 +1100
>> Subject: [PATCH] hack to make SPARC32 build
>> 
>> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
>> ---
>>  mm/vmalloc.c | 8 ++++++++
>>  1 file changed, 8 insertions(+)
>> 
>> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
>> index 57b7f62d25a7..96444d64129a 100644
>> --- a/mm/vmalloc.c
>> +++ b/mm/vmalloc.c
>> @@ -640,7 +640,11 @@ struct page *vmalloc_to_page(const void *vmalloc_addr)
>>  	if (p4d_none(*p4d))
>>  		return NULL;
>>  	if (p4d_leaf(*p4d))
>> +#ifdef CONFIG_SPARC32
>> +		return NULL;
>> +#else
>>  		return p4d_page(*p4d) + ((addr & ~P4D_MASK) >> PAGE_SHIFT);
>> +#endif
>>  	if (WARN_ON_ONCE(p4d_bad(*p4d)))
>>  		return NULL;
>>  
>> @@ -648,7 +652,11 @@ struct page *vmalloc_to_page(const void *vmalloc_addr)
>>  	if (pud_none(*pud))
>>  		return NULL;
>>  	if (pud_leaf(*pud))
>> +#ifdef CONFIG_SPARC32
>> +		return NULL;
>> +#else
>>  		return pud_page(*pud) + ((addr & ~PUD_MASK) >> PAGE_SHIFT);
>> +#endif
>>  	if (WARN_ON_ONCE(pud_bad(*pud)))
>>  		return NULL;
>>  
>> -- 
>> 2.30.0
> 
> I am still applying this hack.

Oh I missed your first mail, thanks for the ping. I'll have a look 
today.

Thanks,
Nick

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

[Stephen Rothwell]

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

Hi all,

On Thu, 18 Mar 2021 20:56:07 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> 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:25:0,
>                  from arch/sparc/include/asm/pgtable.h:7,
>                  from include/linux/pgtable.h:6,
>                  from include/linux/mm.h:33,
>                  from mm/vmalloc.c:12:
> mm/vmalloc.c: In function 'vmalloc_to_page':
> include/asm-generic/pgtable-nopud.h:51:27: error: implicit declaration of function 'pud_page'; did you mean 'put_page'? [-Werror=implicit-function-declaration]
>  #define p4d_page(p4d)    (pud_page((pud_t){ p4d }))
>                            ^
> mm/vmalloc.c:643:10: note: in expansion of macro 'p4d_page'
>    return p4d_page(*p4d) + ((addr & ~P4D_MASK) >> PAGE_SHIFT);
>           ^~~~~~~~
> mm/vmalloc.c:643:25: warning: return makes pointer from integer without a cast [-Wint-conversion]
>    return p4d_page(*p4d) + ((addr & ~P4D_MASK) >> PAGE_SHIFT);
> mm/vmalloc.c:651:25: warning: return makes pointer from integer without a cast [-Wint-conversion]
>    return pud_page(*pud) + ((addr & ~PUD_MASK) >> PAGE_SHIFT);
>           ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> Caused by commit
> 
>   70d18d470920 ("mm/vmalloc: fix HUGE_VMAP regression by enabling huge pages in vmalloc_to_page")
> 
> I have applied the following hack path for today (hopefully someone can
> come up with something better):
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 18 Mar 2021 18:32:58 +1100
> Subject: [PATCH] hack to make SPARC32 build
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  mm/vmalloc.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 57b7f62d25a7..96444d64129a 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -640,7 +640,11 @@ struct page *vmalloc_to_page(const void *vmalloc_addr)
>  	if (p4d_none(*p4d))
>  		return NULL;
>  	if (p4d_leaf(*p4d))
> +#ifdef CONFIG_SPARC32
> +		return NULL;
> +#else
>  		return p4d_page(*p4d) + ((addr & ~P4D_MASK) >> PAGE_SHIFT);
> +#endif
>  	if (WARN_ON_ONCE(p4d_bad(*p4d)))
>  		return NULL;
>  
> @@ -648,7 +652,11 @@ struct page *vmalloc_to_page(const void *vmalloc_addr)
>  	if (pud_none(*pud))
>  		return NULL;
>  	if (pud_leaf(*pud))
> +#ifdef CONFIG_SPARC32
> +		return NULL;
> +#else
>  		return pud_page(*pud) + ((addr & ~PUD_MASK) >> PAGE_SHIFT);
> +#endif
>  	if (WARN_ON_ONCE(pud_bad(*pud)))
>  		return NULL;
>  
> -- 
> 2.30.0

I am still applying this hack.
-- 
Cheers,
Stephen Rothwell

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

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

[Stephen Rothwell]

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

Hi all,

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:25:0,
                 from arch/sparc/include/asm/pgtable.h:7,
                 from include/linux/pgtable.h:6,
                 from include/linux/mm.h:33,
                 from mm/vmalloc.c:12:
mm/vmalloc.c: In function 'vmalloc_to_page':
include/asm-generic/pgtable-nopud.h:51:27: error: implicit declaration of function 'pud_page'; did you mean 'put_page'? [-Werror=implicit-function-declaration]
 #define p4d_page(p4d)    (pud_page((pud_t){ p4d }))
                           ^
mm/vmalloc.c:643:10: note: in expansion of macro 'p4d_page'
   return p4d_page(*p4d) + ((addr & ~P4D_MASK) >> PAGE_SHIFT);
          ^~~~~~~~
mm/vmalloc.c:643:25: warning: return makes pointer from integer without a cast [-Wint-conversion]
   return p4d_page(*p4d) + ((addr & ~P4D_MASK) >> PAGE_SHIFT);
mm/vmalloc.c:651:25: warning: return makes pointer from integer without a cast [-Wint-conversion]
   return pud_page(*pud) + ((addr & ~PUD_MASK) >> PAGE_SHIFT);
          ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Caused by commit

  70d18d470920 ("mm/vmalloc: fix HUGE_VMAP regression by enabling huge pages in vmalloc_to_page")

I have applied the following hack path for today (hopefully someone can
come up with something better):

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 18 Mar 2021 18:32:58 +1100
Subject: [PATCH] hack to make SPARC32 build

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

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 57b7f62d25a7..96444d64129a 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -640,7 +640,11 @@ struct page *vmalloc_to_page(const void *vmalloc_addr)
 	if (p4d_none(*p4d))
 		return NULL;
 	if (p4d_leaf(*p4d))
+#ifdef CONFIG_SPARC32
+		return NULL;
+#else
 		return p4d_page(*p4d) + ((addr & ~P4D_MASK) >> PAGE_SHIFT);
+#endif
 	if (WARN_ON_ONCE(p4d_bad(*p4d)))
 		return NULL;
 
@@ -648,7 +652,11 @@ struct page *vmalloc_to_page(const void *vmalloc_addr)
 	if (pud_none(*pud))
 		return NULL;
 	if (pud_leaf(*pud))
+#ifdef CONFIG_SPARC32
+		return NULL;
+#else
 		return pud_page(*pud) + ((addr & ~PUD_MASK) >> PAGE_SHIFT);
+#endif
 	if (WARN_ON_ONCE(pud_bad(*pud)))
 		return NULL;
 
-- 
2.30.0

-- 
Cheers,
Stephen Rothwell

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

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

[Axel Rasmussen]

On Tue, Mar 9, 2021 at 7:16 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> After merging the akpm-current tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:

Hi Stephen,

Sorry about the failure! Indeed, I had guarded this in the header, but
not in the .c file. I sent a v2.5 of the patch earlier today which
fixes the issue, but it hasn't made its way to Andrew's tree just yet.
I'll CC you on that thread as well, as an FYI. Reverting the patches
is also a fine workaround.

Next time, I'll test with more config permutations. :)

>
> mm/shmem.c:2365:12: warning: 'enum mcopy_atomic_mode' declared inside parameter list will not be visible outside of this definition or declaration
>  2365 |       enum mcopy_atomic_mode mode, struct page **pagep)
>       |            ^~~~~~~~~~~~~~~~~
> mm/shmem.c:2365:30: error: parameter 6 ('mode') has incomplete type
>  2365 |       enum mcopy_atomic_mode mode, struct page **pagep)
>       |       ~~~~~~~~~~~~~~~~~~~~~~~^~~~
> mm/shmem.c:2362:5: error: function declaration isn't a prototype [-Werror=strict-prototypes]
>  2362 | int shmem_mcopy_atomic_pte(struct mm_struct *dst_mm, pmd_t *dst_pmd,
>       |     ^~~~~~~~~~~~~~~~~~~~~~
> mm/shmem.c: In function 'shmem_mcopy_atomic_pte':
> mm/shmem.c:2367:30: error: 'MCOPY_ATOMIC_CONTINUE' undeclared (first use in this function)
>  2367 |  bool is_continue = (mode == MCOPY_ATOMIC_CONTINUE);
>       |                              ^~~~~~~~~~~~~~~~~~~~~
> mm/shmem.c:2367:30: note: each undeclared identifier is reported only once for each function it appears in
> mm/shmem.c:2394:15: error: 'MCOPY_ATOMIC_NORMAL' undeclared (first use in this function)
>  2394 |   if (mode == MCOPY_ATOMIC_NORMAL) { /* mcopy_atomic */
>       |               ^~~~~~~~~~~~~~~~~~~
>
> Caused by commit
>
>   3407bec05d6d ("userfaultfd: support minor fault handling for shmem")
>
> # CONFIG_USERFAULTFD is not set
>
> I have reverted that commit (and the following 4 as well).
> --
> Cheers,
> Stephen Rothwell

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

[Stephen Rothwell]

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

Hi all,

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

arch/sparc/mm/init_64.c:2495:4: error: implicit declaration of function 'register_page_bootmem_info_node'; did you mean 'register_page_bootmem_info'? [-Werror=implicit-function-declaration]
    register_page_bootmem_info_node(NODE_DATA(i));
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    register_page_bootmem_info

Caused by commit

  cd28b1a6791d ("mm: memory_hotplug: factor out bootmem core functions to bootmem_info.c")

grep is your friend ...

I have applied the following patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 10 Mar 2021 14:46:27 +1100
Subject: [PATCH] fix for "mm: memory_hotplug: factor out bootmem core
 functions to bootmem_info.c"

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

diff --git a/arch/sparc/mm/init_64.c b/arch/sparc/mm/init_64.c
index 182bb7bdaa0a..c709b72e81bf 100644
--- a/arch/sparc/mm/init_64.c
+++ b/arch/sparc/mm/init_64.c
@@ -27,6 +27,7 @@
 #include <linux/percpu.h>
 #include <linux/mmzone.h>
 #include <linux/gfp.h>
+#include <linux/bootmem_info.h>
 
 #include <asm/head.h>
 #include <asm/page.h>
-- 
2.30.0

-- 
Cheers,
Stephen Rothwell

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

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

[Stephen Rothwell]

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

Hi all,

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

mm/shmem.c:2365:12: warning: 'enum mcopy_atomic_mode' declared inside parameter list will not be visible outside of this definition or declaration
 2365 |       enum mcopy_atomic_mode mode, struct page **pagep)
      |            ^~~~~~~~~~~~~~~~~
mm/shmem.c:2365:30: error: parameter 6 ('mode') has incomplete type
 2365 |       enum mcopy_atomic_mode mode, struct page **pagep)
      |       ~~~~~~~~~~~~~~~~~~~~~~~^~~~
mm/shmem.c:2362:5: error: function declaration isn't a prototype [-Werror=strict-prototypes]
 2362 | int shmem_mcopy_atomic_pte(struct mm_struct *dst_mm, pmd_t *dst_pmd,
      |     ^~~~~~~~~~~~~~~~~~~~~~
mm/shmem.c: In function 'shmem_mcopy_atomic_pte':
mm/shmem.c:2367:30: error: 'MCOPY_ATOMIC_CONTINUE' undeclared (first use in this function)
 2367 |  bool is_continue = (mode == MCOPY_ATOMIC_CONTINUE);
      |                              ^~~~~~~~~~~~~~~~~~~~~
mm/shmem.c:2367:30: note: each undeclared identifier is reported only once for each function it appears in
mm/shmem.c:2394:15: error: 'MCOPY_ATOMIC_NORMAL' undeclared (first use in this function)
 2394 |   if (mode == MCOPY_ATOMIC_NORMAL) { /* mcopy_atomic */
      |               ^~~~~~~~~~~~~~~~~~~

Caused by commit

  3407bec05d6d ("userfaultfd: support minor fault handling for shmem")

# CONFIG_USERFAULTFD is not set

I have reverted that commit (and the following 4 as well).
-- 
Cheers,
Stephen Rothwell

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

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

[Stephen Rothwell]

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

Hi all,

On Tue, 2 Feb 2021 20:03:24 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the akpm-current tree, today's linux-next build (x86_64
> allnoconfig) failed like this:
> 
> In file included from arch/x86/include/asm/page.h:76,
>                  from arch/x86/include/asm/thread_info.h:12,
>                  from include/linux/thread_info.h:56,
>                  from arch/x86/include/asm/preempt.h:7,
>                  from include/linux/preempt.h:78,
>                  from include/linux/spinlock.h:51,
>                  from include/linux/mmzone.h:8,
>                  from include/linux/gfp.h:6,
>                  from include/linux/slab.h:15,
>                  from include/linux/crypto.h:20,
>                  from arch/x86/kernel/asm-offsets.c:9:
> include/linux/mm.h: In function 'is_pinnable_page':
> include/asm-generic/memory_model.h:64:14: error: implicit declaration of function 'page_to_section'; did you mean 'present_section'? [-Werror=implicit-function-declaration]
>    64 |  int __sec = page_to_section(__pg);   \
>       |              ^~~~~~~~~~~~~~~
> include/asm-generic/memory_model.h:81:21: note: in expansion of macro '__page_to_pfn'
>    81 | #define page_to_pfn __page_to_pfn
>       |                     ^~~~~~~~~~~~~
> include/linux/mm.h:1134:15: note: in expansion of macro 'page_to_pfn'
>  1134 |   is_zero_pfn(page_to_pfn(page));
>       |               ^~~~~~~~~~~
> In file included from include/linux/kallsyms.h:12,
>                  from include/linux/bpf.h:21,
>                  from include/linux/bpf-cgroup.h:5,
>                  from include/linux/cgroup-defs.h:22,
>                  from include/linux/cgroup.h:28,
>                  from include/linux/memcontrol.h:13,
>                  from include/linux/swap.h:9,
>                  from include/linux/suspend.h:5,
>                  from arch/x86/kernel/asm-offsets.c:13:
> include/linux/mm.h: At top level:
> include/linux/mm.h:1505:29: error: conflicting types for 'page_to_section'
>  1505 | static inline unsigned long page_to_section(const struct page *page)
>       |                             ^~~~~~~~~~~~~~~
> In file included from arch/x86/include/asm/page.h:76,
>                  from arch/x86/include/asm/thread_info.h:12,
>                  from include/linux/thread_info.h:56,
>                  from arch/x86/include/asm/preempt.h:7,
>                  from include/linux/preempt.h:78,
>                  from include/linux/spinlock.h:51,
>                  from include/linux/mmzone.h:8,
>                  from include/linux/gfp.h:6,
>                  from include/linux/slab.h:15,
>                  from include/linux/crypto.h:20,
>                  from arch/x86/kernel/asm-offsets.c:9:
> include/asm-generic/memory_model.h:64:14: note: previous implicit declaration of 'page_to_section' was here
>    64 |  int __sec = page_to_section(__pg);   \
>       |              ^~~~~~~~~~~~~~~
> include/asm-generic/memory_model.h:81:21: note: in expansion of macro '__page_to_pfn'
>    81 | #define page_to_pfn __page_to_pfn
>       |                     ^~~~~~~~~~~~~
> include/linux/mm.h:1134:15: note: in expansion of macro 'page_to_pfn'
>  1134 |   is_zero_pfn(page_to_pfn(page));
>       |               ^~~~~~~~~~~
> 
> This build has CONFIG_SPARSEMEM set and CONFIG_SPARSEMEM_VMEMMAP not set.
> 
> Caused by commit
> 
>   983cb10d3f90 ("mm/gup: do not migrate zero page")
> 
> I have applied the following patch for today:
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 2 Feb 2021 19:49:00 +1100
> Subject: [PATCH] make is_pinnable_page a macro
> 
> As it is currently defined before page_to_section() which it needs.
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  include/linux/mm.h | 8 +++-----
>  1 file changed, 3 insertions(+), 5 deletions(-)
> 
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 58f250cabea6..a608feb0d42e 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -1128,11 +1128,9 @@ static inline bool is_zone_movable_page(const struct page *page)
>  }
>  
>  /* MIGRATE_CMA and ZONE_MOVABLE do not allow pin pages */
> -static inline bool is_pinnable_page(struct page *page)
> -{
> -	return !(is_zone_movable_page(page) || is_migrate_cma_page(page)) ||
> -		is_zero_pfn(page_to_pfn(page));
> -}
> +#define is_pinnable_page(page)		\
> +	(!(is_zone_movable_page(page) || is_migrate_cma_page(page)) ||	\
> +		is_zero_pfn(page_to_pfn(page)))
>  
>  #ifdef CONFIG_DEV_PAGEMAP_OPS
>  void free_devmap_managed_page(struct page *page);
> -- 
> 2.29.2

OK, so today I will add the following to linux-next as it is still
needed.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 4 Feb 2021 12:05:57 +1100
Subject: [PATCH] make is_pinnable_page a macro

As it is currently defined before page_to_section() which it needs.

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

diff --git a/include/linux/mm.h b/include/linux/mm.h
index baa3d3a9b655..8b1f889c6715 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1123,16 +1123,11 @@ static inline bool is_zone_movable_page(const struct page *page)
 
 #ifdef CONFIG_MIGRATION
 /* MIGRATE_CMA and ZONE_MOVABLE do not allow pin pages */
-static inline bool is_pinnable_page(struct page *page)
-{
-	return !(is_zone_movable_page(page) || is_migrate_cma_page(page)) ||
-		is_zero_pfn(page_to_pfn(page));
-}
+#define is_pinnable_page(page)						\
+	(!(is_zone_movable_page(page) || is_migrate_cma_page(page)) ||	\
+		is_zero_pfn(page_to_pfn(page)))
 #else
-static inline bool is_pinnable_page(struct page *page)
-{
-	return true;
-}
+#define is_pinnable_page(page)	true
 #endif
 
 #ifdef CONFIG_DEV_PAGEMAP_OPS
-- 
2.30.0

-- 
Cheers,
Stephen Rothwell

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

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

[Randy Dunlap]

On 2/3/21 2:22 PM, Arnd Bergmann wrote:
> On Wed, Feb 3, 2021 at 6:34 PM Randy Dunlap <rdunlap@infradead.org> wrote:
>>
>> On 2/3/21 9:09 AM, Arnd Bergmann wrote:
>>> On Tue, Feb 2, 2021 at 10:12 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>>
>>>>
>>>>   983cb10d3f90 ("mm/gup: do not migrate zero page")
>>>>
>>>> I have applied the following patch for today:
>>>>
>>>> From: Stephen Rothwell <sfr@canb.auug.org.au>
>>>> Date: Tue, 2 Feb 2021 19:49:00 +1100
>>>> Subject: [PATCH] make is_pinnable_page a macro
>>>>
>>>> As it is currently defined before page_to_section() which it needs.
>>>>
>>>> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
>>>
>>> I still see the same problem in next-20210203, and your patch below
>>> fixes it for me.
>>> Did you drop it from the latest build?
>>>
>>
>> After the most recent build errors, I tried to apply Pavel's patch
>>   https://lore.kernel.org/linux-mm/CA+CK2bBjC8=cRsL5VhWkcevPsqSXWhsANVjsFNMERLT8vWtiQw@mail.gmail.com/
>> but patch said that it was already applied (by Andrew I think),
>> so I bailed out (gave up).
> 
> As far as I can tell, there are two different bugs that got mixed up, and
> we need both Pavel's patch (which is now in -next) and Stephen's
> (which got dropped again).

Thanks. Having both patches makes my builds happy again. :)

-- 
~Randy

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

[Pavel Tatashin]

> >
> > Stephen, do you want to send a new patch based on the current
> > linux-next, or do you want me to send an updated version?
>
> I'll send another one and include it in linux-next today.

I appreciate it.

Pasha

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

[Stephen Rothwell]

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

Hi Pavel,

On Wed, 3 Feb 2021 18:21:07 -0500 Pavel Tatashin <pasha.tatashin@soleen.com> wrote:
>
> Stephen, do you want to send a new patch based on the current
> linux-next, or do you want me to send an updated version?

I'll send another one and include it in linux-next today.

-- 
Cheers,
Stephen Rothwell

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

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

[Pavel Tatashin]

Stephen, do you want to send a new patch based on the current
linux-next, or do you want me to send an updated version?

Thank you,
Pasha

On Wed, Feb 3, 2021 at 5:36 PM Pavel Tatashin <pasha.tatashin@soleen.com> wrote:
>
> > > After the most recent build errors, I tried to apply Pavel's patch
> > >   https://lore.kernel.org/linux-mm/CA+CK2bBjC8=cRsL5VhWkcevPsqSXWhsANVjsFNMERLT8vWtiQw@mail.gmail.com/
> > > but patch said that it was already applied (by Andrew I think),
> > > so I bailed out (gave up).
> >
> > As far as I can tell, there are two different bugs that got mixed up, and
> > we need both Pavel's patch (which is now in -next) and Stephen's
> > (which got dropped again).
>
> Stephen's patch looks OK to me. I should have used define instead of
> inline to begin with.
>
> Thank you,
> Pasha
>
> >
> >         Arnd

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

[Pavel Tatashin]

> > After the most recent build errors, I tried to apply Pavel's patch
> >   https://lore.kernel.org/linux-mm/CA+CK2bBjC8=cRsL5VhWkcevPsqSXWhsANVjsFNMERLT8vWtiQw@mail.gmail.com/
> > but patch said that it was already applied (by Andrew I think),
> > so I bailed out (gave up).
>
> As far as I can tell, there are two different bugs that got mixed up, and
> we need both Pavel's patch (which is now in -next) and Stephen's
> (which got dropped again).

Stephen's patch looks OK to me. I should have used define instead of
inline to begin with.

Thank you,
Pasha

>
>         Arnd

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

[Arnd Bergmann]

On Wed, Feb 3, 2021 at 6:34 PM Randy Dunlap <rdunlap@infradead.org> wrote:
>
> On 2/3/21 9:09 AM, Arnd Bergmann wrote:
> > On Tue, Feb 2, 2021 at 10:12 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> >>
> >>   983cb10d3f90 ("mm/gup: do not migrate zero page")
> >>
> >> I have applied the following patch for today:
> >>
> >> From: Stephen Rothwell <sfr@canb.auug.org.au>
> >> Date: Tue, 2 Feb 2021 19:49:00 +1100
> >> Subject: [PATCH] make is_pinnable_page a macro
> >>
> >> As it is currently defined before page_to_section() which it needs.
> >>
> >> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> >
> > I still see the same problem in next-20210203, and your patch below
> > fixes it for me.
> > Did you drop it from the latest build?
> >
>
> After the most recent build errors, I tried to apply Pavel's patch
>   https://lore.kernel.org/linux-mm/CA+CK2bBjC8=cRsL5VhWkcevPsqSXWhsANVjsFNMERLT8vWtiQw@mail.gmail.com/
> but patch said that it was already applied (by Andrew I think),
> so I bailed out (gave up).

As far as I can tell, there are two different bugs that got mixed up, and
we need both Pavel's patch (which is now in -next) and Stephen's
(which got dropped again).

        Arnd

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

[Randy Dunlap]

On 2/3/21 9:09 AM, Arnd Bergmann wrote:
> On Tue, Feb 2, 2021 at 10:12 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
>>
>>   983cb10d3f90 ("mm/gup: do not migrate zero page")
>>
>> I have applied the following patch for today:
>>
>> From: Stephen Rothwell <sfr@canb.auug.org.au>
>> Date: Tue, 2 Feb 2021 19:49:00 +1100
>> Subject: [PATCH] make is_pinnable_page a macro
>>
>> As it is currently defined before page_to_section() which it needs.
>>
>> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> 
> I still see the same problem in next-20210203, and your patch below
> fixes it for me.
> Did you drop it from the latest build?
> 
>        Arnd

After the most recent build errors, I tried to apply Pavel's patch
  https://lore.kernel.org/linux-mm/CA+CK2bBjC8=cRsL5VhWkcevPsqSXWhsANVjsFNMERLT8vWtiQw@mail.gmail.com/
but patch said that it was already applied (by Andrew I think),
so I bailed out (gave up).


>> diff --git a/include/linux/mm.h b/include/linux/mm.h
>> index 58f250cabea6..a608feb0d42e 100644
>> --- a/include/linux/mm.h
>> +++ b/include/linux/mm.h
>> @@ -1128,11 +1128,9 @@ static inline bool is_zone_movable_page(const struct page *page)
>>  }
>>
>>  /* MIGRATE_CMA and ZONE_MOVABLE do not allow pin pages */
>> -static inline bool is_pinnable_page(struct page *page)
>> -{
>> -       return !(is_zone_movable_page(page) || is_migrate_cma_page(page)) ||
>> -               is_zero_pfn(page_to_pfn(page));
>> -}
>> +#define is_pinnable_page(page)         \
>> +       (!(is_zone_movable_page(page) || is_migrate_cma_page(page)) ||  \
>> +               is_zero_pfn(page_to_pfn(page)))
>>
>>  #ifdef CONFIG_DEV_PAGEMAP_OPS
>>  void free_devmap_managed_page(struct page *page);


-- 
~Randy

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

[Arnd Bergmann]

On Tue, Feb 2, 2021 at 10:12 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:

>
>   983cb10d3f90 ("mm/gup: do not migrate zero page")
>
> I have applied the following patch for today:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 2 Feb 2021 19:49:00 +1100
> Subject: [PATCH] make is_pinnable_page a macro
>
> As it is currently defined before page_to_section() which it needs.
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

I still see the same problem in next-20210203, and your patch below
fixes it for me.
Did you drop it from the latest build?

       Arnd

> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 58f250cabea6..a608feb0d42e 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -1128,11 +1128,9 @@ static inline bool is_zone_movable_page(const struct page *page)
>  }
>
>  /* MIGRATE_CMA and ZONE_MOVABLE do not allow pin pages */
> -static inline bool is_pinnable_page(struct page *page)
> -{
> -       return !(is_zone_movable_page(page) || is_migrate_cma_page(page)) ||
> -               is_zero_pfn(page_to_pfn(page));
> -}
> +#define is_pinnable_page(page)         \
> +       (!(is_zone_movable_page(page) || is_migrate_cma_page(page)) ||  \
> +               is_zero_pfn(page_to_pfn(page)))
>
>  #ifdef CONFIG_DEV_PAGEMAP_OPS
>  void free_devmap_managed_page(struct page *page);

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

[Geert Uytterhoeven]

Hi Pavel,

On Tue, Feb 2, 2021 at 1:34 PM Pavel Tatashin <pasha.tatashin@soleen.com> wrote:
> The fix is here:
> https://lore.kernel.org/linux-mm/CA+CK2bBjC8=cRsL5VhWkcevPsqSXWhsANVjsFNMERLT8vWtiQw@mail.gmail.com/

Thanks, that fixed the m68k/m5272c3_defconfig build.

> On Tue, Feb 2, 2021 at 5:35 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Tue, Feb 2, 2021 at 10:13 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > After merging the akpm-current tree, today's linux-next build (x86_64
> > > allnoconfig) failed like this:
> > >
> > > In file included from arch/x86/include/asm/page.h:76,
> > >                  from arch/x86/include/asm/thread_info.h:12,
> > >                  from include/linux/thread_info.h:56,
> > >                  from arch/x86/include/asm/preempt.h:7,
> > >                  from include/linux/preempt.h:78,
> > >                  from include/linux/spinlock.h:51,
> > >                  from include/linux/mmzone.h:8,
> > >                  from include/linux/gfp.h:6,
> > >                  from include/linux/slab.h:15,
> > >                  from include/linux/crypto.h:20,
> > >                  from arch/x86/kernel/asm-offsets.c:9:
> > > include/linux/mm.h: In function 'is_pinnable_page':
> > > include/asm-generic/memory_model.h:64:14: error: implicit declaration of function 'page_to_section'; did you mean 'present_section'? [-Werror=implicit-function-declaration]
> > >    64 |  int __sec = page_to_section(__pg);   \
> > >       |              ^~~~~~~~~~~~~~~
> > > include/asm-generic/memory_model.h:81:21: note: in expansion of macro '__page_to_pfn'
> > >    81 | #define page_to_pfn __page_to_pfn
> > >       |                     ^~~~~~~~~~~~~
> > > include/linux/mm.h:1134:15: note: in expansion of macro 'page_to_pfn'
> > >  1134 |   is_zero_pfn(page_to_pfn(page));
> > >       |               ^~~~~~~~~~~
> >
> > In addition, noreply@ellerman.id.au reports for m68k/m5272c3_defconfig:
> >
> >     include/linux/mm.h:1133:3: error: implicit declaration of function
> > 'is_zero_pfn'; did you mean 'is_zero_ino'?
> > [-Werror=implicit-function-declaration]
> >
> > is_zero_pfn() is only defined if CONFIG_MMU=y.
> >
> > Hence using it in mm/gup.c in commit 3f509f6aef4bb868 ("mm/gup: migrate
> > pinned pages out of movable zone") breaks compilation of gup.c, too.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[Pavel Tatashin]

Hi Geert,

The fix is here:
https://lore.kernel.org/linux-mm/CA+CK2bBjC8=cRsL5VhWkcevPsqSXWhsANVjsFNMERLT8vWtiQw@mail.gmail.com/

Thank you,
Pasha

On Tue, Feb 2, 2021 at 5:35 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> On Tue, Feb 2, 2021 at 10:13 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > After merging the akpm-current tree, today's linux-next build (x86_64
> > allnoconfig) failed like this:
> >
> > In file included from arch/x86/include/asm/page.h:76,
> >                  from arch/x86/include/asm/thread_info.h:12,
> >                  from include/linux/thread_info.h:56,
> >                  from arch/x86/include/asm/preempt.h:7,
> >                  from include/linux/preempt.h:78,
> >                  from include/linux/spinlock.h:51,
> >                  from include/linux/mmzone.h:8,
> >                  from include/linux/gfp.h:6,
> >                  from include/linux/slab.h:15,
> >                  from include/linux/crypto.h:20,
> >                  from arch/x86/kernel/asm-offsets.c:9:
> > include/linux/mm.h: In function 'is_pinnable_page':
> > include/asm-generic/memory_model.h:64:14: error: implicit declaration of function 'page_to_section'; did you mean 'present_section'? [-Werror=implicit-function-declaration]
> >    64 |  int __sec = page_to_section(__pg);   \
> >       |              ^~~~~~~~~~~~~~~
> > include/asm-generic/memory_model.h:81:21: note: in expansion of macro '__page_to_pfn'
> >    81 | #define page_to_pfn __page_to_pfn
> >       |                     ^~~~~~~~~~~~~
> > include/linux/mm.h:1134:15: note: in expansion of macro 'page_to_pfn'
> >  1134 |   is_zero_pfn(page_to_pfn(page));
> >       |               ^~~~~~~~~~~
>
> In addition, noreply@ellerman.id.au reports for m68k/m5272c3_defconfig:
>
>     include/linux/mm.h:1133:3: error: implicit declaration of function
> 'is_zero_pfn'; did you mean 'is_zero_ino'?
> [-Werror=implicit-function-declaration]
>
> is_zero_pfn() is only defined if CONFIG_MMU=y.
>
> Hence using it in mm/gup.c in commit 3f509f6aef4bb868 ("mm/gup: migrate
> pinned pages out of movable zone") breaks compilation of gup.c, too.
>
>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds

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

[Geert Uytterhoeven]

On Tue, Feb 2, 2021 at 10:13 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> After merging the akpm-current tree, today's linux-next build (x86_64
> allnoconfig) failed like this:
>
> In file included from arch/x86/include/asm/page.h:76,
>                  from arch/x86/include/asm/thread_info.h:12,
>                  from include/linux/thread_info.h:56,
>                  from arch/x86/include/asm/preempt.h:7,
>                  from include/linux/preempt.h:78,
>                  from include/linux/spinlock.h:51,
>                  from include/linux/mmzone.h:8,
>                  from include/linux/gfp.h:6,
>                  from include/linux/slab.h:15,
>                  from include/linux/crypto.h:20,
>                  from arch/x86/kernel/asm-offsets.c:9:
> include/linux/mm.h: In function 'is_pinnable_page':
> include/asm-generic/memory_model.h:64:14: error: implicit declaration of function 'page_to_section'; did you mean 'present_section'? [-Werror=implicit-function-declaration]
>    64 |  int __sec = page_to_section(__pg);   \
>       |              ^~~~~~~~~~~~~~~
> include/asm-generic/memory_model.h:81:21: note: in expansion of macro '__page_to_pfn'
>    81 | #define page_to_pfn __page_to_pfn
>       |                     ^~~~~~~~~~~~~
> include/linux/mm.h:1134:15: note: in expansion of macro 'page_to_pfn'
>  1134 |   is_zero_pfn(page_to_pfn(page));
>       |               ^~~~~~~~~~~

In addition, noreply@ellerman.id.au reports for m68k/m5272c3_defconfig:

    include/linux/mm.h:1133:3: error: implicit declaration of function
'is_zero_pfn'; did you mean 'is_zero_ino'?
[-Werror=implicit-function-declaration]

is_zero_pfn() is only defined if CONFIG_MMU=y.

Hence using it in mm/gup.c in commit 3f509f6aef4bb868 ("mm/gup: migrate
pinned pages out of movable zone") breaks compilation of gup.c, too.


Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[Stephen Rothwell]

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

Hi all,

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

In file included from arch/x86/include/asm/page.h:76,
                 from arch/x86/include/asm/thread_info.h:12,
                 from include/linux/thread_info.h:56,
                 from arch/x86/include/asm/preempt.h:7,
                 from include/linux/preempt.h:78,
                 from include/linux/spinlock.h:51,
                 from include/linux/mmzone.h:8,
                 from include/linux/gfp.h:6,
                 from include/linux/slab.h:15,
                 from include/linux/crypto.h:20,
                 from arch/x86/kernel/asm-offsets.c:9:
include/linux/mm.h: In function 'is_pinnable_page':
include/asm-generic/memory_model.h:64:14: error: implicit declaration of function 'page_to_section'; did you mean 'present_section'? [-Werror=implicit-function-declaration]
   64 |  int __sec = page_to_section(__pg);   \
      |              ^~~~~~~~~~~~~~~
include/asm-generic/memory_model.h:81:21: note: in expansion of macro '__page_to_pfn'
   81 | #define page_to_pfn __page_to_pfn
      |                     ^~~~~~~~~~~~~
include/linux/mm.h:1134:15: note: in expansion of macro 'page_to_pfn'
 1134 |   is_zero_pfn(page_to_pfn(page));
      |               ^~~~~~~~~~~
In file included from include/linux/kallsyms.h:12,
                 from include/linux/bpf.h:21,
                 from include/linux/bpf-cgroup.h:5,
                 from include/linux/cgroup-defs.h:22,
                 from include/linux/cgroup.h:28,
                 from include/linux/memcontrol.h:13,
                 from include/linux/swap.h:9,
                 from include/linux/suspend.h:5,
                 from arch/x86/kernel/asm-offsets.c:13:
include/linux/mm.h: At top level:
include/linux/mm.h:1505:29: error: conflicting types for 'page_to_section'
 1505 | static inline unsigned long page_to_section(const struct page *page)
      |                             ^~~~~~~~~~~~~~~
In file included from arch/x86/include/asm/page.h:76,
                 from arch/x86/include/asm/thread_info.h:12,
                 from include/linux/thread_info.h:56,
                 from arch/x86/include/asm/preempt.h:7,
                 from include/linux/preempt.h:78,
                 from include/linux/spinlock.h:51,
                 from include/linux/mmzone.h:8,
                 from include/linux/gfp.h:6,
                 from include/linux/slab.h:15,
                 from include/linux/crypto.h:20,
                 from arch/x86/kernel/asm-offsets.c:9:
include/asm-generic/memory_model.h:64:14: note: previous implicit declaration of 'page_to_section' was here
   64 |  int __sec = page_to_section(__pg);   \
      |              ^~~~~~~~~~~~~~~
include/asm-generic/memory_model.h:81:21: note: in expansion of macro '__page_to_pfn'
   81 | #define page_to_pfn __page_to_pfn
      |                     ^~~~~~~~~~~~~
include/linux/mm.h:1134:15: note: in expansion of macro 'page_to_pfn'
 1134 |   is_zero_pfn(page_to_pfn(page));
      |               ^~~~~~~~~~~

This build has CONFIG_SPARSEMEM set and CONFIG_SPARSEMEM_VMEMMAP not set.

Caused by commit

  983cb10d3f90 ("mm/gup: do not migrate zero page")

I have applied the following patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 2 Feb 2021 19:49:00 +1100
Subject: [PATCH] make is_pinnable_page a macro

As it is currently defined before page_to_section() which it needs.

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

diff --git a/include/linux/mm.h b/include/linux/mm.h
index 58f250cabea6..a608feb0d42e 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1128,11 +1128,9 @@ static inline bool is_zone_movable_page(const struct page *page)
 }
 
 /* MIGRATE_CMA and ZONE_MOVABLE do not allow pin pages */
-static inline bool is_pinnable_page(struct page *page)
-{
-	return !(is_zone_movable_page(page) || is_migrate_cma_page(page)) ||
-		is_zero_pfn(page_to_pfn(page));
-}
+#define is_pinnable_page(page)		\
+	(!(is_zone_movable_page(page) || is_migrate_cma_page(page)) ||	\
+		is_zero_pfn(page_to_pfn(page)))
 
 #ifdef CONFIG_DEV_PAGEMAP_OPS
 void free_devmap_managed_page(struct page *page);
-- 
2.29.2

-- 
Cheers,
Stephen Rothwell

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

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

[Alexey Dobriyan]

On Wed, Jan 27, 2021 at 11:21:18PM +1100, Stephen Rothwell wrote:
> Caused by commit
> 
>   5567a1a4b1c3 ("ramfs: support O_TMPFILE")

Can this be merged or sent to Al, please? It's ancient patch.

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

[Stephen Rothwell]

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

Hi all,

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

fs/ramfs/inode.c:175:13: error: initialization of 'int (*)(struct user_namespace *, struct inode *, struct dentry *, umode_t)' {aka 'int (*)(struct user_namespace *, struct inode *, struct dentry *, short unsigned int)'} from incompatible pointer type 'int (*)(struct inode *, struct dentry *, umode_t)' {aka 'int (*)(struct inode *, struct dentry *, short unsigned int)'} [-Werror=incompatible-pointer-types]
  175 |  .tmpfile = ramfs_tmpfile,
      |             ^~~~~~~~~~~~~
fs/ramfs/inode.c:175:13: note: (near initialization for 'ramfs_dir_inode_operations.tmpfile')

Caused by commit

  5567a1a4b1c3 ("ramfs: support O_TMPFILE")

interacting with commit

  549c7297717c ("fs: make helpers idmap mount aware")

from the pidfd tree.

I have applied this merge fix patch:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 27 Jan 2021 23:10:31 +1100
Subject: [PATCH] ramfs-support-O_TMPFILE-fix

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

diff --git a/fs/ramfs/inode.c b/fs/ramfs/inode.c
index b4a37102adf2..ba8e20584811 100644
--- a/fs/ramfs/inode.c
+++ b/fs/ramfs/inode.c
@@ -151,7 +151,8 @@ static int ramfs_symlink(struct user_namespace *mnt_userns, struct inode *dir,
 	return error;
 }
 
-static int ramfs_tmpfile(struct inode *dir, struct dentry *dentry, umode_t mode)
+static int ramfs_tmpfile(struct user_namespace *mnt_userns, struct inode *dir,
+			 struct dentry *dentry, umode_t mode)
 {
 	struct inode *inode;
 
-- 
2.29.2

-- 
Cheers,
Stephen Rothwell

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

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

[Stephen Rothwell]

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

Hi Dan,

On Tue, 19 Jan 2021 21:48:52 -0800 Dan Williams <dan.j.williams@intel.com> wrote:
>
> On Tue, Jan 19, 2021 at 9:25 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Hi all,
> >
> > After merging the akpm-current tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > mm/memory_hotplug.c: In function 'move_pfn_range_to_zone':
> > mm/memory_hotplug.c:772:24: error: 'ZONE_DEVICE' undeclared (first use in this function)
> >   772 |  if (zone_idx(zone) == ZONE_DEVICE) {
> >       |                        ^~~~~~~~~~~
> >
> > Caused by commit
> >
> >   e821cf25cfee ("mm: teach pfn_to_online_page() about ZONE_DEVICE section collisions")
> >
> > I applied the patch from Randy Dunlap for today.
> >
> > That, however, lead to this warning:
> >
> > mm/memory_hotplug.c:730:13: warning: 'section_taint_zone_device' defined but not used [-Wunused-function]
> >   730 | static void section_taint_zone_device(unsigned long pfn)
> >       |             ^~~~~~~~~~~~~~~~~~~~~~~~~
> >  
> 
> I sent this one as an alternate:
> 
> http://lore.kernel.org/r/161111619868.2787408.1710192276369197040.stgit@dwillia2-desk3.amr.corp.intel.com

I have used that today instead of Randy's patch, thanks.

-- 
Cheers,
Stephen Rothwell

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

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

[Dan Williams]

On Tue, Jan 19, 2021 at 9:25 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> After merging the akpm-current tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> mm/memory_hotplug.c: In function 'move_pfn_range_to_zone':
> mm/memory_hotplug.c:772:24: error: 'ZONE_DEVICE' undeclared (first use in this function)
>   772 |  if (zone_idx(zone) == ZONE_DEVICE) {
>       |                        ^~~~~~~~~~~
>
> Caused by commit
>
>   e821cf25cfee ("mm: teach pfn_to_online_page() about ZONE_DEVICE section collisions")
>
> I applied the patch from Randy Dunlap for today.
>
> That, however, lead to this warning:
>
> mm/memory_hotplug.c:730:13: warning: 'section_taint_zone_device' defined but not used [-Wunused-function]
>   730 | static void section_taint_zone_device(unsigned long pfn)
>       |             ^~~~~~~~~~~~~~~~~~~~~~~~~
>

I sent this one as an alternate:

http://lore.kernel.org/r/161111619868.2787408.1710192276369197040.stgit@dwillia2-desk3.amr.corp.intel.com

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

[Stephen Rothwell]

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

Hi all,

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

mm/memory_hotplug.c: In function 'move_pfn_range_to_zone':
mm/memory_hotplug.c:772:24: error: 'ZONE_DEVICE' undeclared (first use in this function)
  772 |  if (zone_idx(zone) == ZONE_DEVICE) {
      |                        ^~~~~~~~~~~

Caused by commit

  e821cf25cfee ("mm: teach pfn_to_online_page() about ZONE_DEVICE section collisions")

I applied the patch from Randy Dunlap for today.

That, however, lead to this warning:

mm/memory_hotplug.c:730:13: warning: 'section_taint_zone_device' defined but not used [-Wunused-function]
  730 | static void section_taint_zone_device(unsigned long pfn)
      |             ^~~~~~~~~~~~~~~~~~~~~~~~~

-- 
Cheers,
Stephen Rothwell

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

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

[Kuan-Ying Lee]

On Mon, 2020-12-21 at 13:55 +1100, Stephen Rothwell wrote:
> Hi Kuan-Ying,
> 
> On Mon, 21 Dec 2020 10:31:38 +0800 Kuan-Ying Lee <Kuan-Ying.Lee@mediatek.com> wrote:
> >
> > On Mon, 2020-12-21 at 13:10 +1100, Stephen Rothwell wrote:
> > > 
> > > After merging the akpm-current tree, today's linux-next build (x86_64
> > > allmodconfig) failed like this:
> > > 
> > > mm/kasan/quarantine.c: In function 'quarantine_put':
> > > mm/kasan/quarantine.c:207:15: error: 'info' undeclared (first use in this function)
> > >   207 |   qlink_free(&info->quarantine_link, cache);
> > >       |               ^~~~
> > > 
> > > Caused by commit
> > > 
> > >   120d593a8650 ("kasan: fix memory leak of kasan quarantine")
> > > 
> > > interacting with commit
> > > 
> > >   cfbc92088e1d ("kasan: rename get_alloc/free_info")
> > > 
> > > Can we please get this sorted out once and for all?
> > > 
> > > I have applied the following patch for today:
> > > 
> > > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > > Date: Mon, 21 Dec 2020 13:07:42 +1100
> > > Subject: [PATCH] kasan: fix memory leak of kasan quarantine fix
> > > 
> > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > > ---
> > >  mm/kasan/quarantine.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/mm/kasan/quarantine.c b/mm/kasan/quarantine.c
> > > index 3f3b3d902c18..091a57f942b3 100644
> > > --- a/mm/kasan/quarantine.c
> > > +++ b/mm/kasan/quarantine.c
> > > @@ -204,7 +204,7 @@ bool quarantine_put(struct kmem_cache *cache, void *object)
> > >  
> > >  	q = this_cpu_ptr(&cpu_quarantine);
> > >  	if (q->offline) {
> > > -		qlink_free(&info->quarantine_link, cache);
> > > +		qlink_free(&meta->quarantine_link, cache); // free once
> > >  		local_irq_restore(flags);
> > >  		return false;  // free twice
> > >  	}
> > > -- 
> > > 2.29.2
> > >   
> > 
> > Please just drop this patch "kasan: fix memory leak of kasan quarantine"
> > from linux-next. Otherwise, it would cause double free issue.
> 
> OK, so for today I have reverted my fix patch and 120d593a8650 ("kasan:
> fix memory leak of kasan quarantine").
> 

Dear Andrew,

I am sorry. I didn't mean to.

This patch has build error.
https://www.ozlabs.org/~akpm/mmotm/broken-out/kasan-fix-memory-leak-of-kasan-quarantine.patch


Sorry to make the build errors and merge issues repeatedly.
My fix has dependency issues with Andrey's patches [1, 2], and I think
it's better to merge Andrey's patches first and I will push a fix after
Andrey's patch.
Please just drop this patch from akpm-tree directly.

[1]https://www.ozlabs.org/~akpm/mmotm/broken-out/kasan-sanitize-objects-when-metadata-doesnt-fit.patch
[2]https://www.ozlabs.org/~akpm/mmotm/broken-out/kasan-rename-get_alloc-free_info.patch


Thanks.

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

[Stephen Rothwell]

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

Hi Kuan-Ying,

On Mon, 21 Dec 2020 10:31:38 +0800 Kuan-Ying Lee <Kuan-Ying.Lee@mediatek.com> wrote:
>
> On Mon, 2020-12-21 at 13:10 +1100, Stephen Rothwell wrote:
> > 
> > After merging the akpm-current tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> > 
> > mm/kasan/quarantine.c: In function 'quarantine_put':
> > mm/kasan/quarantine.c:207:15: error: 'info' undeclared (first use in this function)
> >   207 |   qlink_free(&info->quarantine_link, cache);
> >       |               ^~~~
> > 
> > Caused by commit
> > 
> >   120d593a8650 ("kasan: fix memory leak of kasan quarantine")
> > 
> > interacting with commit
> > 
> >   cfbc92088e1d ("kasan: rename get_alloc/free_info")
> > 
> > Can we please get this sorted out once and for all?
> > 
> > I have applied the following patch for today:
> > 
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Date: Mon, 21 Dec 2020 13:07:42 +1100
> > Subject: [PATCH] kasan: fix memory leak of kasan quarantine fix
> > 
> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > ---
> >  mm/kasan/quarantine.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/mm/kasan/quarantine.c b/mm/kasan/quarantine.c
> > index 3f3b3d902c18..091a57f942b3 100644
> > --- a/mm/kasan/quarantine.c
> > +++ b/mm/kasan/quarantine.c
> > @@ -204,7 +204,7 @@ bool quarantine_put(struct kmem_cache *cache, void *object)
> >  
> >  	q = this_cpu_ptr(&cpu_quarantine);
> >  	if (q->offline) {
> > -		qlink_free(&info->quarantine_link, cache);
> > +		qlink_free(&meta->quarantine_link, cache); // free once
> >  		local_irq_restore(flags);
> >  		return false;  // free twice
> >  	}
> > -- 
> > 2.29.2
> >   
> 
> Please just drop this patch "kasan: fix memory leak of kasan quarantine"
> from linux-next. Otherwise, it would cause double free issue.

OK, so for today I have reverted my fix patch and 120d593a8650 ("kasan:
fix memory leak of kasan quarantine").

-- 
Cheers,
Stephen Rothwell

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

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

[Kuan-Ying Lee]

On Mon, 2020-12-21 at 13:10 +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the akpm-current tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> mm/kasan/quarantine.c: In function 'quarantine_put':
> mm/kasan/quarantine.c:207:15: error: 'info' undeclared (first use in this function)
>   207 |   qlink_free(&info->quarantine_link, cache);
>       |               ^~~~
> 
> Caused by commit
> 
>   120d593a8650 ("kasan: fix memory leak of kasan quarantine")
> 
> interacting with commit
> 
>   cfbc92088e1d ("kasan: rename get_alloc/free_info")
> 
> Can we please get this sorted out once and for all?
> 
> I have applied the following patch for today:
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 21 Dec 2020 13:07:42 +1100
> Subject: [PATCH] kasan: fix memory leak of kasan quarantine fix
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  mm/kasan/quarantine.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/kasan/quarantine.c b/mm/kasan/quarantine.c
> index 3f3b3d902c18..091a57f942b3 100644
> --- a/mm/kasan/quarantine.c
> +++ b/mm/kasan/quarantine.c
> @@ -204,7 +204,7 @@ bool quarantine_put(struct kmem_cache *cache, void *object)
>  
>  	q = this_cpu_ptr(&cpu_quarantine);
>  	if (q->offline) {
> -		qlink_free(&info->quarantine_link, cache);
> +		qlink_free(&meta->quarantine_link, cache); // free once
>  		local_irq_restore(flags);
>  		return false;  // free twice
>  	}
> -- 
> 2.29.2
> 

Hi Stephen,
Please just drop this patch "kasan: fix memory leak of kasan quarantine"
from linux-next. Otherwise, it would cause double free issue.


Hi Andrew,

Sorry to bother.
I upload the v2 standalone fixup patch to fix the memory leak issue on
kernel-5.10 stable as below.
https://marc.info/?l=linux-mm&m=160820751825252&w=2
I think this slab memory leak issue is important. It's because when we
do kmem_cache_destroy, it will report object remaining error.

Add this v2 patch to mm-tree, it will have conflicts with
Andrey's patches as below.
"kasan: rename get_alloc/free_info"
"kasan: sanitize objects when metadata doesnt fit"

I think this standalone fixup patch should be added ""before"" Andrey's
patch in mm-tree. Because only merging this standalone fix patch to 5.10
stable, we can resolve this leak issue instead of merging the whole 
patchset of Andrey's patch to 5.10 stable.
However, merging the fixup patch into mm-tree will cause some conflicts
in mm-tree.

Please help to fix the conflicts.
And I think the conflict between standalone fixup patch and
Andrey's patches will be fixed as below.

I think this patch "kasan: rename get_alloc/free_info" need to rename
the "info" to "meta" as below.

-       qlink_free(&info->quarantine_link, cache);
+       qlink_free(&meta->quarantine_link, cache);


This patch "kasan: sanitize objects when metadata doesnt fit" need to
remove the qlink_free() and add return false as below.

        q = this_cpu_ptr(&cpu_quarantine);
        if (q->offline) {
-               qlink_free(&meta->quarantine_link, cache);
                local_irq_restore(flags);
-               return;
+               return false;
        }

Thanks a lot.

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

[Stephen Rothwell]

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

Hi all,

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

mm/kasan/quarantine.c: In function 'quarantine_put':
mm/kasan/quarantine.c:207:15: error: 'info' undeclared (first use in this function)
  207 |   qlink_free(&info->quarantine_link, cache);
      |               ^~~~

Caused by commit

  120d593a8650 ("kasan: fix memory leak of kasan quarantine")

interacting with commit

  cfbc92088e1d ("kasan: rename get_alloc/free_info")

Can we please get this sorted out once and for all?

I have applied the following patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 21 Dec 2020 13:07:42 +1100
Subject: [PATCH] kasan: fix memory leak of kasan quarantine fix

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

diff --git a/mm/kasan/quarantine.c b/mm/kasan/quarantine.c
index 3f3b3d902c18..091a57f942b3 100644
--- a/mm/kasan/quarantine.c
+++ b/mm/kasan/quarantine.c
@@ -204,7 +204,7 @@ bool quarantine_put(struct kmem_cache *cache, void *object)
 
 	q = this_cpu_ptr(&cpu_quarantine);
 	if (q->offline) {
-		qlink_free(&info->quarantine_link, cache);
+		qlink_free(&meta->quarantine_link, cache);
 		local_irq_restore(flags);
 		return false;
 	}
-- 
2.29.2

-- 
Cheers,
Stephen Rothwell

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

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

[Rui Salvaterra]

On Thu, 3 Dec 2020 at 09:37, Rui Salvaterra <rsalvaterra@gmail.com> wrote:
>
> Thanks for the heads-up, I think I know where the problem is.

Then again, maybe not. I don't have a PowerPC machine to test, at the
moment, and all my x86(-64) machines work fine. If no one beats me to
it, I can debug on an iBook G4, but only next week.

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

[Rui Salvaterra]

Hi, Stephen,

On Thu, 3 Dec 2020 at 09:08, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> After merging the akpm-current tree, today's linux-next build (powerpc
> ppc44x_defconfig) failed like this:
>
[…]
>
> Caused by commit
>
>   a6d52df2d8bc ("zram: break the strict dependency from lzo")
>
> I have reverted that commit for today.

Thanks for the heads-up, I think I know where the problem is.

Cheers,
Rui

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

[Stephen Rothwell]

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

Hi all,

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

WARNING: unmet direct dependencies detected for CRYPTO_LZO
  Depends on [m]: CRYPTO [=m]
  Selected by [y]:
  - ZRAM_DEF_COMP_LZORLE [=y] && <choice>
  Selected by [m]:
  - UBIFS_FS [=m] && MISC_FILESYSTEMS [=y] && MTD_UBI [=m] && UBIFS_FS_LZO [=y]

WARNING: unmet direct dependencies detected for CRYPTO_LZO
  Depends on [m]: CRYPTO [=m]
  Selected by [y]:
  - ZRAM_DEF_COMP_LZORLE [=y] && <choice>
  Selected by [m]:
  - UBIFS_FS [=m] && MISC_FILESYSTEMS [=y] && MTD_UBI [=m] && UBIFS_FS_LZO [=y]

WARNING: unmet direct dependencies detected for CRYPTO_LZO
  Depends on [m]: CRYPTO [=m]
  Selected by [y]:
  - ZRAM_DEF_COMP_LZORLE [=y] && <choice>
  Selected by [m]:
  - UBIFS_FS [=m] && MISC_FILESYSTEMS [=y] && MTD_UBI [=m] && UBIFS_FS_LZO [=y]

WARNING: unmet direct dependencies detected for CRYPTO_LZO
  Depends on [m]: CRYPTO [=m]
  Selected by [y]:
  - ZRAM_DEF_COMP_LZORLE [=y] && <choice>
  Selected by [m]:
  - UBIFS_FS [=m] && MISC_FILESYSTEMS [=y] && MTD_UBI [=m] && UBIFS_FS_LZO [=y]

WARNING: unmet direct dependencies detected for CRYPTO_LZO
  Depends on [m]: CRYPTO [=m]
  Selected by [y]:
  - ZRAM_DEF_COMP_LZORLE [=y] && <choice>
  Selected by [m]:
  - UBIFS_FS [=m] && MISC_FILESYSTEMS [=y] && MTD_UBI [=m] && UBIFS_FS_LZO [=y]
ld: crypto/lzo.o: in function `lzo_compress':
lzo.c:(.text+0xbc): undefined reference to `lzo1x_1_compress'
ld: crypto/lzo.o: in function `lzo_scompress':
lzo.c:(.text+0x228): undefined reference to `lzo1x_1_compress'
ld: crypto/lzo.o: in function `lzo_mod_fini':
lzo.c:(.exit.text+0x1c): undefined reference to `crypto_unregister_alg'
ld: lzo.c:(.exit.text+0x34): undefined reference to `crypto_unregister_scomp'
ld: crypto/lzo.o: in function `lzo_mod_init':
lzo.c:(.init.text+0x20): undefined reference to `crypto_register_alg'
ld: lzo.c:(.init.text+0x30): undefined reference to `crypto_register_scomp'
ld: lzo.c:(.init.text+0x40): undefined reference to `crypto_unregister_alg'
ld: crypto/lzo-rle.o: in function `lzorle_compress':
lzo-rle.c:(.text+0xbc): undefined reference to `lzorle1x_1_compress'
ld: crypto/lzo-rle.o: in function `lzorle_scompress':
lzo-rle.c:(.text+0x228): undefined reference to `lzorle1x_1_compress'
ld: crypto/lzo-rle.o: in function `lzorle_mod_fini':
lzo-rle.c:(.exit.text+0x1c): undefined reference to `crypto_unregister_alg'
ld: lzo-rle.c:(.exit.text+0x34): undefined reference to `crypto_unregister_scomp'
ld: crypto/lzo-rle.o: in function `lzorle_mod_init':
lzo-rle.c:(.init.text+0x20): undefined reference to `crypto_register_alg'
ld: lzo-rle.c:(.init.text+0x30): undefined reference to `crypto_register_scomp'
ld: lzo-rle.c:(.init.text+0x40): undefined reference to `crypto_unregister_alg'

Caused by commit

  a6d52df2d8bc ("zram: break the strict dependency from lzo")

I have reverted that commit for today.

-- 
Cheers,
Stephen Rothwell

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

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

[Dan Williams]

On Wed, Nov 4, 2020 at 9:05 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> After merging the akpm-current tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> In file included from include/linux/numa.h:25,
>                  from include/linux/nodemask.h:96,
>                  from include/linux/mount.h:15,
>                  from fs/pnode.c:9:
> arch/powerpc/include/asm/sparsemem.h:17:16: error: unknown type name 'pgprot_t'
>    17 |       int nid, pgprot_t prot);
>       |                ^~~~~~~~
>
> Caused by commit
>
>   45339c019cbc ("mm: fix phys_to_target_node() and memory_add_physaddr_to_nid() exports")
>
> I have reverted that commit for today (maybe I should not have added
> it :-().

Ugh, I'll check my cross-compile coverage.

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

[Stephen Rothwell]

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

Hi all,

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

In file included from include/linux/numa.h:25,
                 from include/linux/nodemask.h:96,
                 from include/linux/mount.h:15,
                 from fs/pnode.c:9:
arch/powerpc/include/asm/sparsemem.h:17:16: error: unknown type name 'pgprot_t'
   17 |       int nid, pgprot_t prot);
      |                ^~~~~~~~

Caused by commit

  45339c019cbc ("mm: fix phys_to_target_node() and memory_add_physaddr_to_nid() exports")

I have reverted that commit for today (maybe I should not have added
it :-().

-- 
Cheers,
Stephen Rothwell

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

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

[Andy Shevchenko]

On Thu, Oct 29, 2020 at 03:08:09PM +1100, Stephen Rothwell wrote:
> After merging the akpm-current tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> lib/math/div64.c: In function 'mul_u64_u64_div_u64':
> lib/math/div64.c:202:6: error: implicit declaration of function 'ilog2' [-Werror=implicit-function-declaration]
>   202 |  if (ilog2(a) + ilog2(b) > 62) {
>       |      ^~~~~
> 
> Caused by commit
> 
>   4ec993a18ff6 ("kernel.h: Split out mathematical helpers")
> 
> I have applied the following patch for today:

Right, thanks! It seems x86 has this inclusion somewhere else and my patch
reveals this on PPC which has cleaner inclusion chain.

Andrew, can you attach this fix to your tree?

-- 
With Best Regards,
Andy Shevchenko

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

[Stephen Rothwell]

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

Hi all,

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

lib/math/div64.c: In function 'mul_u64_u64_div_u64':
lib/math/div64.c:202:6: error: implicit declaration of function 'ilog2' [-Werror=implicit-function-declaration]
  202 |  if (ilog2(a) + ilog2(b) > 62) {
      |      ^~~~~

Caused by commit

  4ec993a18ff6 ("kernel.h: Split out mathematical helpers")

I have applied the following patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 29 Oct 2020 15:03:58 +1100
Subject: [PATCH] kernel.h: Split out mathematical helpers fix

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

diff --git a/lib/math/div64.c b/lib/math/div64.c
index dcc826c40ca1..064d68a5391a 100644
--- a/lib/math/div64.c
+++ b/lib/math/div64.c
@@ -22,6 +22,7 @@
 #include <linux/export.h>
 #include <linux/math.h>
 #include <linux/math64.h>
+#include <linux/log2.h>
 
 /* Not needed on 64bit architectures */
 #if BITS_PER_LONG == 32
-- 
2.28.0

-- 
Cheers,
Stephen Rothwell

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

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

[Dan Williams]

On Fri, Oct 16, 2020 at 12:45 PM Miklos Szeredi <miklos@szeredi.hu> wrote:
[..]
> > This is broken... it needs to be converted to 'struct range'. I'll take
> > care of that when I respin the series. Sorry for the thrash it seems
> > this is a new memremap_pages() user since the conversion patches
> > landed.
>
> Hi Dan,
>
> I'd like to send this upstream and this conflict needs to be dealt
> with some way or another.   Can you send the correct fixup against
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git#for-next

Sorry, I just circled back to this and found your for-next branch is
already merged. The resolution looks good. Apologies for not taking a
look earlier.

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

[Miklos Szeredi]

On Thu, Sep 24, 2020 at 3:40 AM Williams, Dan J
<dan.j.williams@intel.com> wrote:
>
> On Tue, 2020-09-08 at 20:09 +1000, Stephen Rothwell wrote:

[...]

> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Date: Tue, 8 Sep 2020 20:00:20 +1000
> > Subject: [PATCH] merge fix up for "mm/memremap_pages: convert to
> > 'struct
> >  range'"
> >
> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > ---
> >  drivers/xen/unpopulated-alloc.c | 15 +++++++++------
> >  fs/fuse/virtio_fs.c             |  3 +--
> >  2 files changed, 10 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/xen/unpopulated-alloc.c
> > b/drivers/xen/unpopulated-alloc.c
> > index 3b98dc921426..9fa7ce330628 100644
> > --- a/drivers/xen/unpopulated-alloc.c
> > +++ b/drivers/xen/unpopulated-alloc.c
> > @@ -18,6 +18,7 @@ static unsigned int list_count;
> >  static int fill_list(unsigned int nr_pages)
> >  {
> >       struct dev_pagemap *pgmap;
> > +     struct resource res;
> >       void *vaddr;
> >       unsigned int i, alloc_pages = round_up(nr_pages,
> > PAGES_PER_SECTION);
> >       int ret;
> > @@ -27,10 +28,10 @@ static int fill_list(unsigned int nr_pages)
> >               return -ENOMEM;
> >
> >       pgmap->type = MEMORY_DEVICE_GENERIC;
> > -     pgmap->res.name = "Xen scratch";
> > -     pgmap->res.flags = IORESOURCE_MEM | IORESOURCE_BUSY;
>
> This is broken... it needs to be converted to 'struct range'. I'll take
> care of that when I respin the series. Sorry for the thrash it seems
> this is a new memremap_pages() user since the conversion patches
> landed.

Hi Dan,

I'd like to send this upstream and this conflict needs to be dealt
with some way or another.   Can you send the correct fixup against

git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git#for-next

?

Thanks,
Miklos

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

[Stephen Rothwell]

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

Hi all,

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

mm/readahead.c: In function 'page_cache_sync_ra':
mm/readahead.c:565:8: error: 'filp' undeclared (first use in this function); did you mean 'file'?
  565 |   if (!filp)
      |        ^~~~
      |        file

Caused by commit

  f65bd470e7ed ("mm/readahead: add page_cache_sync_ra and page_cache_async_ra")

interacting with commit

  09d008e3868e ("readahead: use limited read-ahead to satisfy read")

from the block tree.

I have added the following merge fix patch.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 16 Oct 2020 15:39:09 +1100
Subject: [PATCH] mm/readahead: fix up for "readahead: use limited read-ahead to satisfy read"

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

diff --git a/mm/readahead.c b/mm/readahead.c
index a673ec53de37..b4d162b38bd6 100644
--- a/mm/readahead.c
+++ b/mm/readahead.c
@@ -562,7 +562,7 @@ void page_cache_sync_ra(struct readahead_control *ractl,
 	 * we're congested or tight on memory.
 	 */
 	if (!ra->ra_pages || blk_cgroup_congested()) {
-		if (!filp)
+		if (!ractl->file)
 			return;
 		req_count = 1;
 		do_forced_ra = true;
-- 
2.28.0

-- 
Cheers,
Stephen Rothwell

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

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

[Williams, Dan J]

On Tue, 2020-09-08 at 20:09 +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the akpm-current tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/xen/unpopulated-alloc.c: In function 'fill_list':
> drivers/xen/unpopulated-alloc.c:30:9: error: 'struct dev_pagemap' has
> no member named 'res'; did you mean 'ref'?
>    30 |  pgmap->res.name = "Xen scratch";
>       |         ^~~
>       |         ref
> drivers/xen/unpopulated-alloc.c:31:9: error: 'struct dev_pagemap' has
> no member named 'res'; did you mean 'ref'?
>    31 |  pgmap->res.flags = IORESOURCE_MEM | IORESOURCE_BUSY;
>       |         ^~~
>       |         ref
> drivers/xen/unpopulated-alloc.c:33:51: error: 'struct dev_pagemap'
> has no member named 'res'; did you mean 'ref'?
>    33 |  ret = allocate_resource(&iomem_resource, &pgmap->res,
>       |                                                   ^~~
>       |                                                   ref
> In file included from include/asm-generic/memory_model.h:5,
>                  from arch/x86/include/asm/page.h:76,
>                  from arch/x86/include/asm/thread_info.h:12,
>                  from include/linux/thread_info.h:38,
>                  from arch/x86/include/asm/preempt.h:7,
>                  from include/linux/preempt.h:78,
>                  from include/linux/spinlock.h:51,
>                  from include/linux/mmzone.h:8,
>                  from include/linux/gfp.h:6,
>                  from drivers/xen/unpopulated-alloc.c:3:
> drivers/xen/unpopulated-alloc.c:53:35: error: 'struct dev_pagemap'
> has no member named 'res'; did you mean 'ref'?
>    53 |   xen_pfn_t pfn = PFN_DOWN(pgmap->res.start);
>       |                                   ^~~
> include/linux/pfn.h:20:23: note: in definition of macro 'PFN_DOWN'
>    20 | #define PFN_DOWN(x) ((x) >> PAGE_SHIFT)
>       |                       ^
> drivers/xen/unpopulated-alloc.c:58:30: error: 'struct dev_pagemap'
> has no member named 'res'; did you mean 'ref'?
>    58 |     release_resource(&pgmap->res);
>       |                              ^~~
>       |                              ref
> drivers/xen/unpopulated-alloc.c:69:28: error: 'struct dev_pagemap'
> has no member named 'res'; did you mean 'ref'?
>    69 |   release_resource(&pgmap->res);
>       |                            ^~~
>       |                            ref
> fs/fuse/virtio_fs.c: In function 'virtio_fs_setup_dax':
> fs/fuse/virtio_fs.c:838:9: error: 'struct dev_pagemap' has no member
> named 'res'; did you mean 'ref'?
>   838 |  pgmap->res = (struct resource){
>       |         ^~~
>       |         ref
> 
> Caused by commit
> 
>   b3e022c5a68c ("mm/memremap_pages: convert to 'struct range'")
> 
> interacting with commit
> 
>   9e2369c06c8a ("xen: add helpers to allocate unpopulated memory")
> 
> from Linus' tree (in v5.9-rc4) and commit
> 
>   7e833303db20 ("virtiofs: set up virtio_fs dax_device")
> 
> from the fuse tree.
> 
> I have added the following patch which may require more work but at
> least makes it all build.
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 8 Sep 2020 20:00:20 +1000
> Subject: [PATCH] merge fix up for "mm/memremap_pages: convert to
> 'struct
>  range'"
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  drivers/xen/unpopulated-alloc.c | 15 +++++++++------
>  fs/fuse/virtio_fs.c             |  3 +--
>  2 files changed, 10 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/xen/unpopulated-alloc.c
> b/drivers/xen/unpopulated-alloc.c
> index 3b98dc921426..9fa7ce330628 100644
> --- a/drivers/xen/unpopulated-alloc.c
> +++ b/drivers/xen/unpopulated-alloc.c
> @@ -18,6 +18,7 @@ static unsigned int list_count;
>  static int fill_list(unsigned int nr_pages)
>  {
>  	struct dev_pagemap *pgmap;
> +	struct resource res;
>  	void *vaddr;
>  	unsigned int i, alloc_pages = round_up(nr_pages,
> PAGES_PER_SECTION);
>  	int ret;
> @@ -27,10 +28,10 @@ static int fill_list(unsigned int nr_pages)
>  		return -ENOMEM;
>  
>  	pgmap->type = MEMORY_DEVICE_GENERIC;
> -	pgmap->res.name = "Xen scratch";
> -	pgmap->res.flags = IORESOURCE_MEM | IORESOURCE_BUSY;

This is broken... it needs to be converted to 'struct range'. I'll take
care of that when I respin the series. Sorry for the thrash it seems
this is a new memremap_pages() user since the conversion patches
landed.

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

[Roger Pau Monné]

On Tue, Sep 08, 2020 at 08:09:50PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the akpm-current tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/xen/unpopulated-alloc.c: In function 'fill_list':
> drivers/xen/unpopulated-alloc.c:30:9: error: 'struct dev_pagemap' has no member named 'res'; did you mean 'ref'?
>    30 |  pgmap->res.name = "Xen scratch";
>       |         ^~~
>       |         ref
> drivers/xen/unpopulated-alloc.c:31:9: error: 'struct dev_pagemap' has no member named 'res'; did you mean 'ref'?
>    31 |  pgmap->res.flags = IORESOURCE_MEM | IORESOURCE_BUSY;
>       |         ^~~
>       |         ref
> drivers/xen/unpopulated-alloc.c:33:51: error: 'struct dev_pagemap' has no member named 'res'; did you mean 'ref'?
>    33 |  ret = allocate_resource(&iomem_resource, &pgmap->res,
>       |                                                   ^~~
>       |                                                   ref
> In file included from include/asm-generic/memory_model.h:5,
>                  from arch/x86/include/asm/page.h:76,
>                  from arch/x86/include/asm/thread_info.h:12,
>                  from include/linux/thread_info.h:38,
>                  from arch/x86/include/asm/preempt.h:7,
>                  from include/linux/preempt.h:78,
>                  from include/linux/spinlock.h:51,
>                  from include/linux/mmzone.h:8,
>                  from include/linux/gfp.h:6,
>                  from drivers/xen/unpopulated-alloc.c:3:
> drivers/xen/unpopulated-alloc.c:53:35: error: 'struct dev_pagemap' has no member named 'res'; did you mean 'ref'?
>    53 |   xen_pfn_t pfn = PFN_DOWN(pgmap->res.start);
>       |                                   ^~~
> include/linux/pfn.h:20:23: note: in definition of macro 'PFN_DOWN'
>    20 | #define PFN_DOWN(x) ((x) >> PAGE_SHIFT)
>       |                       ^
> drivers/xen/unpopulated-alloc.c:58:30: error: 'struct dev_pagemap' has no member named 'res'; did you mean 'ref'?
>    58 |     release_resource(&pgmap->res);
>       |                              ^~~
>       |                              ref
> drivers/xen/unpopulated-alloc.c:69:28: error: 'struct dev_pagemap' has no member named 'res'; did you mean 'ref'?
>    69 |   release_resource(&pgmap->res);
>       |                            ^~~
>       |                            ref
> fs/fuse/virtio_fs.c: In function 'virtio_fs_setup_dax':
> fs/fuse/virtio_fs.c:838:9: error: 'struct dev_pagemap' has no member named 'res'; did you mean 'ref'?
>   838 |  pgmap->res = (struct resource){
>       |         ^~~
>       |         ref
> 
> Caused by commit
> 
>   b3e022c5a68c ("mm/memremap_pages: convert to 'struct range'")
> 
> interacting with commit
> 
>   9e2369c06c8a ("xen: add helpers to allocate unpopulated memory")
> 
> from Linus' tree (in v5.9-rc4) and commit
> 
>   7e833303db20 ("virtiofs: set up virtio_fs dax_device")
> 
> from the fuse tree.
> 
> I have added the following patch which may require more work but at
> least makes it all build.
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 8 Sep 2020 20:00:20 +1000
> Subject: [PATCH] merge fix up for "mm/memremap_pages: convert to 'struct
>  range'"
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

Thanks, LGTM.

> ---
>  drivers/xen/unpopulated-alloc.c | 15 +++++++++------
>  fs/fuse/virtio_fs.c             |  3 +--
>  2 files changed, 10 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/xen/unpopulated-alloc.c b/drivers/xen/unpopulated-alloc.c
> index 3b98dc921426..9fa7ce330628 100644
> --- a/drivers/xen/unpopulated-alloc.c
> +++ b/drivers/xen/unpopulated-alloc.c
> @@ -18,6 +18,7 @@ static unsigned int list_count;
>  static int fill_list(unsigned int nr_pages)
>  {
>  	struct dev_pagemap *pgmap;
> +	struct resource res;
>  	void *vaddr;
>  	unsigned int i, alloc_pages = round_up(nr_pages, PAGES_PER_SECTION);
>  	int ret;
> @@ -27,10 +28,10 @@ static int fill_list(unsigned int nr_pages)
>  		return -ENOMEM;
>  
>  	pgmap->type = MEMORY_DEVICE_GENERIC;
> -	pgmap->res.name = "Xen scratch";
> -	pgmap->res.flags = IORESOURCE_MEM | IORESOURCE_BUSY;
> +	res.name = "Xen scratch";
> +	res.flags = IORESOURCE_MEM | IORESOURCE_BUSY;

You could init the fields at res definition time now, since it's no
longer dynamically allocated.

Roger.

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

[Vivek Goyal]

On Tue, Sep 08, 2020 at 08:09:50PM +1000, Stephen Rothwell wrote:

[..]
> fs/fuse/virtio_fs.c: In function 'virtio_fs_setup_dax':
> fs/fuse/virtio_fs.c:838:9: error: 'struct dev_pagemap' has no member named 'res'; did you mean 'ref'?
>   838 |  pgmap->res = (struct resource){
>       |         ^~~
>       |         ref
> 
> Caused by commit
> 
>   b3e022c5a68c ("mm/memremap_pages: convert to 'struct range'")
> 
> interacting with commit
> 
>   9e2369c06c8a ("xen: add helpers to allocate unpopulated memory")
> 
> from Linus' tree (in v5.9-rc4) and commit
> 
>   7e833303db20 ("virtiofs: set up virtio_fs dax_device")
> 
> from the fuse tree.
> 
> I have added the following patch which may require more work but at
> least makes it all build.
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 8 Sep 2020 20:00:20 +1000
> Subject: [PATCH] merge fix up for "mm/memremap_pages: convert to 'struct
>  range'"
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  drivers/xen/unpopulated-alloc.c | 15 +++++++++------
>  fs/fuse/virtio_fs.c             |  3 +--
>  2 files changed, 10 insertions(+), 8 deletions(-)
> 

[..]
> diff --git a/fs/fuse/virtio_fs.c b/fs/fuse/virtio_fs.c
> index da3ede268604..8f27478497fa 100644
> --- a/fs/fuse/virtio_fs.c
> +++ b/fs/fuse/virtio_fs.c
> @@ -835,8 +835,7 @@ static int virtio_fs_setup_dax(struct virtio_device *vdev, struct virtio_fs *fs)
>  	 * initialize a struct resource from scratch (only the start
>  	 * and end fields will be used).
>  	 */
> -	pgmap->res = (struct resource){
> -		.name = "virtio-fs dax window",
> +	pgmap->range = (struct range){
>  		.start = (phys_addr_t) cache_reg.addr,
>  		.end = (phys_addr_t) cache_reg.addr + cache_reg.len - 1,
>  	};

Thanks Stephen. This change looks good to me for virtiofs.

Thanks
Vivek

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

[Stephen Rothwell]

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

Hi all,

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

drivers/xen/unpopulated-alloc.c: In function 'fill_list':
drivers/xen/unpopulated-alloc.c:30:9: error: 'struct dev_pagemap' has no member named 'res'; did you mean 'ref'?
   30 |  pgmap->res.name = "Xen scratch";
      |         ^~~
      |         ref
drivers/xen/unpopulated-alloc.c:31:9: error: 'struct dev_pagemap' has no member named 'res'; did you mean 'ref'?
   31 |  pgmap->res.flags = IORESOURCE_MEM | IORESOURCE_BUSY;
      |         ^~~
      |         ref
drivers/xen/unpopulated-alloc.c:33:51: error: 'struct dev_pagemap' has no member named 'res'; did you mean 'ref'?
   33 |  ret = allocate_resource(&iomem_resource, &pgmap->res,
      |                                                   ^~~
      |                                                   ref
In file included from include/asm-generic/memory_model.h:5,
                 from arch/x86/include/asm/page.h:76,
                 from arch/x86/include/asm/thread_info.h:12,
                 from include/linux/thread_info.h:38,
                 from arch/x86/include/asm/preempt.h:7,
                 from include/linux/preempt.h:78,
                 from include/linux/spinlock.h:51,
                 from include/linux/mmzone.h:8,
                 from include/linux/gfp.h:6,
                 from drivers/xen/unpopulated-alloc.c:3:
drivers/xen/unpopulated-alloc.c:53:35: error: 'struct dev_pagemap' has no member named 'res'; did you mean 'ref'?
   53 |   xen_pfn_t pfn = PFN_DOWN(pgmap->res.start);
      |                                   ^~~
include/linux/pfn.h:20:23: note: in definition of macro 'PFN_DOWN'
   20 | #define PFN_DOWN(x) ((x) >> PAGE_SHIFT)
      |                       ^
drivers/xen/unpopulated-alloc.c:58:30: error: 'struct dev_pagemap' has no member named 'res'; did you mean 'ref'?
   58 |     release_resource(&pgmap->res);
      |                              ^~~
      |                              ref
drivers/xen/unpopulated-alloc.c:69:28: error: 'struct dev_pagemap' has no member named 'res'; did you mean 'ref'?
   69 |   release_resource(&pgmap->res);
      |                            ^~~
      |                            ref
fs/fuse/virtio_fs.c: In function 'virtio_fs_setup_dax':
fs/fuse/virtio_fs.c:838:9: error: 'struct dev_pagemap' has no member named 'res'; did you mean 'ref'?
  838 |  pgmap->res = (struct resource){
      |         ^~~
      |         ref

Caused by commit

  b3e022c5a68c ("mm/memremap_pages: convert to 'struct range'")

interacting with commit

  9e2369c06c8a ("xen: add helpers to allocate unpopulated memory")

from Linus' tree (in v5.9-rc4) and commit

  7e833303db20 ("virtiofs: set up virtio_fs dax_device")

from the fuse tree.

I have added the following patch which may require more work but at
least makes it all build.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 8 Sep 2020 20:00:20 +1000
Subject: [PATCH] merge fix up for "mm/memremap_pages: convert to 'struct
 range'"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/xen/unpopulated-alloc.c | 15 +++++++++------
 fs/fuse/virtio_fs.c             |  3 +--
 2 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/xen/unpopulated-alloc.c b/drivers/xen/unpopulated-alloc.c
index 3b98dc921426..9fa7ce330628 100644
--- a/drivers/xen/unpopulated-alloc.c
+++ b/drivers/xen/unpopulated-alloc.c
@@ -18,6 +18,7 @@ static unsigned int list_count;
 static int fill_list(unsigned int nr_pages)
 {
 	struct dev_pagemap *pgmap;
+	struct resource res;
 	void *vaddr;
 	unsigned int i, alloc_pages = round_up(nr_pages, PAGES_PER_SECTION);
 	int ret;
@@ -27,10 +28,10 @@ static int fill_list(unsigned int nr_pages)
 		return -ENOMEM;
 
 	pgmap->type = MEMORY_DEVICE_GENERIC;
-	pgmap->res.name = "Xen scratch";
-	pgmap->res.flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+	res.name = "Xen scratch";
+	res.flags = IORESOURCE_MEM | IORESOURCE_BUSY;
 
-	ret = allocate_resource(&iomem_resource, &pgmap->res,
+	ret = allocate_resource(&iomem_resource, &res,
 				alloc_pages * PAGE_SIZE, 0, -1,
 				PAGES_PER_SECTION * PAGE_SIZE, NULL, NULL);
 	if (ret < 0) {
@@ -38,6 +39,8 @@ static int fill_list(unsigned int nr_pages)
 		kfree(pgmap);
 		return ret;
 	}
+	pgmap->range.start = res.start;
+	pgmap->range.end = res.end;
 
 #ifdef CONFIG_XEN_HAVE_PVMMU
         /*
@@ -50,12 +53,12 @@ static int fill_list(unsigned int nr_pages)
          * conflict with any devices.
          */
 	if (!xen_feature(XENFEAT_auto_translated_physmap)) {
-		xen_pfn_t pfn = PFN_DOWN(pgmap->res.start);
+		xen_pfn_t pfn = PFN_DOWN(res.start);
 
 		for (i = 0; i < alloc_pages; i++) {
 			if (!set_phys_to_machine(pfn + i, INVALID_P2M_ENTRY)) {
 				pr_warn("set_phys_to_machine() failed, no memory added\n");
-				release_resource(&pgmap->res);
+				release_resource(&res);
 				kfree(pgmap);
 				return -ENOMEM;
 			}
@@ -66,7 +69,7 @@ static int fill_list(unsigned int nr_pages)
 	vaddr = memremap_pages(pgmap, NUMA_NO_NODE);
 	if (IS_ERR(vaddr)) {
 		pr_err("Cannot remap memory range\n");
-		release_resource(&pgmap->res);
+		release_resource(&res);
 		kfree(pgmap);
 		return PTR_ERR(vaddr);
 	}
diff --git a/fs/fuse/virtio_fs.c b/fs/fuse/virtio_fs.c
index da3ede268604..8f27478497fa 100644
--- a/fs/fuse/virtio_fs.c
+++ b/fs/fuse/virtio_fs.c
@@ -835,8 +835,7 @@ static int virtio_fs_setup_dax(struct virtio_device *vdev, struct virtio_fs *fs)
 	 * initialize a struct resource from scratch (only the start
 	 * and end fields will be used).
 	 */
-	pgmap->res = (struct resource){
-		.name = "virtio-fs dax window",
+	pgmap->range = (struct range){
 		.start = (phys_addr_t) cache_reg.addr,
 		.end = (phys_addr_t) cache_reg.addr + cache_reg.len - 1,
 	};
-- 
2.28.0

-- 
Cheers,
Stephen Rothwell

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

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

[Stephen Rothwell]

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

Hi Mike,

On Thu, 27 Aug 2020 15:45:49 +0300 Mike Rapoport <rppt@linux.ibm.com> wrote:
>
> On Thu, Aug 27, 2020 at 06:20:58PM +1000, Stephen Rothwell wrote:
> > Hi all,
> > 
> > After merging the akpm-current tree, today's linux-next build (mips
> > cavium_octeon_defconfig) failed like this:
> > 
> > arch/mips/cavium-octeon/dma-octeon.c:205:7: error: ‘mem’ undeclared (first use in this function); did you mean ‘sem’?
> > 
> > Caused by commit
> > 
> >   52e1a745395d ("arch, drivers: replace for_each_membock() with for_each_mem_range()")
> > 
> > Reported by "kernelci.org bot" <bot@kernelci.org>.  
> 
> Here's the fix:
> 
> From 9e46da6793528e35883ff81835d65a864bf98007 Mon Sep 17 00:00:00 2001
> From: Mike Rapoport <rppt@linux.ibm.com>
> Date: Thu, 27 Aug 2020 15:42:49 +0300
> Subject: [PATCH] mips: fix cavium-octeon build caused by memblock refactoring

Thanks, I have added that to linux-next today.

-- 
Cheers,
Stephen Rothwell

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

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

[Mike Rapoport]

On Thu, Aug 27, 2020 at 06:20:58PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the akpm-current tree, today's linux-next build (mips
> cavium_octeon_defconfig) failed like this:
> 
> arch/mips/cavium-octeon/dma-octeon.c:205:7: error: ‘mem’ undeclared (first use in this function); did you mean ‘sem’?
> 
> Caused by commit
> 
>   52e1a745395d ("arch, drivers: replace for_each_membock() with for_each_mem_range()")
> 
> Reported by "kernelci.org bot" <bot@kernelci.org>.

Here's the fix:

From 9e46da6793528e35883ff81835d65a864bf98007 Mon Sep 17 00:00:00 2001
From: Mike Rapoport <rppt@linux.ibm.com>
Date: Thu, 27 Aug 2020 15:42:49 +0300
Subject: [PATCH] mips: fix cavium-octeon build caused by memblock refactoring
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

MIPS cavium_octeon_defconfig build failed like this:

arch/mips/cavium-octeon/dma-octeon.c:205:7: error: ‘mem’ undeclared
(first use in this function); did you mean ‘sem’?

Caused by patch ("arch, drivers: replace for_each_membock() with
for_each_mem_range()")

Replacing stale 'mem->base' reference with 'start' fixes the issue.

Reported by "kernelci.org bot" <bot@kernelci.org>.
Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
---
 arch/mips/cavium-octeon/dma-octeon.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/mips/cavium-octeon/dma-octeon.c b/arch/mips/cavium-octeon/dma-octeon.c
index d938c1f7c1e1..ad1aecc4b401 100644
--- a/arch/mips/cavium-octeon/dma-octeon.c
+++ b/arch/mips/cavium-octeon/dma-octeon.c
@@ -202,7 +202,7 @@ void __init plat_swiotlb_setup(void)
 
 	for_each_mem_range(i, &start, &end) {
 		/* These addresses map low for PCI. */
-		if (mem->base > 0x410000000ull && !OCTEON_IS_OCTEON2())
+		if (start > 0x410000000ull && !OCTEON_IS_OCTEON2())
 			continue;
 
 		addr_size += (end - start);
-- 
2.26.2

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

[Stephen Rothwell]

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

Hi all,

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

arch/mips/cavium-octeon/dma-octeon.c:205:7: error: ‘mem’ undeclared (first use in this function); did you mean ‘sem’?

Caused by commit

  52e1a745395d ("arch, drivers: replace for_each_membock() with for_each_mem_range()")

Reported by "kernelci.org bot" <bot@kernelci.org>.

-- 
Cheers,
Stephen Rothwell

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

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

[Stephen Rothwell]

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

Hi all,

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

mm/memory.c: In function '__apply_to_page_range':
mm/memory.c:2358:13: error: 'ARCH_PAGE_TABLE_SYNC_MASK' undeclared (first use in this function)
 2358 |  if (mask & ARCH_PAGE_TABLE_SYNC_MASK)
      |             ^~~~~~~~~~~~~~~~~~~~~~~~~
mm/memory.c:2358:13: note: each undeclared identifier is reported only once for each function it appears in
mm/memory.c:2359:3: error: implicit declaration of function 'arch_sync_kernel_mappings' [-Werror=implicit-function-declaration]
 2359 |   arch_sync_kernel_mappings(start, start + size);
      |   ^~~~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors

Caused by commit

  a9354f1a10d5 ("mm: track page table modifications in __apply_to_page_range()")

I have added the following fix patch.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 25 Aug 2020 17:17:12 +1000
Subject: [PATCH] ARCH_PAGE_TABLE_SYNC_MASK needs vmalloc.h

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

diff --git a/mm/memory.c b/mm/memory.c
index 64352f8e3a70..fb5463153351 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -73,6 +73,7 @@
 #include <linux/numa.h>
 #include <linux/perf_event.h>
 #include <linux/ptrace.h>
+#include <linux/vmalloc.h>
 
 #include <trace/events/kmem.h>
 
-- 
2.28.0

-- 
Cheers,
Stephen Rothwell

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

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

[Mike Kravetz]

On 7/21/20 3:57 AM, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the akpm-current tree, today's linux-next build
> (sparc64 defconfig) failed like this:
> 
> mm/hugetlb.c: In function 'free_gigantic_page':
> mm/hugetlb.c:1233:18: error: 'hugetlb_cma' undeclared (first use in this function); did you mean 'hugetlb_lock'?
>       cma_release(hugetlb_cma[page_to_nid(page)], page, 1 << order))
>                   ^~~~~~~~~~~
>                   hugetlb_lock
> 
> Caused by commits
> 
>   ee0889218f26 ("mm/hugetlb: avoid hardcoding while checking if cma is enabled")
>   8729fda59982 ("mm-hugetlb-avoid-hardcoding-while-checking-if-cma-is-enabled-fix")
> 
> I have added this patch for today:
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 21 Jul 2020 20:44:57 +1000
> Subject: [PATCH] mm/hugetlb: better checks before using hugetlb_cma
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

Thanks Stephen, sorry for missing that in review.

Acked-by: Mike Kravetz <mike.kravetz@oracle.com>
-- 
Mike Kravetz

> ---
>  mm/hugetlb.c | 9 ++++++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 4b560c7555e7..4645f1441d32 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -1229,9 +1229,10 @@ static void free_gigantic_page(struct page *page, unsigned int order)
>  	 * If the page isn't allocated using the cma allocator,
>  	 * cma_release() returns false.
>  	 */
> -	if (IS_ENABLED(CONFIG_CMA) &&
> -	    cma_release(hugetlb_cma[page_to_nid(page)], page, 1 << order))
> +#ifdef CONFIG_CMA
> +	if (cma_release(hugetlb_cma[page_to_nid(page)], page, 1 << order))
>  		return;
> +#endif
>  
>  	free_contig_range(page_to_pfn(page), 1 << order);
>  }
> @@ -1242,7 +1243,8 @@ static struct page *alloc_gigantic_page(struct hstate *h, gfp_t gfp_mask,
>  {
>  	unsigned long nr_pages = 1UL << huge_page_order(h);
>  
> -	if (IS_ENABLED(CONFIG_CMA)) {
> +#ifdef CONFIG_CMA
> +	{
>  		struct page *page;
>  		int node;
>  
> @@ -1256,6 +1258,7 @@ static struct page *alloc_gigantic_page(struct hstate *h, gfp_t gfp_mask,
>  				return page;
>  		}
>  	}
> +#endif
>  
>  	return alloc_contig_pages(nr_pages, gfp_mask, nid, nodemask);
>  }
> 

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

[Stephen Rothwell]

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

Hi all,

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

mm/hugetlb.c: In function 'free_gigantic_page':
mm/hugetlb.c:1233:18: error: 'hugetlb_cma' undeclared (first use in this function); did you mean 'hugetlb_lock'?
      cma_release(hugetlb_cma[page_to_nid(page)], page, 1 << order))
                  ^~~~~~~~~~~
                  hugetlb_lock

Caused by commits

  ee0889218f26 ("mm/hugetlb: avoid hardcoding while checking if cma is enabled")
  8729fda59982 ("mm-hugetlb-avoid-hardcoding-while-checking-if-cma-is-enabled-fix")

I have added this patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 21 Jul 2020 20:44:57 +1000
Subject: [PATCH] mm/hugetlb: better checks before using hugetlb_cma

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

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 4b560c7555e7..4645f1441d32 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1229,9 +1229,10 @@ static void free_gigantic_page(struct page *page, unsigned int order)
 	 * If the page isn't allocated using the cma allocator,
 	 * cma_release() returns false.
 	 */
-	if (IS_ENABLED(CONFIG_CMA) &&
-	    cma_release(hugetlb_cma[page_to_nid(page)], page, 1 << order))
+#ifdef CONFIG_CMA
+	if (cma_release(hugetlb_cma[page_to_nid(page)], page, 1 << order))
 		return;
+#endif
 
 	free_contig_range(page_to_pfn(page), 1 << order);
 }
@@ -1242,7 +1243,8 @@ static struct page *alloc_gigantic_page(struct hstate *h, gfp_t gfp_mask,
 {
 	unsigned long nr_pages = 1UL << huge_page_order(h);
 
-	if (IS_ENABLED(CONFIG_CMA)) {
+#ifdef CONFIG_CMA
+	{
 		struct page *page;
 		int node;
 
@@ -1256,6 +1258,7 @@ static struct page *alloc_gigantic_page(struct hstate *h, gfp_t gfp_mask,
 				return page;
 		}
 	}
+#endif
 
 	return alloc_contig_pages(nr_pages, gfp_mask, nid, nodemask);
 }
-- 
2.27.0

-- 
Cheers,
Stephen Rothwell

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

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

[Stephen Rothwell]

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

Hi all,

[Also reported by Randy Dunlap.]

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

mm/migrate.c: In function 'migrate_pages':
mm/migrate.c:1528:19: error: 'THP_MIGRATION_SUCCESS' undeclared (first use in this function); did you mean 'PGMIGRATE_SUCCESS'?
 1528 |   count_vm_events(THP_MIGRATION_SUCCESS, nr_thp_succeeded);
      |                   ^~~~~~~~~~~~~~~~~~~~~
      |                   PGMIGRATE_SUCCESS
mm/migrate.c:1528:19: note: each undeclared identifier is reported only once for each function it appears in
mm/migrate.c:1530:19: error: 'THP_MIGRATION_FAILURE' undeclared (first use in this function); did you mean 'SWP_MIGRATION_WRITE'?
 1530 |   count_vm_events(THP_MIGRATION_FAILURE, nr_thp_failed);
      |                   ^~~~~~~~~~~~~~~~~~~~~
      |                   SWP_MIGRATION_WRITE
mm/migrate.c:1532:19: error: 'THP_MIGRATION_SPLIT' undeclared (first use in this function); did you mean 'SWP_MIGRATION_WRITE'?
 1532 |   count_vm_events(THP_MIGRATION_SPLIT, nr_thp_split);
      |                   ^~~~~~~~~~~~~~~~~~~
      |                   SWP_MIGRATION_WRITE

Caused by commit

  f85bb1e35327 ("mm/vmstat: add events for THP migration without split")

I have reverted that commit (and its followup fix) for today.

-- 
Cheers,
Stephen Rothwell

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

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

[Kees Cook]

On Fri, Jun 26, 2020 at 05:06:03PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the akpm-current tree, today's linux-next build (sparc
> defconfig) failed like this:
> 
> mm/slab.c: In function '___cache_free':
> mm/slab.c:3471:2: error: implicit declaration of function '__free_one'; did you mean '__free_page'? [-Werror=implicit-function-declaration]
>   __free_one(ac, objp);
>   ^~~~~~~~~~
>   __free_page
> 
> 
> Caused by commit
> 
>   1420b22124be ("mm/slab: add naive detection of double free")
> 
> __free_one() is ony defined when CONFIG_NUMA is set but used more
> generally.
> 
> I have reverted that commit for today.

Thanks! Just to close the loop here, Randy also pointed this out and
I've sent a fix:
https://lore.kernel.org/lkml/1de6b098-a759-dd96-df5d-9a282b2a991b@infradead.org/

-- 
Kees Cook

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

[Stephen Rothwell]

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

Hi all,

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

mm/slab.c: In function '___cache_free':
mm/slab.c:3471:2: error: implicit declaration of function '__free_one'; did you mean '__free_page'? [-Werror=implicit-function-declaration]
  __free_one(ac, objp);
  ^~~~~~~~~~
  __free_page


Caused by commit

  1420b22124be ("mm/slab: add naive detection of double free")

__free_one() is ony defined when CONFIG_NUMA is set but used more
generally.

I have reverted that commit for today.

-- 
Cheers,
Stephen Rothwell

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

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

[Stephen Rothwell]

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

Hi all,

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


Caused by commit

  a1e988dda7bb ("drivers/tty/serial/sh-sci.c: suppress uninitialized var warning")

interacting with commit

  2d0e6f87039d ("compiler: Remove uninitialized_var() macro")

from the kspp tree.

I have just reverted that commit for today.

BTW, I don't see the warning that this patch is trying to fix ... (gcc 9)
-- 
Cheers,
Stephen Rothwell

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

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

[Stephen Rothwell]

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

Hi Andrew,

On Tue, 9 Jun 2020 21:01:37 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> I've sent this in as well:
> 
> From: Andrew Morton <akpm@linux-foundation.org>
> Subject: arch/sparc/mm/srmmu.c: fix build
> 
> "mm: consolidate pte_index() and pte_offset_*() definitions" was supposed
> to remove arch/sparc/mm/srmmu.c:pte_offset_kernel().
> 
> Fixes: 974b9b2c68f3d35 ("mm: consolidate pte_index() and pte_offset_*() definitions")
> Reported-by: kernel test robot <lkp@intel.com>
> Cc: Mike Rapoport <rppt@linux.ibm.com>
> Cc: Johannes Weiner <hannes@cmpxchg.org>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
> 
>  arch/sparc/mm/srmmu.c |   10 ----------
>  1 file changed, 10 deletions(-)
> 
> --- a/arch/sparc/mm/srmmu.c~arch-sparc-mm-srmmuc-fix-build
> +++ a/arch/sparc/mm/srmmu.c
> @@ -140,16 +140,6 @@ void pmd_set(pmd_t *pmdp, pte_t *ptep)
>  	set_pte((pte_t *)&pmd_val(*pmdp), __pte(SRMMU_ET_PTD | ptp));
>  }
>  
> -/* Find an entry in the third-level page table.. */
> -pte_t *pte_offset_kernel(pmd_t *dir, unsigned long address)
> -{
> -	void *pte;
> -
> -	pte = __nocache_va((pmd_val(*dir) & SRMMU_PTD_PMASK) << 4);
> -	return (pte_t *) pte +
> -	    ((address >> PAGE_SHIFT) & (PTRS_PER_PTE - 1));
> -}
> -
>  /*
>   * size: bytes to allocate in the nocache area.
>   * align: bytes, number to align at.
> _
> 

Thanks.

-- 
Cheers,
Stephen Rothwell

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

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

[Andrew Morton]

On Wed, 10 Jun 2020 13:44:25 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> On Tue, 9 Jun 2020 22:42:52 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > After merging the akpm-current tree, today's linux-next build (sparc
> > defconfig) failed like this:
> > 
> > In file included from include/linux/mm.h:32:0,
> >                  from include/linux/memblock.h:13,
> >                  from arch/sparc/mm/srmmu.c:14:
> > include/linux/pgtable.h:74:27: error: redefinition of 'pte_offset_kernel'
> >  #define pte_offset_kernel pte_offset_kernel
> >                            ^
> > arch/sparc/mm/srmmu.c:144:8: note: in expansion of macro 'pte_offset_kernel'
> >  pte_t *pte_offset_kernel(pmd_t *dir, unsigned long address)
> >         ^~~~~~~~~~~~~~~~~
> > include/linux/pgtable.h:70:22: note: previous definition of 'pte_offset_kernel' was here
> >  static inline pte_t *pte_offset_kernel(pmd_t *pmd, unsigned long address)
> >                       ^~~~~~~~~~~~~~~~~
> > 
> > Caused by commit
> > 
> >   292aa65ed13a ("mm: consolidate pte_index() and pte_offset_*() definitions")
> 
> This breakage is now in Linus' tree :-(

I've sent this in as well:

From: Andrew Morton <akpm@linux-foundation.org>
Subject: arch/sparc/mm/srmmu.c: fix build

"mm: consolidate pte_index() and pte_offset_*() definitions" was supposed
to remove arch/sparc/mm/srmmu.c:pte_offset_kernel().

Fixes: 974b9b2c68f3d35 ("mm: consolidate pte_index() and pte_offset_*() definitions")
Reported-by: kernel test robot <lkp@intel.com>
Cc: Mike Rapoport <rppt@linux.ibm.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 arch/sparc/mm/srmmu.c |   10 ----------
 1 file changed, 10 deletions(-)

--- a/arch/sparc/mm/srmmu.c~arch-sparc-mm-srmmuc-fix-build
+++ a/arch/sparc/mm/srmmu.c
@@ -140,16 +140,6 @@ void pmd_set(pmd_t *pmdp, pte_t *ptep)
 	set_pte((pte_t *)&pmd_val(*pmdp), __pte(SRMMU_ET_PTD | ptp));
 }
 
-/* Find an entry in the third-level page table.. */
-pte_t *pte_offset_kernel(pmd_t *dir, unsigned long address)
-{
-	void *pte;
-
-	pte = __nocache_va((pmd_val(*dir) & SRMMU_PTD_PMASK) << 4);
-	return (pte_t *) pte +
-	    ((address >> PAGE_SHIFT) & (PTRS_PER_PTE - 1));
-}
-
 /*
  * size: bytes to allocate in the nocache area.
  * align: bytes, number to align at.
_

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

[Stephen Rothwell]

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

Hi all,

On Tue, 9 Jun 2020 22:42:52 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the akpm-current tree, today's linux-next build (sparc
> defconfig) failed like this:
> 
> In file included from include/linux/mm.h:32:0,
>                  from include/linux/memblock.h:13,
>                  from arch/sparc/mm/srmmu.c:14:
> include/linux/pgtable.h:74:27: error: redefinition of 'pte_offset_kernel'
>  #define pte_offset_kernel pte_offset_kernel
>                            ^
> arch/sparc/mm/srmmu.c:144:8: note: in expansion of macro 'pte_offset_kernel'
>  pte_t *pte_offset_kernel(pmd_t *dir, unsigned long address)
>         ^~~~~~~~~~~~~~~~~
> include/linux/pgtable.h:70:22: note: previous definition of 'pte_offset_kernel' was here
>  static inline pte_t *pte_offset_kernel(pmd_t *pmd, unsigned long address)
>                       ^~~~~~~~~~~~~~~~~
> 
> Caused by commit
> 
>   292aa65ed13a ("mm: consolidate pte_index() and pte_offset_*() definitions")

This breakage is now in Linus' tree :-(

-- 
Cheers,
Stephen Rothwell

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

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

[Stephen Rothwell]

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

Hi all,

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

In file included from include/linux/mm.h:32:0,
                 from include/linux/memblock.h:13,
                 from arch/sparc/mm/srmmu.c:14:
include/linux/pgtable.h:74:27: error: redefinition of 'pte_offset_kernel'
 #define pte_offset_kernel pte_offset_kernel
                           ^
arch/sparc/mm/srmmu.c:144:8: note: in expansion of macro 'pte_offset_kernel'
 pte_t *pte_offset_kernel(pmd_t *dir, unsigned long address)
        ^~~~~~~~~~~~~~~~~
include/linux/pgtable.h:70:22: note: previous definition of 'pte_offset_kernel' was here
 static inline pte_t *pte_offset_kernel(pmd_t *pmd, unsigned long address)
                      ^~~~~~~~~~~~~~~~~

Caused by commit

  292aa65ed13a ("mm: consolidate pte_index() and pte_offset_*() definitions")

I used the (missing part of the) patch from next-20200608:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 9 Jun 2020 22:36:14 +1000
Subject: [PATCH] update sparc32 for "mm: consolidate pte_index() and
 pte_offset_*() definitions"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/sparc/mm/srmmu.c | 10 ----------
 1 file changed, 10 deletions(-)

diff --git a/arch/sparc/mm/srmmu.c b/arch/sparc/mm/srmmu.c
index 989da22ba8e9..0070f8b9a753 100644
--- a/arch/sparc/mm/srmmu.c
+++ b/arch/sparc/mm/srmmu.c
@@ -140,16 +140,6 @@ void pmd_set(pmd_t *pmdp, pte_t *ptep)
 	set_pte((pte_t *)&pmd_val(*pmdp), __pte(SRMMU_ET_PTD | ptp));
 }
 
-/* Find an entry in the third-level page table.. */
-pte_t *pte_offset_kernel(pmd_t *dir, unsigned long address)
-{
-	void *pte;
-
-	pte = __nocache_va((pmd_val(*dir) & SRMMU_PTD_PMASK) << 4);
-	return (pte_t *) pte +
-	    ((address >> PAGE_SHIFT) & (PTRS_PER_PTE - 1));
-}
-
 /*
  * size: bytes to allocate in the nocache area.
  * align: bytes, number to align at.
-- 
2.26.2

-- 
Cheers,
Stephen Rothwell

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

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

[Andrew Morton]

On Fri, 8 May 2020 07:51:23 -0700 Ira Weiny <ira.weiny@intel.com> wrote:

> This should probably be squashed into that patch though...
> 
> Andrew do you want a V3.1?

Is OK, I'll always fold foo-fix.patch into foo.patch before sending it onwards.

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

[Ira Weiny]

On Thu, May 07, 2020 at 07:08:08PM -0700, Andrew Morton wrote:
> On Fri, 8 May 2020 11:43:38 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > Hi all,
> > 
> > On Thu, 7 May 2020 22:17:21 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
> > > After merging the akpm-current tree, today's linux-next build (arm
> > > collie_defconfig and many others) failed like this:
> > > 
> > > arch/arm/mm/dma-mapping.c: In function 'dma_cache_maint_page':
> > > arch/arm/mm/dma-mapping.c:892:6: error: implicit declaration of function 'kunmap_high' [-Werror=implicit-function-declaration]
> > >       kunmap_high(page);
> > >       ^
> > > arch/arm/mm/flush.c: In function '__flush_dcache_page':
> > > arch/arm/mm/flush.c:221:6: error: implicit declaration of function 'kunmap_high' [-Werror=implicit-function-declaration]
> > >       kunmap_high(page + i);
> > >       ^
> > > 
> > > Caused by commit
> > > 
> > >   6b66ab470b4d ("arch/kunmap: remove duplicate kunmap implementations")
> > > 
> > > kunmap_high() is now only declared when CONFIG_HIGHMEM is defined.
> > 
> > Is there anything that can be done quickly about this as it broke a
> > large number of builds ...
> 
> This?  It's based on Ira's v3 series but should work.

Looks like arm is using kmap_high_get() internally which needs a
kunmap_high()...

> 
> 
> From: Andrew Morton <akpm@linux-foundation.org>
> Subject: arch-kunmap-remove-duplicate-kunmap-implementations-fix
> 
> fix CONFIG_HIGHMEM=n build on various architectures
> 

Reviewed-by: Ira Weiny <ira.weiny@intel.com>

This should probably be squashed into that patch though...

Andrew do you want a V3.1?

Ira

> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Cc: Ira Weiny <ira.weiny@intel.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
> 
>  include/linux/highmem.h |    5 +++++
>  1 file changed, 5 insertions(+)
> 
> --- a/include/linux/highmem.h~arch-kunmap-remove-duplicate-kunmap-implementations-fix
> +++ a/include/linux/highmem.h
> @@ -53,6 +53,7 @@ static inline void *kmap(struct page *pa
>  }
>  
>  void kunmap_high(struct page *page);
> +
>  static inline void kunmap(struct page *page)
>  {
>  	might_sleep();
> @@ -111,6 +112,10 @@ static inline void *kmap(struct page *pa
>  	return page_address(page);
>  }
>  
> +static inline void kunmap_high(struct page *page)
> +{
> +}
> +
>  static inline void kunmap(struct page *page)
>  {
>  }
> _
> 

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

[Stephen Rothwell]

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

Hi Andrew,

On Thu, 7 May 2020 19:08:08 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
> 
> This?  It's based on Ira's v3 series but should work.
> 
> 
> From: Andrew Morton <akpm@linux-foundation.org>
> Subject: arch-kunmap-remove-duplicate-kunmap-implementations-fix
> 
> fix CONFIG_HIGHMEM=n build on various architectures
> 
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Cc: Ira Weiny <ira.weiny@intel.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
> 
>  include/linux/highmem.h |    5 +++++
>  1 file changed, 5 insertions(+)
> 
> --- a/include/linux/highmem.h~arch-kunmap-remove-duplicate-kunmap-implementations-fix
> +++ a/include/linux/highmem.h
> @@ -53,6 +53,7 @@ static inline void *kmap(struct page *pa
>  }
>  
>  void kunmap_high(struct page *page);
> +
>  static inline void kunmap(struct page *page)
>  {
>  	might_sleep();
> @@ -111,6 +112,10 @@ static inline void *kmap(struct page *pa
>  	return page_address(page);
>  }
>  
> +static inline void kunmap_high(struct page *page)
> +{
> +}
> +
>  static inline void kunmap(struct page *page)
>  {
>  }
> _
> 

Thanks, I have added that to linux-next today.

-- 
Cheers,
Stephen Rothwell

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

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

[Andrew Morton]

On Fri, 8 May 2020 11:43:38 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> On Thu, 7 May 2020 22:17:21 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > After merging the akpm-current tree, today's linux-next build (arm
> > collie_defconfig and many others) failed like this:
> > 
> > arch/arm/mm/dma-mapping.c: In function 'dma_cache_maint_page':
> > arch/arm/mm/dma-mapping.c:892:6: error: implicit declaration of function 'kunmap_high' [-Werror=implicit-function-declaration]
> >       kunmap_high(page);
> >       ^
> > arch/arm/mm/flush.c: In function '__flush_dcache_page':
> > arch/arm/mm/flush.c:221:6: error: implicit declaration of function 'kunmap_high' [-Werror=implicit-function-declaration]
> >       kunmap_high(page + i);
> >       ^
> > 
> > Caused by commit
> > 
> >   6b66ab470b4d ("arch/kunmap: remove duplicate kunmap implementations")
> > 
> > kunmap_high() is now only declared when CONFIG_HIGHMEM is defined.
> 
> Is there anything that can be done quickly about this as it broke a
> large number of builds ...

This?  It's based on Ira's v3 series but should work.


From: Andrew Morton <akpm@linux-foundation.org>
Subject: arch-kunmap-remove-duplicate-kunmap-implementations-fix

fix CONFIG_HIGHMEM=n build on various architectures

Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Ira Weiny <ira.weiny@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 include/linux/highmem.h |    5 +++++
 1 file changed, 5 insertions(+)

--- a/include/linux/highmem.h~arch-kunmap-remove-duplicate-kunmap-implementations-fix
+++ a/include/linux/highmem.h
@@ -53,6 +53,7 @@ static inline void *kmap(struct page *pa
 }
 
 void kunmap_high(struct page *page);
+
 static inline void kunmap(struct page *page)
 {
 	might_sleep();
@@ -111,6 +112,10 @@ static inline void *kmap(struct page *pa
 	return page_address(page);
 }
 
+static inline void kunmap_high(struct page *page)
+{
+}
+
 static inline void kunmap(struct page *page)
 {
 }
_

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

[Stephen Rothwell]

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

Hi all,

On Thu, 7 May 2020 22:17:21 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the akpm-current tree, today's linux-next build (arm
> collie_defconfig and many others) failed like this:
> 
> arch/arm/mm/dma-mapping.c: In function 'dma_cache_maint_page':
> arch/arm/mm/dma-mapping.c:892:6: error: implicit declaration of function 'kunmap_high' [-Werror=implicit-function-declaration]
>       kunmap_high(page);
>       ^
> arch/arm/mm/flush.c: In function '__flush_dcache_page':
> arch/arm/mm/flush.c:221:6: error: implicit declaration of function 'kunmap_high' [-Werror=implicit-function-declaration]
>       kunmap_high(page + i);
>       ^
> 
> Caused by commit
> 
>   6b66ab470b4d ("arch/kunmap: remove duplicate kunmap implementations")
> 
> kunmap_high() is now only declared when CONFIG_HIGHMEM is defined.

Is there anything that can be done quickly about this as it broke a
large number of builds ...

-- 
Cheers,
Stephen Rothwell

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

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

[Stephen Rothwell]

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

Hi all,

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

arch/arm/mm/dma-mapping.c: In function 'dma_cache_maint_page':
arch/arm/mm/dma-mapping.c:892:6: error: implicit declaration of function 'kunmap_high' [-Werror=implicit-function-declaration]
      kunmap_high(page);
      ^
arch/arm/mm/flush.c: In function '__flush_dcache_page':
arch/arm/mm/flush.c:221:6: error: implicit declaration of function 'kunmap_high' [-Werror=implicit-function-declaration]
      kunmap_high(page + i);
      ^

Caused by commit

  6b66ab470b4d ("arch/kunmap: remove duplicate kunmap implementations")

kunmap_high() is now only declared when CONFIG_HIGHMEM is defined.

-- 
Cheers,
Stephen Rothwell

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

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

[Christoph Hellwig]

Andrew,

can you fold in these two fixes into the original patches?


diff --git a/mm/nommu.c b/mm/nommu.c
index d32ab47b58a9..371697bf372d 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -155,13 +155,13 @@ void *__vmalloc_node_range(unsigned long size, unsigned long align,
 		pgprot_t prot, unsigned long vm_flags, int node,
 		const void *caller)
 {
-	return __vmalloc(size, gfp);
+	return __vmalloc(size, gfp_mask);
 }
 
 void *__vmalloc_node(unsigned long size, unsigned long align, gfp_t gfp_mask,
 		int node, const void *caller)
 {
-	return __vmalloc(size, gfp);
+	return __vmalloc(size, gfp_mask);
 }
 
 static void *__vmalloc_user_flags(unsigned long size, gfp_t flags)

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

[Stephen Rothwell]

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

Hi all,

[also reported by the kernelci.org bot]

After merging the akpm-current tree, today's linux-next build (microblaze
nommu_defconfig and serveral others) failed like this:

mm/nommu.c: In function '__vmalloc_node_range':
mm/nommu.c:158:25: error: 'flags' undeclared (first use in this function)
  return __vmalloc(size, flags);
                         ^
mm/nommu.c: In function '__vmalloc_node':
mm/nommu.c:164:25: error: 'flags' undeclared (first use in this function)
  return __vmalloc(size, flags);
                         ^

Caused by commits

  be950c0b6fb2 ("mm: remove __vmalloc_node_flags_caller")
  a18681b211ea ("mm: remove vmalloc_user_node_flags")

-- 
Cheers,
Stephen Rothwell

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

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

[J. Bruce Fields]

On Sat, Feb 01, 2020 at 08:54:01AM +0100, Arnd Bergmann wrote:
> On Sat, Feb 1, 2020 at 1:32 AM J. Bruce Fields <bfields@fieldses.org> wrote:
> >
> > On Fri, Jan 31, 2020 at 02:13:09PM +1100, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > After merging the akpm-current tree, today's linux-next build (arm
> > > multi_v7_defconfig) failed like this:
> > >
> > > net/sunrpc/auth_gss/svcauth_gss.c: In function 'gss_proxy_save_rsc':
> > > net/sunrpc/auth_gss/svcauth_gss.c:1251:19: error: storage size of 'boot' isn't known
> > >  1251 |   struct timespec boot;
> > >       |                   ^~~~
> > > net/sunrpc/auth_gss/svcauth_gss.c:1273:3: error: implicit declaration of function 'getboottime'; did you mean 'getboottime64'? [-Werror=implicit-function-declaration]
> > >  1273 |   getboottime(&boot);
> > >       |   ^~~~~~~~~~~
> > >       |   getboottime64
> > > net/sunrpc/auth_gss/svcauth_gss.c:1251:19: warning: unused variable 'boot' [-Wunused-variable]
> > >  1251 |   struct timespec boot;
> > >       |                   ^~~~
> > >
> > > Caused by commit
> > >
> > >   a415f20a18c9 ("sunrpc: expiry_time should be seconds not timeval")
> 
> This commit uses the now-removed 'struct timespec' type and 'getboottime()'
> function, so to fix the compilation error, the 64-bit replacements need to e
> used as described in Documentation/core-api/timekeeping.rst
> 
> > > from the nfsd tree interacting with commits
> > >
> > >   de371b6c7b73 ("y2038: remove unused time32 interfaces")
> > >   aa7ff200a719 ("y2038: hide timeval/timespec/itimerval/itimerspec types")
> > >
> > > from the akpm-current tree.
> > >
> > > I have reverted the nfsd commit for today.  A better solution is requested.
> >
> > Unfortunately that expiry time seems to be a signed 32-bit integer in
> > both the kernel<->gss-proxy and the gss-proxy<->krb5 interfaces.
> >
> > I guess we'll have to come to an agreement with the krb5 developers.
> >
> > Simplest might be to agree that the thing's unsigned.  The expiry
> > shouldn't ever need to be decades in the future, so unsigned mod 2^32
> > arithmetic should work forever.
> 
> Can you be more specific which interface you are referring to?
> My change to gss_import_v1_context() is now part of mainline
> as of 294ec5b87a8a ("sunrpc: convert to time64_t for expiry"),
> is anything else needed there?

Oops, thanks, I was looking at a branch without that patch and forgot
that it changed that field to unsigned.

Looking at gss-proxy: it gets this expiration time from the krb5
libraries with a call to gss_inquire_context(..., &lifetime_rec, ...)
where lifetime_rec is uint32_t.

Treating this as a 64-bit time makes everything work till 2106, but, for
what it's worth, keeping it a u32 would make it correct forever (since
mod-2^32 subtraction will still give a reasonable answer).

--b.

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

[Arnd Bergmann]

On Sat, Feb 1, 2020 at 1:32 AM J. Bruce Fields <bfields@fieldses.org> wrote:
>
> On Fri, Jan 31, 2020 at 02:13:09PM +1100, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the akpm-current tree, today's linux-next build (arm
> > multi_v7_defconfig) failed like this:
> >
> > net/sunrpc/auth_gss/svcauth_gss.c: In function 'gss_proxy_save_rsc':
> > net/sunrpc/auth_gss/svcauth_gss.c:1251:19: error: storage size of 'boot' isn't known
> >  1251 |   struct timespec boot;
> >       |                   ^~~~
> > net/sunrpc/auth_gss/svcauth_gss.c:1273:3: error: implicit declaration of function 'getboottime'; did you mean 'getboottime64'? [-Werror=implicit-function-declaration]
> >  1273 |   getboottime(&boot);
> >       |   ^~~~~~~~~~~
> >       |   getboottime64
> > net/sunrpc/auth_gss/svcauth_gss.c:1251:19: warning: unused variable 'boot' [-Wunused-variable]
> >  1251 |   struct timespec boot;
> >       |                   ^~~~
> >
> > Caused by commit
> >
> >   a415f20a18c9 ("sunrpc: expiry_time should be seconds not timeval")

This commit uses the now-removed 'struct timespec' type and 'getboottime()'
function, so to fix the compilation error, the 64-bit replacements need to e
used as described in Documentation/core-api/timekeeping.rst

> > from the nfsd tree interacting with commits
> >
> >   de371b6c7b73 ("y2038: remove unused time32 interfaces")
> >   aa7ff200a719 ("y2038: hide timeval/timespec/itimerval/itimerspec types")
> >
> > from the akpm-current tree.
> >
> > I have reverted the nfsd commit for today.  A better solution is requested.
>
> Unfortunately that expiry time seems to be a signed 32-bit integer in
> both the kernel<->gss-proxy and the gss-proxy<->krb5 interfaces.
>
> I guess we'll have to come to an agreement with the krb5 developers.
>
> Simplest might be to agree that the thing's unsigned.  The expiry
> shouldn't ever need to be decades in the future, so unsigned mod 2^32
> arithmetic should work forever.

Can you be more specific which interface you are referring to?
My change to gss_import_v1_context() is now part of mainline
as of 294ec5b87a8a ("sunrpc: convert to time64_t for expiry"),
is anything else needed there?

       Arnd

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

[J. Bruce Fields]

On Fri, Jan 31, 2020 at 02:13:09PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the akpm-current tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> net/sunrpc/auth_gss/svcauth_gss.c: In function 'gss_proxy_save_rsc':
> net/sunrpc/auth_gss/svcauth_gss.c:1251:19: error: storage size of 'boot' isn't known
>  1251 |   struct timespec boot;
>       |                   ^~~~
> net/sunrpc/auth_gss/svcauth_gss.c:1273:3: error: implicit declaration of function 'getboottime'; did you mean 'getboottime64'? [-Werror=implicit-function-declaration]
>  1273 |   getboottime(&boot);
>       |   ^~~~~~~~~~~
>       |   getboottime64
> net/sunrpc/auth_gss/svcauth_gss.c:1251:19: warning: unused variable 'boot' [-Wunused-variable]
>  1251 |   struct timespec boot;
>       |                   ^~~~
> 
> Caused by commit
> 
>   a415f20a18c9 ("sunrpc: expiry_time should be seconds not timeval")
> 
> from the nfsd tree interacting with commits
> 
>   de371b6c7b73 ("y2038: remove unused time32 interfaces")
>   aa7ff200a719 ("y2038: hide timeval/timespec/itimerval/itimerspec types")
> 
> from the akpm-current tree.
> 
> I have reverted the nfsd commit for today.  A better solution is requested.

Unfortunately that expiry time seems to be a signed 32-bit integer in
both the kernel<->gss-proxy and the gss-proxy<->krb5 interfaces.

I guess we'll have to come to an agreement with the krb5 developers.

Simplest might be to agree that the thing's unsigned.  The expiry
shouldn't ever need to be decades in the future, so unsigned mod 2^32
arithmetic should work forever.

--b.

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

[Stephen Rothwell]

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

Hi all,

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

net/sunrpc/auth_gss/svcauth_gss.c: In function 'gss_proxy_save_rsc':
net/sunrpc/auth_gss/svcauth_gss.c:1251:19: error: storage size of 'boot' isn't known
 1251 |   struct timespec boot;
      |                   ^~~~
net/sunrpc/auth_gss/svcauth_gss.c:1273:3: error: implicit declaration of function 'getboottime'; did you mean 'getboottime64'? [-Werror=implicit-function-declaration]
 1273 |   getboottime(&boot);
      |   ^~~~~~~~~~~
      |   getboottime64
net/sunrpc/auth_gss/svcauth_gss.c:1251:19: warning: unused variable 'boot' [-Wunused-variable]
 1251 |   struct timespec boot;
      |                   ^~~~

Caused by commit

  a415f20a18c9 ("sunrpc: expiry_time should be seconds not timeval")

from the nfsd tree interacting with commits

  de371b6c7b73 ("y2038: remove unused time32 interfaces")
  aa7ff200a719 ("y2038: hide timeval/timespec/itimerval/itimerspec types")

from the akpm-current tree.

I have reverted the nfsd commit for today.  A better solution is requested.

-- 
Cheers,
Stephen Rothwell

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

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

[Stephen Rothwell]

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

Hi all,

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

arch/powerpc/platforms/pseries/hotplug-memory.c: In function 'lmb_to_memblock':
arch/powerpc/platforms/pseries/hotplug-memory.c:217:14: error: implicit declaration of function 'find_memory_block'; did you mean 'walk_memory_blocks'? [-Werror=implicit-function-declaration]
  217 |  mem_block = find_memory_block(mem_sect);
      |              ^~~~~~~~~~~~~~~~~
      |              walk_memory_blocks

Caused by commit

  eca658f58c58 ("drivers/base/memory.c: get rid of find_memory_block()")

I have reverted that commit for today.

-- 
Cheers,
Stephen Rothwell

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

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

[Stephen Rothwell]

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

Hi all,

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

ERROR: "_debug_pagealloc_enabled_early" [sound/drivers/pcsp/snd-pcsp.ko] undefined!

Caused by commit

  6538817e7869 ("mm, debug_pagealloc: don't rely on static keys too early")

I have added this patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 6 Jan 2020 16:44:57 +1100
Subject: [PATCH] mm, debug_pagealloc: need to export _debug_pagealloc_enabled_early

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

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 85811f1465e5..a41bd7341de1 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -696,6 +696,7 @@ unsigned int _debug_guardpage_minorder;
 
 bool _debug_pagealloc_enabled_early __read_mostly
 			= IS_ENABLED(CONFIG_DEBUG_PAGEALLOC_ENABLE_DEFAULT);
+EXPORT_SYMBOL(_debug_pagealloc_enabled_early);
 DEFINE_STATIC_KEY_FALSE(_debug_pagealloc_enabled);
 EXPORT_SYMBOL(_debug_pagealloc_enabled);
 
-- 
2.24.0

-- 
Cheers,
Stephen Rothwell

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

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

[Randy Dunlap]

On 11/15/19 3:23 PM, Andrew Morton wrote:
> On Fri, 15 Nov 2019 18:19:57 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
>> Hi all,
>>
>> [Also reported by Randy Dunlap]
>>
>> After merging the akpm-current tree, today's linux-next build (arm
>> multi_v7_defconfig) failed like this:
>>
>> mm/vmalloc.c: In function '__purge_vmap_area_lazy':
>> mm/vmalloc.c:1286:8: error: 'SHARED_KERNEL_PMD' undeclared (first use in this function)
>>  1286 |   if (!SHARED_KERNEL_PMD && boot_cpu_has(X86_FEATURE_PTI))
>>       |        ^~~~~~~~~~~~~~~~~
>> mm/vmalloc.c:1286:8: note: each undeclared identifier is reported only once for each function it appears in
>> mm/vmalloc.c:1286:29: error: implicit declaration of function 'boot_cpu_has' [-Werror=implicit-function-declaration]
>>  1286 |   if (!SHARED_KERNEL_PMD && boot_cpu_has(X86_FEATURE_PTI))
>>       |                             ^~~~~~~~~~~~
>> mm/vmalloc.c:1286:42: error: 'X86_FEATURE_PTI' undeclared (first use in this function)
>>  1286 |   if (!SHARED_KERNEL_PMD && boot_cpu_has(X86_FEATURE_PTI))
>>       |                                          ^~~~~~~~~~~~~~~
>>
>> Caused by commit
>>
>>   07ef40e149bf ("mm-vmalloc-fix-regression-caused-by-needless-vmalloc_sync_all-fix")
>>
>> SHARED_KERNEL_PMD, boot_cpu_has() and X86_FEATURE_PTI are only defined
>> for X86.
>>
>> I have reverted that commit for today.
> 
> Thanks.  So it has to be an ifdef.

Yes, that works.  Thanks.

Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested


> --- a/mm/vmalloc.c~mm-vmalloc-fix-regression-caused-by-needless-vmalloc_sync_all-fix-fix
> +++ a/mm/vmalloc.c
> @@ -1255,17 +1255,17 @@ static bool __purge_vmap_area_lazy(unsig
>  	if (unlikely(valist == NULL))
>  		return false;
>  
> -	if (IS_ENABLED(CONFIG_X86_PAE)) {
> -		/*
> -		 * First make sure the mappings are removed from all page-tables
> -		 * before they are freed.
> -		 *
> -		 * This is only needed on x86-32 with !SHARED_KERNEL_PMD, which
> -		 * is the case on a PAE kernel with PTI enabled.
> -		 */
> -		if (!SHARED_KERNEL_PMD && boot_cpu_has(X86_FEATURE_PTI))
> -			vmalloc_sync_all();
> -	}
> +#ifdef CONFIG_X86_PAE
> +	/*
> +	 * First make sure the mappings are removed from all pagetables before
> +	 * they are freed.
> +	 *
> +	 * This is only needed on x86-32 with !SHARED_KERNEL_PMD, which is the
> +	 * case on a PAE kernel with PTI enabled.
> +	 */
> +	if (!SHARED_KERNEL_PMD && boot_cpu_has(X86_FEATURE_PTI))
> +		vmalloc_sync_all();
> +#endif
>  
>  	/*
>  	 * TODO: to calculate a flush range without looping.
> _
> 


-- 
~Randy
Reported-by: Randy Dunlap <rdunlap@infradead.org>

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

[Andrew Morton]

On Fri, 15 Nov 2019 18:19:57 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> [Also reported by Randy Dunlap]
> 
> After merging the akpm-current tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> mm/vmalloc.c: In function '__purge_vmap_area_lazy':
> mm/vmalloc.c:1286:8: error: 'SHARED_KERNEL_PMD' undeclared (first use in this function)
>  1286 |   if (!SHARED_KERNEL_PMD && boot_cpu_has(X86_FEATURE_PTI))
>       |        ^~~~~~~~~~~~~~~~~
> mm/vmalloc.c:1286:8: note: each undeclared identifier is reported only once for each function it appears in
> mm/vmalloc.c:1286:29: error: implicit declaration of function 'boot_cpu_has' [-Werror=implicit-function-declaration]
>  1286 |   if (!SHARED_KERNEL_PMD && boot_cpu_has(X86_FEATURE_PTI))
>       |                             ^~~~~~~~~~~~
> mm/vmalloc.c:1286:42: error: 'X86_FEATURE_PTI' undeclared (first use in this function)
>  1286 |   if (!SHARED_KERNEL_PMD && boot_cpu_has(X86_FEATURE_PTI))
>       |                                          ^~~~~~~~~~~~~~~
> 
> Caused by commit
> 
>   07ef40e149bf ("mm-vmalloc-fix-regression-caused-by-needless-vmalloc_sync_all-fix")
> 
> SHARED_KERNEL_PMD, boot_cpu_has() and X86_FEATURE_PTI are only defined
> for X86.
> 
> I have reverted that commit for today.

Thanks.  So it has to be an ifdef.

--- a/mm/vmalloc.c~mm-vmalloc-fix-regression-caused-by-needless-vmalloc_sync_all-fix-fix
+++ a/mm/vmalloc.c
@@ -1255,17 +1255,17 @@ static bool __purge_vmap_area_lazy(unsig
 	if (unlikely(valist == NULL))
 		return false;
 
-	if (IS_ENABLED(CONFIG_X86_PAE)) {
-		/*
-		 * First make sure the mappings are removed from all page-tables
-		 * before they are freed.
-		 *
-		 * This is only needed on x86-32 with !SHARED_KERNEL_PMD, which
-		 * is the case on a PAE kernel with PTI enabled.
-		 */
-		if (!SHARED_KERNEL_PMD && boot_cpu_has(X86_FEATURE_PTI))
-			vmalloc_sync_all();
-	}
+#ifdef CONFIG_X86_PAE
+	/*
+	 * First make sure the mappings are removed from all pagetables before
+	 * they are freed.
+	 *
+	 * This is only needed on x86-32 with !SHARED_KERNEL_PMD, which is the
+	 * case on a PAE kernel with PTI enabled.
+	 */
+	if (!SHARED_KERNEL_PMD && boot_cpu_has(X86_FEATURE_PTI))
+		vmalloc_sync_all();
+#endif
 
 	/*
 	 * TODO: to calculate a flush range without looping.
_

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

[Stephen Rothwell]

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

Hi all,

[Also reported by Randy Dunlap]

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

mm/vmalloc.c: In function '__purge_vmap_area_lazy':
mm/vmalloc.c:1286:8: error: 'SHARED_KERNEL_PMD' undeclared (first use in this function)
 1286 |   if (!SHARED_KERNEL_PMD && boot_cpu_has(X86_FEATURE_PTI))
      |        ^~~~~~~~~~~~~~~~~
mm/vmalloc.c:1286:8: note: each undeclared identifier is reported only once for each function it appears in
mm/vmalloc.c:1286:29: error: implicit declaration of function 'boot_cpu_has' [-Werror=implicit-function-declaration]
 1286 |   if (!SHARED_KERNEL_PMD && boot_cpu_has(X86_FEATURE_PTI))
      |                             ^~~~~~~~~~~~
mm/vmalloc.c:1286:42: error: 'X86_FEATURE_PTI' undeclared (first use in this function)
 1286 |   if (!SHARED_KERNEL_PMD && boot_cpu_has(X86_FEATURE_PTI))
      |                                          ^~~~~~~~~~~~~~~

Caused by commit

  07ef40e149bf ("mm-vmalloc-fix-regression-caused-by-needless-vmalloc_sync_all-fix")

SHARED_KERNEL_PMD, boot_cpu_has() and X86_FEATURE_PTI are only defined
for X86.

I have reverted that commit for today.

-- 
Cheers,
Stephen Rothwell

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

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

[Mike Kravetz]

On 11/11/19 4:59 PM, Michael Ellerman wrote:
> Michael Ellerman <mpe@ellerman.id.au> writes:
>>
>> Mike Kravetz <mike.kravetz@oracle.com> writes:
>>> On 11/5/19 2:19 AM, Stephen Rothwell wrote:
> ...
>>> From 4b3ab017e639e4e583fff801e6d8e6727b7877e8 Mon Sep 17 00:00:00 2001
>>> From: Mike Kravetz <mike.kravetz@oracle.com>
>>> Date: Tue, 5 Nov 2019 15:12:15 -0800
>>> Subject: [PATCH] powerpc/mm: remove pmd_huge/pud_huge stubs and include
>>>  hugetlb.h
>>>
>>> This removes the power specific stubs created by commit aad71e3928be
>>> ("powerpc/mm: Fix build break with RADIX=y & HUGETLBFS=n") used when
>>> !CONFIG_HUGETLB_PAGE.  Instead, it addresses the build break by
>>> getting the definitions from <linux/hugetlb.h>.
>>>
>>> Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
>>> ---
>>>  arch/powerpc/include/asm/book3s/64/pgtable-4k.h  | 3 ---
>>>  arch/powerpc/include/asm/book3s/64/pgtable-64k.h | 3 ---
>>>  arch/powerpc/mm/book3s64/radix_pgtable.c         | 1 +
>>>  3 files changed, 1 insertion(+), 6 deletions(-)
>>
>> The two pgtable headers are included eventually by our top-level
>> pgtable.h, and that is included by over 100 files. So I worry this is
>> going to break the build somewhere in some obscure configuration.
>>
>> I'll push it through some test builds and see what happens.
> 
> Seems OK, it didn't introduce any new build failures.
> 
> Acked-by: Michael Ellerman <mpe@ellerman.id.au>
>

Thank you Michael!

I'll add it to the other patch as a 'proper series' so this can be a
requisite patch for the other.

-- 
Mike Kravetz

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

[Michael Ellerman]

Michael Ellerman <mpe@ellerman.id.au> writes:
>
> Mike Kravetz <mike.kravetz@oracle.com> writes:
>> On 11/5/19 2:19 AM, Stephen Rothwell wrote:
...
>> From 4b3ab017e639e4e583fff801e6d8e6727b7877e8 Mon Sep 17 00:00:00 2001
>> From: Mike Kravetz <mike.kravetz@oracle.com>
>> Date: Tue, 5 Nov 2019 15:12:15 -0800
>> Subject: [PATCH] powerpc/mm: remove pmd_huge/pud_huge stubs and include
>>  hugetlb.h
>>
>> This removes the power specific stubs created by commit aad71e3928be
>> ("powerpc/mm: Fix build break with RADIX=y & HUGETLBFS=n") used when
>> !CONFIG_HUGETLB_PAGE.  Instead, it addresses the build break by
>> getting the definitions from <linux/hugetlb.h>.
>>
>> Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
>> ---
>>  arch/powerpc/include/asm/book3s/64/pgtable-4k.h  | 3 ---
>>  arch/powerpc/include/asm/book3s/64/pgtable-64k.h | 3 ---
>>  arch/powerpc/mm/book3s64/radix_pgtable.c         | 1 +
>>  3 files changed, 1 insertion(+), 6 deletions(-)
>
> The two pgtable headers are included eventually by our top-level
> pgtable.h, and that is included by over 100 files. So I worry this is
> going to break the build somewhere in some obscure configuration.
>
> I'll push it through some test builds and see what happens.

Seems OK, it didn't introduce any new build failures.

Acked-by: Michael Ellerman <mpe@ellerman.id.au>

cheers

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

[Michael Ellerman]

Hi Mike,

Mike Kravetz <mike.kravetz@oracle.com> writes:
> On 11/5/19 2:19 AM, Stephen Rothwell wrote:
>> Hi all,
>> 
>> After merging the akpm-current tree, today's linux-next build (powerpc64
>> allnoconfig) failed like this:
>> 
>> In file included from arch/powerpc/mm/mem.c:30:
>> include/linux/hugetlb.h:233:19: error: redefinition of 'pmd_huge'
>>   233 | static inline int pmd_huge(pmd_t pmd)
>>       |                   ^~~~~~~~
>> In file included from arch/powerpc/include/asm/book3s/64/pgtable.h:301,
>>                  from arch/powerpc/include/asm/book3s/64/mmu-hash.h:20,
>>                  from arch/powerpc/include/asm/book3s/64/mmu.h:46,
>>                  from arch/powerpc/include/asm/mmu.h:356,
>>                  from arch/powerpc/include/asm/lppaca.h:47,
>>                  from arch/powerpc/include/asm/paca.h:17,
>>                  from arch/powerpc/include/asm/current.h:13,
>>                  from include/linux/sched.h:12,
>>                  from arch/powerpc/mm/mem.c:16:
>> arch/powerpc/include/asm/book3s/64/pgtable-4k.h:74:19: note: previous definition of 'pmd_huge' was here
>>    74 | static inline int pmd_huge(pmd_t pmd) { return 0; }
>>       |                   ^~~~~~~~
...
>
> Hello Michael,
>
> When I started to look into this I noticed that you added commit aad71e3928be
> ("powerpc/mm: Fix build break with RADIX=y & HUGETLBFS=n") some time back.
> It appears that all other architectures get the definition of pmd_huge and
> pud_huge from <linux/hugetlb.h> in the !CONFIG_HUGETLB_PAGE case.  Previously,
> this was not an issue as the #define pmd_huge/pud_huge did not conflict with
> the static inline in the powerpc header files.  The conflicts above happened
> when I converted the macros to also be static inlines.  Could you live with
> a patch like the following to remove the stubs from powerpc header files and
> fix your original build break by including  <linux/hugetlb.h>?  After the
> below patch is applied, the above commit will not cause the build errors seen
> in linux-next.

As long as the end result is the same, ie. we get an empty definition
that always returns false then yeah that's fine by me.

> From 4b3ab017e639e4e583fff801e6d8e6727b7877e8 Mon Sep 17 00:00:00 2001
> From: Mike Kravetz <mike.kravetz@oracle.com>
> Date: Tue, 5 Nov 2019 15:12:15 -0800
> Subject: [PATCH] powerpc/mm: remove pmd_huge/pud_huge stubs and include
>  hugetlb.h
>
> This removes the power specific stubs created by commit aad71e3928be
> ("powerpc/mm: Fix build break with RADIX=y & HUGETLBFS=n") used when
> !CONFIG_HUGETLB_PAGE.  Instead, it addresses the build break by
> getting the definitions from <linux/hugetlb.h>.
>
> Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
> ---
>  arch/powerpc/include/asm/book3s/64/pgtable-4k.h  | 3 ---
>  arch/powerpc/include/asm/book3s/64/pgtable-64k.h | 3 ---
>  arch/powerpc/mm/book3s64/radix_pgtable.c         | 1 +
>  3 files changed, 1 insertion(+), 6 deletions(-)

The two pgtable headers are included eventually by our top-level
pgtable.h, and that is included by over 100 files. So I worry this is
going to break the build somewhere in some obscure configuration.

I'll push it through some test builds and see what happens.

cheers

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

[Mike Kravetz]

On 11/5/19 2:19 AM, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the akpm-current tree, today's linux-next build (powerpc64
> allnoconfig) failed like this:
> 
> In file included from arch/powerpc/mm/mem.c:30:
> include/linux/hugetlb.h:233:19: error: redefinition of 'pmd_huge'
>   233 | static inline int pmd_huge(pmd_t pmd)
>       |                   ^~~~~~~~
> In file included from arch/powerpc/include/asm/book3s/64/pgtable.h:301,
>                  from arch/powerpc/include/asm/book3s/64/mmu-hash.h:20,
>                  from arch/powerpc/include/asm/book3s/64/mmu.h:46,
>                  from arch/powerpc/include/asm/mmu.h:356,
>                  from arch/powerpc/include/asm/lppaca.h:47,
>                  from arch/powerpc/include/asm/paca.h:17,
>                  from arch/powerpc/include/asm/current.h:13,
>                  from include/linux/sched.h:12,
>                  from arch/powerpc/mm/mem.c:16:
> arch/powerpc/include/asm/book3s/64/pgtable-4k.h:74:19: note: previous definition of 'pmd_huge' was here
>    74 | static inline int pmd_huge(pmd_t pmd) { return 0; }
>       |                   ^~~~~~~~
> In file included from arch/powerpc/mm/mem.c:30:
> include/linux/hugetlb.h:238:19: error: redefinition of 'pud_huge'
>   238 | static inline int pud_huge(pud_t pud)
>       |                   ^~~~~~~~
> In file included from arch/powerpc/include/asm/book3s/64/pgtable.h:301,
>                  from arch/powerpc/include/asm/book3s/64/mmu-hash.h:20,
>                  from arch/powerpc/include/asm/book3s/64/mmu.h:46,
>                  from arch/powerpc/include/asm/mmu.h:356,
>                  from arch/powerpc/include/asm/lppaca.h:47,
>                  from arch/powerpc/include/asm/paca.h:17,
>                  from arch/powerpc/include/asm/current.h:13,
>                  from include/linux/sched.h:12,
>                  from arch/powerpc/mm/mem.c:16:
> arch/powerpc/include/asm/book3s/64/pgtable-4k.h:75:19: note: previous definition of 'pud_huge' was here
>    75 | static inline int pud_huge(pud_t pud) { return 0; }
>       |                   ^~~~~~~~
> 
> Caused by commit
> 
>   9823e12e021f ("hugetlbfs: convert macros to static inline, fix sparse warning")
> 
> I have reverted that commit for today.

Hello Michael,

When I started to look into this I noticed that you added commit aad71e3928be
("powerpc/mm: Fix build break with RADIX=y & HUGETLBFS=n") some time back.
It appears that all other architectures get the definition of pmd_huge and
pud_huge from <linux/hugetlb.h> in the !CONFIG_HUGETLB_PAGE case.  Previously,
this was not an issue as the #define pmd_huge/pud_huge did not conflict with
the static inline in the powerpc header files.  The conflicts above happened
when I converted the macros to also be static inlines.  Could you live with
a patch like the following to remove the stubs from powerpc header files and
fix your original build break by including  <linux/hugetlb.h>?  After the
below patch is applied, the above commit will not cause the build errors seen
in linux-next.

From 4b3ab017e639e4e583fff801e6d8e6727b7877e8 Mon Sep 17 00:00:00 2001
From: Mike Kravetz <mike.kravetz@oracle.com>
Date: Tue, 5 Nov 2019 15:12:15 -0800
Subject: [PATCH] powerpc/mm: remove pmd_huge/pud_huge stubs and include
 hugetlb.h

This removes the power specific stubs created by commit aad71e3928be
("powerpc/mm: Fix build break with RADIX=y & HUGETLBFS=n") used when
!CONFIG_HUGETLB_PAGE.  Instead, it addresses the build break by
getting the definitions from <linux/hugetlb.h>.

Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
---
 arch/powerpc/include/asm/book3s/64/pgtable-4k.h  | 3 ---
 arch/powerpc/include/asm/book3s/64/pgtable-64k.h | 3 ---
 arch/powerpc/mm/book3s64/radix_pgtable.c         | 1 +
 3 files changed, 1 insertion(+), 6 deletions(-)

diff --git a/arch/powerpc/include/asm/book3s/64/pgtable-4k.h b/arch/powerpc/include/asm/book3s/64/pgtable-4k.h
index a069dfcac9a9..4e697bc2f4cd 100644
--- a/arch/powerpc/include/asm/book3s/64/pgtable-4k.h
+++ b/arch/powerpc/include/asm/book3s/64/pgtable-4k.h
@@ -70,9 +70,6 @@ static inline int get_hugepd_cache_index(int index)
 	/* should not reach */
 }
 
-#else /* !CONFIG_HUGETLB_PAGE */
-static inline int pmd_huge(pmd_t pmd) { return 0; }
-static inline int pud_huge(pud_t pud) { return 0; }
 #endif /* CONFIG_HUGETLB_PAGE */
 
 #endif /* __ASSEMBLY__ */
diff --git a/arch/powerpc/include/asm/book3s/64/pgtable-64k.h b/arch/powerpc/include/asm/book3s/64/pgtable-64k.h
index e3d4dd4ae2fa..34d1018896b3 100644
--- a/arch/powerpc/include/asm/book3s/64/pgtable-64k.h
+++ b/arch/powerpc/include/asm/book3s/64/pgtable-64k.h
@@ -59,9 +59,6 @@ static inline int get_hugepd_cache_index(int index)
 	BUG();
 }
 
-#else /* !CONFIG_HUGETLB_PAGE */
-static inline int pmd_huge(pmd_t pmd) { return 0; }
-static inline int pud_huge(pud_t pud) { return 0; }
 #endif /* CONFIG_HUGETLB_PAGE */
 
 static inline int remap_4k_pfn(struct vm_area_struct *vma, unsigned long addr,
diff --git a/arch/powerpc/mm/book3s64/radix_pgtable.c b/arch/powerpc/mm/book3s64/radix_pgtable.c
index 6ee17d09649c..974109bb85db 100644
--- a/arch/powerpc/mm/book3s64/radix_pgtable.c
+++ b/arch/powerpc/mm/book3s64/radix_pgtable.c
@@ -13,6 +13,7 @@
 #include <linux/memblock.h>
 #include <linux/of_fdt.h>
 #include <linux/mm.h>
+#include <linux/hugetlb.h>
 #include <linux/string_helpers.h>
 #include <linux/stop_machine.h>
 
-- 
2.23.0

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

[Mike Kravetz]

On 11/5/19 2:19 AM, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the akpm-current tree, today's linux-next build (powerpc64
> allnoconfig) failed like this:
> 
> In file included from arch/powerpc/mm/mem.c:30:
> include/linux/hugetlb.h:233:19: error: redefinition of 'pmd_huge'
>   233 | static inline int pmd_huge(pmd_t pmd)
>       |                   ^~~~~~~~
> In file included from arch/powerpc/include/asm/book3s/64/pgtable.h:301,
>                  from arch/powerpc/include/asm/book3s/64/mmu-hash.h:20,
>                  from arch/powerpc/include/asm/book3s/64/mmu.h:46,
>                  from arch/powerpc/include/asm/mmu.h:356,
>                  from arch/powerpc/include/asm/lppaca.h:47,
>                  from arch/powerpc/include/asm/paca.h:17,
>                  from arch/powerpc/include/asm/current.h:13,
>                  from include/linux/sched.h:12,
>                  from arch/powerpc/mm/mem.c:16:
> arch/powerpc/include/asm/book3s/64/pgtable-4k.h:74:19: note: previous definition of 'pmd_huge' was here
>    74 | static inline int pmd_huge(pmd_t pmd) { return 0; }
>       |                   ^~~~~~~~
> In file included from arch/powerpc/mm/mem.c:30:
> include/linux/hugetlb.h:238:19: error: redefinition of 'pud_huge'
>   238 | static inline int pud_huge(pud_t pud)
>       |                   ^~~~~~~~
> In file included from arch/powerpc/include/asm/book3s/64/pgtable.h:301,
>                  from arch/powerpc/include/asm/book3s/64/mmu-hash.h:20,
>                  from arch/powerpc/include/asm/book3s/64/mmu.h:46,
>                  from arch/powerpc/include/asm/mmu.h:356,
>                  from arch/powerpc/include/asm/lppaca.h:47,
>                  from arch/powerpc/include/asm/paca.h:17,
>                  from arch/powerpc/include/asm/current.h:13,
>                  from include/linux/sched.h:12,
>                  from arch/powerpc/mm/mem.c:16:
> arch/powerpc/include/asm/book3s/64/pgtable-4k.h:75:19: note: previous definition of 'pud_huge' was here
>    75 | static inline int pud_huge(pud_t pud) { return 0; }
>       |                   ^~~~~~~~
> 
> Caused by commit
> 
>   9823e12e021f ("hugetlbfs: convert macros to static inline, fix sparse warning")
> 
> I have reverted that commit for today.

Thanks Stephen,

I will fix up and send another version via Andrew's tree.

-- 
Mike Kravetz

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

[Stephen Rothwell]

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

Hi all,

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

In file included from arch/powerpc/mm/mem.c:30:
include/linux/hugetlb.h:233:19: error: redefinition of 'pmd_huge'
  233 | static inline int pmd_huge(pmd_t pmd)
      |                   ^~~~~~~~
In file included from arch/powerpc/include/asm/book3s/64/pgtable.h:301,
                 from arch/powerpc/include/asm/book3s/64/mmu-hash.h:20,
                 from arch/powerpc/include/asm/book3s/64/mmu.h:46,
                 from arch/powerpc/include/asm/mmu.h:356,
                 from arch/powerpc/include/asm/lppaca.h:47,
                 from arch/powerpc/include/asm/paca.h:17,
                 from arch/powerpc/include/asm/current.h:13,
                 from include/linux/sched.h:12,
                 from arch/powerpc/mm/mem.c:16:
arch/powerpc/include/asm/book3s/64/pgtable-4k.h:74:19: note: previous definition of 'pmd_huge' was here
   74 | static inline int pmd_huge(pmd_t pmd) { return 0; }
      |                   ^~~~~~~~
In file included from arch/powerpc/mm/mem.c:30:
include/linux/hugetlb.h:238:19: error: redefinition of 'pud_huge'
  238 | static inline int pud_huge(pud_t pud)
      |                   ^~~~~~~~
In file included from arch/powerpc/include/asm/book3s/64/pgtable.h:301,
                 from arch/powerpc/include/asm/book3s/64/mmu-hash.h:20,
                 from arch/powerpc/include/asm/book3s/64/mmu.h:46,
                 from arch/powerpc/include/asm/mmu.h:356,
                 from arch/powerpc/include/asm/lppaca.h:47,
                 from arch/powerpc/include/asm/paca.h:17,
                 from arch/powerpc/include/asm/current.h:13,
                 from include/linux/sched.h:12,
                 from arch/powerpc/mm/mem.c:16:
arch/powerpc/include/asm/book3s/64/pgtable-4k.h:75:19: note: previous definition of 'pud_huge' was here
   75 | static inline int pud_huge(pud_t pud) { return 0; }
      |                   ^~~~~~~~

Caused by commit

  9823e12e021f ("hugetlbfs: convert macros to static inline, fix sparse warning")

I have reverted that commit for today.

-- 
Cheers,
Stephen Rothwell

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

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

[Jason Gunthorpe]

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

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

[Stephen Rothwell]

[-- 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 --]

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

[Catalin Marinas]

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

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

[Stephen Rothwell]

[-- 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 --]

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

[Song Liu]

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

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

[Stephen Rothwell]

[-- 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 --]

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

[Stephen Rothwell]

[-- 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 --]

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

[Andrew Morton]

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.

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

[Arnd Bergmann]

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

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

[Andrew Morton]

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
_

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

[Michal Hocko]

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

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

[Andrew Morton]

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);
_

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

[Stephen Rothwell]

[-- 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 --]

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

[Stephen Rothwell]

[-- 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 --]

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

[Marco Elver]

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?

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

[Stephen Rothwell]

[-- 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 --]

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

[Stephen Rothwell]

[-- 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 --]

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

[Christoph Hellwig]

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

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

[Stephen Rothwell]

[-- 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 --]

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

[Stephen Rothwell]

[-- 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 --]

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

[Anshuman Khandual]

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

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

[Stephen Rothwell]

[-- 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 --]

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

[Andrew Morton]

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.

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

[Stephen Rothwell]

[-- 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 --]

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

[Masahiro Yamada]

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

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

[David Hildenbrand]

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

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

[Stephen Rothwell]

[-- 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 --]

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

[Stephen Rothwell]

[-- 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 --]

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

[Stephen Rothwell]

[-- 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 --]

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

[Stephen Rothwell]

[-- 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 --]

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

[Alexey Dobriyan]

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.

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

[Stephen Rothwell]

[-- 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 --]

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

[Kees Cook]

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

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

[Kees Cook]

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

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

[Kees Cook]

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

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

[Stephen Rothwell]

[-- 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 --]

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

[Stephen Rothwell]

[-- 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 --]

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

[Stephen Rothwell]

[-- Attachment #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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Andrew Morton]

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.

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

[Stephen Rothwell]

[-- 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 --]

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

[Stephen Rothwell]

[-- 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 --]

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

[Stephen Rothwell]

[-- 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 --]

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

[Anshuman Khandual]

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.

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

[-- 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 --]

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

[Stephen Rothwell]

[-- 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 --]

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

[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.

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

[Stephen Rothwell]

[-- 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 --]

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

[Stephen Rothwell]

[-- 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 --]

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

[Alexey Dobriyan]

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 ?

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

[Stephen Rothwell]

[-- 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 --]

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

[Stephen Rothwell]

[-- 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 --]

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

[Stephen Rothwell]

[-- 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 --]

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

[Andrew Morton]

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.

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

[Stephen Rothwell]

[-- 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 --]

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

[Stephen Rothwell]

[-- 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 --]

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

[Stephen Rothwell]

[-- 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 --]

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

[Michal Hocko]

On Fri 23-02-18 00:56:26, Stephen Rothwell wrote:
> Hi Michal,
> 
> On Thu, 22 Feb 2018 08:11:00 +0100 Michal Hocko <mhocko@kernel.org> wrote:
> >
> > This is interesting. I thought that IS_ENABLED(CONFIG_HAVE_MEMBLOCK)
> > would have the same meaning as ifdef CONFIG_HAVE_MEMBLOCK so the branch
> > will never be considered. If that is not the case then I would rather
> > reintroduce that ifdef. We already have those in the function anyway.
> 
> Actually, you don't need a definition of memblock_next_valid_pfn() in the
> !CONFIG_HAVE_MEMBLOCK case, just a declaration, so the minimal fix is
> to move the declaration out of the #ifdef CONFIG_HAVE_MEMBLOCK in the
> header file.

You are right.

> That way if there is any use of memblock_next_valid_pfn()
> introduced that is no guarded by IS_ENABLED(CONFIG_HAVE_MEMBLOCK) the
> build will fail to link.  I like IS_ENABLED() being used wherever
> possible because it allows us better compiler coverage (in the face of
> CONFIG options) even if the compiler then elides the actual code.  It
> also breaks the code up less than #ifdef's.
> 
> Your choice, of course.

The function already has those ugly ifdefs so I would keep it
consistent. Deuglyfying it would need a bigger stick.
-- 
Michal Hocko
SUSE Labs

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

[Stephen Rothwell]

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

Hi Michal,

On Thu, 22 Feb 2018 08:11:00 +0100 Michal Hocko <mhocko@kernel.org> wrote:
>
> This is interesting. I thought that IS_ENABLED(CONFIG_HAVE_MEMBLOCK)
> would have the same meaning as ifdef CONFIG_HAVE_MEMBLOCK so the branch
> will never be considered. If that is not the case then I would rather
> reintroduce that ifdef. We already have those in the function anyway.

Actually, you don't need a definition of memblock_next_valid_pfn() in the
!CONFIG_HAVE_MEMBLOCK case, just a declaration, so the minimal fix is
to move the declaration out of the #ifdef CONFIG_HAVE_MEMBLOCK in the
header file.  That way if there is any use of memblock_next_valid_pfn()
introduced that is no guarded by IS_ENABLED(CONFIG_HAVE_MEMBLOCK) the
build will fail to link.  I like IS_ENABLED() being used wherever
possible because it allows us better compiler coverage (in the face of
CONFIG options) even if the compiler then elides the actual code.  It
also breaks the code up less than #ifdef's.

Your choice, of course.

-- 
Cheers,
Stephen Rothwell

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

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

[Michal Hocko]

On Thu 22-02-18 14:30:57, Stephen Rothwell wrote:
> Hi Andrew,
> 
> [As reported by Randy for uml ...]
> 
> After merging the akpm-current tree, today's linux-next build (sparc
> defconfig) failed like this:
> 
> /home/sfr/next/next/mm/page_alloc.c: In function 'memmap_init_zone':
> /home/sfr/next/next/mm/page_alloc.c:5450:11: error: implicit declaration of function 'memblock_next_valid_pfn'; did you mean 'memblock_virt_alloc_low'? [-Werror=implicit-function-declaration]
>      pfn = memblock_next_valid_pfn(pfn, end_pfn) - 1;
>            ^~~~~~~~~~~~~~~~~~~~~~~
>            memblock_virt_alloc_low

This is interesting. I thought that IS_ENABLED(CONFIG_HAVE_MEMBLOCK)
would have the same meaning as ifdef CONFIG_HAVE_MEMBLOCK so the branch
will never be considered. If that is not the case then I would rather
reintroduce that ifdef. We already have those in the function anyway.
-- 
Michal Hocko
SUSE Labs

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

[Stephen Rothwell]

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

Hi Andrew,

[As reported by Randy for uml ...]

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

/home/sfr/next/next/mm/page_alloc.c: In function 'memmap_init_zone':
/home/sfr/next/next/mm/page_alloc.c:5450:11: error: implicit declaration of function 'memblock_next_valid_pfn'; did you mean 'memblock_virt_alloc_low'? [-Werror=implicit-function-declaration]
     pfn = memblock_next_valid_pfn(pfn, end_pfn) - 1;
           ^~~~~~~~~~~~~~~~~~~~~~~
           memblock_virt_alloc_low

Caused by commit

  c3d8f8809701 ("mm: page_alloc: skip over regions of invalid pfns on UMA")

I have applied the following patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 22 Feb 2018 14:20:45 +1100
Subject: [PATCH] mm: page_alloc: skip over regions of invalid pfns on UMA fix

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

diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index c2f1a6996fad..90e6845f44be 100644
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@ -423,6 +423,11 @@ static inline phys_addr_t memblock_alloc(phys_addr_t size, phys_addr_t align)
 {
 	return 0;
 }
+static inline unsigned long memblock_next_valid_pfn(unsigned long pfn,
+						    unsigned long max_pfn)
+{
+	return pfn;
+}
 #endif /* CONFIG_HAVE_MEMBLOCK */
 
 #endif /* __KERNEL__ */
-- 
2.16.1

-- 
Cheers,
Stephen Rothwell

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

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

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (x86_64
allmodconfig) 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

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

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (powerpc
ppc64_defconfig) 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

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

[Stephen Rothwell]

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

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

[Dan Williams]

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.

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

[Stephen Rothwell]

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

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

[Dan Williams]

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.

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

[Stephen Rothwell]

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

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

[Mark Brown]

[-- 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 --]

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

[Zi Yan]

[-- 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 --]

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Zi Yan]

[-- 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 --]

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

[Andrew Morton]

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.

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

[Stephen Rothwell]

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

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

[Martin Wilck]

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)

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

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (x86_64
allmodconfig) 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

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

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (arm
multi_v7_defconfig) 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

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

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (arm
multi_v7_defconfig) 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

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

[Stephen Rothwell]

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

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

[Christoph Hellwig]

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

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

[Stephen Rothwell]

Hi all,

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

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

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

[Andrew Morton]

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>
_

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

Hi all,

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

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

[-- 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 --]

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

[Zi Yan]

[-- 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 --]

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

[Zi Yan]

[-- 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 --]

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (powerpc
ppc64_defconfig) 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

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

[Stephen Rothwell]

Hi all,

After merging the akpm-current tree, today's linux-next build (arm
multi_v7_defconfig) 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

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

[Kees Cook]

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

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

[Stephen Rothwell]

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

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

[Andrew Morton]

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.

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

[Stephen Rothwell]

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

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

[Kees Cook]

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

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

[Daniel Micay]

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.

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

[Kees Cook]

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

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

[Andrew Morton]

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?

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

[Kees Cook]

]

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

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

[Michael Ellerman]

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

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

[Daniel Micay]

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

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

[Daniel Micay]

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 ;).

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

[Kees Cook]

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

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

[Kees Cook]

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

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

[Daniel Micay]

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.

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Daniel Micay]

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.

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

[Kees Cook]

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

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

[Stephen Rothwell]

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

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

[Daniel Micay]

> 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.

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

[Daniel Micay]

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.

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

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (x86_64
allmodconfig) 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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Andrew Morton]

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.

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

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (arm
multi_v7_defconfig) 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

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

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (powerpc
ppc64_defconfig) 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

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

[Stephen Rothwell]

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

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

[Andrew Morton]

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...

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

[Stephen Rothwell]

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

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

[Eric Ren]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Andrew Morton]

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

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

[Eric Ren]

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 */

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Thiago Jung Bauermann]

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

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

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (powerpc
ppc64_defconfig) 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

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

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (x86_64
allmodconfig) 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

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

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (arm
multi_v7_defconfig) 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

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

[Andrew Morton]

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 :(

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

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (powerpc
ppc64_defconfig) 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

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

[Stephen Rothwell]

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

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

[Thiago Jung Bauermann]

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

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

[Stephen Rothwell]

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

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

[Thiago Jung Bauermann]

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

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

[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?

cheers

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (powerpc
ppc64_defconfig) 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

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

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (powerpc
ppc64_defconfig) 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

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

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (arm
multi_v7_defconfig) 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

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

[Stephen Rothwell]

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

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

[Thiago Jung Bauermann]

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

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

[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
-- 
2.8.1

-- 
Cheers,
Stephen Rothwell

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

[Stephen Rothwell]

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

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

[Paul Bolle]

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

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

[Josh Poimboeuf]

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

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

[Paul Bolle]

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

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

[Andrew Morton]

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

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

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (powerpc
ppc64_defconfig) 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

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

[Michael Ellerman]

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

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

[Stephen Rothwell]

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

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

[Andrew Morton]

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
_

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

[Stephen Rothwell]

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

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

[Aneesh Kumar K.V]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (x86_64
allmodconfig) 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

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

[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

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

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (arm
multi_v7_defconfig) 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

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

[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;
>  	}
> -- 

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

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (arm
multi_v7_defconfig) 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

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

[Stephen Rothwell]

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

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

[Andrew Morton]

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.

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

[Dave Hansen]

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>

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

[Dave Hansen]

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;
>                         };

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

[Stephen Rothwell]

Hi all,

After merging the akpm-current tree, today's linux-next build (arm
multi_v7_defconfig) 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

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

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (arm
multi_v7_defconfig) 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

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

[Jiri Kosina]

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

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

[Stephen Rothwell]

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

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

[Andrew Morton]

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?

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

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (x86_64
allmodconfig) 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

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

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (powerpc
ppc64_defconfig) 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

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

[Andrew Morton]

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);
_

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

[Sergey Senozhatsky]

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

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

[Sudip Mukherjee]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

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