Re: linux-next: build failure after merge of the akpm-current tree
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
> 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
>> Date: Thu, 18 Mar 2021 18:32:58 +1100
>> Subject: [PATCH] hack to make SPARC32 build
>>
>> Signed-off-by: Stephen Rothwell
>> ---
>> 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
Hi all,
On Thu, 18 Mar 2021 20:56:07 +1100 Stephen Rothwell
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
> Date: Thu, 18 Mar 2021 18:32:58 +1100
> Subject: [PATCH] hack to make SPARC32 build
>
> Signed-off-by: Stephen Rothwell
> ---
> 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
pgpCrBwxQIR66.pgp
Description: OpenPGP digital signature
linux-next: build failure after merge of the akpm-current tree
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
Date: Thu, 18 Mar 2021 18:32:58 +1100
Subject: [PATCH] hack to make SPARC32 build
Signed-off-by: Stephen Rothwell
---
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
pgpnwBfLYvs58.pgp
Description: OpenPGP digital signature
Re: [External] linux-next: build failure after merge of the akpm-current tree
On Wed, Mar 10, 2021 at 11:55 AM Stephen Rothwell wrote:
>
> 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
> 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
Sorry, it is my mistake. Thanks Stephen to fix this. This is the right fix.
> ---
> 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
> #include
> #include
> +#include
>
> #include
> #include
> --
> 2.30.0
>
> --
> Cheers,
> Stephen Rothwell
Re: linux-next: build failure after merge of the akpm-current tree
On Tue, Mar 9, 2021 at 7:16 PM Stephen Rothwell 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
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
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
---
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
#include
#include
+#include
#include
#include
--
2.30.0
--
Cheers,
Stephen Rothwell
pgpthJnpAQhuP.pgp
Description: OpenPGP digital signature
linux-next: build failure after merge of the akpm-current tree
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
pgpzjuF3qLtoc.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the akpm-current tree
Hi all,
On Tue, 2 Feb 2021 20:03:24 +1100 Stephen Rothwell
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
> 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
> ---
> 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
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
---
include/linux/mm.h | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git
Re: linux-next: build failure after merge of the akpm-current tree
On 2/3/21 2:22 PM, Arnd Bergmann wrote:
> On Wed, Feb 3, 2021 at 6:34 PM Randy Dunlap wrote:
>>
>> On 2/3/21 9:09 AM, Arnd Bergmann wrote:
>>> On Tue, Feb 2, 2021 at 10:12 AM Stephen Rothwell
>>> wrote:
>>>
983cb10d3f90 ("mm/gup: do not migrate zero page")
I have applied the following patch for today:
From: Stephen Rothwell
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
>>>
>>> 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=crsl5vhwkcevpsqsxwhsanvjsfnmerlt8vwt...@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
> > > > 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
Hi Pavel, On Wed, 3 Feb 2021 18:21:07 -0500 Pavel Tatashin 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 pgpgWT1_z_R5H.pgp Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the akpm-current tree
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 wrote: > > > > After the most recent build errors, I tried to apply Pavel's patch > > > > > > https://lore.kernel.org/linux-mm/CA+CK2bBjC8=crsl5vhwkcevpsqsxwhsanvjsfnmerlt8vwt...@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
> > After the most recent build errors, I tried to apply Pavel's patch > > > > https://lore.kernel.org/linux-mm/CA+CK2bBjC8=crsl5vhwkcevpsqsxwhsanvjsfnmerlt8vwt...@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
On Wed, Feb 3, 2021 at 6:34 PM Randy Dunlap wrote:
>
> On 2/3/21 9:09 AM, Arnd Bergmann wrote:
> > On Tue, Feb 2, 2021 at 10:12 AM Stephen Rothwell
> > wrote:
> >
> >>
> >> 983cb10d3f90 ("mm/gup: do not migrate zero page")
> >>
> >> I have applied the following patch for today:
> >>
> >> From: Stephen Rothwell
> >> 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
> >
> > 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=crsl5vhwkcevpsqsxwhsanvjsfnmerlt8vwt...@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
On 2/3/21 9:09 AM, Arnd Bergmann wrote:
> On Tue, Feb 2, 2021 at 10:12 AM Stephen Rothwell
> wrote:
>
>>
>> 983cb10d3f90 ("mm/gup: do not migrate zero page")
>>
>> I have applied the following patch for today:
>>
>> From: Stephen Rothwell
>> 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
>
> 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=crsl5vhwkcevpsqsxwhsanvjsfnmerlt8vwt...@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
On Tue, Feb 2, 2021 at 10:12 AM Stephen Rothwell wrote:
>
> 983cb10d3f90 ("mm/gup: do not migrate zero page")
>
> I have applied the following patch for today:
>
> From: Stephen Rothwell
> 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
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
Hi Pavel,
On Tue, Feb 2, 2021 at 1:34 PM Pavel Tatashin wrote:
> The fix is here:
> https://lore.kernel.org/linux-mm/CA+CK2bBjC8=crsl5vhwkcevpsqsxwhsanvjsfnmerlt8vwt...@mail.gmail.com/
Thanks, that fixed the m68k/m5272c3_defconfig build.
> On Tue, Feb 2, 2021 at 5:35 AM Geert Uytterhoeven
> wrote:
> > On Tue, Feb 2, 2021 at 10:13 AM Stephen Rothwell
> > 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, nore...@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 -- ge...@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
Hi Geert,
The fix is here:
https://lore.kernel.org/linux-mm/CA+CK2bBjC8=crsl5vhwkcevpsqsxwhsanvjsfnmerlt8vwt...@mail.gmail.com/
Thank you,
Pasha
On Tue, Feb 2, 2021 at 5:35 AM Geert Uytterhoeven wrote:
>
> On Tue, Feb 2, 2021 at 10:13 AM Stephen Rothwell
> 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, nore...@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 --
> ge...@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
On Tue, Feb 2, 2021 at 10:13 AM Stephen Rothwell 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, nore...@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 -- ge...@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
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
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
---
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
pgpcCXxKFUhO1.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the akpm-current tree
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
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
Date: Wed, 27 Jan 2021 23:10:31 +1100
Subject: [PATCH] ramfs-support-O_TMPFILE-fix
Signed-off-by: Stephen Rothwell
---
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
pgp0yQKLkAwcg.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the akpm-current tree
Hi Dan,
On Tue, 19 Jan 2021 21:48:52 -0800 Dan Williams
wrote:
>
> On Tue, Jan 19, 2021 at 9:25 PM Stephen Rothwell
> 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/16619868.2787408.1710192276369197040.st...@dwillia2-desk3.amr.corp.intel.com
I have used that today instead of Randy's patch, thanks.
--
Cheers,
Stephen Rothwell
pgpdx5xZlPjYo.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the akpm-current tree
On Tue, Jan 19, 2021 at 9:25 PM Stephen Rothwell 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/16619868.2787408.1710192276369197040.st...@dwillia2-desk3.amr.corp.intel.com
linux-next: build failure after merge of the akpm-current tree
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
pgppfm3hBsTKn.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the akpm-current tree
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
> 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(>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
> > > Date: Mon, 21 Dec 2020 13:07:42 +1100
> > > Subject: [PATCH] kasan: fix memory leak of kasan quarantine fix
> > >
> > > Signed-off-by: Stephen Rothwell
> > > ---
> > > 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(_quarantine);
> > > if (q->offline) {
> > > - qlink_free(>quarantine_link, cache);
> > > + qlink_free(>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
Hi Kuan-Ying,
On Mon, 21 Dec 2020 10:31:38 +0800 Kuan-Ying Lee
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(>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
> > Date: Mon, 21 Dec 2020 13:07:42 +1100
> > Subject: [PATCH] kasan: fix memory leak of kasan quarantine fix
> >
> > Signed-off-by: Stephen Rothwell
> > ---
> > 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(_quarantine);
> > if (q->offline) {
> > - qlink_free(>quarantine_link, cache);
> > + qlink_free(>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
pgpb1ZjqSx570.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the akpm-current tree
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(>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
> Date: Mon, 21 Dec 2020 13:07:42 +1100
> Subject: [PATCH] kasan: fix memory leak of kasan quarantine fix
>
> Signed-off-by: Stephen Rothwell
> ---
> 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(_quarantine);
> if (q->offline) {
> - qlink_free(>quarantine_link, cache);
> + qlink_free(>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=160820751825252=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(>quarantine_link, cache);
+ qlink_free(>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(_quarantine);
if (q->offline) {
- qlink_free(>quarantine_link, cache);
local_irq_restore(flags);
- return;
+ return false;
}
Thanks a lot.
linux-next: build failure after merge of the akpm-current tree
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(>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
Date: Mon, 21 Dec 2020 13:07:42 +1100
Subject: [PATCH] kasan: fix memory leak of kasan quarantine fix
Signed-off-by: Stephen Rothwell
---
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(_quarantine);
if (q->offline) {
- qlink_free(>quarantine_link, cache);
+ qlink_free(>quarantine_link, cache);
local_irq_restore(flags);
return false;
}
--
2.29.2
--
Cheers,
Stephen Rothwell
pgpPhmdQ06BmE.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the akpm-current tree
On Thu, 3 Dec 2020 at 09:37, Rui Salvaterra 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
Hi, Stephen,
On Thu, 3 Dec 2020 at 09:08, Stephen Rothwell 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
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] &&
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] &&
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] &&
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] &&
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] &&
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
pgpIrFMrEYfRQ.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the akpm-current tree
On Wed, Nov 4, 2020 at 9:05 PM Stephen Rothwell 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
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
pgp_GIk95QpB_.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the akpm-current tree
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
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
Date: Thu, 29 Oct 2020 15:03:58 +1100
Subject: [PATCH] kernel.h: Split out mathematical helpers fix
Signed-off-by: Stephen Rothwell
---
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
#include
#include
+#include
/* Not needed on 64bit architectures */
#if BITS_PER_LONG == 32
--
2.28.0
--
Cheers,
Stephen Rothwell
pgprkWI50y3Fr.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the akpm-current tree
On Fri, Oct 16, 2020 at 12:45 PM Miklos Szeredi 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
On Thu, Sep 24, 2020 at 3:40 AM Williams, Dan J
wrote:
>
> On Tue, 2020-09-08 at 20:09 +1000, Stephen Rothwell wrote:
[...]
> > From: Stephen Rothwell
> > 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
> > ---
> > 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
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
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
---
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
pgpzFDPUF8rD4.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the akpm-current tree
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(_resource, >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(>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(>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
> 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
> ---
> 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
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(_resource, >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(>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(>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
> 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
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
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
> 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
> ---
> 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
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(_resource, >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(>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(>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
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
---
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(_resource, >res,
+ ret = allocate_resource(_resource, ,
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()
Re: linux-next: build failure after merge of the akpm-current tree
Hi Mike,
On Thu, 27 Aug 2020 15:45:49 +0300 Mike Rapoport 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" .
>
> Here's the fix:
>
> From 9e46da6793528e35883ff81835d65a864bf98007 Mon Sep 17 00:00:00 2001
> From: Mike Rapoport
> 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
pgpfacfX9KHqF.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the akpm-current tree
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" .
Here's the fix:
>From 9e46da6793528e35883ff81835d65a864bf98007 Mon Sep 17 00:00:00 2001
From: Mike Rapoport
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" .
Signed-off-by: Mike Rapoport
---
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, , ) {
/* These addresses map low for PCI. */
- if (mem->base > 0x41000ull && !OCTEON_IS_OCTEON2())
+ if (start > 0x41000ull && !OCTEON_IS_OCTEON2())
continue;
addr_size += (end - start);
--
2.26.2
linux-next: build failure after merge of the akpm-current tree
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" .
--
Cheers,
Stephen Rothwell
pgpQmbmNOR09Y.pgp
Description: OpenPGP digital signature
linux-next: build failure after merge of the akpm-current tree
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
Date: Tue, 25 Aug 2020 17:17:12 +1000
Subject: [PATCH] ARCH_PAGE_TABLE_SYNC_MASK needs vmalloc.h
Signed-off-by: Stephen Rothwell
---
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
#include
#include
+#include
#include
--
2.28.0
--
Cheers,
Stephen Rothwell
pgp67aUo054p4.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the akpm-current tree
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
> Date: Tue, 21 Jul 2020 20:44:57 +1000
> Subject: [PATCH] mm/hugetlb: better checks before using hugetlb_cma
>
> Signed-off-by: Stephen Rothwell
Thanks Stephen, sorry for missing that in review.
Acked-by: Mike Kravetz
--
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
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
Date: Tue, 21 Jul 2020 20:44:57 +1000
Subject: [PATCH] mm/hugetlb: better checks before using hugetlb_cma
Signed-off-by: Stephen Rothwell
---
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
pgpYO6CJhOrmu.pgp
Description: OpenPGP digital signature
linux-next: build failure after merge of the akpm-current tree
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
pgpPGW1xA3Uhq.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the akpm-current tree
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-9a282b2a9...@infradead.org/
--
Kees Cook
linux-next: build failure after merge of the akpm-current tree
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
pgpSD2N10sP4u.pgp
Description: OpenPGP digital signature
linux-next: build failure after merge of the akpm-current tree
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
pgpQxfzfI3IKY.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the akpm-current tree
Hi Andrew,
On Tue, 9 Jun 2020 21:01:37 -0700 Andrew Morton
wrote:
>
> I've sent this in as well:
>
> From: Andrew Morton
> 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
> Cc: Mike Rapoport
> Cc: Johannes Weiner
> Signed-off-by: Andrew Morton
> ---
>
> 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 *)_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
pgpPtEe8sVM2t.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the akpm-current tree
On Wed, 10 Jun 2020 13:44:25 +1000 Stephen Rothwell
wrote:
> Hi all,
>
> On Tue, 9 Jun 2020 22:42:52 +1000 Stephen Rothwell
> 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
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
Cc: Mike Rapoport
Cc: Johannes Weiner
Signed-off-by: Andrew Morton
---
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 *)_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
Hi all,
On Tue, 9 Jun 2020 22:42:52 +1000 Stephen Rothwell
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
pgp0vemaS42R5.pgp
Description: OpenPGP digital signature
linux-next: build failure after merge of the akpm-current tree
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
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
---
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 *)_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
pgpIgBgiZlmo2.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the akpm-current tree
On Fri, 8 May 2020 07:51:23 -0700 Ira Weiny 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
On Thu, May 07, 2020 at 07:08:08PM -0700, Andrew Morton wrote:
> On Fri, 8 May 2020 11:43:38 +1000 Stephen Rothwell
> wrote:
>
> > Hi all,
> >
> > On Thu, 7 May 2020 22:17:21 +1000 Stephen Rothwell
> > 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
> Subject: arch-kunmap-remove-duplicate-kunmap-implementations-fix
>
> fix CONFIG_HIGHMEM=n build on various architectures
>
Reviewed-by: Ira Weiny
This should probably be squashed into that patch though...
Andrew do you want a V3.1?
Ira
> Reported-by: Stephen Rothwell
> Cc: Ira Weiny
> Signed-off-by: Andrew Morton
> ---
>
> 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
Hi Andrew,
On Thu, 7 May 2020 19:08:08 -0700 Andrew Morton
wrote:
>
> This? It's based on Ira's v3 series but should work.
>
>
> From: Andrew Morton
> Subject: arch-kunmap-remove-duplicate-kunmap-implementations-fix
>
> fix CONFIG_HIGHMEM=n build on various architectures
>
> Reported-by: Stephen Rothwell
> Cc: Ira Weiny
> Signed-off-by: Andrew Morton
> ---
>
> 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
pgpoD05LFTNzL.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the akpm-current tree
On Fri, 8 May 2020 11:43:38 +1000 Stephen Rothwell
wrote:
> Hi all,
>
> On Thu, 7 May 2020 22:17:21 +1000 Stephen Rothwell
> 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
Subject: arch-kunmap-remove-duplicate-kunmap-implementations-fix
fix CONFIG_HIGHMEM=n build on various architectures
Reported-by: Stephen Rothwell
Cc: Ira Weiny
Signed-off-by: Andrew Morton
---
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
Hi all,
On Thu, 7 May 2020 22:17:21 +1000 Stephen Rothwell
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
pgp1_OMC2YqmT.pgp
Description: OpenPGP digital signature
linux-next: build failure after merge of the akpm-current tree
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
pgpUamlcOhi1c.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the akpm-current tree
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
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, _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, _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, _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, _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, _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, _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
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
---
mm/madvise.c | 24 ++--
1 file changed, 10 insertions(+), 14 deletions(-)
diff --git a/mm/madvise.c b/mm/madvise.c
index
Re: linux-next: build failure after merge of the akpm-current tree
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
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
pgpMUCH5Tte66.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the akpm-current tree
Hi Stephen,
> On Aug 7, 2019, at 12:24 AM, 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/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
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
pgph5VGQgzDpW.pgp
Description: OpenPGP digital signature
linux-next: build failure after merge of the akpm-current tree
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
pgpKDVvsTj1xV.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the akpm-current tree
On Fri, 12 Jul 2019 12:59:45 +0200 Arnd Bergmann wrote:
> On Thu, Jul 11, 2019 at 2:41 AM Andrew Morton
> wrote:
> >
> >
> > From: Yang Shi
> > 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
On Thu, Jul 11, 2019 at 2:41 AM Andrew Morton wrote:
>
>
> From: Yang Shi
> 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
On Wed, 10 Jul 2019 09:05:09 +0200 Michal Hocko 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.ca...@lca.pw.
From: Yang Shi
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.
[a...@linux-foundation.org: fix build]
Link: http://lkml.kernel.org/r/201907052120.ogyphvno%...@intel.com
[shy828...@gmail.com: fixes]
Link:
http://lkml.kernel.org/r/cahblzkr8h0t+2xs6f7htkzfdkdbsd5f4z-aat+cda-uvwsk...@mail.gmail.com
[a...@linux-foundation.org: coding style fixes]
[a...@linux-foundation.org: build fix]
Link:
http://lkml.kernel.org/r/1561507361-59349-4-git-send-email-yang@linux.alibaba.com
Signed-off-by: Yang Shi
Acked-by: Kirill A. Shutemov
Cc: Kirill Tkhai
Cc: Johannes Weiner
Cc: Michal Hocko
Cc: "Kirill A . Shutemov"
Cc: Hugh Dickins
Cc: Shakeel Butt
Cc: David Rientjes
Cc: Randy Dunlap
Signed-off-by: Andrew Morton
---
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(_idr, id);
up_write(_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(_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(, shrinker, priority);
if (ret == SHRINK_EMPTY) {
clear_bit(i, map->map);
@@ -649,13 +651,13 @@ unlock:
up_read(_rwsem);
return freed;
}
-#else /* CONFIG_MEMCG_KMEM */
+#else /* CONFIG_MEMCG */
static unsigned long shrink_slab_memcg(gfp_t gfp_mask, int nid,
struct
Re: linux-next: build failure after merge of the akpm-current tree
On Tue 09-07-19 13:42:33, Andrew Morton wrote:
> On Tue, 9 Jul 2019 21:15:59 +1000 Stephen Rothwell
> 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
On Tue, 9 Jul 2019 21:15:59 +1000 Stephen Rothwell
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
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
pgp_MIkHw6YMg.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the akpm-current tree
Hi Marco, On Fri, 5 Jul 2019 11:27:58 +0200 Marco Elver 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 pgpUCMsz7_r0l.pgp Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the akpm-current tree
On Fri, 5 Jul 2019 at 10:49, 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/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
> Date: Fri, 5 Jul 2019 18:44:55 +1000
> Subject: [PATCH] mm/kasan: include types.h for "bool"
>
> Signed-off-by: Stephen Rothwell
> ---
> 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
> +
> /*
> * __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
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
Date: Fri, 5 Jul 2019 18:44:55 +1000
Subject: [PATCH] mm/kasan: include types.h for "bool"
Signed-off-by: Stephen Rothwell
---
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
+
/*
* __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
pgpGfUCPC_WSQ.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the akpm-current tree
Hi Christoph,
On Wed, 26 Jun 2019 15:13:18 +0200 Christoph Hellwig 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
pgpxa4ebx6NJA.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the akpm-current tree
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
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
pgplHwkrVZsFS.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the akpm-current tree
Hi Anshuman, On Wed, 26 Jun 2019 17:32:18 +0530 Anshuman Khandual 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 pgpwgjIozgXjL.pgp Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the akpm-current tree
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
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
pgpaTtAfHrEin.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the akpm-current tree
On Mon, 24 Jun 2019 21:00:43 +1000 Stephen Rothwell
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(>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(>mmap_sem);
> + lockdep_assert_held_write(>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
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(>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
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
---
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(>mmap_sem);
+ lockdep_assert_held_write(>mmap_sem);
locked_vm = mm->locked_vm;
if (inc) {
--
2.20.1
--
Cheers,
Stephen Rothwell
pgpcGFHqUCtlq.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the akpm-current tree
On Wed, Jun 19, 2019 at 7:06 PM Stephen Rothwell wrote:
>
> Hi all,
>
> After merging the akpm-current tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> In file included from 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
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
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
pgpS5kxzgn_wo.pgp
Description: OpenPGP digital signature
linux-next: build failure after merge of the akpm-current tree
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
pgpMNyYTg_lhr.pgp
Description: OpenPGP digital signature
linux-next: build failure after merge of the akpm-current tree
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
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
---
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
pgpR9mrwJNrK6.pgp
Description: OpenPGP digital signature
linux-next: build failure after merge of the akpm-current tree
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
pgpA8zZMaMTC3.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the akpm-current tree
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 wrote:
> >
> > On Wed, Apr 17, 2019 at 5:22 PM Kees Cook wrote:
> > >
> > > On Wed, Apr 17, 2019 at 1:53 AM Stephen Rothwell
> > > 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
> > > > 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
> > > > ---
> > > > 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
Hi Kees,
On Wed, 17 Apr 2019 17:28:39 -0500 Kees Cook wrote:
>
> On Wed, Apr 17, 2019 at 5:22 PM Kees Cook wrote:
> >
> > On Wed, Apr 17, 2019 at 1:53 AM Stephen Rothwell
> > 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
> > > 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
> > > ---
> > > 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
pgpATuAIcs8I4.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the akpm-current tree
On Wed, Apr 17, 2019 at 5:22 PM Kees Cook wrote:
>
> On Wed, Apr 17, 2019 at 1:53 AM Stephen Rothwell
> 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
> > 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
> > ---
> > 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
On Wed, Apr 17, 2019 at 5:28 PM Kees Cook wrote:
>
> On Wed, Apr 17, 2019 at 5:22 PM Kees Cook wrote:
> >
> > On Wed, Apr 17, 2019 at 1:53 AM Stephen Rothwell
> > 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
On Wed, Apr 17, 2019 at 1:53 AM Stephen Rothwell 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
> 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
> ---
> 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
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
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
---
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
pgpVPUw1Vy9NV.pgp
Description: OpenPGP digital signature
linux-next: build failure after merge of the akpm-current tree
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
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
---
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
pgpuf0CAJDrxW.pgp
Description: OpenPGP digital signature
