* linux-next: build failure after merge of the mm tree
@ 2022-09-23 8:12 Stephen Rothwell
2022-09-23 8:15 ` David Hildenbrand
0 siblings, 1 reply; 138+ messages in thread
From: Stephen Rothwell @ 2022-09-23 8:12 UTC (permalink / raw)
To: Andrew Morton
Cc: David Hildenbrand, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 561 bytes --]
Hi all,
After merging the mm tree, today's linux-next build (htmldocs) failed
like this:
Sphinx parallel build error:
docutils.utils.SystemMessage: /home/sfr/next/next/Documentation/process/coding-style.rst:1213: (SEVERE/4) Title level inconsistent:
Use WARN_ON_ONCE() rather than WARN() or WARN_ON()
**************************************************
Caused by commit
13ea678a035b ("coding-style.rst: document BUG() and WARN() rules ("do not crash the kernel")")
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2022-09-23 8:12 linux-next: build failure after merge of the mm tree Stephen Rothwell
@ 2022-09-23 8:15 ` David Hildenbrand
0 siblings, 0 replies; 138+ messages in thread
From: David Hildenbrand @ 2022-09-23 8:15 UTC (permalink / raw)
To: Stephen Rothwell, Andrew Morton
Cc: Linux Kernel Mailing List, Linux Next Mailing List
On 23.09.22 10:12, Stephen Rothwell wrote:
> Hi all,
>
> After merging the mm tree, today's linux-next build (htmldocs) failed
> like this:
>
> Sphinx parallel build error:
> docutils.utils.SystemMessage: /home/sfr/next/next/Documentation/process/coding-style.rst:1213: (SEVERE/4) Title level inconsistent:
>
> Use WARN_ON_ONCE() rather than WARN() or WARN_ON()
> **************************************************
>
> Caused by commit
>
> 13ea678a035b ("coding-style.rst: document BUG() and WARN() rules ("do not crash the kernel")")
>
> I have reverted that commit for today.
Thanks, an updated patch is already in the works as that issue has been
raised independently.
--
Thanks,
David / dhildenb
^ permalink raw reply [flat|nested] 138+ messages in thread
* linux-next: build failure after merge of the mm tree
@ 2024-04-12 6:39 Stephen Rothwell
0 siblings, 0 replies; 138+ messages in thread
From: Stephen Rothwell @ 2024-04-12 6:39 UTC (permalink / raw)
To: Andrew Morton
Cc: Barry Song, Chuanhua Han, Linux Kernel Mailing List,
Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1349 bytes --]
Hi all,
After merging the mm tree, today's linux-next build (x86_64 allnoconfig)
failed like this:
In file included from include/linux/suspend.h:5,
from arch/x86/kernel/asm-offsets.c:14:
include/linux/swap.h:568:6: warning: no previous prototype for 'swap_free_nr' [-Wmissing-prototypes]
568 | void swap_free_nr(swp_entry_t entry, int nr_pages)
| ^~~~~~~~~~~~
(lots of these)
Caused by commit
ca23b4d4cae5 ("mm: swap: introduce swap_free_nr() for batched swap_free()")
from the mm-unstable branch of the mm tree.
I have applied the following patch for today.
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 12 Apr 2024 16:25:26 +1000
Subject: [PATCH] fixup for "mm: swap: introduce swap_free_nr() for batched
swap_free()"
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
include/linux/swap.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/swap.h b/include/linux/swap.h
index b7a107e983b8..d1d35e92d7e9 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -565,7 +565,7 @@ static inline void swap_free(swp_entry_t swp)
{
}
-void swap_free_nr(swp_entry_t entry, int nr_pages)
+static inline void swap_free_nr(swp_entry_t entry, int nr_pages)
{
}
--
2.43.0
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 138+ messages in thread
* linux-next: build failure after merge of the mm tree
@ 2024-04-11 23:14 Stephen Rothwell
0 siblings, 0 replies; 138+ messages in thread
From: Stephen Rothwell @ 2024-04-11 23:14 UTC (permalink / raw)
To: Andrew Morton
Cc: Barry Song, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1869 bytes --]
Hi all,
After merging the mm tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
mm/memory.c: In function 'do_swap_page':
mm/memory.c:4169:17: error: implicit declaration of function 'count_mthp_stat' [-Werror=implicit-function-declaration]
4169 | count_mthp_stat(folio_order(folio), MTHP_STAT_ANON_SWPIN_REFAULT);
| ^~~~~~~~~~~~~~~
mm/memory.c:4169:53: error: 'MTHP_STAT_ANON_SWPIN_REFAULT' undeclared (first use in this function)
4169 | count_mthp_stat(folio_order(folio), MTHP_STAT_ANON_SWPIN_REFAULT);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
mm/memory.c:4169:53: note: each undeclared identifier is reported only once for each function it appears in
cc1: some warnings being treated as errors
Caused by commits
d46de7357458 ("mm: add per-order mTHP anon_alloc and anon_alloc_fallback counters")
37a4ecbf36cb ("mm: add per-order mTHP swpin_refault counter")
I have applied the following patch for today:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 12 Apr 2024 09:11:42 +1000
Subject: [PATCH] fix up for ""mm: add per-order mTHP anon_alloc and
anon_alloc_fallback counters"
and "mm: add per-order mTHP swpin_refault counter"
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
mm/memory.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mm/memory.c b/mm/memory.c
index b6fa5146b260..b3c33a76bcfa 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -4166,7 +4166,9 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
nr_pages = nr;
entry = folio->swap;
page = &folio->page;
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
count_mthp_stat(folio_order(folio), MTHP_STAT_ANON_SWPIN_REFAULT);
+#endif
}
check_pte:
--
2.43.0
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2024-04-07 23:15 Stephen Rothwell
@ 2024-04-08 1:44 ` Barry Song
0 siblings, 0 replies; 138+ messages in thread
From: Barry Song @ 2024-04-08 1:44 UTC (permalink / raw)
To: sfr; +Cc: akpm, linux-kernel, linux-next, v-songbaohua
>
> Hi all,
>
> After merging the mm tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> In file included from include/linux/mm.h:1115,
> from include/linux/mman.h:5,
> from arch/powerpc/kernel/asm-offsets.c:19:
> include/linux/huge_mm.h:276:23: error: variably modified 'stats' at file scope
> 276 | unsigned long stats[PMD_ORDER + 1][__MTHP_STAT_COUNT];
> | ^~~~~
>
> Caused by commit
>
> d4358ee0a075 ("mm: add per-order mTHP anon_alloc and anon_alloc_fallback counters")
>
> from the mm-unstable branch of the mm tree.
>
> PMD_ORDER is not necessarily constant on PowerPC (since it depends on
> PTE_INDEX_SIZE).
Thanks!
There is a fix and tested by LTP, Yujie [1].
https://lore.kernel.org/all/20240407042247.201412-1-21cnbao@gmail.com/
>
> I have reverted that commit (and the following one) for today.
Thanks
Barry
^ permalink raw reply [flat|nested] 138+ messages in thread
* linux-next: build failure after merge of the mm tree
@ 2024-04-07 23:15 Stephen Rothwell
2024-04-08 1:44 ` Barry Song
0 siblings, 1 reply; 138+ messages in thread
From: Stephen Rothwell @ 2024-04-07 23:15 UTC (permalink / raw)
To: Andrew Morton
Cc: Barry Song, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 803 bytes --]
Hi all,
After merging the mm tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
In file included from include/linux/mm.h:1115,
from include/linux/mman.h:5,
from arch/powerpc/kernel/asm-offsets.c:19:
include/linux/huge_mm.h:276:23: error: variably modified 'stats' at file scope
276 | unsigned long stats[PMD_ORDER + 1][__MTHP_STAT_COUNT];
| ^~~~~
Caused by commit
d4358ee0a075 ("mm: add per-order mTHP anon_alloc and anon_alloc_fallback counters")
from the mm-unstable branch of the mm tree.
PMD_ORDER is not necessarily constant on PowerPC (since it depends on
PTE_INDEX_SIZE).
I have reverted that commit (and the following one) for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* linux-next: build failure after merge of the mm tree
@ 2024-04-05 2:55 Stephen Rothwell
0 siblings, 0 replies; 138+ messages in thread
From: Stephen Rothwell @ 2024-04-05 2:55 UTC (permalink / raw)
To: Andrew Morton; +Cc: Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1740 bytes --]
Hi all,
After merging the mm tree, today's linux-next build (arm64 defconfig)
failed like this:
In file included from arch/arm64/include/asm/memory.h:213,
from arch/arm64/include/asm/page.h:46,
from include/linux/page_counter.h:8,
from mm/memcontrol.c:28:
mm/memcontrol.c: In function '__mod_memcg_lruvec_state':
include/linux/mmdebug.h:114:35: error: expected expression before 'do'
114 | #define VM_WARN_ON_IRQS_ENABLED() do { } while (0)
| ^~
mm/memcontrol.c:867:29: note: in expansion of macro 'VM_WARN_ON_IRQS_ENABLED'
867 | if (VM_WARN_ON_IRQS_ENABLED())
| ^~~~~~~~~~~~~~~~~~~~~~~
Caused by commit
e04f729678f6 ("__mod_memcg_lruvec_state(): enhance diagnostics")
from the mm-unstable branch of the mm tree.
I have applied the following patch for today.
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 5 Apr 2024 13:27:48 +1100
Subject: [PATCH] fix up for "__mod_memcg_lruvec_state(): enhance diagnostics"
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
mm/memcontrol.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 42f82259864f..91ac261877ec 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -864,8 +864,12 @@ void __mod_memcg_lruvec_state(struct lruvec *lruvec, enum node_stat_item idx,
pr_warn("stat item index: %d\n", idx);
break;
default:
+#ifdef CONFIG_DEBUG_VM_IRQSOFF
if (VM_WARN_ON_IRQS_ENABLED())
pr_warn("stat item index: %d\n", idx);
+#else
+ ;
+#endif
}
}
--
2.43.0
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 138+ messages in thread
* linux-next: build failure after merge of the mm tree
@ 2024-03-28 4:34 Stephen Rothwell
0 siblings, 0 replies; 138+ messages in thread
From: Stephen Rothwell @ 2024-03-28 4:34 UTC (permalink / raw)
To: Andrew Morton
Cc: Matthew Wilcox (Oracle),
Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1974 bytes --]
Hi all,
After merging the mm tree, today's linux-next build (arm64 defconfig)
failed like this:
In file included from include/linux/hugetlb.h:828,
from fs/proc/task_mmu.c:4:
arch/arm64/include/asm/hugetlb.h:25:34: error: redefinition of 'arch_clear_hugetlb_flags'
25 | #define arch_clear_hugetlb_flags arch_clear_hugetlb_flags
| ^~~~~~~~~~~~~~~~~~~~~~~~
include/linux/hugetlb.h:840:20: note: in expansion of macro 'arch_clear_hugetlb_flags'
840 | static inline void arch_clear_hugetlb_flags(struct folio *folio) { }
| ^~~~~~~~~~~~~~~~~~~~~~~~
arch/arm64/include/asm/hugetlb.h:21:20: note: previous definition of 'arch_clear_hugetlb_flags' with type 'void(struct folio *)'
21 | static inline void arch_clear_hugetlb_flags(struct folio *folio)
| ^~~~~~~~~~~~~~~~~~~~~~~~
Caused by commit
34ffd5e56690 ("mm: convert arch_clear_hugepage_flags to take a folio")
from the mm-unstable branch of the mm tree.
I applied the following patch:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 28 Mar 2024 15:24:47 +1100
Subject: [PATCH] fix up for "mm: convert arch_clear_hugepage_flags to take a folio"
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
include/linux/hugetlb.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index cc420c42a773..03fc6d625068 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -836,7 +836,7 @@ static inline int is_hugepage_only_range(struct mm_struct *mm,
#define is_hugepage_only_range is_hugepage_only_range
#endif
-#ifndef arch_clear_hugepage_flags
+#ifndef arch_clear_hugetlb_flags
static inline void arch_clear_hugetlb_flags(struct folio *folio) { }
#define arch_clear_hugetlb_flags arch_clear_hugetlb_flags
#endif
--
2.43.0
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2024-03-05 4:26 Stephen Rothwell
@ 2024-03-05 6:39 ` Qi Zheng
0 siblings, 0 replies; 138+ messages in thread
From: Qi Zheng @ 2024-03-05 6:39 UTC (permalink / raw)
To: Stephen Rothwell, Andrew Morton
Cc: Linux Kernel Mailing List, Linux Next Mailing List
On 2024/3/5 12:26, Stephen Rothwell wrote:
> Hi all,
>
> After merging the mm tree, today's linux-next build (s390 defconfig)
> failed like this:
>
> In file included from include/linux/smp.h:12,
> from include/linux/lockdep.h:14,
> from include/linux/spinlock.h:63,
> from include/linux/mmzone.h:8,
> from include/linux/gfp.h:7,
> from include/linux/mm.h:7,
> from include/linux/pagewalk.h:5,
> from arch/s390/mm/gmap.c:12:
> arch/s390/mm/gmap.c: In function 'gmap_free':
> include/linux/list.h:866:19: error: assignment to 'struct page *' from incompatible pointer type 'struct ptdesc *' [-Werror=incompatible-pointer-types]
> 866 | n = list_next_entry(pos, member); \
> | ^
> arch/s390/mm/gmap.c:212:17: note: in expansion of macro 'list_for_each_entry_safe'
> 212 | list_for_each_entry_safe(ptdesc, next, &gmap->pt_list, pt_list)
> | ^~~~~~~~~~~~~~~~~~~~~~~~
> include/linux/list.h:868:18: error: assignment to 'struct ptdesc *' from incompatible pointer type 'struct page *' [-Werror=incompatible-pointer-types]
> 868 | pos = n, n = list_next_entry(n, member))
> | ^
> arch/s390/mm/gmap.c:212:17: note: in expansion of macro 'list_for_each_entry_safe'
> 212 | list_for_each_entry_safe(ptdesc, next, &gmap->pt_list, pt_list)
> | ^~~~~~~~~~~~~~~~~~~~~~~~
> In file included from include/linux/kernel.h:22,
> from arch/s390/mm/gmap.c:11:
> arch/s390/mm/gmap.c:212:72: error: 'struct page' has no member named 'pt_list'; did you mean 'pcp_list'?
> 212 | list_for_each_entry_safe(ptdesc, next, &gmap->pt_list, pt_list)
> | ^~~~~~~
> include/linux/container_of.h:19:33: note: in definition of macro 'container_of'
> 19 | void *__mptr = (void *)(ptr); \
> | ^~~
> include/linux/list.h:645:9: note: in expansion of macro 'list_entry'
> 645 | list_entry((pos)->member.next, typeof(*(pos)), member)
> | ^~~~~~~~~~
> include/linux/list.h:868:27: note: in expansion of macro 'list_next_entry'
> 868 | pos = n, n = list_next_entry(n, member))
> | ^~~~~~~~~~~~~~~
> arch/s390/mm/gmap.c:212:17: note: in expansion of macro 'list_for_each_entry_safe'
> 212 | list_for_each_entry_safe(ptdesc, next, &gmap->pt_list, pt_list)
> | ^~~~~~~~~~~~~~~~~~~~~~~~
> In file included from include/linux/container_of.h:5:
> arch/s390/mm/gmap.c:212:72: error: 'struct page' has no member named 'pt_list'; did you mean 'pcp_list'?
> 212 | list_for_each_entry_safe(ptdesc, next, &gmap->pt_list, pt_list)
> | ^~~~~~~
> include/linux/build_bug.h:78:56: note: in definition of macro '__static_assert'
> 78 | #define __static_assert(expr, msg, ...) _Static_assert(expr, msg)
> | ^~~~
> include/linux/container_of.h:20:9: note: in expansion of macro 'static_assert'
> 20 | static_assert(__same_type(*(ptr), ((type *)0)->member) || \
> | ^~~~~~~~~~~~~
> include/linux/container_of.h:20:23: note: in expansion of macro '__same_type'
> 20 | static_assert(__same_type(*(ptr), ((type *)0)->member) || \
> | ^~~~~~~~~~~
> include/linux/list.h:601:9: note: in expansion of macro 'container_of'
> 601 | container_of(ptr, type, member)
> | ^~~~~~~~~~~~
> include/linux/list.h:645:9: note: in expansion of macro 'list_entry'
> 645 | list_entry((pos)->member.next, typeof(*(pos)), member)
> | ^~~~~~~~~~
> include/linux/list.h:868:27: note: in expansion of macro 'list_next_entry'
> 868 | pos = n, n = list_next_entry(n, member))
> | ^~~~~~~~~~~~~~~
> arch/s390/mm/gmap.c:212:17: note: in expansion of macro 'list_for_each_entry_safe'
> 212 | list_for_each_entry_safe(ptdesc, next, &gmap->pt_list, pt_list)
> | ^~~~~~~~~~~~~~~~~~~~~~~~
> arch/s390/mm/gmap.c:212:72: error: 'struct page' has no member named 'pt_list'; did you mean 'pcp_list'?
> 212 | list_for_each_entry_safe(ptdesc, next, &gmap->pt_list, pt_list)
> | ^~~~~~~
> include/linux/build_bug.h:78:56: note: in definition of macro '__static_assert'
> 78 | #define __static_assert(expr, msg, ...) _Static_assert(expr, msg)
> | ^~~~
> include/linux/container_of.h:20:9: note: in expansion of macro 'static_assert'
> 20 | static_assert(__same_type(*(ptr), ((type *)0)->member) || \
> | ^~~~~~~~~~~~~
> include/linux/container_of.h:20:23: note: in expansion of macro '__same_type'
> 20 | static_assert(__same_type(*(ptr), ((type *)0)->member) || \
> | ^~~~~~~~~~~
> include/linux/list.h:601:9: note: in expansion of macro 'container_of'
> 601 | container_of(ptr, type, member)
> | ^~~~~~~~~~~~
> include/linux/list.h:645:9: note: in expansion of macro 'list_entry'
> 645 | list_entry((pos)->member.next, typeof(*(pos)), member)
> | ^~~~~~~~~~
> include/linux/list.h:868:27: note: in expansion of macro 'list_next_entry'
> 868 | pos = n, n = list_next_entry(n, member))
> | ^~~~~~~~~~~~~~~
> arch/s390/mm/gmap.c:212:17: note: in expansion of macro 'list_for_each_entry_safe'
> 212 | list_for_each_entry_safe(ptdesc, next, &gmap->pt_list, pt_list)
> | ^~~~~~~~~~~~~~~~~~~~~~~~
> arch/s390/mm/gmap.c:212:72: error: 'struct page' has no member named 'pt_list'; did you mean 'pcp_list'?
> 212 | list_for_each_entry_safe(ptdesc, next, &gmap->pt_list, pt_list)
> | ^~~~~~~
> include/linux/build_bug.h:78:56: note: in definition of macro '__static_assert'
> 78 | #define __static_assert(expr, msg, ...) _Static_assert(expr, msg)
> | ^~~~
> include/linux/container_of.h:20:9: note: in expansion of macro 'static_assert'
> 20 | static_assert(__same_type(*(ptr), ((type *)0)->member) || \
> | ^~~~~~~~~~~~~
> include/linux/container_of.h:21:23: note: in expansion of macro '__same_type'
> 21 | __same_type(*(ptr), void), \
> | ^~~~~~~~~~~
> include/linux/list.h:601:9: note: in expansion of macro 'container_of'
> 601 | container_of(ptr, type, member)
> | ^~~~~~~~~~~~
> include/linux/list.h:645:9: note: in expansion of macro 'list_entry'
> 645 | list_entry((pos)->member.next, typeof(*(pos)), member)
> | ^~~~~~~~~~
> include/linux/list.h:868:27: note: in expansion of macro 'list_next_entry'
> 868 | pos = n, n = list_next_entry(n, member))
> | ^~~~~~~~~~~~~~~
> arch/s390/mm/gmap.c:212:17: note: in expansion of macro 'list_for_each_entry_safe'
> 212 | list_for_each_entry_safe(ptdesc, next, &gmap->pt_list, pt_list)
> | ^~~~~~~~~~~~~~~~~~~~~~~~
> include/linux/compiler_types.h:390:27: error: expression in static assertion is not an integer
> 390 | #define __same_type(a, b) __builtin_types_compatible_p(typeof(a), typeof(b))
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
> include/linux/build_bug.h:78:56: note: in definition of macro '__static_assert'
> 78 | #define __static_assert(expr, msg, ...) _Static_assert(expr, msg)
> | ^~~~
> include/linux/container_of.h:20:9: note: in expansion of macro 'static_assert'
> 20 | static_assert(__same_type(*(ptr), ((type *)0)->member) || \
> | ^~~~~~~~~~~~~
> include/linux/container_of.h:20:23: note: in expansion of macro '__same_type'
> 20 | static_assert(__same_type(*(ptr), ((type *)0)->member) || \
> | ^~~~~~~~~~~
> include/linux/list.h:601:9: note: in expansion of macro 'container_of'
> 601 | container_of(ptr, type, member)
> | ^~~~~~~~~~~~
> include/linux/list.h:645:9: note: in expansion of macro 'list_entry'
> 645 | list_entry((pos)->member.next, typeof(*(pos)), member)
> | ^~~~~~~~~~
> include/linux/list.h:868:27: note: in expansion of macro 'list_next_entry'
> 868 | pos = n, n = list_next_entry(n, member))
> | ^~~~~~~~~~~~~~~
> arch/s390/mm/gmap.c:212:17: note: in expansion of macro 'list_for_each_entry_safe'
> 212 | list_for_each_entry_safe(ptdesc, next, &gmap->pt_list, pt_list)
> | ^~~~~~~~~~~~~~~~~~~~~~~~
> In file included from include/uapi/linux/posix_types.h:5,
> from include/uapi/linux/types.h:14,
> from include/linux/types.h:6,
> from include/linux/kasan-checks.h:5,
> from include/asm-generic/rwonce.h:26,
> from arch/s390/include/asm/rwonce.h:29,
> from include/linux/compiler.h:299,
> from include/linux/array_size.h:5,
> from include/linux/kernel.h:16:
> arch/s390/mm/gmap.c:212:72: error: 'struct page' has no member named 'pt_list'; did you mean 'pcp_list'?
> 212 | list_for_each_entry_safe(ptdesc, next, &gmap->pt_list, pt_list)
> | ^~~~~~~
> include/linux/stddef.h:16:58: note: in definition of macro 'offsetof'
> 16 | #define offsetof(TYPE, MEMBER) __builtin_offsetof(TYPE, MEMBER)
> | ^~~~~~
> include/linux/list.h:601:9: note: in expansion of macro 'container_of'
> 601 | container_of(ptr, type, member)
> | ^~~~~~~~~~~~
> include/linux/list.h:645:9: note: in expansion of macro 'list_entry'
> 645 | list_entry((pos)->member.next, typeof(*(pos)), member)
> | ^~~~~~~~~~
> include/linux/list.h:868:27: note: in expansion of macro 'list_next_entry'
> 868 | pos = n, n = list_next_entry(n, member))
> | ^~~~~~~~~~~~~~~
> arch/s390/mm/gmap.c:212:17: note: in expansion of macro 'list_for_each_entry_safe'
> 212 | list_for_each_entry_safe(ptdesc, next, &gmap->pt_list, pt_list)
> | ^~~~~~~~~~~~~~~~~~~~~~~~
> cc1: some warnings being treated as errors
Thanks for reporting that, will fix it:
diff --git a/arch/s390/mm/gmap.c b/arch/s390/mm/gmap.c
index 4d2674f89322..e43a5a3befd4 100644
--- a/arch/s390/mm/gmap.c
+++ b/arch/s390/mm/gmap.c
@@ -206,10 +206,10 @@ static void gmap_free(struct gmap *gmap)
/* Free additional data for a shadow gmap */
if (gmap_is_shadow(gmap)) {
- struct ptdesc *ptdesc;
+ struct ptdesc *ptdesc, *n;
/* Free all page tables. */
- list_for_each_entry_safe(ptdesc, next, &gmap->pt_list,
pt_list)
+ list_for_each_entry_safe(ptdesc, n, &gmap->pt_list, pt_list)
page_table_free_pgste(ptdesc);
gmap_rmap_radix_tree_free(&gmap->host_to_rmap);
/* Release reference to the parent */
>
> Caused by commit
>
> 859584c3ddba ("s390: supplement for ptdesc conversion")
>
> from the mm-unstable branch of the mm tree.
>
> I have reverted that commit for today.
^ permalink raw reply related [flat|nested] 138+ messages in thread
* linux-next: build failure after merge of the mm tree
@ 2024-03-05 4:26 Stephen Rothwell
2024-03-05 6:39 ` Qi Zheng
0 siblings, 1 reply; 138+ messages in thread
From: Stephen Rothwell @ 2024-03-05 4:26 UTC (permalink / raw)
To: Andrew Morton
Cc: Qi Zheng, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 11213 bytes --]
Hi all,
After merging the mm tree, today's linux-next build (s390 defconfig)
failed like this:
In file included from include/linux/smp.h:12,
from include/linux/lockdep.h:14,
from include/linux/spinlock.h:63,
from include/linux/mmzone.h:8,
from include/linux/gfp.h:7,
from include/linux/mm.h:7,
from include/linux/pagewalk.h:5,
from arch/s390/mm/gmap.c:12:
arch/s390/mm/gmap.c: In function 'gmap_free':
include/linux/list.h:866:19: error: assignment to 'struct page *' from incompatible pointer type 'struct ptdesc *' [-Werror=incompatible-pointer-types]
866 | n = list_next_entry(pos, member); \
| ^
arch/s390/mm/gmap.c:212:17: note: in expansion of macro 'list_for_each_entry_safe'
212 | list_for_each_entry_safe(ptdesc, next, &gmap->pt_list, pt_list)
| ^~~~~~~~~~~~~~~~~~~~~~~~
include/linux/list.h:868:18: error: assignment to 'struct ptdesc *' from incompatible pointer type 'struct page *' [-Werror=incompatible-pointer-types]
868 | pos = n, n = list_next_entry(n, member))
| ^
arch/s390/mm/gmap.c:212:17: note: in expansion of macro 'list_for_each_entry_safe'
212 | list_for_each_entry_safe(ptdesc, next, &gmap->pt_list, pt_list)
| ^~~~~~~~~~~~~~~~~~~~~~~~
In file included from include/linux/kernel.h:22,
from arch/s390/mm/gmap.c:11:
arch/s390/mm/gmap.c:212:72: error: 'struct page' has no member named 'pt_list'; did you mean 'pcp_list'?
212 | list_for_each_entry_safe(ptdesc, next, &gmap->pt_list, pt_list)
| ^~~~~~~
include/linux/container_of.h:19:33: note: in definition of macro 'container_of'
19 | void *__mptr = (void *)(ptr); \
| ^~~
include/linux/list.h:645:9: note: in expansion of macro 'list_entry'
645 | list_entry((pos)->member.next, typeof(*(pos)), member)
| ^~~~~~~~~~
include/linux/list.h:868:27: note: in expansion of macro 'list_next_entry'
868 | pos = n, n = list_next_entry(n, member))
| ^~~~~~~~~~~~~~~
arch/s390/mm/gmap.c:212:17: note: in expansion of macro 'list_for_each_entry_safe'
212 | list_for_each_entry_safe(ptdesc, next, &gmap->pt_list, pt_list)
| ^~~~~~~~~~~~~~~~~~~~~~~~
In file included from include/linux/container_of.h:5:
arch/s390/mm/gmap.c:212:72: error: 'struct page' has no member named 'pt_list'; did you mean 'pcp_list'?
212 | list_for_each_entry_safe(ptdesc, next, &gmap->pt_list, pt_list)
| ^~~~~~~
include/linux/build_bug.h:78:56: note: in definition of macro '__static_assert'
78 | #define __static_assert(expr, msg, ...) _Static_assert(expr, msg)
| ^~~~
include/linux/container_of.h:20:9: note: in expansion of macro 'static_assert'
20 | static_assert(__same_type(*(ptr), ((type *)0)->member) || \
| ^~~~~~~~~~~~~
include/linux/container_of.h:20:23: note: in expansion of macro '__same_type'
20 | static_assert(__same_type(*(ptr), ((type *)0)->member) || \
| ^~~~~~~~~~~
include/linux/list.h:601:9: note: in expansion of macro 'container_of'
601 | container_of(ptr, type, member)
| ^~~~~~~~~~~~
include/linux/list.h:645:9: note: in expansion of macro 'list_entry'
645 | list_entry((pos)->member.next, typeof(*(pos)), member)
| ^~~~~~~~~~
include/linux/list.h:868:27: note: in expansion of macro 'list_next_entry'
868 | pos = n, n = list_next_entry(n, member))
| ^~~~~~~~~~~~~~~
arch/s390/mm/gmap.c:212:17: note: in expansion of macro 'list_for_each_entry_safe'
212 | list_for_each_entry_safe(ptdesc, next, &gmap->pt_list, pt_list)
| ^~~~~~~~~~~~~~~~~~~~~~~~
arch/s390/mm/gmap.c:212:72: error: 'struct page' has no member named 'pt_list'; did you mean 'pcp_list'?
212 | list_for_each_entry_safe(ptdesc, next, &gmap->pt_list, pt_list)
| ^~~~~~~
include/linux/build_bug.h:78:56: note: in definition of macro '__static_assert'
78 | #define __static_assert(expr, msg, ...) _Static_assert(expr, msg)
| ^~~~
include/linux/container_of.h:20:9: note: in expansion of macro 'static_assert'
20 | static_assert(__same_type(*(ptr), ((type *)0)->member) || \
| ^~~~~~~~~~~~~
include/linux/container_of.h:20:23: note: in expansion of macro '__same_type'
20 | static_assert(__same_type(*(ptr), ((type *)0)->member) || \
| ^~~~~~~~~~~
include/linux/list.h:601:9: note: in expansion of macro 'container_of'
601 | container_of(ptr, type, member)
| ^~~~~~~~~~~~
include/linux/list.h:645:9: note: in expansion of macro 'list_entry'
645 | list_entry((pos)->member.next, typeof(*(pos)), member)
| ^~~~~~~~~~
include/linux/list.h:868:27: note: in expansion of macro 'list_next_entry'
868 | pos = n, n = list_next_entry(n, member))
| ^~~~~~~~~~~~~~~
arch/s390/mm/gmap.c:212:17: note: in expansion of macro 'list_for_each_entry_safe'
212 | list_for_each_entry_safe(ptdesc, next, &gmap->pt_list, pt_list)
| ^~~~~~~~~~~~~~~~~~~~~~~~
arch/s390/mm/gmap.c:212:72: error: 'struct page' has no member named 'pt_list'; did you mean 'pcp_list'?
212 | list_for_each_entry_safe(ptdesc, next, &gmap->pt_list, pt_list)
| ^~~~~~~
include/linux/build_bug.h:78:56: note: in definition of macro '__static_assert'
78 | #define __static_assert(expr, msg, ...) _Static_assert(expr, msg)
| ^~~~
include/linux/container_of.h:20:9: note: in expansion of macro 'static_assert'
20 | static_assert(__same_type(*(ptr), ((type *)0)->member) || \
| ^~~~~~~~~~~~~
include/linux/container_of.h:21:23: note: in expansion of macro '__same_type'
21 | __same_type(*(ptr), void), \
| ^~~~~~~~~~~
include/linux/list.h:601:9: note: in expansion of macro 'container_of'
601 | container_of(ptr, type, member)
| ^~~~~~~~~~~~
include/linux/list.h:645:9: note: in expansion of macro 'list_entry'
645 | list_entry((pos)->member.next, typeof(*(pos)), member)
| ^~~~~~~~~~
include/linux/list.h:868:27: note: in expansion of macro 'list_next_entry'
868 | pos = n, n = list_next_entry(n, member))
| ^~~~~~~~~~~~~~~
arch/s390/mm/gmap.c:212:17: note: in expansion of macro 'list_for_each_entry_safe'
212 | list_for_each_entry_safe(ptdesc, next, &gmap->pt_list, pt_list)
| ^~~~~~~~~~~~~~~~~~~~~~~~
include/linux/compiler_types.h:390:27: error: expression in static assertion is not an integer
390 | #define __same_type(a, b) __builtin_types_compatible_p(typeof(a), typeof(b))
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:78:56: note: in definition of macro '__static_assert'
78 | #define __static_assert(expr, msg, ...) _Static_assert(expr, msg)
| ^~~~
include/linux/container_of.h:20:9: note: in expansion of macro 'static_assert'
20 | static_assert(__same_type(*(ptr), ((type *)0)->member) || \
| ^~~~~~~~~~~~~
include/linux/container_of.h:20:23: note: in expansion of macro '__same_type'
20 | static_assert(__same_type(*(ptr), ((type *)0)->member) || \
| ^~~~~~~~~~~
include/linux/list.h:601:9: note: in expansion of macro 'container_of'
601 | container_of(ptr, type, member)
| ^~~~~~~~~~~~
include/linux/list.h:645:9: note: in expansion of macro 'list_entry'
645 | list_entry((pos)->member.next, typeof(*(pos)), member)
| ^~~~~~~~~~
include/linux/list.h:868:27: note: in expansion of macro 'list_next_entry'
868 | pos = n, n = list_next_entry(n, member))
| ^~~~~~~~~~~~~~~
arch/s390/mm/gmap.c:212:17: note: in expansion of macro 'list_for_each_entry_safe'
212 | list_for_each_entry_safe(ptdesc, next, &gmap->pt_list, pt_list)
| ^~~~~~~~~~~~~~~~~~~~~~~~
In file included from include/uapi/linux/posix_types.h:5,
from include/uapi/linux/types.h:14,
from include/linux/types.h:6,
from include/linux/kasan-checks.h:5,
from include/asm-generic/rwonce.h:26,
from arch/s390/include/asm/rwonce.h:29,
from include/linux/compiler.h:299,
from include/linux/array_size.h:5,
from include/linux/kernel.h:16:
arch/s390/mm/gmap.c:212:72: error: 'struct page' has no member named 'pt_list'; did you mean 'pcp_list'?
212 | list_for_each_entry_safe(ptdesc, next, &gmap->pt_list, pt_list)
| ^~~~~~~
include/linux/stddef.h:16:58: note: in definition of macro 'offsetof'
16 | #define offsetof(TYPE, MEMBER) __builtin_offsetof(TYPE, MEMBER)
| ^~~~~~
include/linux/list.h:601:9: note: in expansion of macro 'container_of'
601 | container_of(ptr, type, member)
| ^~~~~~~~~~~~
include/linux/list.h:645:9: note: in expansion of macro 'list_entry'
645 | list_entry((pos)->member.next, typeof(*(pos)), member)
| ^~~~~~~~~~
include/linux/list.h:868:27: note: in expansion of macro 'list_next_entry'
868 | pos = n, n = list_next_entry(n, member))
| ^~~~~~~~~~~~~~~
arch/s390/mm/gmap.c:212:17: note: in expansion of macro 'list_for_each_entry_safe'
212 | list_for_each_entry_safe(ptdesc, next, &gmap->pt_list, pt_list)
| ^~~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
Caused by commit
859584c3ddba ("s390: supplement for ptdesc conversion")
from the mm-unstable branch of the mm tree.
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2024-02-14 15:19 ` Andrew Morton
@ 2024-02-15 3:47 ` Stephen Rothwell
0 siblings, 0 replies; 138+ messages in thread
From: Stephen Rothwell @ 2024-02-15 3:47 UTC (permalink / raw)
To: Andrew Morton
Cc: Oscar Salvador, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1580 bytes --]
Hi Andrew,
On Wed, 14 Feb 2024 07:19:38 -0800 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Wed, 14 Feb 2024 14:57:19 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> > After merging the mm tree, today's linux-next build (sparc defconfig)
> > failed like this:
> >
> > In file included from include/linux/page_ext.h:7,
> > from include/linux/mm.h:22,
> > from fs/sysfs/file.c:18:
> > include/linux/stackdepot.h:59:39: error: 'CONFIG_STACKDEPOT_MAX_FRAMES' undeclared here (not in a function)
> > 59 | unsigned long entries[CONFIG_STACKDEPOT_MAX_FRAMES]; /* Frames */
> > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> > (and many more)
> >
> > Caused by commit
> >
> > 18d4230bb372 ("lib/stackdepot: move stack_record struct definition into the header")
>
> Thanks, I'll try this.
>
>
> --- a/include/linux/stackdepot.h~lib-stackdepot-move-stack_record-struct-definition-into-the-header-fix
> +++ a/include/linux/stackdepot.h
> @@ -39,6 +39,7 @@ typedef u32 depot_stack_handle_t;
> #define DEPOT_POOL_INDEX_BITS (DEPOT_HANDLE_BITS - DEPOT_OFFSET_BITS - \
> STACK_DEPOT_EXTRA_BITS)
>
> +#ifdef CONFIG_STACKDEPOT
> /* Compact structure that stores a reference to a stack. */
> union handle_parts {
> depot_stack_handle_t handle;
> @@ -73,6 +74,7 @@ struct stack_record {
> };
> };
> };
> +#endif
>
> typedef u32 depot_flags_t;
>
> _
>
Works for me.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2024-02-14 3:57 Stephen Rothwell
@ 2024-02-14 15:19 ` Andrew Morton
2024-02-15 3:47 ` Stephen Rothwell
0 siblings, 1 reply; 138+ messages in thread
From: Andrew Morton @ 2024-02-14 15:19 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Oscar Salvador, Linux Kernel Mailing List, Linux Next Mailing List
On Wed, 14 Feb 2024 14:57:19 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> After merging the mm tree, today's linux-next build (sparc defconfig)
> failed like this:
>
> In file included from include/linux/page_ext.h:7,
> from include/linux/mm.h:22,
> from fs/sysfs/file.c:18:
> include/linux/stackdepot.h:59:39: error: 'CONFIG_STACKDEPOT_MAX_FRAMES' undeclared here (not in a function)
> 59 | unsigned long entries[CONFIG_STACKDEPOT_MAX_FRAMES]; /* Frames */
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> (and many more)
>
> Caused by commit
>
> 18d4230bb372 ("lib/stackdepot: move stack_record struct definition into the header")
Thanks, I'll try this.
--- a/include/linux/stackdepot.h~lib-stackdepot-move-stack_record-struct-definition-into-the-header-fix
+++ a/include/linux/stackdepot.h
@@ -39,6 +39,7 @@ typedef u32 depot_stack_handle_t;
#define DEPOT_POOL_INDEX_BITS (DEPOT_HANDLE_BITS - DEPOT_OFFSET_BITS - \
STACK_DEPOT_EXTRA_BITS)
+#ifdef CONFIG_STACKDEPOT
/* Compact structure that stores a reference to a stack. */
union handle_parts {
depot_stack_handle_t handle;
@@ -73,6 +74,7 @@ struct stack_record {
};
};
};
+#endif
typedef u32 depot_flags_t;
_
^ permalink raw reply [flat|nested] 138+ messages in thread
* linux-next: build failure after merge of the mm tree
@ 2024-02-14 3:57 Stephen Rothwell
2024-02-14 15:19 ` Andrew Morton
0 siblings, 1 reply; 138+ messages in thread
From: Stephen Rothwell @ 2024-02-14 3:57 UTC (permalink / raw)
To: Andrew Morton
Cc: Oscar Salvador, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1696 bytes --]
Hi all,
After merging the mm tree, today's linux-next build (sparc defconfig)
failed like this:
In file included from include/linux/page_ext.h:7,
from include/linux/mm.h:22,
from fs/sysfs/file.c:18:
include/linux/stackdepot.h:59:39: error: 'CONFIG_STACKDEPOT_MAX_FRAMES' undeclared here (not in a function)
59 | unsigned long entries[CONFIG_STACKDEPOT_MAX_FRAMES]; /* Frames */
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
(and many more)
Caused by commit
18d4230bb372 ("lib/stackdepot: move stack_record struct definition into the header")
from the mm-unstable branch of the mm tree.
$ grep CONFIG_STACKDEPOT .config
$
I have reverted the following commits for today:
7e56cf9a7f10 ("mm: add swappiness= arg to memory.reclaim")
6290011d1ce1 ("mm: add defines for min/max swappiness")
afb37edbd1e3 ("mm: optimization on page allocation when CMA enabled")
0b222ac0b19c ("userfaultfd: use per-vma locks in userfaultfd operations")
f8b7d8e37cb3 ("userfaultfd: protect mmap_changing with rw_sem in userfaulfd_ctx")
cd8df983e066 ("userfaultfd: move userfaultfd_ctx struct to header file")
292f31cdb470 ("mm,page_owner: update Documentation regarding page_owner_stacks")
76d2da5f4805 ("mm,page_owner: filter out stacks by a threshold")
37781739c4ad ("mm,page_owner: display all stacks and their count")
525a88caf59c ("mm,page_owner: implement the tracking of the stacks count")
18d4230bb372 ("lib/stackdepot: move stack_record struct definition into the header")
(from 18d4230bb372 to the end of mm-unstable)
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* linux-next: build failure after merge of the mm tree
@ 2024-02-07 6:17 Stephen Rothwell
0 siblings, 0 replies; 138+ messages in thread
From: Stephen Rothwell @ 2024-02-07 6:17 UTC (permalink / raw)
To: Andrew Morton
Cc: Kairui Song, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1422 bytes --]
Hi all,
After merging the mm tree, today's linux-next build (x86_64 allnodconfig)
failed like this:
mm/memory.c: In function 'do_swap_page':
mm/memory.c:4004:29: error: implicit declaration of function 'swapcache_prepare'; did you mean 'swapcache_clear'? [-Werror=implicit-function-declaration]
4004 | if (swapcache_prepare(entry))
| ^~~~~~~~~~~~~~~~~
| swapcache_clear
Caused by commit
1fa5b77af107 ("mm/swap: fix race condition in direct swapin path")
from the mm-unstable branch of the mm tree.
# CONFIG_SWAP is not set
I have applied the following patch for today:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 7 Feb 2024 17:04:15 +1100
Subject: [PATCH] fix up for "mm/swap: fix race condition in direct swapin
path"
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
include/linux/swap.h | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/include/linux/swap.h b/include/linux/swap.h
index 768a9078070d..b4c389b9e4e0 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -552,6 +552,11 @@ static inline int swap_duplicate(swp_entry_t swp)
return 0;
}
+static inline int swapcache_prepare(swp_entry_t swp)
+{
+ return 0;
+}
+
static inline void swap_free(swp_entry_t swp)
{
}
--
2.43.0
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2024-02-01 2:57 Stephen Rothwell
@ 2024-02-01 8:35 ` Marco Elver
0 siblings, 0 replies; 138+ messages in thread
From: Marco Elver @ 2024-02-01 8:35 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Andrew Morton, Linux Kernel Mailing List, Linux Next Mailing List
On Thu, 1 Feb 2024 at 03:57, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> After merging the mm tree, today's linux-next build (i386 defconfig)
> failed like this:
>
> In file included from arch/x86/include/asm/string.h:3,
> from include/linux/string.h:61,
> from arch/x86/include/asm/page_32.h:18,
> from arch/x86/include/asm/page.h:14,
> from arch/x86/include/asm/thread_info.h:12,
> from include/linux/thread_info.h:60,
> from include/linux/spinlock.h:60,
> from include/linux/wait.h:9,
> from include/linux/wait_bit.h:8,
> from include/linux/fs.h:6,
> from include/linux/debugfs.h:15,
> from lib/stackdepot.c:17:
> In function 'depot_alloc_stack',
> inlined from 'stack_depot_save_flags' at lib/stackdepot.c:688:4:
> arch/x86/include/asm/string_32.h:150:25: error: '__builtin_memcpy' specified bound 4294967295 exceeds maximum object size 2147483647 [-Werror=stringop-overflow=]
> 150 | #define memcpy(t, f, n) __builtin_memcpy(t, f, n)
> | ^~~~~~~~~~~~~~~~~~~~~~~~~
> lib/stackdepot.c:459:9: note: in expansion of macro 'memcpy'
> 459 | memcpy(stack->entries, entries, flex_array_size(stack, entries, nr_entries));
> | ^~~~~~
> cc1: all warnings being treated as errors
This is a false positives due to -next enabling some new warnings by
default: https://lore.kernel.org/all/20240201083259.1734865-1-elver@google.com/T/#u
^ permalink raw reply [flat|nested] 138+ messages in thread
* linux-next: build failure after merge of the mm tree
@ 2024-02-01 2:57 Stephen Rothwell
2024-02-01 8:35 ` Marco Elver
0 siblings, 1 reply; 138+ messages in thread
From: Stephen Rothwell @ 2024-02-01 2:57 UTC (permalink / raw)
To: Andrew Morton
Cc: Marco Elver, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1599 bytes --]
Hi all,
After merging the mm tree, today's linux-next build (i386 defconfig)
failed like this:
In file included from arch/x86/include/asm/string.h:3,
from include/linux/string.h:61,
from arch/x86/include/asm/page_32.h:18,
from arch/x86/include/asm/page.h:14,
from arch/x86/include/asm/thread_info.h:12,
from include/linux/thread_info.h:60,
from include/linux/spinlock.h:60,
from include/linux/wait.h:9,
from include/linux/wait_bit.h:8,
from include/linux/fs.h:6,
from include/linux/debugfs.h:15,
from lib/stackdepot.c:17:
In function 'depot_alloc_stack',
inlined from 'stack_depot_save_flags' at lib/stackdepot.c:688:4:
arch/x86/include/asm/string_32.h:150:25: error: '__builtin_memcpy' specified bound 4294967295 exceeds maximum object size 2147483647 [-Werror=stringop-overflow=]
150 | #define memcpy(t, f, n) __builtin_memcpy(t, f, n)
| ^~~~~~~~~~~~~~~~~~~~~~~~~
lib/stackdepot.c:459:9: note: in expansion of macro 'memcpy'
459 | memcpy(stack->entries, entries, flex_array_size(stack, entries, nr_entries));
| ^~~~~~
cc1: all warnings being treated as errors
Presumably caused by commit
d869d3fb362c ("stackdepot: use variable size records for non-evictable entries")
from the mm-unstable branch of the mm tree.
I have reverted that commit and the following one for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2024-01-25 14:29 ` Baoquan He
@ 2024-01-25 18:03 ` Stephen Rothwell
0 siblings, 0 replies; 138+ messages in thread
From: Stephen Rothwell @ 2024-01-25 18:03 UTC (permalink / raw)
To: Baoquan He
Cc: Andrew Morton, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 361 bytes --]
Hi Baoquan,
On Thu, 25 Jan 2024 22:29:07 +0800 Baoquan He <bhe@redhat.com> wrote:
>
> I reproduced the failure with allnoconfig on ppc, and found below change
> can fix it too. And the change makes ARCH_SELECTS_KEXEC consistent with
> ARCH_SELECTS_KEXEC_FILE on the dependency. What do you think?
Makes sense to me.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2024-01-25 3:29 Stephen Rothwell
@ 2024-01-25 14:29 ` Baoquan He
2024-01-25 18:03 ` Stephen Rothwell
0 siblings, 1 reply; 138+ messages in thread
From: Baoquan He @ 2024-01-25 14:29 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Andrew Morton, Linux Kernel Mailing List, Linux Next Mailing List
Hi Stephen,
On 01/25/24 at 02:29pm, Stephen Rothwell wrote:
......
> Caused by commit
>
> 9dc830523e4e ("ppc, crash: enforce KEXEC and KEXEC_FILE to select CRASH_DUMP")
>
> I have applied the following patch:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 25 Jan 2024 14:20:51 +1100
> Subject: [PATCH] fix up for "ppc, crash: enforce KEXEC and KEXEC_FILE to
> select CRASH_DUMP"
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> arch/powerpc/Kconfig | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 31f013e636e3..e7707bebc061 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -610,6 +610,8 @@ config ARCH_SUPPORTS_KEXEC
>
> config ARCH_SELECTS_KEXEC
> def_bool y
> + depends on ARCH_SUPPORTS_CRASH_DUMP
> + depends on KEXEC_CORE
> select CRASH_DUMP
>
> config ARCH_SUPPORTS_KEXEC_FILE
Thanks for the work.
I reproduced the failure with allnoconfig on ppc, and found below change
can fix it too. And the change makes ARCH_SELECTS_KEXEC consistent with
ARCH_SELECTS_KEXEC_FILE on the dependency. What do you think?
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 31f013e636e3..79f98cd5f2c9 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -610,6 +610,7 @@ config ARCH_SUPPORTS_KEXEC
config ARCH_SELECTS_KEXEC
def_bool y
+ depends on KEXEC
select CRASH_DUMP
config ARCH_SUPPORTS_KEXEC_FILE
^ permalink raw reply related [flat|nested] 138+ messages in thread
* linux-next: build failure after merge of the mm tree
@ 2024-01-25 3:29 Stephen Rothwell
2024-01-25 14:29 ` Baoquan He
0 siblings, 1 reply; 138+ messages in thread
From: Stephen Rothwell @ 2024-01-25 3:29 UTC (permalink / raw)
To: Andrew Morton
Cc: Baoquan He, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 8127 bytes --]
Hi all,
After merging the mm tree, today's linux-next build (powerpc allnoconfig)
failed like this:
WARNING: unmet direct dependencies detected for CRASH_DUMP
Depends on [n]: ARCH_SUPPORTS_CRASH_DUMP [=y] && KEXEC_CORE [=n]
Selected by [y]:
- ARCH_SELECTS_KEXEC [=y]
arch/powerpc/kernel/crash_dump.c:101:6: error: redefinition of 'is_kdump_kernel'
101 | bool is_kdump_kernel(void)
| ^~~~~~~~~~~~~~~
In file included from arch/powerpc/kernel/crash_dump.c:12:
include/linux/crash_dump.h:64:20: note: previous definition of 'is_kdump_kernel' with type 'bool(void)' {aka '_Bool(void)'}
64 | static inline bool is_kdump_kernel(void)
| ^~~~~~~~~~~~~~~
kernel/crash_core.c: In function 'kimage_crash_copy_vmcoreinfo':
kernel/crash_core.c:43:18: error: invalid use of undefined type 'struct kimage'
43 | if (image->type != KEXEC_TYPE_CRASH)
| ^~
kernel/crash_core.c:43:28: error: 'KEXEC_TYPE_CRASH' undeclared (first use in this function); did you mean 'KEXEC_ON_CRASH'?
43 | if (image->type != KEXEC_TYPE_CRASH)
| ^~~~~~~~~~~~~~~~
| KEXEC_ON_CRASH
kernel/crash_core.c:43:28: note: each undeclared identifier is reported only once for each function it appears in
kernel/crash_core.c:55:27: error: implicit declaration of function 'kimage_alloc_control_pages' [-Werror=implicit-function-declaration]
55 | vmcoreinfo_page = kimage_alloc_control_pages(image, 0);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
kernel/crash_core.c:55:25: warning: assignment to 'struct page *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
55 | vmcoreinfo_page = kimage_alloc_control_pages(image, 0);
| ^
kernel/crash_core.c:66:14: error: invalid use of undefined type 'struct kimage'
66 | image->vmcoreinfo_data_copy = safecopy;
| ^~
kernel/crash_core.c: At top level:
kernel/crash_core.c:74:5: error: redefinition of 'kexec_should_crash'
74 | int kexec_should_crash(struct task_struct *p)
| ^~~~~~~~~~~~~~~~~~
In file included from kernel/crash_core.c:12:
include/linux/kexec.h:474:19: note: previous definition of 'kexec_should_crash' with type 'int(struct task_struct *)'
474 | static inline int kexec_should_crash(struct task_struct *p) { return 0; }
| ^~~~~~~~~~~~~~~~~~
kernel/crash_core.c:92:5: error: redefinition of 'kexec_crash_loaded'
92 | int kexec_crash_loaded(void)
| ^~~~~~~~~~~~~~~~~~
include/linux/kexec.h:475:19: note: previous definition of 'kexec_crash_loaded' with type 'int(void)'
475 | static inline int kexec_crash_loaded(void) { return 0; }
| ^~~~~~~~~~~~~~~~~~
kernel/crash_core.c: In function 'kexec_crash_loaded':
kernel/crash_core.c:94:18: error: 'kexec_crash_image' undeclared (first use in this function); did you mean 'kexec_crash_loaded'?
94 | return !!kexec_crash_image;
| ^~~~~~~~~~~~~~~~~
| kexec_crash_loaded
kernel/crash_core.c: At top level:
kernel/crash_core.c:103:16: error: redefinition of '__crash_kexec'
103 | void __noclone __crash_kexec(struct pt_regs *regs)
| ^~~~~~~~~~~~~
include/linux/kexec.h:472:20: note: previous definition of '__crash_kexec' with type 'void(struct pt_regs *)'
472 | static inline void __crash_kexec(struct pt_regs *regs) { }
| ^~~~~~~~~~~~~
kernel/crash_core.c: In function '__crash_kexec':
kernel/crash_core.c:114:21: error: 'kexec_crash_image' undeclared (first use in this function); did you mean 'kexec_crash_loaded'?
114 | if (kexec_crash_image) {
| ^~~~~~~~~~~~~~~~~
| kexec_crash_loaded
kernel/crash_core.c:117:25: error: implicit declaration of function 'crash_setup_regs' [-Werror=implicit-function-declaration]
117 | crash_setup_regs(&fixed_regs, regs);
| ^~~~~~~~~~~~~~~~
kernel/crash_core.c:120:25: error: implicit declaration of function 'machine_kexec' [-Werror=implicit-function-declaration]
120 | machine_kexec(kexec_crash_image);
| ^~~~~~~~~~~~~
kernel/crash_core.c: At top level:
kernel/crash_core.c:128:1: warning: ignoring attribute 'noinline' because it conflicts with attribute 'gnu_inline' [-Wattributes]
128 | {
| ^
include/linux/kexec.h:473:20: note: previous declaration here
473 | static inline void crash_kexec(struct pt_regs *regs) { }
| ^~~~~~~~~~~
kernel/crash_core.c:127:18: error: redefinition of 'crash_kexec'
127 | __bpf_kfunc void crash_kexec(struct pt_regs *regs)
| ^~~~~~~~~~~
include/linux/kexec.h:473:20: note: previous definition of 'crash_kexec' with type 'void(struct pt_regs *)'
473 | static inline void crash_kexec(struct pt_regs *regs) { }
| ^~~~~~~~~~~
kernel/crash_core.c: In function '__crash_shrink_memory':
kernel/crash_core.c:356:9: error: implicit declaration of function 'crash_free_reserved_phys_range' [-Werror=implicit-function-declaration]
356 | crash_free_reserved_phys_range(ram_res->start, ram_res->end);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
kernel/crash_core.c: In function 'crash_shrink_memory':
kernel/crash_core.c:370:13: error: 'kexec_crash_image' undeclared (first use in this function); did you mean 'kexec_crash_loaded'?
370 | if (kexec_crash_image) {
| ^~~~~~~~~~~~~~~~~
| kexec_crash_loaded
In file included from include/linux/kernel.h:27,
from arch/powerpc/include/asm/page.h:11,
from arch/powerpc/include/asm/thread_info.h:13,
from include/linux/thread_info.h:60,
from arch/powerpc/include/asm/processor.h:41,
from include/linux/sched.h:13,
from include/linux/utsname.h:6,
from kernel/crash_core.c:9:
kernel/crash_core.c:377:38: error: 'KEXEC_CRASH_MEM_ALIGN' undeclared (first use in this function)
377 | new_size = roundup(new_size, KEXEC_CRASH_MEM_ALIGN);
| ^~~~~~~~~~~~~~~~~~~~~
include/linux/math.h:61:16: note: in definition of macro 'roundup'
61 | typeof(y) __y = y; \
| ^
kernel/crash_core.c: In function 'crash_save_cpu':
kernel/crash_core.c:437:36: error: 'KEXEC_CORE_NOTE_NAME' undeclared (first use in this function); did you mean 'CRASH_CORE_NOTE_NAME'?
437 | buf = append_elf_note(buf, KEXEC_CORE_NOTE_NAME, NT_PRSTATUS,
| ^~~~~~~~~~~~~~~~~~~~
| CRASH_CORE_NOTE_NAME
kernel/crash_core.c: In function 'kexec_crash_loaded':
kernel/crash_core.c:95:1: error: control reaches end of non-void function [-Werror=return-type]
95 | }
| ^
cc1: some warnings being treated as errors
Caused by commit
9dc830523e4e ("ppc, crash: enforce KEXEC and KEXEC_FILE to select CRASH_DUMP")
I have applied the following patch:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 25 Jan 2024 14:20:51 +1100
Subject: [PATCH] fix up for "ppc, crash: enforce KEXEC and KEXEC_FILE to
select CRASH_DUMP"
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/Kconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 31f013e636e3..e7707bebc061 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -610,6 +610,8 @@ config ARCH_SUPPORTS_KEXEC
config ARCH_SELECTS_KEXEC
def_bool y
+ depends on ARCH_SUPPORTS_CRASH_DUMP
+ depends on KEXEC_CORE
select CRASH_DUMP
config ARCH_SUPPORTS_KEXEC_FILE
--
2.43.0
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2024-01-24 23:52 ` Suren Baghdasaryan
@ 2024-01-25 2:40 ` Baoquan He
0 siblings, 0 replies; 138+ messages in thread
From: Baoquan He @ 2024-01-25 2:40 UTC (permalink / raw)
To: Suren Baghdasaryan
Cc: Stephen Rothwell, Andrew Morton, Linux Kernel Mailing List,
Linux Next Mailing List
On 01/24/24 at 03:52pm, Suren Baghdasaryan wrote:
> On Wed, Jan 24, 2024 at 3:24 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Hi all,
> >
> > After merging the mm tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > make[4]: *** No rule to make target 'kernel/elfcorehdr.o', needed by 'kernel/built-in.a'. Stop.
> >
> > Presumably caused by commit
> >
> > 1777bfb42f56 ("crash: remove dependency of FA_DUMP on CRASH_DUMP")
> >
> > from the mm-unstable branch of the mm tree. It looks like the expected
> > file rename did not happen.
> >
> > I have applied the following (git) patch for today.
>
> I've got the same error in mm-unstable and your patch below fixed it. Thanks!
This happened in v2 merging. I doubt there's something wrong with Andrew's
patch merging script regarding this kind of patch renaming.
>
> >
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Date: Thu, 25 Jan 2024 09:58:54 +1100
> > Subject: [PATCH] fix up for "crash: remove dependency of FA_DUMP on
> > CRASH_DUMP"
> >
> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > ---
> > kernel/{crash_dump.c => elfcorehdr.c} | 0
> > 1 file changed, 0 insertions(+), 0 deletions(-)
> > rename kernel/{crash_dump.c => elfcorehdr.c} (100%)
> >
> > diff --git a/kernel/crash_dump.c b/kernel/elfcorehdr.c
> > similarity index 100%
> > rename from kernel/crash_dump.c
> > rename to kernel/elfcorehdr.c
> > --
> > 2.43.0
> >
> > --
> > Cheers,
> > Stephen Rothwell
>
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2024-01-24 23:23 Stephen Rothwell
@ 2024-01-24 23:52 ` Suren Baghdasaryan
2024-01-25 2:40 ` Baoquan He
0 siblings, 1 reply; 138+ messages in thread
From: Suren Baghdasaryan @ 2024-01-24 23:52 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Andrew Morton, Baoquan He, Linux Kernel Mailing List,
Linux Next Mailing List
On Wed, Jan 24, 2024 at 3:24 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> After merging the mm tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> make[4]: *** No rule to make target 'kernel/elfcorehdr.o', needed by 'kernel/built-in.a'. Stop.
>
> Presumably caused by commit
>
> 1777bfb42f56 ("crash: remove dependency of FA_DUMP on CRASH_DUMP")
>
> from the mm-unstable branch of the mm tree. It looks like the expected
> file rename did not happen.
>
> I have applied the following (git) patch for today.
I've got the same error in mm-unstable and your patch below fixed it. Thanks!
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 25 Jan 2024 09:58:54 +1100
> Subject: [PATCH] fix up for "crash: remove dependency of FA_DUMP on
> CRASH_DUMP"
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> kernel/{crash_dump.c => elfcorehdr.c} | 0
> 1 file changed, 0 insertions(+), 0 deletions(-)
> rename kernel/{crash_dump.c => elfcorehdr.c} (100%)
>
> diff --git a/kernel/crash_dump.c b/kernel/elfcorehdr.c
> similarity index 100%
> rename from kernel/crash_dump.c
> rename to kernel/elfcorehdr.c
> --
> 2.43.0
>
> --
> Cheers,
> Stephen Rothwell
^ permalink raw reply [flat|nested] 138+ messages in thread
* linux-next: build failure after merge of the mm tree
@ 2024-01-24 23:23 Stephen Rothwell
2024-01-24 23:52 ` Suren Baghdasaryan
0 siblings, 1 reply; 138+ messages in thread
From: Stephen Rothwell @ 2024-01-24 23:23 UTC (permalink / raw)
To: Andrew Morton
Cc: Baoquan He, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1045 bytes --]
Hi all,
After merging the mm tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
make[4]: *** No rule to make target 'kernel/elfcorehdr.o', needed by 'kernel/built-in.a'. Stop.
Presumably caused by commit
1777bfb42f56 ("crash: remove dependency of FA_DUMP on CRASH_DUMP")
from the mm-unstable branch of the mm tree. It looks like the expected
file rename did not happen.
I have applied the following (git) patch for today.
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 25 Jan 2024 09:58:54 +1100
Subject: [PATCH] fix up for "crash: remove dependency of FA_DUMP on
CRASH_DUMP"
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
kernel/{crash_dump.c => elfcorehdr.c} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename kernel/{crash_dump.c => elfcorehdr.c} (100%)
diff --git a/kernel/crash_dump.c b/kernel/elfcorehdr.c
similarity index 100%
rename from kernel/crash_dump.c
rename to kernel/elfcorehdr.c
--
2.43.0
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2024-01-23 23:05 Stephen Rothwell
@ 2024-01-23 23:14 ` Suren Baghdasaryan
0 siblings, 0 replies; 138+ messages in thread
From: Suren Baghdasaryan @ 2024-01-23 23:14 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Andrew Morton, Linux Kernel Mailing List, Linux Next Mailing List
On Tue, Jan 23, 2024 at 3:05 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> After merging the mm tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> fs/proc/task_mmu.c: In function 'get_vma_snapshow':
> fs/proc/task_mmu.c:145:19: error: 'struct vm_area_struct' has no member named 'anon_name'; did you mean 'anon_vma'?
> 145 | if (copy->anon_name && !anon_vma_name_get_rcu(copy))
> | ^~~~~~~~~
> | anon_vma
> fs/proc/task_mmu.c:161:19: error: 'struct vm_area_struct' has no member named 'anon_name'; did you mean 'anon_vma'?
> 161 | if (copy->anon_name)
> | ^~~~~~~~~
> | anon_vma
> fs/proc/task_mmu.c:162:41: error: 'struct vm_area_struct' has no member named 'anon_name'; did you mean 'anon_vma'?
> 162 | anon_vma_name_put(copy->anon_name);
> | ^~~~~~~~~
> | anon_vma
> fs/proc/task_mmu.c: In function 'put_vma_snapshot':
> fs/proc/task_mmu.c:174:18: error: 'struct vm_area_struct' has no member named 'anon_name'; did you mean 'anon_vma'?
> 174 | if (vma->anon_name)
> | ^~~~~~~~~
> | anon_vma
> fs/proc/task_mmu.c:175:40: error: 'struct vm_area_struct' has no member named 'anon_name'; did you mean 'anon_vma'?
> 175 | anon_vma_name_put(vma->anon_name);
> | ^~~~~~~~~
> | anon_vma
>
> Caused by commit
>
> 786cebbd51a4 ("mm/maps: read proc/pid/maps under RCU")
>
> from the mm-unstable branch.
>
> This build does not have CONFIG_ANON_VMA_NAME set.
>
> I have reverted that commit for today.
Yes, this problem was reported yesterday and I just posted v2 with a
fix: https://lore.kernel.org/all/20240123231014.3801041-1-surenb@google.com/
Thanks,
Suren.
>
> --
> Cheers,
> Stephen Rothwell
^ permalink raw reply [flat|nested] 138+ messages in thread
* linux-next: build failure after merge of the mm tree
@ 2024-01-23 23:05 Stephen Rothwell
2024-01-23 23:14 ` Suren Baghdasaryan
0 siblings, 1 reply; 138+ messages in thread
From: Stephen Rothwell @ 2024-01-23 23:05 UTC (permalink / raw)
To: Andrew Morton
Cc: Suren Baghdasaryan, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1759 bytes --]
Hi all,
After merging the mm tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
fs/proc/task_mmu.c: In function 'get_vma_snapshow':
fs/proc/task_mmu.c:145:19: error: 'struct vm_area_struct' has no member named 'anon_name'; did you mean 'anon_vma'?
145 | if (copy->anon_name && !anon_vma_name_get_rcu(copy))
| ^~~~~~~~~
| anon_vma
fs/proc/task_mmu.c:161:19: error: 'struct vm_area_struct' has no member named 'anon_name'; did you mean 'anon_vma'?
161 | if (copy->anon_name)
| ^~~~~~~~~
| anon_vma
fs/proc/task_mmu.c:162:41: error: 'struct vm_area_struct' has no member named 'anon_name'; did you mean 'anon_vma'?
162 | anon_vma_name_put(copy->anon_name);
| ^~~~~~~~~
| anon_vma
fs/proc/task_mmu.c: In function 'put_vma_snapshot':
fs/proc/task_mmu.c:174:18: error: 'struct vm_area_struct' has no member named 'anon_name'; did you mean 'anon_vma'?
174 | if (vma->anon_name)
| ^~~~~~~~~
| anon_vma
fs/proc/task_mmu.c:175:40: error: 'struct vm_area_struct' has no member named 'anon_name'; did you mean 'anon_vma'?
175 | anon_vma_name_put(vma->anon_name);
| ^~~~~~~~~
| anon_vma
Caused by commit
786cebbd51a4 ("mm/maps: read proc/pid/maps under RCU")
from the mm-unstable branch.
This build does not have CONFIG_ANON_VMA_NAME set.
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2023-12-22 0:16 ` Stephen Rothwell
@ 2023-12-22 6:26 ` Andrew Morton
0 siblings, 0 replies; 138+ messages in thread
From: Andrew Morton @ 2023-12-22 6:26 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Arnd Bergmann, Linux Kernel Mailing List,
Linux Next Mailing List, David Miller
On Fri, 22 Dec 2023 11:16:49 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> On Mon, 27 Nov 2023 14:44:18 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > After merging the mm tree, today's linux-next build (sparc64 defconfig)
> > failed like this:
> >
> > arch/sparc/vdso/vclock_gettime.c:254:1: warning: no previous prototype for '__vdso_clock_gettime' [-Wmissing-prototypes]
> > 254 | __vdso_clock_gettime(clockid_t clock, struct __kernel_old_timespec *ts)
> >
>
> ...
>
> > So I turned off -Werrror in the lib directory as well which added this:
> >
> > arch/sparc/lib/ucmpdi2.c:5:11: warning: no previous prototype for '__ucmpdi2' [-Wmissing-prototypes]
> > 5 | word_type __ucmpdi2(unsigned long long a, unsigned long long b)
> > | ^~~~~~~~~
>
> Is anything being done about the above warnings?
OK, here's sparc64. I'll do sparc32 in a bit.
From: Andrew Morton <akpm@linux-foundation.org>
Subject: sparc64: fix up fallout from enabling -Wmissing-prototypes
Date: Thu Dec 21 04:33:25 PM PST 2023
Fix sparc64 allmodconfig build errors caused by enabling
-Wmissing-prototypes.
- Symbols only used from assembly were given local prototypes
- A couple of missing inclusions were added
- Define some functions to be static
- vmemmap_free() is only needed if CONFIG_MEMORY_HOTPLUG
- add new arch/sparc/include/asm/irq_work.h for arch_irq_work_raise()
- move prom_cif_init() prototype to header, fix longstanding
prom_cif_init() borkage.
- various function declarations were moved from .c into shared .h
Fixes: c6345dfa6e3e ("Makefile.extrawarn: turn on missing-prototypes globally")
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
arch/sparc/include/asm/floppy_64.h | 4 +++-
arch/sparc/include/asm/irq_work.h | 10 ++++++++++
arch/sparc/include/asm/openprom.h | 2 ++
arch/sparc/kernel/adi_64.c | 6 +++---
arch/sparc/kernel/asm-offsets.c | 4 +++-
arch/sparc/kernel/pci_sun4v.c | 2 +-
arch/sparc/kernel/setup_64.c | 2 +-
arch/sparc/kernel/time_64.c | 2 ++
arch/sparc/kernel/traps_64.c | 7 ++++---
arch/sparc/kernel/uprobes.c | 1 +
arch/sparc/mm/init_64.c | 2 ++
arch/sparc/power/hibernate.c | 1 +
arch/sparc/prom/init_64.c | 2 --
arch/sparc/prom/misc_64.c | 2 +-
arch/sparc/prom/p1275.c | 2 +-
arch/sparc/vdso/vclock_gettime.c | 10 ++++++++++
arch/sparc/vdso/vma.c | 2 +-
drivers/mtd/maps/sun_uflash.c | 2 +-
drivers/sbus/char/bbc_i2c.c | 3 ---
drivers/sbus/char/bbc_i2c.h | 3 +++
20 files changed, 50 insertions(+), 19 deletions(-)
--- a/arch/sparc/vdso/vclock_gettime.c~arch-sparc-fix-up-fallout-from-enabling-wmissing-prototypes
+++ a/arch/sparc/vdso/vclock_gettime.c
@@ -250,6 +250,8 @@ notrace static int do_monotonic_coarse(s
return 0;
}
+int __vdso_clock_gettime(clockid_t clock, struct __kernel_old_timespec *ts);
+
notrace int
__vdso_clock_gettime(clockid_t clock, struct __kernel_old_timespec *ts)
{
@@ -278,6 +280,9 @@ int
clock_gettime(clockid_t, struct __kernel_old_timespec *)
__attribute__((weak, alias("__vdso_clock_gettime")));
+int
+__vdso_clock_gettime_stick(clockid_t clock, struct __kernel_old_timespec *ts);
+
notrace int
__vdso_clock_gettime_stick(clockid_t clock, struct __kernel_old_timespec *ts)
{
@@ -303,6 +308,8 @@ __vdso_clock_gettime_stick(clockid_t clo
return vdso_fallback_gettime(clock, ts);
}
+int __vdso_gettimeofday(struct __kernel_old_timeval *tv, struct timezone *tz);
+
notrace int
__vdso_gettimeofday(struct __kernel_old_timeval *tv, struct timezone *tz)
{
@@ -339,6 +346,9 @@ int
gettimeofday(struct __kernel_old_timeval *, struct timezone *)
__attribute__((weak, alias("__vdso_gettimeofday")));
+int
+__vdso_gettimeofday_stick(struct __kernel_old_timeval *tv, struct timezone *tz);
+
notrace int
__vdso_gettimeofday_stick(struct __kernel_old_timeval *tv, struct timezone *tz)
{
--- a/arch/sparc/kernel/asm-offsets.c~arch-sparc-fix-up-fallout-from-enabling-wmissing-prototypes
+++ a/arch/sparc/kernel/asm-offsets.c
@@ -19,6 +19,7 @@
#include <asm/hibernate.h>
#ifdef CONFIG_SPARC32
+int sparc32_foo(void);
int sparc32_foo(void)
{
DEFINE(AOFF_thread_fork_kpsr,
@@ -26,6 +27,7 @@ int sparc32_foo(void)
return 0;
}
#else
+int sparc64_foo(void);
int sparc64_foo(void)
{
#ifdef CONFIG_HIBERNATION
@@ -45,6 +47,7 @@ int sparc64_foo(void)
}
#endif
+int foo(void);
int foo(void)
{
BLANK();
@@ -57,4 +60,3 @@ int foo(void)
/* DEFINE(NUM_USER_SEGMENTS, TASK_SIZE>>28); */
return 0;
}
-
--- a/arch/sparc/prom/misc_64.c~arch-sparc-fix-up-fallout-from-enabling-wmissing-prototypes
+++ a/arch/sparc/prom/misc_64.c
@@ -162,7 +162,7 @@ unsigned char prom_get_idprom(char *idbu
return 0xff;
}
-int prom_get_mmu_ihandle(void)
+static int prom_get_mmu_ihandle(void)
{
phandle node;
int ret;
--- a/arch/sparc/kernel/traps_64.c~arch-sparc-fix-up-fallout-from-enabling-wmissing-prototypes
+++ a/arch/sparc/kernel/traps_64.c
@@ -22,6 +22,7 @@
#include <linux/kdebug.h>
#include <linux/ftrace.h>
#include <linux/reboot.h>
+#include <linux/cpu.h>
#include <linux/gfp.h>
#include <linux/context_tracking.h>
@@ -249,7 +250,7 @@ void sun4v_insn_access_exception_tl1(str
sun4v_insn_access_exception(regs, addr, type_ctx);
}
-bool is_no_fault_exception(struct pt_regs *regs)
+static bool is_no_fault_exception(struct pt_regs *regs)
{
unsigned char asi;
u32 insn;
@@ -2031,7 +2032,7 @@ static void sun4v_log_error(struct pt_re
/* Handle memory corruption detected error which is vectored in
* through resumable error trap.
*/
-void do_mcd_err(struct pt_regs *regs, struct sun4v_error_entry ent)
+static void do_mcd_err(struct pt_regs *regs, struct sun4v_error_entry ent)
{
if (notify_die(DIE_TRAP, "MCD error", regs, 0, 0x34,
SIGSEGV) == NOTIFY_STOP)
@@ -2149,7 +2150,7 @@ static unsigned long sun4v_get_vaddr(str
/* Attempt to handle non-resumable errors generated from userspace.
* Returns true if the signal was handled, false otherwise.
*/
-bool sun4v_nonresum_error_user_handled(struct pt_regs *regs,
+static bool sun4v_nonresum_error_user_handled(struct pt_regs *regs,
struct sun4v_error_entry *ent) {
unsigned int attrs = ent->err_attrs;
--- a/arch/sparc/mm/init_64.c~arch-sparc-fix-up-fallout-from-enabling-wmissing-prototypes
+++ a/arch/sparc/mm/init_64.c
@@ -2641,10 +2641,12 @@ int __meminit vmemmap_populate(unsigned
return 0;
}
+#ifdef CONFIG_MEMORY_HOTPLUG
void vmemmap_free(unsigned long start, unsigned long end,
struct vmem_altmap *altmap)
{
}
+#endif
#endif /* CONFIG_SPARSEMEM_VMEMMAP */
/* These are actually filled in at boot time by sun4{u,v}_pgprot_init() */
--- a/arch/sparc/vdso/vma.c~arch-sparc-fix-up-fallout-from-enabling-wmissing-prototypes
+++ a/arch/sparc/vdso/vma.c
@@ -243,7 +243,7 @@ static int stick_patch(const struct vdso
* Allocate pages for the vdso and vvar, and copy in the vdso text from the
* kernel image.
*/
-int __init init_vdso_image(const struct vdso_image *image,
+static int __init init_vdso_image(const struct vdso_image *image,
struct vm_special_mapping *vdso_mapping, bool elf64)
{
int cnpages = (image->size) / PAGE_SIZE;
--- a/arch/sparc/kernel/setup_64.c~arch-sparc-fix-up-fallout-from-enabling-wmissing-prototypes
+++ a/arch/sparc/kernel/setup_64.c
@@ -599,7 +599,7 @@ static void __init init_sparc64_elf_hwca
pause_patch();
}
-void __init alloc_irqstack_bootmem(void)
+static void __init alloc_irqstack_bootmem(void)
{
unsigned int i, node;
--- a/arch/sparc/kernel/time_64.c~arch-sparc-fix-up-fallout-from-enabling-wmissing-prototypes
+++ a/arch/sparc/kernel/time_64.c
@@ -35,6 +35,8 @@
#include <linux/platform_device.h>
#include <linux/ftrace.h>
+#include <linux/sched/clock.h>
+
#include <asm/oplib.h>
#include <asm/timer.h>
#include <asm/irq.h>
--- a/arch/sparc/power/hibernate.c~arch-sparc-fix-up-fallout-from-enabling-wmissing-prototypes
+++ a/arch/sparc/power/hibernate.c
@@ -6,6 +6,7 @@
*/
#include <linux/mm.h>
+#include <linux/suspend.h>
#include <asm/hibernate.h>
#include <asm/visasm.h>
--- a/arch/sparc/kernel/adi_64.c~arch-sparc-fix-up-fallout-from-enabling-wmissing-prototypes
+++ a/arch/sparc/kernel/adi_64.c
@@ -121,7 +121,7 @@ adi_not_found:
mdesc_release(hp);
}
-tag_storage_desc_t *find_tag_store(struct mm_struct *mm,
+static tag_storage_desc_t *find_tag_store(struct mm_struct *mm,
struct vm_area_struct *vma,
unsigned long addr)
{
@@ -153,7 +153,7 @@ tag_storage_desc_t *find_tag_store(struc
return tag_desc;
}
-tag_storage_desc_t *alloc_tag_store(struct mm_struct *mm,
+static tag_storage_desc_t *alloc_tag_store(struct mm_struct *mm,
struct vm_area_struct *vma,
unsigned long addr)
{
@@ -296,7 +296,7 @@ out:
return tag_desc;
}
-void del_tag_store(tag_storage_desc_t *tag_desc, struct mm_struct *mm)
+static void del_tag_store(tag_storage_desc_t *tag_desc, struct mm_struct *mm)
{
unsigned long flags;
unsigned char *tags = NULL;
--- /dev/null
+++ a/arch/sparc/include/asm/irq_work.h
@@ -0,0 +1,10 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef __ASM_SPARC_IRQ_WORK_H
+#define __ASM_SPARC_IRQ_WORK_H
+
+#include <asm-generic/irq_work.h>
+
+extern void arch_irq_work_raise(void);
+
+#endif /* __ASM_SPARC_IRQ_WORK_H */
--- a/arch/sparc/include/asm/floppy_64.h~arch-sparc-fix-up-fallout-from-enabling-wmissing-prototypes
+++ a/arch/sparc/include/asm/floppy_64.h
@@ -197,6 +197,7 @@ static void sun_fd_enable_dma(void)
pdma_areasize = pdma_size;
}
+irqreturn_t sparc_floppy_irq(int irq, void *dev_cookie);
irqreturn_t sparc_floppy_irq(int irq, void *dev_cookie)
{
if (likely(doing_pdma)) {
@@ -434,7 +435,8 @@ static int sun_pci_fd_eject(int drive)
return -EINVAL;
}
-void sun_pci_fd_dma_callback(struct ebus_dma_info *p, int event, void *cookie)
+static void
+sun_pci_fd_dma_callback(struct ebus_dma_info *p, int event, void *cookie)
{
floppy_interrupt(0, NULL);
}
--- a/arch/sparc/prom/init_64.c~arch-sparc-fix-up-fallout-from-enabling-wmissing-prototypes
+++ a/arch/sparc/prom/init_64.c
@@ -27,8 +27,6 @@ phandle prom_chosen_node;
* It gets passed the pointer to the PROM vector.
*/
-extern void prom_cif_init(void *);
-
void __init prom_init(void *cif_handler)
{
phandle node;
--- a/arch/sparc/prom/p1275.c~arch-sparc-fix-up-fallout-from-enabling-wmissing-prototypes
+++ a/arch/sparc/prom/p1275.c
@@ -49,7 +49,7 @@ void p1275_cmd_direct(unsigned long *arg
local_irq_restore(flags);
}
-void prom_cif_init(void *cif_handler, void *cif_stack)
+void prom_cif_init(void *cif_handler)
{
p1275buf.prom_cif_handler = (void (*)(long *))cif_handler;
}
--- a/arch/sparc/include/asm/openprom.h~arch-sparc-fix-up-fallout-from-enabling-wmissing-prototypes
+++ a/arch/sparc/include/asm/openprom.h
@@ -275,6 +275,8 @@ struct linux_prom_pci_intmask {
unsigned int interrupt;
};
+extern void prom_cif_init(void *cif_handler);
+
#endif /* !(__ASSEMBLY__) */
#endif /* !(__SPARC_OPENPROM_H) */
--- a/arch/sparc/kernel/pci_sun4v.c~arch-sparc-fix-up-fallout-from-enabling-wmissing-prototypes
+++ a/arch/sparc/kernel/pci_sun4v.c
@@ -256,7 +256,7 @@ range_alloc_fail:
return NULL;
}
-unsigned long dma_4v_iotsb_bind(unsigned long devhandle,
+static unsigned long dma_4v_iotsb_bind(unsigned long devhandle,
unsigned long iotsb_num,
struct pci_bus *bus_dev)
{
--- a/arch/sparc/kernel/uprobes.c~arch-sparc-fix-up-fallout-from-enabling-wmissing-prototypes
+++ a/arch/sparc/kernel/uprobes.c
@@ -234,6 +234,7 @@ int arch_uprobe_post_xol(struct arch_upr
/* Handler for uprobe traps. This is called from the traps table and
* triggers the proper die notification.
*/
+void uprobe_trap(struct pt_regs *regs, unsigned long trap_level);
asmlinkage void uprobe_trap(struct pt_regs *regs,
unsigned long trap_level)
{
--- a/drivers/sbus/char/bbc_i2c.c~arch-sparc-fix-up-fallout-from-enabling-wmissing-prototypes
+++ a/drivers/sbus/char/bbc_i2c.c
@@ -358,9 +358,6 @@ fail:
return NULL;
}
-extern int bbc_envctrl_init(struct bbc_i2c_bus *bp);
-extern void bbc_envctrl_cleanup(struct bbc_i2c_bus *bp);
-
static int bbc_i2c_probe(struct platform_device *op)
{
struct bbc_i2c_bus *bp;
--- a/drivers/sbus/char/bbc_i2c.h~arch-sparc-fix-up-fallout-from-enabling-wmissing-prototypes
+++ a/drivers/sbus/char/bbc_i2c.h
@@ -82,4 +82,7 @@ extern int bbc_i2c_readb(struct bbc_i2c_
extern int bbc_i2c_write_buf(struct bbc_i2c_client *, char *buf, int len, int off);
extern int bbc_i2c_read_buf(struct bbc_i2c_client *, char *buf, int len, int off);
+extern int bbc_envctrl_init(struct bbc_i2c_bus *bp);
+extern void bbc_envctrl_cleanup(struct bbc_i2c_bus *bp);
+
#endif /* _BBC_I2C_H */
--- a/drivers/mtd/maps/sun_uflash.c~arch-sparc-fix-up-fallout-from-enabling-wmissing-prototypes
+++ a/drivers/mtd/maps/sun_uflash.c
@@ -47,7 +47,7 @@ struct map_info uflash_map_templ = {
.bankwidth = UFLASH_BUSWIDTH,
};
-int uflash_devinit(struct platform_device *op, struct device_node *dp)
+static int uflash_devinit(struct platform_device *op, struct device_node *dp)
{
struct uflash_dev *up;
_
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2023-11-27 3:44 Stephen Rothwell
@ 2023-12-22 0:16 ` Stephen Rothwell
2023-12-22 6:26 ` Andrew Morton
0 siblings, 1 reply; 138+ messages in thread
From: Stephen Rothwell @ 2023-12-22 0:16 UTC (permalink / raw)
To: Andrew Morton
Cc: Arnd Bergmann, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 7780 bytes --]
Hi all,
On Mon, 27 Nov 2023 14:44:18 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the mm tree, today's linux-next build (sparc64 defconfig)
> failed like this:
>
> arch/sparc/vdso/vclock_gettime.c:254:1: warning: no previous prototype for '__vdso_clock_gettime' [-Wmissing-prototypes]
> 254 | __vdso_clock_gettime(clockid_t clock, struct __kernel_old_timespec *ts)
> | ^~~~~~~~~~~~~~~~~~~~
> arch/sparc/vdso/vclock_gettime.c:282:1: warning: no previous prototype for '__vdso_clock_gettime_stick' [-Wmissing-prototypes]
> 282 | __vdso_clock_gettime_stick(clockid_t clock, struct __kernel_old_timespec *ts)
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~
> arch/sparc/vdso/vclock_gettime.c:307:1: warning: no previous prototype for '__vdso_gettimeofday' [-Wmissing-prototypes]
> 307 | __vdso_gettimeofday(struct __kernel_old_timeval *tv, struct timezone *tz)
> | ^~~~~~~~~~~~~~~~~~~
> arch/sparc/vdso/vclock_gettime.c:343:1: warning: no previous prototype for '__vdso_gettimeofday_stick' [-Wmissing-prototypes]
> 343 | __vdso_gettimeofday_stick(struct __kernel_old_timeval *tv, struct timezone *tz)
> | ^~~~~~~~~~~~~~~~~~~~~~~~~
> arch/sparc/vdso/vma.c:246:12: warning: no previous prototype for 'init_vdso_image' [-Wmissing-prototypes]
> 246 | int __init init_vdso_image(const struct vdso_image *image,
> | ^~~~~~~~~~~~~~~
> arch/sparc/prom/p1275.c:52:6: warning: no previous prototype for 'prom_cif_init' [-Wmissing-prototypes]
> 52 | void prom_cif_init(void *cif_handler, void *cif_stack)
> | ^~~~~~~~~~~~~
> In file included from arch/sparc/vdso/vdso32/vclock_gettime.c:22:
> arch/sparc/vdso/vdso32/../vclock_gettime.c:254:1: warning: no previous prototype for '__vdso_clock_gettime' [-Wmissing-prototypes]
> 254 | __vdso_clock_gettime(clockid_t clock, struct __kernel_old_timespec *ts)
> | ^~~~~~~~~~~~~~~~~~~~
> arch/sparc/vdso/vdso32/../vclock_gettime.c:282:1: warning: no previous prototype for '__vdso_clock_gettime_stick' [-Wmissing-prototypes]
> 282 | __vdso_clock_gettime_stick(clockid_t clock, struct __kernel_old_timespec *ts)
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~
> arch/sparc/vdso/vdso32/../vclock_gettime.c:307:1: warning: no previous prototype for '__vdso_gettimeofday' [-Wmissing-prototypes]
> 307 | __vdso_gettimeofday(struct __kernel_old_timeval *tv, struct timezone *tz)
> | ^~~~~~~~~~~~~~~~~~~
> arch/sparc/vdso/vdso32/../vclock_gettime.c:343:1: warning: no previous prototype for '__vdso_gettimeofday_stick' [-Wmissing-prototypes]
> 343 | __vdso_gettimeofday_stick(struct __kernel_old_timeval *tv, struct timezone *tz)
> | ^~~~~~~~~~~~~~~~~~~~~~~~~
> arch/sparc/prom/misc_64.c:165:5: warning: no previous prototype for 'prom_get_mmu_ihandle' [-Wmissing-prototypes]
> 165 | int prom_get_mmu_ihandle(void)
> | ^~~~~~~~~~~~~~~~~~~~
> arch/sparc/kernel/traps_64.c:253:6: error: no previous prototype for 'is_no_fault_exception' [-Werror=missing-prototypes]
> 253 | bool is_no_fault_exception(struct pt_regs *regs)
> | ^~~~~~~~~~~~~~~~~~~~~
> arch/sparc/kernel/traps_64.c:2035:6: error: no previous prototype for 'do_mcd_err' [-Werror=missing-prototypes]
> 2035 | void do_mcd_err(struct pt_regs *regs, struct sun4v_error_entry ent)
> | ^~~~~~~~~~
> arch/sparc/kernel/traps_64.c:2153:6: error: no previous prototype for 'sun4v_nonresum_error_user_handled' [-Werror=missing-prototypes]
> 2153 | bool sun4v_nonresum_error_user_handled(struct pt_regs *regs,
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> cc1: all warnings being treated as errors
> arch/sparc/mm/init_64.c:2644:6: error: no previous prototype for 'vmemmap_free' [-Werror=missing-prototypes]
> 2644 | void vmemmap_free(unsigned long start, unsigned long end,
> | ^~~~~~~~~~~~
> cc1: all warnings being treated as errors
>
> Caused by commit
>
> c6345dfa6e3e ("Makefile.extrawarn: turn on missing-prototypes globally")
>
> I applied the following hack for today.
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 27 Nov 2023 14:18:45 +1100
> Subject: [PATCH] sparc: turn off Werror for now
>
> ---
> arch/sparc/kernel/Makefile | 2 +-
> arch/sparc/mm/Makefile | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/sparc/kernel/Makefile b/arch/sparc/kernel/Makefile
> index 0984bb6f0f17..1ce4d5028c86 100644
> --- a/arch/sparc/kernel/Makefile
> +++ b/arch/sparc/kernel/Makefile
> @@ -5,7 +5,7 @@
> #
>
> asflags-y := -ansi
> -ccflags-y := -Werror
> +#ccflags-y := -Werror
>
> # Undefine sparc when processing vmlinux.lds - it is used
> # And teach CPP we are doing $(BITS) builds (for this case)
> diff --git a/arch/sparc/mm/Makefile b/arch/sparc/mm/Makefile
> index 871354aa3c00..a199484e131f 100644
> --- a/arch/sparc/mm/Makefile
> +++ b/arch/sparc/mm/Makefile
> @@ -3,7 +3,7 @@
> #
>
> asflags-y := -ansi
> -ccflags-y := -Werror
> +#ccflags-y := -Werror
>
> obj-$(CONFIG_SPARC64) += ultra.o tlb.o tsb.o
> obj-y += fault_$(BITS).o
> --
> 2.40.1
>
> After which I got these as well:
>
> arch/sparc/kernel/adi_64.c:124:21: warning: no previous prototype for 'find_tag_store' [-Wmissing-prototypes]
> 124 | tag_storage_desc_t *find_tag_store(struct mm_struct *mm,
> | ^~~~~~~~~~~~~~
> arch/sparc/kernel/adi_64.c:156:21: warning: no previous prototype for 'alloc_tag_store' [-Wmissing-prototypes]
> 156 | tag_storage_desc_t *alloc_tag_store(struct mm_struct *mm,
> | ^~~~~~~~~~~~~~~
> arch/sparc/kernel/adi_64.c:299:6: warning: no previous prototype for 'del_tag_store' [-Wmissing-prototypes]
> 299 | void del_tag_store(tag_storage_desc_t *tag_desc, struct mm_struct *mm)
> | ^~~~~~~~~~~~~
> arch/sparc/kernel/uprobes.c:237:17: warning: no previous prototype for 'uprobe_trap' [-Wmissing-prototypes]
> 237 | asmlinkage void uprobe_trap(struct pt_regs *regs,
> | ^~~~~~~~~~~
> arch/sparc/kernel/time_64.c:880:20: warning: no previous prototype for 'sched_clock' [-Wmissing-prototypes]
> 880 | unsigned long long sched_clock(void)
> | ^~~~~~~~~~~
> arch/sparc/kernel/pci_sun4v.c:259:15: warning: no previous prototype for 'dma_4v_iotsb_bind' [-Wmissing-prototypes]
> 259 | unsigned long dma_4v_iotsb_bind(unsigned long devhandle,
> | ^~~~~~~~~~~~~~~~~
> arch/sparc/kernel/setup_64.c:602:13: warning: no previous prototype for 'alloc_irqstack_bootmem' [-Wmissing-prototypes]
> 602 | void __init alloc_irqstack_bootmem(void)
> | ^~~~~~~~~~~~~~~~~~~~~~
>
> And these from the sparc (32) defconfig build:
>
> arch/sparc/lib/cmpdi2.c:6:11: error: no previous prototype for '__cmpdi2' [-Werror=missing-prototypes]
> 6 | word_type __cmpdi2(long long a, long long b)
> | ^~~~~~~~
> cc1: all warnings being treated as errors
> kernel/dma.c:70:5: warning: no previous prototype for 'request_dma' [-Wmissing-prototypes]
> 70 | int request_dma(unsigned int dmanr, const char * device_id)
> | ^~~~~~~~~~~
> kernel/dma.c:88:6: warning: no previous prototype for 'free_dma' [-Wmissing-prototypes]
> 88 | void free_dma(unsigned int dmanr)
> | ^~~~~~~~
>
> So I turned off -Werrror in the lib directory as well which added this:
>
> arch/sparc/lib/ucmpdi2.c:5:11: warning: no previous prototype for '__ucmpdi2' [-Wmissing-prototypes]
> 5 | word_type __ucmpdi2(unsigned long long a, unsigned long long b)
> | ^~~~~~~~~
Is anything being done about the above warnings?
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2023-12-21 7:38 Stephen Rothwell
@ 2023-12-21 7:45 ` Changbin Du
0 siblings, 0 replies; 138+ messages in thread
From: Changbin Du @ 2023-12-21 7:45 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Andrew Morton, Changbin Du, Linux Kernel Mailing List,
Linux Next Mailing List
Hi, Rothwell,
Please hold this patch. It need more discussion and probably the flush can be
simply removed.
On Thu, Dec 21, 2023 at 06:38:03PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the mm tree, today's linux-next build (x86_64 allnoconfig)
> failed like this:
>
> x86_64-linux-gnu-ld: init/main.o: in function `kernel_init':
> main.c:(.ref.text+0xbf): undefined reference to `flush_module_init_free_work'
>
> Caused by commit
>
> 1d8053432676 ("modules: wait do_free_init correctly")
>
> This build has
> # CONFIG_MODULES is not set
>
> I have applied this (hack) patch for today.
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 21 Dec 2023 18:27:07 +1100
> Subject: [PATCH] fix up for "modules: wait do_free_init correctly"
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> init/main.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/init/main.c b/init/main.c
> index f0b7e21ac67f..1df1106ff09b 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -1407,7 +1407,9 @@ static void mark_readonly(void)
> * flushed so that we don't hit false positives looking for
> * insecure pages which are W+X.
> */
> +#ifdef CONFIG_MODULES
> flush_module_init_free_work();
> +#endif
> mark_rodata_ro();
> rodata_test();
> } else
> --
> 2.43.0
>
> --
> Cheers,
> Stephen Rothwell
--
Cheers,
Changbin Du
^ permalink raw reply [flat|nested] 138+ messages in thread
* linux-next: build failure after merge of the mm tree
@ 2023-12-21 7:38 Stephen Rothwell
2023-12-21 7:45 ` Changbin Du
0 siblings, 1 reply; 138+ messages in thread
From: Stephen Rothwell @ 2023-12-21 7:38 UTC (permalink / raw)
To: Andrew Morton
Cc: Changbin Du, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1145 bytes --]
Hi all,
After merging the mm tree, today's linux-next build (x86_64 allnoconfig)
failed like this:
x86_64-linux-gnu-ld: init/main.o: in function `kernel_init':
main.c:(.ref.text+0xbf): undefined reference to `flush_module_init_free_work'
Caused by commit
1d8053432676 ("modules: wait do_free_init correctly")
This build has
# CONFIG_MODULES is not set
I have applied this (hack) patch for today.
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 21 Dec 2023 18:27:07 +1100
Subject: [PATCH] fix up for "modules: wait do_free_init correctly"
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
init/main.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/init/main.c b/init/main.c
index f0b7e21ac67f..1df1106ff09b 100644
--- a/init/main.c
+++ b/init/main.c
@@ -1407,7 +1407,9 @@ static void mark_readonly(void)
* flushed so that we don't hit false positives looking for
* insecure pages which are W+X.
*/
+#ifdef CONFIG_MODULES
flush_module_init_free_work();
+#endif
mark_rodata_ro();
rodata_test();
} else
--
2.43.0
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2023-11-27 2:28 Stephen Rothwell
2023-11-27 3:48 ` Stephen Rothwell
@ 2023-12-07 12:38 ` Michael Ellerman
1 sibling, 0 replies; 138+ messages in thread
From: Michael Ellerman @ 2023-12-07 12:38 UTC (permalink / raw)
To: Andrew Morton, Stephen Rothwell
Cc: Arnd Bergmann, Linux Kernel Mailing List, Linux Next Mailing List
On Mon, 27 Nov 2023 13:28:09 +1100, Stephen Rothwell wrote:
> After merging the mm tree, today's linux-next build (powerpc64
> allnoconfig) failed like this:
>
> arch/powerpc/mm/book3s64/pgtable.c:557:5: error: no previous prototype for 'pmd_move_must_withdraw' [-Werror=missing-prototypes]
> 557 | int pmd_move_must_withdraw(struct spinlock *new_pmd_ptl,
> | ^~~~~~~~~~~~~~~~~~~~~~
> cc1: all warnings being treated as errors
>
> [...]
Applied to powerpc/next.
[1/1] linux-next: build failure after merge of the mm tree
https://git.kernel.org/powerpc/c/0d555b57ee660d8a871781c0eebf006e855e918d
cheers
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2023-11-30 22:52 ` Andrew Morton
@ 2023-12-01 3:12 ` Michael Ellerman
0 siblings, 0 replies; 138+ messages in thread
From: Michael Ellerman @ 2023-12-01 3:12 UTC (permalink / raw)
To: Andrew Morton
Cc: Stephen Rothwell, Arnd Bergmann, Linux Kernel Mailing List,
Linux Next Mailing List, PowerPC
Andrew Morton <akpm@linux-foundation.org> writes:
> On Fri, 01 Dec 2023 09:39:20 +1100 Michael Ellerman <mpe@ellerman.id.au> wrote:
>
>> > I am still carrying this patch (it should probably go into the mm
>> > tree). Is someone going to pick it up (assuming it is correct)?
>>
>> I applied it to my next a few days ago, but I must have forgotten to
>> push. It's in there now.
>
> I'll keep a copy in mm.git, to keep the dependencies nice. I added
> your acked-by.
Sure thing. Thanks.
cheers
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2023-11-30 22:39 ` Michael Ellerman
@ 2023-11-30 22:52 ` Andrew Morton
2023-12-01 3:12 ` Michael Ellerman
0 siblings, 1 reply; 138+ messages in thread
From: Andrew Morton @ 2023-11-30 22:52 UTC (permalink / raw)
To: Michael Ellerman
Cc: Stephen Rothwell, Arnd Bergmann, Linux Kernel Mailing List,
Linux Next Mailing List, PowerPC
On Fri, 01 Dec 2023 09:39:20 +1100 Michael Ellerman <mpe@ellerman.id.au> wrote:
> > I am still carrying this patch (it should probably go into the mm
> > tree). Is someone going to pick it up (assuming it is correct)?
>
> I applied it to my next a few days ago, but I must have forgotten to
> push. It's in there now.
I'll keep a copy in mm.git, to keep the dependencies nice. I added
your acked-by.
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2023-11-30 22:04 ` Stephen Rothwell
2023-11-30 22:32 ` Andrew Morton
@ 2023-11-30 22:39 ` Michael Ellerman
2023-11-30 22:52 ` Andrew Morton
1 sibling, 1 reply; 138+ messages in thread
From: Michael Ellerman @ 2023-11-30 22:39 UTC (permalink / raw)
To: Stephen Rothwell, Andrew Morton
Cc: Arnd Bergmann, Linux Kernel Mailing List,
Linux Next Mailing List, PowerPC
Stephen Rothwell <sfr@canb.auug.org.au> writes:
> On Mon, 27 Nov 2023 14:48:52 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> Just cc'ing the PowerPC guys to see if my fix is sensible.
>>
>> On Mon, 27 Nov 2023 13:28:09 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> >
>> > After merging the mm tree, today's linux-next build (powerpc64
>> > allnoconfig) failed like this:
>> >
>> > arch/powerpc/mm/book3s64/pgtable.c:557:5: error: no previous prototype for 'pmd_move_must_withdraw' [-Werror=missing-prototypes]
>> > 557 | int pmd_move_must_withdraw(struct spinlock *new_pmd_ptl,
>> > | ^~~~~~~~~~~~~~~~~~~~~~
>> > cc1: all warnings being treated as errors
>> >
>> > Caused by commit
>> >
>> > c6345dfa6e3e ("Makefile.extrawarn: turn on missing-prototypes globally")
>> >
>> > I have added the following patch for today (which could be applied to
>> > the mm or powerpc trees):
>> >
>> > From 194805b44c11b4c0aa28bdcdc0bb0d82acef394c Mon Sep 17 00:00:00 2001
>> > From: Stephen Rothwell <sfr@canb.auug.org.au>
>> > Date: Mon, 27 Nov 2023 13:08:57 +1100
>> > Subject: [PATCH] powerpc: pmd_move_must_withdraw() is only needed for
>> > CONFIG_TRANSPARENT_HUGEPAGE
>> >
>> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
>> > ---
>> > arch/powerpc/mm/book3s64/pgtable.c | 2 ++
>> > 1 file changed, 2 insertions(+)
>> >
>> > diff --git a/arch/powerpc/mm/book3s64/pgtable.c b/arch/powerpc/mm/book3s64/pgtable.c
>> > index be229290a6a7..3438ab72c346 100644
>> > --- a/arch/powerpc/mm/book3s64/pgtable.c
>> > +++ b/arch/powerpc/mm/book3s64/pgtable.c
>> > @@ -542,6 +542,7 @@ void ptep_modify_prot_commit(struct vm_area_struct *vma, unsigned long addr,
>> > set_pte_at(vma->vm_mm, addr, ptep, pte);
>> > }
>> >
>> > +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
>> > /*
>> > * For hash translation mode, we use the deposited table to store hash slot
>> > * information and they are stored at PTRS_PER_PMD offset from related pmd
>> > @@ -563,6 +564,7 @@ int pmd_move_must_withdraw(struct spinlock *new_pmd_ptl,
>> >
>> > return true;
>> > }
>> > +#endif
>> >
>> > /*
>> > * Does the CPU support tlbie?
>> > --
>> > 2.40.1
>
> I am still carrying this patch (it should probably go into the mm
> tree). Is someone going to pick it up (assuming it is correct)?
I applied it to my next a few days ago, but I must have forgotten to
push. It's in there now.
cheers
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2023-11-30 22:04 ` Stephen Rothwell
@ 2023-11-30 22:32 ` Andrew Morton
2023-11-30 22:39 ` Michael Ellerman
1 sibling, 0 replies; 138+ messages in thread
From: Andrew Morton @ 2023-11-30 22:32 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Arnd Bergmann, Linux Kernel Mailing List,
Linux Next Mailing List, Michael Ellerman, PowerPC
On Fri, 1 Dec 2023 09:04:39 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> > > diff --git a/arch/powerpc/mm/book3s64/pgtable.c b/arch/powerpc/mm/book3s64/pgtable.c
> > > index be229290a6a7..3438ab72c346 100644
> > > --- a/arch/powerpc/mm/book3s64/pgtable.c
> > > +++ b/arch/powerpc/mm/book3s64/pgtable.c
> > > @@ -542,6 +542,7 @@ void ptep_modify_prot_commit(struct vm_area_struct *vma, unsigned long addr,
> > > set_pte_at(vma->vm_mm, addr, ptep, pte);
> > > }
> > >
> > > +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> > > /*
> > > * For hash translation mode, we use the deposited table to store hash slot
> > > * information and they are stored at PTRS_PER_PMD offset from related pmd
> > > @@ -563,6 +564,7 @@ int pmd_move_must_withdraw(struct spinlock *new_pmd_ptl,
> > >
> > > return true;
> > > }
> > > +#endif
> > >
> > > /*
> > > * Does the CPU support tlbie?
> > > --
> > > 2.40.1
>
> I am still carrying this patch (it should probably go into the mm
> tree). Is someone going to pick it up (assuming it is correct)?
AFAIK we're still awaiting input from the ppc team.
I'll grab it. If it breaks things then we-told-you-so!
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2023-11-29 8:17 ` Dmitry Rokosov
@ 2023-11-30 22:12 ` Stephen Rothwell
0 siblings, 0 replies; 138+ messages in thread
From: Stephen Rothwell @ 2023-11-30 22:12 UTC (permalink / raw)
To: Dmitry Rokosov
Cc: Andrew Morton, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1016 bytes --]
Hi Dmitry,
On Wed, 29 Nov 2023 11:17:04 +0300 Dmitry Rokosov <ddrokosov@salutedevices.com> wrote:
>
> On Tue, Nov 28, 2023 at 02:45:14PM -0800, Andrew Morton wrote:
> > On Wed, 29 Nov 2023 08:45:47 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > > After merging the mm tree, today's linux-next build (x86_64 allmodconfig)
> > > failed like this:
> > >
> > > make[5]: *** No rule to make target 'samples/cgroup/cgroup_event_listener.c', needed by 'samples/cgroup/cgroup_event_listener'. Stop.
> > >
> > > Caused by commit
> > >
> > > fc2cf253aaec ("samples: introduce new samples subdir for cgroup")
> > >
> > > I have reverted that commit (and the following one) for today.
> >
> > Thanks, my rename detector broke. Fixed.
>
> Sorry, I don't fully understand the situation. Is there any issue on my
> side?
No, Andrew was just saying that he missed the file move when applying
the patch to his tree and he has fixed it up now.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2023-11-27 3:48 ` Stephen Rothwell
@ 2023-11-30 22:04 ` Stephen Rothwell
2023-11-30 22:32 ` Andrew Morton
2023-11-30 22:39 ` Michael Ellerman
0 siblings, 2 replies; 138+ messages in thread
From: Stephen Rothwell @ 2023-11-30 22:04 UTC (permalink / raw)
To: Andrew Morton
Cc: Arnd Bergmann, Linux Kernel Mailing List,
Linux Next Mailing List, Michael Ellerman, PowerPC
[-- Attachment #1: Type: text/plain, Size: 2313 bytes --]
Hi all,
On Mon, 27 Nov 2023 14:48:52 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Just cc'ing the PowerPC guys to see if my fix is sensible.
>
> On Mon, 27 Nov 2023 13:28:09 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > After merging the mm tree, today's linux-next build (powerpc64
> > allnoconfig) failed like this:
> >
> > arch/powerpc/mm/book3s64/pgtable.c:557:5: error: no previous prototype for 'pmd_move_must_withdraw' [-Werror=missing-prototypes]
> > 557 | int pmd_move_must_withdraw(struct spinlock *new_pmd_ptl,
> > | ^~~~~~~~~~~~~~~~~~~~~~
> > cc1: all warnings being treated as errors
> >
> > Caused by commit
> >
> > c6345dfa6e3e ("Makefile.extrawarn: turn on missing-prototypes globally")
> >
> > I have added the following patch for today (which could be applied to
> > the mm or powerpc trees):
> >
> > From 194805b44c11b4c0aa28bdcdc0bb0d82acef394c Mon Sep 17 00:00:00 2001
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Date: Mon, 27 Nov 2023 13:08:57 +1100
> > Subject: [PATCH] powerpc: pmd_move_must_withdraw() is only needed for
> > CONFIG_TRANSPARENT_HUGEPAGE
> >
> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > ---
> > arch/powerpc/mm/book3s64/pgtable.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/arch/powerpc/mm/book3s64/pgtable.c b/arch/powerpc/mm/book3s64/pgtable.c
> > index be229290a6a7..3438ab72c346 100644
> > --- a/arch/powerpc/mm/book3s64/pgtable.c
> > +++ b/arch/powerpc/mm/book3s64/pgtable.c
> > @@ -542,6 +542,7 @@ void ptep_modify_prot_commit(struct vm_area_struct *vma, unsigned long addr,
> > set_pte_at(vma->vm_mm, addr, ptep, pte);
> > }
> >
> > +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> > /*
> > * For hash translation mode, we use the deposited table to store hash slot
> > * information and they are stored at PTRS_PER_PMD offset from related pmd
> > @@ -563,6 +564,7 @@ int pmd_move_must_withdraw(struct spinlock *new_pmd_ptl,
> >
> > return true;
> > }
> > +#endif
> >
> > /*
> > * Does the CPU support tlbie?
> > --
> > 2.40.1
I am still carrying this patch (it should probably go into the mm
tree). Is someone going to pick it up (assuming it is correct)?
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2023-11-28 22:45 ` Andrew Morton
@ 2023-11-29 8:17 ` Dmitry Rokosov
2023-11-30 22:12 ` Stephen Rothwell
0 siblings, 1 reply; 138+ messages in thread
From: Dmitry Rokosov @ 2023-11-29 8:17 UTC (permalink / raw)
To: Andrew Morton
Cc: Stephen Rothwell, Linux Kernel Mailing List, Linux Next Mailing List
Hello Stephen and Andrew,
On Tue, Nov 28, 2023 at 02:45:14PM -0800, Andrew Morton wrote:
> On Wed, 29 Nov 2023 08:45:47 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> > Hi all,
> >
> > After merging the mm tree, today's linux-next build (x86_64 allmodconfig)
> > failed like this:
> >
> > make[5]: *** No rule to make target 'samples/cgroup/cgroup_event_listener.c', needed by 'samples/cgroup/cgroup_event_listener'. Stop.
> >
> > Caused by commit
> >
> > fc2cf253aaec ("samples: introduce new samples subdir for cgroup")
> >
> > I have reverted that commit (and the following one) for today.
>
> Thanks, my rename detector broke. Fixed.
Sorry, I don't fully understand the situation. Is there any issue on my
side? I have added new samples to the Makefile, and it's very strange
that there are build failures.
Makefile contains:
====
# SPDX-License-Identifier: GPL-2.0
userprogs-always-y += cgroup_event_listener
userccflags += -I usr/include
====
--
Thank you,
Dmitry
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2023-11-28 21:45 Stephen Rothwell
@ 2023-11-28 22:45 ` Andrew Morton
2023-11-29 8:17 ` Dmitry Rokosov
0 siblings, 1 reply; 138+ messages in thread
From: Andrew Morton @ 2023-11-28 22:45 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Dmitry Rokosov, Linux Kernel Mailing List, Linux Next Mailing List
On Wed, 29 Nov 2023 08:45:47 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> After merging the mm tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> make[5]: *** No rule to make target 'samples/cgroup/cgroup_event_listener.c', needed by 'samples/cgroup/cgroup_event_listener'. Stop.
>
> Caused by commit
>
> fc2cf253aaec ("samples: introduce new samples subdir for cgroup")
>
> I have reverted that commit (and the following one) for today.
Thanks, my rename detector broke. Fixed.
^ permalink raw reply [flat|nested] 138+ messages in thread
* linux-next: build failure after merge of the mm tree
@ 2023-11-28 21:45 Stephen Rothwell
2023-11-28 22:45 ` Andrew Morton
0 siblings, 1 reply; 138+ messages in thread
From: Stephen Rothwell @ 2023-11-28 21:45 UTC (permalink / raw)
To: Andrew Morton
Cc: Dmitry Rokosov, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 434 bytes --]
Hi all,
After merging the mm tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
make[5]: *** No rule to make target 'samples/cgroup/cgroup_event_listener.c', needed by 'samples/cgroup/cgroup_event_listener'. Stop.
Caused by commit
fc2cf253aaec ("samples: introduce new samples subdir for cgroup")
I have reverted that commit (and the following one) for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2023-11-27 2:28 Stephen Rothwell
@ 2023-11-27 3:48 ` Stephen Rothwell
2023-11-30 22:04 ` Stephen Rothwell
2023-12-07 12:38 ` Michael Ellerman
1 sibling, 1 reply; 138+ messages in thread
From: Stephen Rothwell @ 2023-11-27 3:48 UTC (permalink / raw)
To: Andrew Morton
Cc: Arnd Bergmann, Linux Kernel Mailing List,
Linux Next Mailing List, Michael Ellerman, PowerPC
[-- Attachment #1: Type: text/plain, Size: 1985 bytes --]
Hi all,
Just cc'ing the PowerPC guys to see if my fix is sensible.
On Mon, 27 Nov 2023 13:28:09 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the mm tree, today's linux-next build (powerpc64
> allnoconfig) failed like this:
>
> arch/powerpc/mm/book3s64/pgtable.c:557:5: error: no previous prototype for 'pmd_move_must_withdraw' [-Werror=missing-prototypes]
> 557 | int pmd_move_must_withdraw(struct spinlock *new_pmd_ptl,
> | ^~~~~~~~~~~~~~~~~~~~~~
> cc1: all warnings being treated as errors
>
> Caused by commit
>
> c6345dfa6e3e ("Makefile.extrawarn: turn on missing-prototypes globally")
>
> I have added the following patch for today (which could be applied to
> the mm or powerpc trees):
>
> From 194805b44c11b4c0aa28bdcdc0bb0d82acef394c Mon Sep 17 00:00:00 2001
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 27 Nov 2023 13:08:57 +1100
> Subject: [PATCH] powerpc: pmd_move_must_withdraw() is only needed for
> CONFIG_TRANSPARENT_HUGEPAGE
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> arch/powerpc/mm/book3s64/pgtable.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/powerpc/mm/book3s64/pgtable.c b/arch/powerpc/mm/book3s64/pgtable.c
> index be229290a6a7..3438ab72c346 100644
> --- a/arch/powerpc/mm/book3s64/pgtable.c
> +++ b/arch/powerpc/mm/book3s64/pgtable.c
> @@ -542,6 +542,7 @@ void ptep_modify_prot_commit(struct vm_area_struct *vma, unsigned long addr,
> set_pte_at(vma->vm_mm, addr, ptep, pte);
> }
>
> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> /*
> * For hash translation mode, we use the deposited table to store hash slot
> * information and they are stored at PTRS_PER_PMD offset from related pmd
> @@ -563,6 +564,7 @@ int pmd_move_must_withdraw(struct spinlock *new_pmd_ptl,
>
> return true;
> }
> +#endif
>
> /*
> * Does the CPU support tlbie?
> --
> 2.40.1
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* linux-next: build failure after merge of the mm tree
@ 2023-11-27 3:44 Stephen Rothwell
2023-12-22 0:16 ` Stephen Rothwell
0 siblings, 1 reply; 138+ messages in thread
From: Stephen Rothwell @ 2023-11-27 3:44 UTC (permalink / raw)
To: Andrew Morton
Cc: Arnd Bergmann, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 7368 bytes --]
Hi all,
After merging the mm tree, today's linux-next build (sparc64 defconfig)
failed like this:
arch/sparc/vdso/vclock_gettime.c:254:1: warning: no previous prototype for '__vdso_clock_gettime' [-Wmissing-prototypes]
254 | __vdso_clock_gettime(clockid_t clock, struct __kernel_old_timespec *ts)
| ^~~~~~~~~~~~~~~~~~~~
arch/sparc/vdso/vclock_gettime.c:282:1: warning: no previous prototype for '__vdso_clock_gettime_stick' [-Wmissing-prototypes]
282 | __vdso_clock_gettime_stick(clockid_t clock, struct __kernel_old_timespec *ts)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
arch/sparc/vdso/vclock_gettime.c:307:1: warning: no previous prototype for '__vdso_gettimeofday' [-Wmissing-prototypes]
307 | __vdso_gettimeofday(struct __kernel_old_timeval *tv, struct timezone *tz)
| ^~~~~~~~~~~~~~~~~~~
arch/sparc/vdso/vclock_gettime.c:343:1: warning: no previous prototype for '__vdso_gettimeofday_stick' [-Wmissing-prototypes]
343 | __vdso_gettimeofday_stick(struct __kernel_old_timeval *tv, struct timezone *tz)
| ^~~~~~~~~~~~~~~~~~~~~~~~~
arch/sparc/vdso/vma.c:246:12: warning: no previous prototype for 'init_vdso_image' [-Wmissing-prototypes]
246 | int __init init_vdso_image(const struct vdso_image *image,
| ^~~~~~~~~~~~~~~
arch/sparc/prom/p1275.c:52:6: warning: no previous prototype for 'prom_cif_init' [-Wmissing-prototypes]
52 | void prom_cif_init(void *cif_handler, void *cif_stack)
| ^~~~~~~~~~~~~
In file included from arch/sparc/vdso/vdso32/vclock_gettime.c:22:
arch/sparc/vdso/vdso32/../vclock_gettime.c:254:1: warning: no previous prototype for '__vdso_clock_gettime' [-Wmissing-prototypes]
254 | __vdso_clock_gettime(clockid_t clock, struct __kernel_old_timespec *ts)
| ^~~~~~~~~~~~~~~~~~~~
arch/sparc/vdso/vdso32/../vclock_gettime.c:282:1: warning: no previous prototype for '__vdso_clock_gettime_stick' [-Wmissing-prototypes]
282 | __vdso_clock_gettime_stick(clockid_t clock, struct __kernel_old_timespec *ts)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
arch/sparc/vdso/vdso32/../vclock_gettime.c:307:1: warning: no previous prototype for '__vdso_gettimeofday' [-Wmissing-prototypes]
307 | __vdso_gettimeofday(struct __kernel_old_timeval *tv, struct timezone *tz)
| ^~~~~~~~~~~~~~~~~~~
arch/sparc/vdso/vdso32/../vclock_gettime.c:343:1: warning: no previous prototype for '__vdso_gettimeofday_stick' [-Wmissing-prototypes]
343 | __vdso_gettimeofday_stick(struct __kernel_old_timeval *tv, struct timezone *tz)
| ^~~~~~~~~~~~~~~~~~~~~~~~~
arch/sparc/prom/misc_64.c:165:5: warning: no previous prototype for 'prom_get_mmu_ihandle' [-Wmissing-prototypes]
165 | int prom_get_mmu_ihandle(void)
| ^~~~~~~~~~~~~~~~~~~~
arch/sparc/kernel/traps_64.c:253:6: error: no previous prototype for 'is_no_fault_exception' [-Werror=missing-prototypes]
253 | bool is_no_fault_exception(struct pt_regs *regs)
| ^~~~~~~~~~~~~~~~~~~~~
arch/sparc/kernel/traps_64.c:2035:6: error: no previous prototype for 'do_mcd_err' [-Werror=missing-prototypes]
2035 | void do_mcd_err(struct pt_regs *regs, struct sun4v_error_entry ent)
| ^~~~~~~~~~
arch/sparc/kernel/traps_64.c:2153:6: error: no previous prototype for 'sun4v_nonresum_error_user_handled' [-Werror=missing-prototypes]
2153 | bool sun4v_nonresum_error_user_handled(struct pt_regs *regs,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
arch/sparc/mm/init_64.c:2644:6: error: no previous prototype for 'vmemmap_free' [-Werror=missing-prototypes]
2644 | void vmemmap_free(unsigned long start, unsigned long end,
| ^~~~~~~~~~~~
cc1: all warnings being treated as errors
Caused by commit
c6345dfa6e3e ("Makefile.extrawarn: turn on missing-prototypes globally")
I applied the following hack for today.
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 27 Nov 2023 14:18:45 +1100
Subject: [PATCH] sparc: turn off Werror for now
---
arch/sparc/kernel/Makefile | 2 +-
arch/sparc/mm/Makefile | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/sparc/kernel/Makefile b/arch/sparc/kernel/Makefile
index 0984bb6f0f17..1ce4d5028c86 100644
--- a/arch/sparc/kernel/Makefile
+++ b/arch/sparc/kernel/Makefile
@@ -5,7 +5,7 @@
#
asflags-y := -ansi
-ccflags-y := -Werror
+#ccflags-y := -Werror
# Undefine sparc when processing vmlinux.lds - it is used
# And teach CPP we are doing $(BITS) builds (for this case)
diff --git a/arch/sparc/mm/Makefile b/arch/sparc/mm/Makefile
index 871354aa3c00..a199484e131f 100644
--- a/arch/sparc/mm/Makefile
+++ b/arch/sparc/mm/Makefile
@@ -3,7 +3,7 @@
#
asflags-y := -ansi
-ccflags-y := -Werror
+#ccflags-y := -Werror
obj-$(CONFIG_SPARC64) += ultra.o tlb.o tsb.o
obj-y += fault_$(BITS).o
--
2.40.1
After which I got these as well:
arch/sparc/kernel/adi_64.c:124:21: warning: no previous prototype for 'find_tag_store' [-Wmissing-prototypes]
124 | tag_storage_desc_t *find_tag_store(struct mm_struct *mm,
| ^~~~~~~~~~~~~~
arch/sparc/kernel/adi_64.c:156:21: warning: no previous prototype for 'alloc_tag_store' [-Wmissing-prototypes]
156 | tag_storage_desc_t *alloc_tag_store(struct mm_struct *mm,
| ^~~~~~~~~~~~~~~
arch/sparc/kernel/adi_64.c:299:6: warning: no previous prototype for 'del_tag_store' [-Wmissing-prototypes]
299 | void del_tag_store(tag_storage_desc_t *tag_desc, struct mm_struct *mm)
| ^~~~~~~~~~~~~
arch/sparc/kernel/uprobes.c:237:17: warning: no previous prototype for 'uprobe_trap' [-Wmissing-prototypes]
237 | asmlinkage void uprobe_trap(struct pt_regs *regs,
| ^~~~~~~~~~~
arch/sparc/kernel/time_64.c:880:20: warning: no previous prototype for 'sched_clock' [-Wmissing-prototypes]
880 | unsigned long long sched_clock(void)
| ^~~~~~~~~~~
arch/sparc/kernel/pci_sun4v.c:259:15: warning: no previous prototype for 'dma_4v_iotsb_bind' [-Wmissing-prototypes]
259 | unsigned long dma_4v_iotsb_bind(unsigned long devhandle,
| ^~~~~~~~~~~~~~~~~
arch/sparc/kernel/setup_64.c:602:13: warning: no previous prototype for 'alloc_irqstack_bootmem' [-Wmissing-prototypes]
602 | void __init alloc_irqstack_bootmem(void)
| ^~~~~~~~~~~~~~~~~~~~~~
And these from the sparc (32) defconfig build:
arch/sparc/lib/cmpdi2.c:6:11: error: no previous prototype for '__cmpdi2' [-Werror=missing-prototypes]
6 | word_type __cmpdi2(long long a, long long b)
| ^~~~~~~~
cc1: all warnings being treated as errors
kernel/dma.c:70:5: warning: no previous prototype for 'request_dma' [-Wmissing-prototypes]
70 | int request_dma(unsigned int dmanr, const char * device_id)
| ^~~~~~~~~~~
kernel/dma.c:88:6: warning: no previous prototype for 'free_dma' [-Wmissing-prototypes]
88 | void free_dma(unsigned int dmanr)
| ^~~~~~~~
So I turned off -Werrror in the lib directory as well which added this:
arch/sparc/lib/ucmpdi2.c:5:11: warning: no previous prototype for '__ucmpdi2' [-Wmissing-prototypes]
5 | word_type __ucmpdi2(unsigned long long a, unsigned long long b)
| ^~~~~~~~~
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 138+ messages in thread
* linux-next: build failure after merge of the mm tree
@ 2023-11-27 2:28 Stephen Rothwell
2023-11-27 3:48 ` Stephen Rothwell
2023-12-07 12:38 ` Michael Ellerman
0 siblings, 2 replies; 138+ messages in thread
From: Stephen Rothwell @ 2023-11-27 2:28 UTC (permalink / raw)
To: Andrew Morton
Cc: Arnd Bergmann, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1741 bytes --]
Hi all,
After merging the mm tree, today's linux-next build (powerpc64
allnoconfig) failed like this:
arch/powerpc/mm/book3s64/pgtable.c:557:5: error: no previous prototype for 'pmd_move_must_withdraw' [-Werror=missing-prototypes]
557 | int pmd_move_must_withdraw(struct spinlock *new_pmd_ptl,
| ^~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
Caused by commit
c6345dfa6e3e ("Makefile.extrawarn: turn on missing-prototypes globally")
I have added the following patch for today (which could be applied to
the mm or powerpc trees):
From 194805b44c11b4c0aa28bdcdc0bb0d82acef394c Mon Sep 17 00:00:00 2001
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 27 Nov 2023 13:08:57 +1100
Subject: [PATCH] powerpc: pmd_move_must_withdraw() is only needed for
CONFIG_TRANSPARENT_HUGEPAGE
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/mm/book3s64/pgtable.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/mm/book3s64/pgtable.c b/arch/powerpc/mm/book3s64/pgtable.c
index be229290a6a7..3438ab72c346 100644
--- a/arch/powerpc/mm/book3s64/pgtable.c
+++ b/arch/powerpc/mm/book3s64/pgtable.c
@@ -542,6 +542,7 @@ void ptep_modify_prot_commit(struct vm_area_struct *vma, unsigned long addr,
set_pte_at(vma->vm_mm, addr, ptep, pte);
}
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
/*
* For hash translation mode, we use the deposited table to store hash slot
* information and they are stored at PTRS_PER_PMD offset from related pmd
@@ -563,6 +564,7 @@ int pmd_move_must_withdraw(struct spinlock *new_pmd_ptl,
return true;
}
+#endif
/*
* Does the CPU support tlbie?
--
2.40.1
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 138+ messages in thread
* linux-next: build failure after merge of the mm tree
@ 2023-10-03 22:50 Stephen Rothwell
0 siblings, 0 replies; 138+ messages in thread
From: Stephen Rothwell @ 2023-10-03 22:50 UTC (permalink / raw)
To: Andrew Morton
Cc: David Laight, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 2319 bytes --]
Hi all,
After merging the mm tree, today's linux-next build (native perf) failed
like this:
In file included from tools/include/linux/bits.h:21,
from tools/include/linux/bitops.h:14,
from tools/include/linux/bitmap.h:6,
from tools/perf/util/header.h:10,
from /home/sfr/next/perf/pmu-events/pmu-events.c:3:
tools/include/linux/find.h: In function 'find_next_bit':
tools/include/linux/bits.h:24:17: error: implicit declaration of function '__is_constexpr' [-Werror=implicit-function-declaration]
24 | __is_constexpr((l) > (h)), (l) > (h), 0)))
| ^~~~~~~~~~~~~~
tools/include/linux/build_bug.h:16:62: note: in definition of macro 'BUILD_BUG_ON_ZERO'
16 | #define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(e)); })))
| ^
tools/include/linux/bits.h:37:10: note: in expansion of macro 'GENMASK_INPUT_CHECK'
37 | (GENMASK_INPUT_CHECK(h, l) + __GENMASK(h, l))
| ^~~~~~~~~~~~~~~~~~~
tools/include/linux/find.h:42:31: note: in expansion of macro 'GENMASK'
42 | val = *addr & GENMASK(size - 1, offset);
| ^~~~~~~
tools/include/linux/bits.h:23:28: error: first argument to '__builtin_choose_expr' not a constant
23 | (BUILD_BUG_ON_ZERO(__builtin_choose_expr( \
| ^~~~~~~~~~~~~~~~~~~~~
tools/include/linux/build_bug.h:16:62: note: in definition of macro 'BUILD_BUG_ON_ZERO'
16 | #define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(e)); })))
| ^
tools/include/linux/bits.h:37:10: note: in expansion of macro 'GENMASK_INPUT_CHECK'
37 | (GENMASK_INPUT_CHECK(h, l) + __GENMASK(h, l))
| ^~~~~~~~~~~~~~~~~~~
tools/include/linux/find.h:42:31: note: in expansion of macro 'GENMASK'
42 | val = *addr & GENMASK(size - 1, offset);
| ^~~~~~~
... and much more ...
Caused by commit
5bee02eadb5d ("compiler.h: move __is_constexpr() to compiler.h")
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2023-09-27 23:22 Stephen Rothwell
@ 2023-09-28 6:47 ` Arnd Bergmann
0 siblings, 0 replies; 138+ messages in thread
From: Arnd Bergmann @ 2023-09-28 6:47 UTC (permalink / raw)
To: Stephen Rothwell, Andrew Morton
Cc: Muhammad Usama Anjum, Linux Kernel Mailing List, linux-next
On Thu, Sep 28, 2023, at 01:22, Stephen Rothwell wrote:
> Hi all,
>
> After merging the mm tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> fs/proc/task_mmu.c: In function 'pagemap_scan_pmd_entry':
> fs/proc/task_mmu.c:2153:22: error: implicit declaration of function
> 'pagemap_scan_is_interesting_page'; did you mean
> 'pagemap_scan_is_interesting_vma'?
> [-Werror=implicit-function-declaration]
> 2153 | if
> (!pagemap_scan_is_interesting_page(categories, p))
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> | pagemap_scan_is_interesting_vma
>
> Caused by commit
>
> 825ebc8e4bf9 ("fs/proc/task_mmu: hide unused
> pagemap_scan_backout_range() function")
>
> I applied the following fix patch.
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 28 Sep 2023 09:09:26 +1000
> Subject: [PATCH] fix for "fs/proc/task_mmu: hide unused
> pagemap_scan_backout_range() function"
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Thanks for the fix. I don't see what happened exactly,
maybe we had two conflicting workarounds for the same problem
applied. The version in linux-next works for me on the randconfig
builds, so folding your patch on top should be fine.
Arnd
^ permalink raw reply [flat|nested] 138+ messages in thread
* linux-next: build failure after merge of the mm tree
@ 2023-09-27 23:22 Stephen Rothwell
2023-09-28 6:47 ` Arnd Bergmann
0 siblings, 1 reply; 138+ messages in thread
From: Stephen Rothwell @ 2023-09-27 23:22 UTC (permalink / raw)
To: Andrew Morton
Cc: Arnd Bergmann, Muhammad Usama Anjum, Linux Kernel Mailing List,
Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 2175 bytes --]
Hi all,
After merging the mm tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
fs/proc/task_mmu.c: In function 'pagemap_scan_pmd_entry':
fs/proc/task_mmu.c:2153:22: error: implicit declaration of function 'pagemap_scan_is_interesting_page'; did you mean 'pagemap_scan_is_interesting_vma'? [-Werror=implicit-function-declaration]
2153 | if (!pagemap_scan_is_interesting_page(categories, p))
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| pagemap_scan_is_interesting_vma
Caused by commit
825ebc8e4bf9 ("fs/proc/task_mmu: hide unused pagemap_scan_backout_range() function")
I applied the following fix patch.
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 28 Sep 2023 09:09:26 +1000
Subject: [PATCH] fix for "fs/proc/task_mmu: hide unused pagemap_scan_backout_range() function"
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
fs/proc/task_mmu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index fdad3536d8ab..d4ef9a2bf95d 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -1940,6 +1940,7 @@ static void make_uffd_wp_huge_pte(struct vm_area_struct *vma,
set_huge_pte_at(vma->vm_mm, addr, ptep,
make_pte_marker(PTE_MARKER_UFFD_WP), psize);
}
+#endif /* CONFIG_HUGETLB_PAGE */
#if defined(CONFIG_TRANSPARENT_HUGEPAGE) || defined(CONFIG_HUGETLB_PAGE)
static void pagemap_scan_backout_range(struct pagemap_scan_private *p,
@@ -1954,7 +1955,7 @@ static void pagemap_scan_backout_range(struct pagemap_scan_private *p,
p->found_pages -= (end - addr) / PAGE_SIZE;
}
-#endif /* CONFIG_HUGETLB_PAGE */
+#endif
static bool pagemap_scan_is_interesting_page(unsigned long categories,
const struct pagemap_scan_private *p)
@@ -1967,7 +1968,6 @@ static bool pagemap_scan_is_interesting_page(unsigned long categories,
return true;
}
-#endif
static bool pagemap_scan_is_interesting_vma(unsigned long categories,
const struct pagemap_scan_private *p)
--
2.40.1
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 138+ messages in thread
* linux-next: build failure after merge of the mm tree
@ 2023-09-25 23:18 Stephen Rothwell
0 siblings, 0 replies; 138+ messages in thread
From: Stephen Rothwell @ 2023-09-25 23:18 UTC (permalink / raw)
To: Andrew Morton
Cc: Jaewon Kim, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1896 bytes --]
Hi all,
After merging the mm tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
In file included from include/trace/trace_events.h:27,
from include/trace/define_trace.h:102,
from include/trace/events/oom.h:195,
from mm/oom_kill.c:53:
include/trace/events/mmflags.h:278:21: error: 'LRU_GEN_ANON' undeclared here (not in a function); did you mean 'LRU_GEN_NAMES'?
278 | EM (LRU_GEN_ANON, "anon") \
| ^~~~~~~~~~~~
include/trace/stages/init.h:20:31: note: in definition of macro 'TRACE_DEFINE_ENUM'
20 | .eval_value = a \
| ^
include/trace/events/mmflags.h:278:17: note: in expansion of macro 'EM'
278 | EM (LRU_GEN_ANON, "anon") \
| ^~
include/trace/events/mmflags.h:295:1: note: in expansion of macro 'LRU_GEN_NAMES'
295 | LRU_GEN_NAMES
| ^~~~~~~~~~~~~
include/trace/events/mmflags.h:279:21: error: 'LRU_GEN_FILE' undeclared here (not in a function); did you mean 'LRU_GEN_NAMES'?
279 | EMe(LRU_GEN_FILE, "file")
| ^~~~~~~~~~~~
include/trace/stages/init.h:20:31: note: in definition of macro 'TRACE_DEFINE_ENUM'
20 | .eval_value = a \
| ^
include/trace/events/mmflags.h:279:17: note: in expansion of macro 'EMe'
279 | EMe(LRU_GEN_FILE, "file")
| ^~~
include/trace/events/mmflags.h:295:1: note: in expansion of macro 'LRU_GEN_NAMES'
295 | LRU_GEN_NAMES
| ^~~~~~~~~~~~~
Caused by commit
11113e8e7b3f ("vmscan: add trace events for lru_gen")
I have reverted that commit (and its followup fix) for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* linux-next: build failure after merge of the mm tree
@ 2023-08-22 22:52 Stephen Rothwell
0 siblings, 0 replies; 138+ messages in thread
From: Stephen Rothwell @ 2023-08-22 22:52 UTC (permalink / raw)
To: Andrew Morton
Cc: Stefan Roesch, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 610 bytes --]
Hi all,
After merging the mm tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
fs/proc/task_mmu.c: In function 'smaps_account':
fs/proc/task_mmu.c:457:40: error: implicit declaration of function 'is_ksm_zero_pte' [-Werror=implicit-function-declaration]
457 | if (PageKsm(page) && (!pte || !is_ksm_zero_pte(*pte)))
| ^~~~~~~~~~~~~~~
Caused by commit
5233d9beb1a8 ("proc/ksm: add ksm stats to /proc/pid/smaps")
# CONFIG_KSM is not set
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2023-08-22 4:00 ` Darrick J. Wong
@ 2023-08-22 20:20 ` Matthew Wilcox
0 siblings, 0 replies; 138+ messages in thread
From: Matthew Wilcox @ 2023-08-22 20:20 UTC (permalink / raw)
To: Darrick J. Wong
Cc: Stephen Rothwell, Andrew Morton, Linux Kernel Mailing List,
Linux Next Mailing List, Michael Ellerman, Nicholas Piggin,
Christophe Leroy, linuxppc-dev, linux-xfs
On Mon, Aug 21, 2023 at 09:00:43PM -0700, Darrick J. Wong wrote:
> Please leave this ^^^ comment, because the need for TRACE_DEFINE_ENUM to
> make enums work in tracepoints is not at all obvious.
>
> "order %u" to match the (non dev_t) style of the rest of the xfs
> tracepoints.
ACK, thanks.
Andrew, please add this -fix patch for "mm: Remove enum
page_entry_size".
diff --git a/fs/xfs/xfs_trace.h b/fs/xfs/xfs_trace.h
index 1904eaf7a2e9..fd789e00dfd6 100644
--- a/fs/xfs/xfs_trace.h
+++ b/fs/xfs/xfs_trace.h
@@ -802,9 +802,6 @@ DEFINE_INODE_EVENT(xfs_inode_inactivating);
* ring buffer. Somehow this was only worth mentioning in the ftrace sample
* code.
*/
-TRACE_DEFINE_ENUM(PMD_ORDER);
-TRACE_DEFINE_ENUM(PUD_ORDER);
-
TRACE_DEFINE_ENUM(XFS_REFC_DOMAIN_SHARED);
TRACE_DEFINE_ENUM(XFS_REFC_DOMAIN_COW);
@@ -823,13 +820,10 @@ TRACE_EVENT(xfs_filemap_fault,
__entry->order = order;
__entry->write_fault = write_fault;
),
- TP_printk("dev %d:%d ino 0x%llx %s write_fault %d",
+ TP_printk("dev %d:%d ino 0x%llx order %u write_fault %d",
MAJOR(__entry->dev), MINOR(__entry->dev),
__entry->ino,
- __print_symbolic(__entry->order,
- { 0, "PTE" },
- { PMD_ORDER, "PMD" },
- { PUD_ORDER, "PUD" }),
+ __entry->order,
__entry->write_fault)
)
^ permalink raw reply related [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2023-08-22 1:11 ` Matthew Wilcox
2023-08-22 1:22 ` Stephen Rothwell
@ 2023-08-22 7:12 ` Michael Ellerman
1 sibling, 0 replies; 138+ messages in thread
From: Michael Ellerman @ 2023-08-22 7:12 UTC (permalink / raw)
To: Matthew Wilcox, Stephen Rothwell
Cc: Andrew Morton, Linux Kernel Mailing List,
Linux Next Mailing List, Nicholas Piggin, Christophe Leroy,
linuxppc-dev
Matthew Wilcox <willy@infradead.org> writes:
> On Tue, Aug 22, 2023 at 09:55:37AM +1000, Stephen Rothwell wrote:
>> In file included from include/trace/trace_events.h:27,
>> from include/trace/define_trace.h:102,
>> from fs/xfs/xfs_trace.h:4428,
>> from fs/xfs/xfs_trace.c:45:
>> include/linux/pgtable.h:8:25: error: initializer element is not constant
>> 8 | #define PMD_ORDER (PMD_SHIFT - PAGE_SHIFT)
>
> Ummm. PowerPC doesn't have a compile-time constant PMD size?
Yeah. The joys of supporting two MMUs with different supported page
sizes in a single kernel binary.
> arch/powerpc/include/asm/book3s/64/pgtable.h:#define PMD_SHIFT (PAGE_SHIFT + PTE_INDEX_SIZE)
> arch/powerpc/include/asm/book3s/64/pgtable.h:#define PTE_INDEX_SIZE __pte_index_size
>
> That's really annoying. I'll try to work around it.
Sorry, thanks.
cheers
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2023-08-22 1:34 ` Matthew Wilcox
@ 2023-08-22 4:00 ` Darrick J. Wong
2023-08-22 20:20 ` Matthew Wilcox
0 siblings, 1 reply; 138+ messages in thread
From: Darrick J. Wong @ 2023-08-22 4:00 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Stephen Rothwell, Andrew Morton, Linux Kernel Mailing List,
Linux Next Mailing List, Michael Ellerman, Nicholas Piggin,
Christophe Leroy, linuxppc-dev, linux-xfs
On Tue, Aug 22, 2023 at 02:34:06AM +0100, Matthew Wilcox wrote:
> On Tue, Aug 22, 2023 at 11:22:17AM +1000, Stephen Rothwell wrote:
> > Hi Matthew,
> >
> > On Tue, 22 Aug 2023 02:11:44 +0100 Matthew Wilcox <willy@infradead.org> wrote:
> > >
> > > On Tue, Aug 22, 2023 at 09:55:37AM +1000, Stephen Rothwell wrote:
> > > > In file included from include/trace/trace_events.h:27,
> > > > from include/trace/define_trace.h:102,
> > > > from fs/xfs/xfs_trace.h:4428,
> > > > from fs/xfs/xfs_trace.c:45:
> > > > include/linux/pgtable.h:8:25: error: initializer element is not constant
> > > > 8 | #define PMD_ORDER (PMD_SHIFT - PAGE_SHIFT)
> > >
> > > Ummm. PowerPC doesn't have a compile-time constant PMD size?
> >
> > Yeah, you are not the first (or probably the last) to be caught by that.
>
> I think this will do the trick. Any comments?
>
> diff --git a/fs/xfs/xfs_trace.h b/fs/xfs/xfs_trace.h
> index 1904eaf7a2e9..d5a4e6c2dcd1 100644
> --- a/fs/xfs/xfs_trace.h
> +++ b/fs/xfs/xfs_trace.h
> @@ -796,15 +796,6 @@ DEFINE_INODE_EVENT(xfs_inode_reclaiming);
> DEFINE_INODE_EVENT(xfs_inode_set_need_inactive);
> DEFINE_INODE_EVENT(xfs_inode_inactivating);
>
> -/*
> - * ftrace's __print_symbolic requires that all enum values be wrapped in the
> - * TRACE_DEFINE_ENUM macro so that the enum value can be encoded in the ftrace
> - * ring buffer. Somehow this was only worth mentioning in the ftrace sample
> - * code.
> - */
Please leave this ^^^ comment, because the need for TRACE_DEFINE_ENUM to
make enums work in tracepoints is not at all obvious.
> -TRACE_DEFINE_ENUM(PMD_ORDER);
> -TRACE_DEFINE_ENUM(PUD_ORDER);
> -
> TRACE_DEFINE_ENUM(XFS_REFC_DOMAIN_SHARED);
> TRACE_DEFINE_ENUM(XFS_REFC_DOMAIN_COW);
>
> @@ -823,13 +814,10 @@ TRACE_EVENT(xfs_filemap_fault,
> __entry->order = order;
> __entry->write_fault = write_fault;
> ),
> - TP_printk("dev %d:%d ino 0x%llx %s write_fault %d",
> + TP_printk("dev %d:%d ino 0x%llx order:%u write_fault %d",
"order %u" to match the (non dev_t) style of the rest of the xfs
tracepoints.
--D
> MAJOR(__entry->dev), MINOR(__entry->dev),
> __entry->ino,
> - __print_symbolic(__entry->order,
> - { 0, "PTE" },
> - { PMD_ORDER, "PMD" },
> - { PUD_ORDER, "PUD" }),
> + __entry->order,
> __entry->write_fault)
> )
>
>
>
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2023-08-22 1:22 ` Stephen Rothwell
@ 2023-08-22 1:34 ` Matthew Wilcox
2023-08-22 4:00 ` Darrick J. Wong
0 siblings, 1 reply; 138+ messages in thread
From: Matthew Wilcox @ 2023-08-22 1:34 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Andrew Morton, Linux Kernel Mailing List,
Linux Next Mailing List, Michael Ellerman, Nicholas Piggin,
Christophe Leroy, linuxppc-dev, linux-xfs
On Tue, Aug 22, 2023 at 11:22:17AM +1000, Stephen Rothwell wrote:
> Hi Matthew,
>
> On Tue, 22 Aug 2023 02:11:44 +0100 Matthew Wilcox <willy@infradead.org> wrote:
> >
> > On Tue, Aug 22, 2023 at 09:55:37AM +1000, Stephen Rothwell wrote:
> > > In file included from include/trace/trace_events.h:27,
> > > from include/trace/define_trace.h:102,
> > > from fs/xfs/xfs_trace.h:4428,
> > > from fs/xfs/xfs_trace.c:45:
> > > include/linux/pgtable.h:8:25: error: initializer element is not constant
> > > 8 | #define PMD_ORDER (PMD_SHIFT - PAGE_SHIFT)
> >
> > Ummm. PowerPC doesn't have a compile-time constant PMD size?
>
> Yeah, you are not the first (or probably the last) to be caught by that.
I think this will do the trick. Any comments?
diff --git a/fs/xfs/xfs_trace.h b/fs/xfs/xfs_trace.h
index 1904eaf7a2e9..d5a4e6c2dcd1 100644
--- a/fs/xfs/xfs_trace.h
+++ b/fs/xfs/xfs_trace.h
@@ -796,15 +796,6 @@ DEFINE_INODE_EVENT(xfs_inode_reclaiming);
DEFINE_INODE_EVENT(xfs_inode_set_need_inactive);
DEFINE_INODE_EVENT(xfs_inode_inactivating);
-/*
- * ftrace's __print_symbolic requires that all enum values be wrapped in the
- * TRACE_DEFINE_ENUM macro so that the enum value can be encoded in the ftrace
- * ring buffer. Somehow this was only worth mentioning in the ftrace sample
- * code.
- */
-TRACE_DEFINE_ENUM(PMD_ORDER);
-TRACE_DEFINE_ENUM(PUD_ORDER);
-
TRACE_DEFINE_ENUM(XFS_REFC_DOMAIN_SHARED);
TRACE_DEFINE_ENUM(XFS_REFC_DOMAIN_COW);
@@ -823,13 +814,10 @@ TRACE_EVENT(xfs_filemap_fault,
__entry->order = order;
__entry->write_fault = write_fault;
),
- TP_printk("dev %d:%d ino 0x%llx %s write_fault %d",
+ TP_printk("dev %d:%d ino 0x%llx order:%u write_fault %d",
MAJOR(__entry->dev), MINOR(__entry->dev),
__entry->ino,
- __print_symbolic(__entry->order,
- { 0, "PTE" },
- { PMD_ORDER, "PMD" },
- { PUD_ORDER, "PUD" }),
+ __entry->order,
__entry->write_fault)
)
^ permalink raw reply related [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2023-08-22 1:11 ` Matthew Wilcox
@ 2023-08-22 1:22 ` Stephen Rothwell
2023-08-22 1:34 ` Matthew Wilcox
2023-08-22 7:12 ` Michael Ellerman
1 sibling, 1 reply; 138+ messages in thread
From: Stephen Rothwell @ 2023-08-22 1:22 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Andrew Morton, Linux Kernel Mailing List,
Linux Next Mailing List, Michael Ellerman, Nicholas Piggin,
Christophe Leroy, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 711 bytes --]
Hi Matthew,
On Tue, 22 Aug 2023 02:11:44 +0100 Matthew Wilcox <willy@infradead.org> wrote:
>
> On Tue, Aug 22, 2023 at 09:55:37AM +1000, Stephen Rothwell wrote:
> > In file included from include/trace/trace_events.h:27,
> > from include/trace/define_trace.h:102,
> > from fs/xfs/xfs_trace.h:4428,
> > from fs/xfs/xfs_trace.c:45:
> > include/linux/pgtable.h:8:25: error: initializer element is not constant
> > 8 | #define PMD_ORDER (PMD_SHIFT - PAGE_SHIFT)
>
> Ummm. PowerPC doesn't have a compile-time constant PMD size?
Yeah, you are not the first (or probably the last) to be caught by that.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2023-08-21 23:55 Stephen Rothwell
@ 2023-08-22 1:11 ` Matthew Wilcox
2023-08-22 1:22 ` Stephen Rothwell
2023-08-22 7:12 ` Michael Ellerman
0 siblings, 2 replies; 138+ messages in thread
From: Matthew Wilcox @ 2023-08-22 1:11 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Andrew Morton, Linux Kernel Mailing List,
Linux Next Mailing List, Michael Ellerman, Nicholas Piggin,
Christophe Leroy, linuxppc-dev
On Tue, Aug 22, 2023 at 09:55:37AM +1000, Stephen Rothwell wrote:
> In file included from include/trace/trace_events.h:27,
> from include/trace/define_trace.h:102,
> from fs/xfs/xfs_trace.h:4428,
> from fs/xfs/xfs_trace.c:45:
> include/linux/pgtable.h:8:25: error: initializer element is not constant
> 8 | #define PMD_ORDER (PMD_SHIFT - PAGE_SHIFT)
Ummm. PowerPC doesn't have a compile-time constant PMD size?
arch/powerpc/include/asm/book3s/64/pgtable.h:#define PMD_SHIFT (PAGE_SHIFT + PTE_INDEX_SIZE)
arch/powerpc/include/asm/book3s/64/pgtable.h:#define PTE_INDEX_SIZE __pte_index_size
That's really annoying. I'll try to work around it.
^ permalink raw reply [flat|nested] 138+ messages in thread
* linux-next: build failure after merge of the mm tree
@ 2023-08-21 23:55 Stephen Rothwell
2023-08-22 1:11 ` Matthew Wilcox
0 siblings, 1 reply; 138+ messages in thread
From: Stephen Rothwell @ 2023-08-21 23:55 UTC (permalink / raw)
To: Andrew Morton
Cc: Matthew Wilcox (Oracle),
Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 7559 bytes --]
Hi all,
After merging the mm tree, today's linux-next build
(powerpc_ppc64_defconfig) failed like this:
In file included from include/trace/trace_events.h:27,
from include/trace/define_trace.h:102,
from fs/xfs/xfs_trace.h:4428,
from fs/xfs/xfs_trace.c:45:
include/linux/pgtable.h:8:25: error: initializer element is not constant
8 | #define PMD_ORDER (PMD_SHIFT - PAGE_SHIFT)
| ^
include/trace/stages/init.h:20:31: note: in definition of macro 'TRACE_DEFINE_ENUM'
20 | .eval_value = a \
| ^
fs/xfs/./xfs_trace.h:805:19: note: in expansion of macro 'PMD_ORDER'
805 | TRACE_DEFINE_ENUM(PMD_ORDER);
| ^~~~~~~~~
include/linux/pgtable.h:8:25: note: (near initialization for '__TRACE_SYSTEM_PMD_ORDER.eval_value')
8 | #define PMD_ORDER (PMD_SHIFT - PAGE_SHIFT)
| ^
include/trace/stages/init.h:20:31: note: in definition of macro 'TRACE_DEFINE_ENUM'
20 | .eval_value = a \
| ^
fs/xfs/./xfs_trace.h:805:19: note: in expansion of macro 'PMD_ORDER'
805 | TRACE_DEFINE_ENUM(PMD_ORDER);
| ^~~~~~~~~
include/linux/pgtable.h:9:25: error: initializer element is not constant
9 | #define PUD_ORDER (PUD_SHIFT - PAGE_SHIFT)
| ^
include/trace/stages/init.h:20:31: note: in definition of macro 'TRACE_DEFINE_ENUM'
20 | .eval_value = a \
| ^
fs/xfs/./xfs_trace.h:806:19: note: in expansion of macro 'PUD_ORDER'
806 | TRACE_DEFINE_ENUM(PUD_ORDER);
| ^~~~~~~~~
include/linux/pgtable.h:9:25: note: (near initialization for '__TRACE_SYSTEM_PUD_ORDER.eval_value')
9 | #define PUD_ORDER (PUD_SHIFT - PAGE_SHIFT)
| ^
include/trace/stages/init.h:20:31: note: in definition of macro 'TRACE_DEFINE_ENUM'
20 | .eval_value = a \
| ^
fs/xfs/./xfs_trace.h:806:19: note: in expansion of macro 'PUD_ORDER'
806 | TRACE_DEFINE_ENUM(PUD_ORDER);
| ^~~~~~~~~
fs/xfs/./xfs_trace.h: In function 'trace_raw_output_xfs_filemap_fault':
include/linux/pgtable.h:8:25: error: initializer element is not constant
8 | #define PMD_ORDER (PMD_SHIFT - PAGE_SHIFT)
| ^
include/trace/trace_events.h:203:34: note: in definition of macro 'DECLARE_EVENT_CLASS'
203 | trace_event_printf(iter, print); \
| ^~~~~
include/trace/trace_events.h:45:30: note: in expansion of macro 'PARAMS'
45 | PARAMS(print)); \
| ^~~~~~
fs/xfs/./xfs_trace.h:811:1: note: in expansion of macro 'TRACE_EVENT'
811 | TRACE_EVENT(xfs_filemap_fault,
| ^~~~~~~~~~~
fs/xfs/./xfs_trace.h:826:9: note: in expansion of macro 'TP_printk'
826 | TP_printk("dev %d:%d ino 0x%llx %s write_fault %d",
| ^~~~~~~~~
fs/xfs/./xfs_trace.h:829:19: note: in expansion of macro '__print_symbolic'
829 | __print_symbolic(__entry->order,
| ^~~~~~~~~~~~~~~~
fs/xfs/./xfs_trace.h:831:27: note: in expansion of macro 'PMD_ORDER'
831 | { PMD_ORDER, "PMD" },
| ^~~~~~~~~
include/linux/pgtable.h:8:25: note: (near initialization for 'symbols[1].mask')
8 | #define PMD_ORDER (PMD_SHIFT - PAGE_SHIFT)
| ^
include/trace/trace_events.h:203:34: note: in definition of macro 'DECLARE_EVENT_CLASS'
203 | trace_event_printf(iter, print); \
| ^~~~~
include/trace/trace_events.h:45:30: note: in expansion of macro 'PARAMS'
45 | PARAMS(print)); \
| ^~~~~~
fs/xfs/./xfs_trace.h:811:1: note: in expansion of macro 'TRACE_EVENT'
811 | TRACE_EVENT(xfs_filemap_fault,
| ^~~~~~~~~~~
fs/xfs/./xfs_trace.h:826:9: note: in expansion of macro 'TP_printk'
826 | TP_printk("dev %d:%d ino 0x%llx %s write_fault %d",
| ^~~~~~~~~
fs/xfs/./xfs_trace.h:829:19: note: in expansion of macro '__print_symbolic'
829 | __print_symbolic(__entry->order,
| ^~~~~~~~~~~~~~~~
fs/xfs/./xfs_trace.h:831:27: note: in expansion of macro 'PMD_ORDER'
831 | { PMD_ORDER, "PMD" },
| ^~~~~~~~~
include/linux/pgtable.h:9:25: error: initializer element is not constant
9 | #define PUD_ORDER (PUD_SHIFT - PAGE_SHIFT)
| ^
include/trace/trace_events.h:203:34: note: in definition of macro 'DECLARE_EVENT_CLASS'
203 | trace_event_printf(iter, print); \
| ^~~~~
include/trace/trace_events.h:45:30: note: in expansion of macro 'PARAMS'
45 | PARAMS(print)); \
| ^~~~~~
fs/xfs/./xfs_trace.h:811:1: note: in expansion of macro 'TRACE_EVENT'
811 | TRACE_EVENT(xfs_filemap_fault,
| ^~~~~~~~~~~
fs/xfs/./xfs_trace.h:826:9: note: in expansion of macro 'TP_printk'
826 | TP_printk("dev %d:%d ino 0x%llx %s write_fault %d",
| ^~~~~~~~~
fs/xfs/./xfs_trace.h:829:19: note: in expansion of macro '__print_symbolic'
829 | __print_symbolic(__entry->order,
| ^~~~~~~~~~~~~~~~
fs/xfs/./xfs_trace.h:832:27: note: in expansion of macro 'PUD_ORDER'
832 | { PUD_ORDER, "PUD" }),
| ^~~~~~~~~
include/linux/pgtable.h:9:25: note: (near initialization for 'symbols[2].mask')
9 | #define PUD_ORDER (PUD_SHIFT - PAGE_SHIFT)
| ^
include/trace/trace_events.h:203:34: note: in definition of macro 'DECLARE_EVENT_CLASS'
203 | trace_event_printf(iter, print); \
| ^~~~~
include/trace/trace_events.h:45:30: note: in expansion of macro 'PARAMS'
45 | PARAMS(print)); \
| ^~~~~~
fs/xfs/./xfs_trace.h:811:1: note: in expansion of macro 'TRACE_EVENT'
811 | TRACE_EVENT(xfs_filemap_fault,
| ^~~~~~~~~~~
fs/xfs/./xfs_trace.h:826:9: note: in expansion of macro 'TP_printk'
826 | TP_printk("dev %d:%d ino 0x%llx %s write_fault %d",
| ^~~~~~~~~
fs/xfs/./xfs_trace.h:829:19: note: in expansion of macro '__print_symbolic'
829 | __print_symbolic(__entry->order,
| ^~~~~~~~~~~~~~~~
fs/xfs/./xfs_trace.h:832:27: note: in expansion of macro 'PUD_ORDER'
832 | { PUD_ORDER, "PUD" }),
| ^~~~~~~~~
Caused by commit
b8088235e872 ("mm: remove enum page_entry_size")
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2023-08-08 4:40 Stephen Rothwell
2023-08-08 15:20 ` Eric DeVolder
@ 2023-08-11 17:16 ` Eric DeVolder
1 sibling, 0 replies; 138+ messages in thread
From: Eric DeVolder @ 2023-08-11 17:16 UTC (permalink / raw)
To: Stephen Rothwell, Andrew Morton
Cc: Linux Kernel Mailing List, Linux Next Mailing List, Sourabh Jain
The build problem has been reproduced and solved in v27. Specifically the builds that fail are
because only PROC_KCORE has been set, which only enables CRASH_CORE by itself. I had to move a few
items to obtain the needed visibility.
"[PATCH v27 0/8] crash: Kernel handling of CPU and memory hot un/plug"
https://lore.kernel.org/lkml/20230811170642.6696-1-eric.devolder@oracle.com/
In addition, I've spot tested/built a few other architectures and do not encounter build errors.
Thanks!
eric
On 8/7/23 23:40, Stephen Rothwell wrote:
> Hi all,
>
> After merging the mm tree, today's linux-next build (powerpc
> ppc44x_defconfig) failed like this:
>
> In file included from kernel/crash_core.c:23:
> kernel/kexec_internal.h:11:54: warning: 'struct kexec_segment' declared inside parameter list will not be visible outside of this definition or declaration
> 11 | int kimage_load_segment(struct kimage *image, struct kexec_segment *segment);
> | ^~~~~~~~~~~~~
> kernel/crash_core.c:321:40: warning: 'struct crash_mem' declared inside parameter list will not be visible outside of this definition or declaration
> 321 | int crash_prepare_elf64_headers(struct crash_mem *mem, int need_kernel_map,
> | ^~~~~~~~~
> kernel/crash_core.c: In function 'crash_prepare_elf64_headers':
> kernel/crash_core.c:334:23: error: invalid use of undefined type 'struct crash_mem'
> 334 | nr_phdr += mem->nr_ranges;
> | ^~
> In file included from include/vdso/const.h:5,
> from include/linux/const.h:4,
> from include/linux/bits.h:5,
> from include/linux/ratelimit_types.h:5,
> from include/linux/printk.h:9,
> from include/asm-generic/bug.h:22,
> from arch/powerpc/include/asm/bug.h:116,
> from include/linux/bug.h:5,
> from arch/powerpc/include/asm/cmpxchg.h:8,
> from arch/powerpc/include/asm/atomic.h:11,
> from include/linux/atomic.h:7,
> from include/linux/mm_types_task.h:13,
> from include/linux/mm_types.h:5,
> from include/linux/buildid.h:5,
> from kernel/crash_core.c:7:
> kernel/crash_core.c:346:32: error: 'ELF_CORE_HEADER_ALIGN' undeclared (first use in this function)
> 346 | elf_sz = ALIGN(elf_sz, ELF_CORE_HEADER_ALIGN);
> | ^~~~~~~~~~~~~~~~~~~~~
> include/uapi/linux/const.h:32:50: note: in definition of macro '__ALIGN_KERNEL_MASK'
> 32 | #define __ALIGN_KERNEL_MASK(x, mask) (((x) + (mask)) & ~(mask))
> | ^~~~
> include/linux/align.h:8:33: note: in expansion of macro '__ALIGN_KERNEL'
> 8 | #define ALIGN(x, a) __ALIGN_KERNEL((x), (a))
> | ^~~~~~~~~~~~~~
> kernel/crash_core.c:346:18: note: in expansion of macro 'ALIGN'
> 346 | elf_sz = ALIGN(elf_sz, ELF_CORE_HEADER_ALIGN);
> | ^~~~~
> kernel/crash_core.c:346:32: note: each undeclared identifier is reported only once for each function it appears in
> 346 | elf_sz = ALIGN(elf_sz, ELF_CORE_HEADER_ALIGN);
> | ^~~~~~~~~~~~~~~~~~~~~
> include/uapi/linux/const.h:32:50: note: in definition of macro '__ALIGN_KERNEL_MASK'
> 32 | #define __ALIGN_KERNEL_MASK(x, mask) (((x) + (mask)) & ~(mask))
> | ^~~~
> include/linux/align.h:8:33: note: in expansion of macro '__ALIGN_KERNEL'
> 8 | #define ALIGN(x, a) __ALIGN_KERNEL((x), (a))
> | ^~~~~~~~~~~~~~
> kernel/crash_core.c:346:18: note: in expansion of macro 'ALIGN'
> 346 | elf_sz = ALIGN(elf_sz, ELF_CORE_HEADER_ALIGN);
> | ^~~~~
> kernel/crash_core.c:396:28: error: invalid use of undefined type 'struct crash_mem'
> 396 | for (i = 0; i < mem->nr_ranges; i++) {
> | ^~
> kernel/crash_core.c:397:29: error: invalid use of undefined type 'struct crash_mem'
> 397 | mstart = mem->ranges[i].start;
> | ^~
> kernel/crash_core.c:398:27: error: invalid use of undefined type 'struct crash_mem'
> 398 | mend = mem->ranges[i].end;
> | ^~
> kernel/crash_core.c: At top level:
> kernel/crash_core.c:420:36: warning: 'struct crash_mem' declared inside parameter list will not be visible outside of this definition or declaration
> 420 | int crash_exclude_mem_range(struct crash_mem *mem,
> | ^~~~~~~~~
> kernel/crash_core.c: In function 'crash_exclude_mem_range':
> kernel/crash_core.c:427:28: error: invalid use of undefined type 'struct crash_mem'
> 427 | for (i = 0; i < mem->nr_ranges; i++) {
> | ^~
> kernel/crash_core.c:428:28: error: invalid use of undefined type 'struct crash_mem'
> 428 | start = mem->ranges[i].start;
> | ^~
> kernel/crash_core.c:429:26: error: invalid use of undefined type 'struct crash_mem'
> 429 | end = mem->ranges[i].end;
> | ^~
> kernel/crash_core.c:444:28: error: invalid use of undefined type 'struct crash_mem'
> 444 | mem->ranges[i].start = 0;
> | ^~
> kernel/crash_core.c:445:28: error: invalid use of undefined type 'struct crash_mem'
> 445 | mem->ranges[i].end = 0;
> | ^~
> kernel/crash_core.c:446:36: error: invalid use of undefined type 'struct crash_mem'
> 446 | if (i < mem->nr_ranges - 1) {
> | ^~
> kernel/crash_core.c:448:52: error: invalid use of undefined type 'struct crash_mem'
> 448 | for (j = i; j < mem->nr_ranges - 1; j++) {
> | ^~
> kernel/crash_core.c:449:44: error: invalid use of undefined type 'struct crash_mem'
> 449 | mem->ranges[j].start =
> | ^~
> kernel/crash_core.c:450:52: error: invalid use of undefined type 'struct crash_mem'
> 450 | mem->ranges[j+1].start;
> | ^~
> kernel/crash_core.c:451:44: error: invalid use of undefined type 'struct crash_mem'
> 451 | mem->ranges[j].end =
> | ^~
> kernel/crash_core.c:452:60: error: invalid use of undefined type 'struct crash_mem'
> 452 | mem->ranges[j+1].end;
> | ^~
> kernel/crash_core.c:461:36: error: invalid use of undefined type 'struct crash_mem'
> 461 | mem->nr_ranges--;
> | ^~
> kernel/crash_core.c:464:28: error: invalid use of undefined type 'struct crash_mem'
> 464 | mem->nr_ranges--;
> | ^~
> kernel/crash_core.c:470:28: error: invalid use of undefined type 'struct crash_mem'
> 470 | mem->ranges[i].end = p_start - 1;
> | ^~
> kernel/crash_core.c:474:28: error: invalid use of undefined type 'struct crash_mem'
> 474 | mem->ranges[i].end = p_start - 1;
> | ^~
> kernel/crash_core.c:476:28: error: invalid use of undefined type 'struct crash_mem'
> 476 | mem->ranges[i].start = p_end + 1;
> | ^~
> kernel/crash_core.c:485:21: error: invalid use of undefined type 'struct crash_mem'
> 485 | if (i == mem->max_nr_ranges - 1)
> | ^~
> kernel/crash_core.c:490:20: error: invalid use of undefined type 'struct crash_mem'
> 490 | if (j < mem->nr_ranges) {
> | ^~
> kernel/crash_core.c:492:29: error: invalid use of undefined type 'struct crash_mem'
> 492 | for (i = mem->nr_ranges - 1; i >= j; i--)
> | ^~
> kernel/crash_core.c:493:28: error: invalid use of undefined type 'struct crash_mem'
> 493 | mem->ranges[i + 1] = mem->ranges[i];
> | ^~
> kernel/crash_core.c:493:49: error: invalid use of undefined type 'struct crash_mem'
> 493 | mem->ranges[i + 1] = mem->ranges[i];
> | ^~
> kernel/crash_core.c:496:12: error: invalid use of undefined type 'struct crash_mem'
> 496 | mem->ranges[j].start = temp_range.start;
> | ^~
> kernel/crash_core.c:497:12: error: invalid use of undefined type 'struct crash_mem'
> 497 | mem->ranges[j].end = temp_range.end;
> | ^~
> kernel/crash_core.c:498:12: error: invalid use of undefined type 'struct crash_mem'
> 498 | mem->nr_ranges++;
> | ^~
>
> I am not sure exactly which commit caused but I have revreted these
> for today:
>
> 6a41fd4665e6 ("x86/crash: optimize CPU changes")
> add3b7e011e9 ("crash: change crash_prepare_elf64_headers() to for_each_possible_cpu()")
> 4a7eed40a7bc ("crash: hotplug support for kexec_load()")
> 8ce41bc6b147 ("x86/crash: add x86 crash hotplug support")
> 2b765af0c14f ("crash: memory and CPU hotplug sysfs attributes")
> 36d2b573329b ("kexec: exclude elfcorehdr from the segment digest")
> ccfe0040500f ("crash: add generic infrastructure for crash hotplug support")
> 626775922a57 ("crash: move a few code bits to setup support of crash hotplug")
>
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2023-08-08 4:40 Stephen Rothwell
@ 2023-08-08 15:20 ` Eric DeVolder
2023-08-11 17:16 ` Eric DeVolder
1 sibling, 0 replies; 138+ messages in thread
From: Eric DeVolder @ 2023-08-08 15:20 UTC (permalink / raw)
To: Stephen Rothwell, Andrew Morton
Cc: Linux Kernel Mailing List, Linux Next Mailing List, Sourabh Jain
I'm looking at this, turns out PROC_KCORE selects CRASH_CORE, which according to the original config
settings, does not pickup KEXEC_CORE. So I'm looking at closing that gap.
eric
On 8/7/23 23:40, Stephen Rothwell wrote:
> Hi all,
>
> After merging the mm tree, today's linux-next build (powerpc
> ppc44x_defconfig) failed like this:
>
> In file included from kernel/crash_core.c:23:
> kernel/kexec_internal.h:11:54: warning: 'struct kexec_segment' declared inside parameter list will not be visible outside of this definition or declaration
> 11 | int kimage_load_segment(struct kimage *image, struct kexec_segment *segment);
> | ^~~~~~~~~~~~~
> kernel/crash_core.c:321:40: warning: 'struct crash_mem' declared inside parameter list will not be visible outside of this definition or declaration
> 321 | int crash_prepare_elf64_headers(struct crash_mem *mem, int need_kernel_map,
> | ^~~~~~~~~
> kernel/crash_core.c: In function 'crash_prepare_elf64_headers':
> kernel/crash_core.c:334:23: error: invalid use of undefined type 'struct crash_mem'
> 334 | nr_phdr += mem->nr_ranges;
> | ^~
> In file included from include/vdso/const.h:5,
> from include/linux/const.h:4,
> from include/linux/bits.h:5,
> from include/linux/ratelimit_types.h:5,
> from include/linux/printk.h:9,
> from include/asm-generic/bug.h:22,
> from arch/powerpc/include/asm/bug.h:116,
> from include/linux/bug.h:5,
> from arch/powerpc/include/asm/cmpxchg.h:8,
> from arch/powerpc/include/asm/atomic.h:11,
> from include/linux/atomic.h:7,
> from include/linux/mm_types_task.h:13,
> from include/linux/mm_types.h:5,
> from include/linux/buildid.h:5,
> from kernel/crash_core.c:7:
> kernel/crash_core.c:346:32: error: 'ELF_CORE_HEADER_ALIGN' undeclared (first use in this function)
> 346 | elf_sz = ALIGN(elf_sz, ELF_CORE_HEADER_ALIGN);
> | ^~~~~~~~~~~~~~~~~~~~~
> include/uapi/linux/const.h:32:50: note: in definition of macro '__ALIGN_KERNEL_MASK'
> 32 | #define __ALIGN_KERNEL_MASK(x, mask) (((x) + (mask)) & ~(mask))
> | ^~~~
> include/linux/align.h:8:33: note: in expansion of macro '__ALIGN_KERNEL'
> 8 | #define ALIGN(x, a) __ALIGN_KERNEL((x), (a))
> | ^~~~~~~~~~~~~~
> kernel/crash_core.c:346:18: note: in expansion of macro 'ALIGN'
> 346 | elf_sz = ALIGN(elf_sz, ELF_CORE_HEADER_ALIGN);
> | ^~~~~
> kernel/crash_core.c:346:32: note: each undeclared identifier is reported only once for each function it appears in
> 346 | elf_sz = ALIGN(elf_sz, ELF_CORE_HEADER_ALIGN);
> | ^~~~~~~~~~~~~~~~~~~~~
> include/uapi/linux/const.h:32:50: note: in definition of macro '__ALIGN_KERNEL_MASK'
> 32 | #define __ALIGN_KERNEL_MASK(x, mask) (((x) + (mask)) & ~(mask))
> | ^~~~
> include/linux/align.h:8:33: note: in expansion of macro '__ALIGN_KERNEL'
> 8 | #define ALIGN(x, a) __ALIGN_KERNEL((x), (a))
> | ^~~~~~~~~~~~~~
> kernel/crash_core.c:346:18: note: in expansion of macro 'ALIGN'
> 346 | elf_sz = ALIGN(elf_sz, ELF_CORE_HEADER_ALIGN);
> | ^~~~~
> kernel/crash_core.c:396:28: error: invalid use of undefined type 'struct crash_mem'
> 396 | for (i = 0; i < mem->nr_ranges; i++) {
> | ^~
> kernel/crash_core.c:397:29: error: invalid use of undefined type 'struct crash_mem'
> 397 | mstart = mem->ranges[i].start;
> | ^~
> kernel/crash_core.c:398:27: error: invalid use of undefined type 'struct crash_mem'
> 398 | mend = mem->ranges[i].end;
> | ^~
> kernel/crash_core.c: At top level:
> kernel/crash_core.c:420:36: warning: 'struct crash_mem' declared inside parameter list will not be visible outside of this definition or declaration
> 420 | int crash_exclude_mem_range(struct crash_mem *mem,
> | ^~~~~~~~~
> kernel/crash_core.c: In function 'crash_exclude_mem_range':
> kernel/crash_core.c:427:28: error: invalid use of undefined type 'struct crash_mem'
> 427 | for (i = 0; i < mem->nr_ranges; i++) {
> | ^~
> kernel/crash_core.c:428:28: error: invalid use of undefined type 'struct crash_mem'
> 428 | start = mem->ranges[i].start;
> | ^~
> kernel/crash_core.c:429:26: error: invalid use of undefined type 'struct crash_mem'
> 429 | end = mem->ranges[i].end;
> | ^~
> kernel/crash_core.c:444:28: error: invalid use of undefined type 'struct crash_mem'
> 444 | mem->ranges[i].start = 0;
> | ^~
> kernel/crash_core.c:445:28: error: invalid use of undefined type 'struct crash_mem'
> 445 | mem->ranges[i].end = 0;
> | ^~
> kernel/crash_core.c:446:36: error: invalid use of undefined type 'struct crash_mem'
> 446 | if (i < mem->nr_ranges - 1) {
> | ^~
> kernel/crash_core.c:448:52: error: invalid use of undefined type 'struct crash_mem'
> 448 | for (j = i; j < mem->nr_ranges - 1; j++) {
> | ^~
> kernel/crash_core.c:449:44: error: invalid use of undefined type 'struct crash_mem'
> 449 | mem->ranges[j].start =
> | ^~
> kernel/crash_core.c:450:52: error: invalid use of undefined type 'struct crash_mem'
> 450 | mem->ranges[j+1].start;
> | ^~
> kernel/crash_core.c:451:44: error: invalid use of undefined type 'struct crash_mem'
> 451 | mem->ranges[j].end =
> | ^~
> kernel/crash_core.c:452:60: error: invalid use of undefined type 'struct crash_mem'
> 452 | mem->ranges[j+1].end;
> | ^~
> kernel/crash_core.c:461:36: error: invalid use of undefined type 'struct crash_mem'
> 461 | mem->nr_ranges--;
> | ^~
> kernel/crash_core.c:464:28: error: invalid use of undefined type 'struct crash_mem'
> 464 | mem->nr_ranges--;
> | ^~
> kernel/crash_core.c:470:28: error: invalid use of undefined type 'struct crash_mem'
> 470 | mem->ranges[i].end = p_start - 1;
> | ^~
> kernel/crash_core.c:474:28: error: invalid use of undefined type 'struct crash_mem'
> 474 | mem->ranges[i].end = p_start - 1;
> | ^~
> kernel/crash_core.c:476:28: error: invalid use of undefined type 'struct crash_mem'
> 476 | mem->ranges[i].start = p_end + 1;
> | ^~
> kernel/crash_core.c:485:21: error: invalid use of undefined type 'struct crash_mem'
> 485 | if (i == mem->max_nr_ranges - 1)
> | ^~
> kernel/crash_core.c:490:20: error: invalid use of undefined type 'struct crash_mem'
> 490 | if (j < mem->nr_ranges) {
> | ^~
> kernel/crash_core.c:492:29: error: invalid use of undefined type 'struct crash_mem'
> 492 | for (i = mem->nr_ranges - 1; i >= j; i--)
> | ^~
> kernel/crash_core.c:493:28: error: invalid use of undefined type 'struct crash_mem'
> 493 | mem->ranges[i + 1] = mem->ranges[i];
> | ^~
> kernel/crash_core.c:493:49: error: invalid use of undefined type 'struct crash_mem'
> 493 | mem->ranges[i + 1] = mem->ranges[i];
> | ^~
> kernel/crash_core.c:496:12: error: invalid use of undefined type 'struct crash_mem'
> 496 | mem->ranges[j].start = temp_range.start;
> | ^~
> kernel/crash_core.c:497:12: error: invalid use of undefined type 'struct crash_mem'
> 497 | mem->ranges[j].end = temp_range.end;
> | ^~
> kernel/crash_core.c:498:12: error: invalid use of undefined type 'struct crash_mem'
> 498 | mem->nr_ranges++;
> | ^~
>
> I am not sure exactly which commit caused but I have revreted these
> for today:
>
> 6a41fd4665e6 ("x86/crash: optimize CPU changes")
> add3b7e011e9 ("crash: change crash_prepare_elf64_headers() to for_each_possible_cpu()")
> 4a7eed40a7bc ("crash: hotplug support for kexec_load()")
> 8ce41bc6b147 ("x86/crash: add x86 crash hotplug support")
> 2b765af0c14f ("crash: memory and CPU hotplug sysfs attributes")
> 36d2b573329b ("kexec: exclude elfcorehdr from the segment digest")
> ccfe0040500f ("crash: add generic infrastructure for crash hotplug support")
> 626775922a57 ("crash: move a few code bits to setup support of crash hotplug")
>
^ permalink raw reply [flat|nested] 138+ messages in thread
* linux-next: build failure after merge of the mm tree
@ 2023-08-08 4:40 Stephen Rothwell
2023-08-08 15:20 ` Eric DeVolder
2023-08-11 17:16 ` Eric DeVolder
0 siblings, 2 replies; 138+ messages in thread
From: Stephen Rothwell @ 2023-08-08 4:40 UTC (permalink / raw)
To: Andrew Morton
Cc: Linux Kernel Mailing List, Linux Next Mailing List,
Eric DeVolder, Sourabh Jain
[-- Attachment #1: Type: text/plain, Size: 9547 bytes --]
Hi all,
After merging the mm tree, today's linux-next build (powerpc
ppc44x_defconfig) failed like this:
In file included from kernel/crash_core.c:23:
kernel/kexec_internal.h:11:54: warning: 'struct kexec_segment' declared inside parameter list will not be visible outside of this definition or declaration
11 | int kimage_load_segment(struct kimage *image, struct kexec_segment *segment);
| ^~~~~~~~~~~~~
kernel/crash_core.c:321:40: warning: 'struct crash_mem' declared inside parameter list will not be visible outside of this definition or declaration
321 | int crash_prepare_elf64_headers(struct crash_mem *mem, int need_kernel_map,
| ^~~~~~~~~
kernel/crash_core.c: In function 'crash_prepare_elf64_headers':
kernel/crash_core.c:334:23: error: invalid use of undefined type 'struct crash_mem'
334 | nr_phdr += mem->nr_ranges;
| ^~
In file included from include/vdso/const.h:5,
from include/linux/const.h:4,
from include/linux/bits.h:5,
from include/linux/ratelimit_types.h:5,
from include/linux/printk.h:9,
from include/asm-generic/bug.h:22,
from arch/powerpc/include/asm/bug.h:116,
from include/linux/bug.h:5,
from arch/powerpc/include/asm/cmpxchg.h:8,
from arch/powerpc/include/asm/atomic.h:11,
from include/linux/atomic.h:7,
from include/linux/mm_types_task.h:13,
from include/linux/mm_types.h:5,
from include/linux/buildid.h:5,
from kernel/crash_core.c:7:
kernel/crash_core.c:346:32: error: 'ELF_CORE_HEADER_ALIGN' undeclared (first use in this function)
346 | elf_sz = ALIGN(elf_sz, ELF_CORE_HEADER_ALIGN);
| ^~~~~~~~~~~~~~~~~~~~~
include/uapi/linux/const.h:32:50: note: in definition of macro '__ALIGN_KERNEL_MASK'
32 | #define __ALIGN_KERNEL_MASK(x, mask) (((x) + (mask)) & ~(mask))
| ^~~~
include/linux/align.h:8:33: note: in expansion of macro '__ALIGN_KERNEL'
8 | #define ALIGN(x, a) __ALIGN_KERNEL((x), (a))
| ^~~~~~~~~~~~~~
kernel/crash_core.c:346:18: note: in expansion of macro 'ALIGN'
346 | elf_sz = ALIGN(elf_sz, ELF_CORE_HEADER_ALIGN);
| ^~~~~
kernel/crash_core.c:346:32: note: each undeclared identifier is reported only once for each function it appears in
346 | elf_sz = ALIGN(elf_sz, ELF_CORE_HEADER_ALIGN);
| ^~~~~~~~~~~~~~~~~~~~~
include/uapi/linux/const.h:32:50: note: in definition of macro '__ALIGN_KERNEL_MASK'
32 | #define __ALIGN_KERNEL_MASK(x, mask) (((x) + (mask)) & ~(mask))
| ^~~~
include/linux/align.h:8:33: note: in expansion of macro '__ALIGN_KERNEL'
8 | #define ALIGN(x, a) __ALIGN_KERNEL((x), (a))
| ^~~~~~~~~~~~~~
kernel/crash_core.c:346:18: note: in expansion of macro 'ALIGN'
346 | elf_sz = ALIGN(elf_sz, ELF_CORE_HEADER_ALIGN);
| ^~~~~
kernel/crash_core.c:396:28: error: invalid use of undefined type 'struct crash_mem'
396 | for (i = 0; i < mem->nr_ranges; i++) {
| ^~
kernel/crash_core.c:397:29: error: invalid use of undefined type 'struct crash_mem'
397 | mstart = mem->ranges[i].start;
| ^~
kernel/crash_core.c:398:27: error: invalid use of undefined type 'struct crash_mem'
398 | mend = mem->ranges[i].end;
| ^~
kernel/crash_core.c: At top level:
kernel/crash_core.c:420:36: warning: 'struct crash_mem' declared inside parameter list will not be visible outside of this definition or declaration
420 | int crash_exclude_mem_range(struct crash_mem *mem,
| ^~~~~~~~~
kernel/crash_core.c: In function 'crash_exclude_mem_range':
kernel/crash_core.c:427:28: error: invalid use of undefined type 'struct crash_mem'
427 | for (i = 0; i < mem->nr_ranges; i++) {
| ^~
kernel/crash_core.c:428:28: error: invalid use of undefined type 'struct crash_mem'
428 | start = mem->ranges[i].start;
| ^~
kernel/crash_core.c:429:26: error: invalid use of undefined type 'struct crash_mem'
429 | end = mem->ranges[i].end;
| ^~
kernel/crash_core.c:444:28: error: invalid use of undefined type 'struct crash_mem'
444 | mem->ranges[i].start = 0;
| ^~
kernel/crash_core.c:445:28: error: invalid use of undefined type 'struct crash_mem'
445 | mem->ranges[i].end = 0;
| ^~
kernel/crash_core.c:446:36: error: invalid use of undefined type 'struct crash_mem'
446 | if (i < mem->nr_ranges - 1) {
| ^~
kernel/crash_core.c:448:52: error: invalid use of undefined type 'struct crash_mem'
448 | for (j = i; j < mem->nr_ranges - 1; j++) {
| ^~
kernel/crash_core.c:449:44: error: invalid use of undefined type 'struct crash_mem'
449 | mem->ranges[j].start =
| ^~
kernel/crash_core.c:450:52: error: invalid use of undefined type 'struct crash_mem'
450 | mem->ranges[j+1].start;
| ^~
kernel/crash_core.c:451:44: error: invalid use of undefined type 'struct crash_mem'
451 | mem->ranges[j].end =
| ^~
kernel/crash_core.c:452:60: error: invalid use of undefined type 'struct crash_mem'
452 | mem->ranges[j+1].end;
| ^~
kernel/crash_core.c:461:36: error: invalid use of undefined type 'struct crash_mem'
461 | mem->nr_ranges--;
| ^~
kernel/crash_core.c:464:28: error: invalid use of undefined type 'struct crash_mem'
464 | mem->nr_ranges--;
| ^~
kernel/crash_core.c:470:28: error: invalid use of undefined type 'struct crash_mem'
470 | mem->ranges[i].end = p_start - 1;
| ^~
kernel/crash_core.c:474:28: error: invalid use of undefined type 'struct crash_mem'
474 | mem->ranges[i].end = p_start - 1;
| ^~
kernel/crash_core.c:476:28: error: invalid use of undefined type 'struct crash_mem'
476 | mem->ranges[i].start = p_end + 1;
| ^~
kernel/crash_core.c:485:21: error: invalid use of undefined type 'struct crash_mem'
485 | if (i == mem->max_nr_ranges - 1)
| ^~
kernel/crash_core.c:490:20: error: invalid use of undefined type 'struct crash_mem'
490 | if (j < mem->nr_ranges) {
| ^~
kernel/crash_core.c:492:29: error: invalid use of undefined type 'struct crash_mem'
492 | for (i = mem->nr_ranges - 1; i >= j; i--)
| ^~
kernel/crash_core.c:493:28: error: invalid use of undefined type 'struct crash_mem'
493 | mem->ranges[i + 1] = mem->ranges[i];
| ^~
kernel/crash_core.c:493:49: error: invalid use of undefined type 'struct crash_mem'
493 | mem->ranges[i + 1] = mem->ranges[i];
| ^~
kernel/crash_core.c:496:12: error: invalid use of undefined type 'struct crash_mem'
496 | mem->ranges[j].start = temp_range.start;
| ^~
kernel/crash_core.c:497:12: error: invalid use of undefined type 'struct crash_mem'
497 | mem->ranges[j].end = temp_range.end;
| ^~
kernel/crash_core.c:498:12: error: invalid use of undefined type 'struct crash_mem'
498 | mem->nr_ranges++;
| ^~
I am not sure exactly which commit caused but I have revreted these
for today:
6a41fd4665e6 ("x86/crash: optimize CPU changes")
add3b7e011e9 ("crash: change crash_prepare_elf64_headers() to for_each_possible_cpu()")
4a7eed40a7bc ("crash: hotplug support for kexec_load()")
8ce41bc6b147 ("x86/crash: add x86 crash hotplug support")
2b765af0c14f ("crash: memory and CPU hotplug sysfs attributes")
36d2b573329b ("kexec: exclude elfcorehdr from the segment digest")
ccfe0040500f ("crash: add generic infrastructure for crash hotplug support")
626775922a57 ("crash: move a few code bits to setup support of crash hotplug")
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2023-07-26 5:14 Stephen Rothwell
@ 2023-07-26 13:22 ` Kuan-Ying Lee (李冠穎)
0 siblings, 0 replies; 138+ messages in thread
From: Kuan-Ying Lee (李冠穎) @ 2023-07-26 13:22 UTC (permalink / raw)
To: sfr, akpm; +Cc: linux-kernel, linux-next
On Wed, 2023-07-26 at 15:14 +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the mm tree, today's linux-next build (s390 defconfig)
> failed like this:
>
> scripts/gdb/linux/constants.py.in:26:10: fatal error: asm/memory.h:
> No such file or directory
> 26 | #include <asm/memory.h>
> | ^~~~~~~~~~~~~~
>
> Caused by commit
>
> dc7e66b9c82a ("scripts/gdb/aarch64: add aarch64 page operation
> helper commands and configs")
>
> I have reverted that commit (and the following 4) for today.
>
Hi Stephen,
Thanks for the report.
Andrew, could you help to drop these GDB changes?
I will try to fix it in v2.
Thanks,
Kuan-Ying Lee
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2023-07-26 5:22 ` Aneesh Kumar K.V
@ 2023-07-26 6:51 ` Stephen Rothwell
0 siblings, 0 replies; 138+ messages in thread
From: Stephen Rothwell @ 2023-07-26 6:51 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: Andrew Morton, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1183 bytes --]
Hi Aneesh,
On Wed, 26 Jul 2023 10:52:33 +0530 "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> wrote:
>
> Thanks for the report. Can you add the below diff. We should look at
> ppc64 not including radix headers if CONFIG_PPC_RADIX_MMU is disabled.
> But for now we can keep the below diff?
>
> diff --git a/arch/powerpc/include/asm/book3s/64/radix.h b/arch/powerpc/include/asm/book3s/64/radix.h
> index 3195f268ed7f..357e23a403d3 100644
> --- a/arch/powerpc/include/asm/book3s/64/radix.h
> +++ b/arch/powerpc/include/asm/book3s/64/radix.h
> @@ -364,8 +364,10 @@ int radix__remove_section_mapping(unsigned long start, unsigned long end);
>
> void radix__kernel_map_pages(struct page *page, int numpages, int enable);
>
> +#ifdef CONFIG_ARCH_WANT_OPTIMIZE_DAX_VMEMMAP
> #define vmemmap_can_optimize vmemmap_can_optimize
> bool vmemmap_can_optimize(struct vmem_altmap *altmap, struct dev_pagemap *pgmap);
> +#endif
>
> #define vmemmap_populate_compound_pages vmemmap_populate_compound_pages
> int __meminit vmemmap_populate_compound_pages(unsigned long start_pfn,
That fixes the powerpc64 allnoconfig build for me
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2023-07-26 4:53 Stephen Rothwell
@ 2023-07-26 5:22 ` Aneesh Kumar K.V
2023-07-26 6:51 ` Stephen Rothwell
0 siblings, 1 reply; 138+ messages in thread
From: Aneesh Kumar K.V @ 2023-07-26 5:22 UTC (permalink / raw)
To: Stephen Rothwell, Andrew Morton
Cc: Linux Kernel Mailing List, Linux Next Mailing List
Hi Stephen,
Stephen Rothwell <sfr@canb.auug.org.au> writes:
> Hi all,
>
> After merging the mm tree, today's linux-next build (powerpc64
> allnoconfig) failed like this:
>
> In file included from arch/powerpc/include/asm/book3s/64/pgtable.h:285,
> from arch/powerpc/include/asm/book3s/64/mmu-hash.h:20,
> from arch/powerpc/include/asm/book3s/64/mmu.h:32,
> from arch/powerpc/include/asm/mmu.h:396,
> from arch/powerpc/include/asm/lppaca.h:46,
> from arch/powerpc/include/asm/paca.h:18,
> from arch/powerpc/include/asm/current.h:13,
> from include/linux/thread_info.h:23,
> from include/asm-generic/preempt.h:5,
> from ./arch/powerpc/include/generated/asm/preempt.h:1,
> from include/linux/preempt.h:79,
> from include/linux/spinlock.h:56,
> from include/linux/ipc.h:5,
> from include/uapi/linux/sem.h:5,
> from include/linux/sem.h:5,
> from include/linux/compat.h:14,
> from arch/powerpc/kernel/asm-offsets.c:12:
> arch/powerpc/include/asm/book3s/64/radix.h:367:30: error: static declaration of 'vmemmap_can_optimize' follows non-static declaration
> 367 | #define vmemmap_can_optimize vmemmap_can_optimize
> | ^~~~~~~~~~~~~~~~~~~~
> include/linux/mm.h:3695:20: note: in expansion of macro 'vmemmap_can_optimize'
> 3695 | static inline bool vmemmap_can_optimize(struct vmem_altmap *altmap,
> | ^~~~~~~~~~~~~~~~~~~~
> arch/powerpc/include/asm/book3s/64/radix.h:367:30: note: previous declaration of 'vmemmap_can_optimize' with type 'bool(struct vmem_altmap *, struct dev_pagemap *)' {aka '_Bool(struct vmem_altmap *, struct dev_pagemap *)'}
> 367 | #define vmemmap_can_optimize vmemmap_can_optimize
> | ^~~~~~~~~~~~~~~~~~~~
> arch/powerpc/include/asm/book3s/64/radix.h:368:6: note: in expansion of macro 'vmemmap_can_optimize'
> 368 | bool vmemmap_can_optimize(struct vmem_altmap *altmap, struct dev_pagemap *pgmap);
> | ^~~~~~~~~~~~~~~~~~~~
>
> Presumably caused by commit
>
> f684ffc3ac9f ("powerpc/book3s64/radix: add support for vmemmap optimization for radix")
>
> I have reverted that commit (and the following 2) for today.
Thanks for the report. Can you add the below diff. We should look at
ppc64 not including radix headers if CONFIG_PPC_RADIX_MMU is disabled.
But for now we can keep the below diff?
diff --git a/arch/powerpc/include/asm/book3s/64/radix.h b/arch/powerpc/include/asm/book3s/64/radix.h
index 3195f268ed7f..357e23a403d3 100644
--- a/arch/powerpc/include/asm/book3s/64/radix.h
+++ b/arch/powerpc/include/asm/book3s/64/radix.h
@@ -364,8 +364,10 @@ int radix__remove_section_mapping(unsigned long start, unsigned long end);
void radix__kernel_map_pages(struct page *page, int numpages, int enable);
+#ifdef CONFIG_ARCH_WANT_OPTIMIZE_DAX_VMEMMAP
#define vmemmap_can_optimize vmemmap_can_optimize
bool vmemmap_can_optimize(struct vmem_altmap *altmap, struct dev_pagemap *pgmap);
+#endif
#define vmemmap_populate_compound_pages vmemmap_populate_compound_pages
int __meminit vmemmap_populate_compound_pages(unsigned long start_pfn,
^ permalink raw reply related [flat|nested] 138+ messages in thread
* linux-next: build failure after merge of the mm tree
@ 2023-07-26 5:14 Stephen Rothwell
2023-07-26 13:22 ` Kuan-Ying Lee (李冠穎)
0 siblings, 1 reply; 138+ messages in thread
From: Stephen Rothwell @ 2023-07-26 5:14 UTC (permalink / raw)
To: Andrew Morton
Cc: Kuan-Ying Lee, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 479 bytes --]
Hi all,
After merging the mm tree, today's linux-next build (s390 defconfig)
failed like this:
scripts/gdb/linux/constants.py.in:26:10: fatal error: asm/memory.h: No such file or directory
26 | #include <asm/memory.h>
| ^~~~~~~~~~~~~~
Caused by commit
dc7e66b9c82a ("scripts/gdb/aarch64: add aarch64 page operation helper commands and configs")
I have reverted that commit (and the following 4) for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* linux-next: build failure after merge of the mm tree
@ 2023-07-26 4:53 Stephen Rothwell
2023-07-26 5:22 ` Aneesh Kumar K.V
0 siblings, 1 reply; 138+ messages in thread
From: Stephen Rothwell @ 2023-07-26 4:53 UTC (permalink / raw)
To: Andrew Morton
Cc: Aneesh Kumar K.V, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 2356 bytes --]
Hi all,
After merging the mm tree, today's linux-next build (powerpc64
allnoconfig) failed like this:
In file included from arch/powerpc/include/asm/book3s/64/pgtable.h:285,
from arch/powerpc/include/asm/book3s/64/mmu-hash.h:20,
from arch/powerpc/include/asm/book3s/64/mmu.h:32,
from arch/powerpc/include/asm/mmu.h:396,
from arch/powerpc/include/asm/lppaca.h:46,
from arch/powerpc/include/asm/paca.h:18,
from arch/powerpc/include/asm/current.h:13,
from include/linux/thread_info.h:23,
from include/asm-generic/preempt.h:5,
from ./arch/powerpc/include/generated/asm/preempt.h:1,
from include/linux/preempt.h:79,
from include/linux/spinlock.h:56,
from include/linux/ipc.h:5,
from include/uapi/linux/sem.h:5,
from include/linux/sem.h:5,
from include/linux/compat.h:14,
from arch/powerpc/kernel/asm-offsets.c:12:
arch/powerpc/include/asm/book3s/64/radix.h:367:30: error: static declaration of 'vmemmap_can_optimize' follows non-static declaration
367 | #define vmemmap_can_optimize vmemmap_can_optimize
| ^~~~~~~~~~~~~~~~~~~~
include/linux/mm.h:3695:20: note: in expansion of macro 'vmemmap_can_optimize'
3695 | static inline bool vmemmap_can_optimize(struct vmem_altmap *altmap,
| ^~~~~~~~~~~~~~~~~~~~
arch/powerpc/include/asm/book3s/64/radix.h:367:30: note: previous declaration of 'vmemmap_can_optimize' with type 'bool(struct vmem_altmap *, struct dev_pagemap *)' {aka '_Bool(struct vmem_altmap *, struct dev_pagemap *)'}
367 | #define vmemmap_can_optimize vmemmap_can_optimize
| ^~~~~~~~~~~~~~~~~~~~
arch/powerpc/include/asm/book3s/64/radix.h:368:6: note: in expansion of macro 'vmemmap_can_optimize'
368 | bool vmemmap_can_optimize(struct vmem_altmap *altmap, struct dev_pagemap *pgmap);
| ^~~~~~~~~~~~~~~~~~~~
Presumably caused by commit
f684ffc3ac9f ("powerpc/book3s64/radix: add support for vmemmap optimization for radix")
I have reverted that commit (and the following 2) for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2023-07-19 4:32 Stephen Rothwell
@ 2023-07-19 5:55 ` Alistair Popple
0 siblings, 0 replies; 138+ messages in thread
From: Alistair Popple @ 2023-07-19 5:55 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Andrew Morton, Linux Kernel Mailing List, Linux Next Mailing List
Thanks Stephen.
Looks like a conflict with 9c47011d3302 ("arm64: support
batched/deferred tlb shootdown during page reclamation/migration") which
restructured that code slightly. I have to respin my series anyway so
will rebase on mm-unstable rather than v6.5-rc2.
- Alistair
Stephen Rothwell <sfr@canb.auug.org.au> writes:
> [[PGP Signed Part:Undecided]]
> Hi all,
>
> After merging the mm tree, today's linux-next build (arm64 defconfig)
> failed like this:
>
> In file included from arch/arm64/include/asm/pgtable.h:15,
> from include/linux/pgtable.h:6,
> from arch/arm64/include/asm/io.h:12,
> from include/linux/io.h:13,
> from include/acpi/acpi_io.h:5,
> from include/linux/acpi.h:37,
> from include/acpi/apei.h:9,
> from include/acpi/ghes.h:5,
> from include/linux/arm_sdei.h:8,
> from arch/arm64/kernel/asm-offsets.c:10:
> arch/arm64/include/asm/tlbflush.h: In function '__flush_tlb_page_nosync':
> arch/arm64/include/asm/tlbflush.h:268:53: error: 'vma' undeclared (first use in this function); did you mean 'cma'?
> 268 | mmu_notifier_arch_invalidate_secondary_tlbs(vma->vm_mm, uaddr & PAGE_MASK,
> | ^~~
> | cma
>
> Caused by commit
>
> 8c2be11e06f4 ("mmu_notifiers: call arch_invalidate_secondary_tlbs() when invalidating TLBs")
>
> I have reverted that commit (and the following clear
> one and the two
> earlier ones - otherwise it would not buildfrom) for today.
^ permalink raw reply [flat|nested] 138+ messages in thread
* linux-next: build failure after merge of the mm tree
@ 2023-07-19 4:32 Stephen Rothwell
2023-07-19 5:55 ` Alistair Popple
0 siblings, 1 reply; 138+ messages in thread
From: Stephen Rothwell @ 2023-07-19 4:32 UTC (permalink / raw)
To: Andrew Morton
Cc: Alistair Popple, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1313 bytes --]
Hi all,
After merging the mm tree, today's linux-next build (arm64 defconfig)
failed like this:
In file included from arch/arm64/include/asm/pgtable.h:15,
from include/linux/pgtable.h:6,
from arch/arm64/include/asm/io.h:12,
from include/linux/io.h:13,
from include/acpi/acpi_io.h:5,
from include/linux/acpi.h:37,
from include/acpi/apei.h:9,
from include/acpi/ghes.h:5,
from include/linux/arm_sdei.h:8,
from arch/arm64/kernel/asm-offsets.c:10:
arch/arm64/include/asm/tlbflush.h: In function '__flush_tlb_page_nosync':
arch/arm64/include/asm/tlbflush.h:268:53: error: 'vma' undeclared (first use in this function); did you mean 'cma'?
268 | mmu_notifier_arch_invalidate_secondary_tlbs(vma->vm_mm, uaddr & PAGE_MASK,
| ^~~
| cma
Caused by commit
8c2be11e06f4 ("mmu_notifiers: call arch_invalidate_secondary_tlbs() when invalidating TLBs")
I have reverted that commit (and the following clear
one and the two
earlier ones - otherwise it would not buildfrom) for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2023-07-18 17:34 ` Andrew Morton
@ 2023-07-18 21:07 ` Andy Shevchenko
0 siblings, 0 replies; 138+ messages in thread
From: Andy Shevchenko @ 2023-07-18 21:07 UTC (permalink / raw)
To: Andrew Morton
Cc: Stephen Rothwell, Linux Kernel Mailing List, Linux Next Mailing List
On Tue, Jul 18, 2023 at 10:34:30AM -0700, Andrew Morton wrote:
> On Tue, 18 Jul 2023 16:43:39 +0300 Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> > On Tue, Jul 18, 2023 at 10:02:57AM +1000, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > After merging the mm tree, today's linux-next build (arm
> > > multi_v7_defconfig) failed like this:
> >
> > Thank you for this report!
> >
> > Andrew, since it's in a separate patch, can you drop the change to
> > include/linux/arm-smccc.h?
>
> I actually dropped the whole series.
Okay, I fixed that locally and soon send a v4.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2023-07-18 13:43 ` Andy Shevchenko
@ 2023-07-18 17:34 ` Andrew Morton
2023-07-18 21:07 ` Andy Shevchenko
0 siblings, 1 reply; 138+ messages in thread
From: Andrew Morton @ 2023-07-18 17:34 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Stephen Rothwell, Linux Kernel Mailing List, Linux Next Mailing List
On Tue, 18 Jul 2023 16:43:39 +0300 Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> On Tue, Jul 18, 2023 at 10:02:57AM +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the mm tree, today's linux-next build (arm
> > multi_v7_defconfig) failed like this:
>
> Thank you for this report!
>
> Andrew, since it's in a separate patch, can you drop the change to
> include/linux/arm-smccc.h?
I actually dropped the whole series.
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2023-07-18 0:02 Stephen Rothwell
@ 2023-07-18 13:43 ` Andy Shevchenko
2023-07-18 17:34 ` Andrew Morton
0 siblings, 1 reply; 138+ messages in thread
From: Andy Shevchenko @ 2023-07-18 13:43 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Andrew Morton, Linux Kernel Mailing List, Linux Next Mailing List
On Tue, Jul 18, 2023 at 10:02:57AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the mm tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
Thank you for this report!
Andrew, since it's in a separate patch, can you drop the change to
include/linux/arm-smccc.h?
I will try to figure out what's going on here.
...
> Presumably caused by commits
by this one
> fceebffabbb6 ("arm64: smccc: replace custom COUNT_ARGS() & CONCATENATE() implementations")
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 138+ messages in thread
* linux-next: build failure after merge of the mm tree
@ 2023-07-18 0:02 Stephen Rothwell
2023-07-18 13:43 ` Andy Shevchenko
0 siblings, 1 reply; 138+ messages in thread
From: Stephen Rothwell @ 2023-07-18 0:02 UTC (permalink / raw)
To: Andrew Morton
Cc: Andy Shevchenko, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 33424 bytes --]
Hi all,
After merging the mm tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
In file included from include/linux/arm-smccc.h:8,
from arch/arm/mm/proc-v7-bugs.c:2:
arch/arm/mm/proc-v7-bugs.c: In function 'spectre_v2_get_cpu_fw_mitigation_state':
include/linux/arm-smccc.h:485:29: error: '__declare_arg_3' undeclared (first use in this function)
485 | CONCATENATE(__declare_arg_, COUNT_ARGS(__VA_ARGS__)); \
| ^~~~~~~~~~~~~~
include/linux/args.h:25:24: note: in definition of macro '__CONCAT'
25 | #define __CONCAT(a, b) a ## b
| ^
include/linux/arm-smccc.h:485:17: note: in expansion of macro 'CONCATENATE'
485 | CONCATENATE(__declare_arg_, COUNT_ARGS(__VA_ARGS__)); \
| ^~~~~~~~~~~
include/linux/arm-smccc.h:526:33: note: in expansion of macro '__arm_smccc_1_1'
526 | #define arm_smccc_1_1_hvc(...) __arm_smccc_1_1(SMCCC_HVC_INST, __VA_ARGS__)
| ^~~~~~~~~~~~~~~
include/linux/arm-smccc.h:563:25: note: in expansion of macro 'arm_smccc_1_1_hvc'
563 | arm_smccc_1_1_hvc(__VA_ARGS__); \
| ^~~~~~~~~~~~~~~~~
arch/arm/mm/proc-v7-bugs.c:17:9: note: in expansion of macro 'arm_smccc_1_1_invoke'
17 | arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
| ^~~~~~~~~~~~~~~~~~~~
include/linux/arm-smccc.h:485:29: note: each undeclared identifier is reported only once for each function it appears in
485 | CONCATENATE(__declare_arg_, COUNT_ARGS(__VA_ARGS__)); \
| ^~~~~~~~~~~~~~
include/linux/args.h:25:24: note: in definition of macro '__CONCAT'
25 | #define __CONCAT(a, b) a ## b
| ^
include/linux/arm-smccc.h:485:17: note: in expansion of macro 'CONCATENATE'
485 | CONCATENATE(__declare_arg_, COUNT_ARGS(__VA_ARGS__)); \
| ^~~~~~~~~~~
include/linux/arm-smccc.h:526:33: note: in expansion of macro '__arm_smccc_1_1'
526 | #define arm_smccc_1_1_hvc(...) __arm_smccc_1_1(SMCCC_HVC_INST, __VA_ARGS__)
| ^~~~~~~~~~~~~~~
include/linux/arm-smccc.h:563:25: note: in expansion of macro 'arm_smccc_1_1_hvc'
563 | arm_smccc_1_1_hvc(__VA_ARGS__); \
| ^~~~~~~~~~~~~~~~~
arch/arm/mm/proc-v7-bugs.c:17:9: note: in expansion of macro 'arm_smccc_1_1_invoke'
17 | arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
| ^~~~~~~~~~~~~~~~~~~~
include/linux/arm-smccc.h:417:38: error: 'arg0' undeclared (first use in this function); did you mean 'r0'?
417 | #define __constraint_read_0 "r" (arg0)
| ^~~~
include/linux/arm-smccc.h:418:33: note: in expansion of macro '__constraint_read_0'
418 | #define __constraint_read_1 __constraint_read_0, "r" (arg1)
| ^~~~~~~~~~~~~~~~~~~
include/linux/arm-smccc.h:419:33: note: in expansion of macro '__constraint_read_1'
419 | #define __constraint_read_2 __constraint_read_1, "r" (arg2)
| ^~~~~~~~~~~~~~~~~~~
include/linux/arm-smccc.h:420:33: note: in expansion of macro '__constraint_read_2'
420 | #define __constraint_read_3 __constraint_read_2, "r" (arg3)
| ^~~~~~~~~~~~~~~~~~~
include/linux/args.h:25:24: note: in expansion of macro '__constraint_read_3'
25 | #define __CONCAT(a, b) a ## b
| ^
include/linux/args.h:26:27: note: in expansion of macro '__CONCAT'
26 | #define CONCATENATE(a, b) __CONCAT(a, b)
| ^~~~~~~~
include/linux/arm-smccc.h:489:32: note: in expansion of macro 'CONCATENATE'
489 | : CONCATENATE(__constraint_read_, \
| ^~~~~~~~~~~
include/linux/arm-smccc.h:526:33: note: in expansion of macro '__arm_smccc_1_1'
526 | #define arm_smccc_1_1_hvc(...) __arm_smccc_1_1(SMCCC_HVC_INST, __VA_ARGS__)
| ^~~~~~~~~~~~~~~
include/linux/arm-smccc.h:563:25: note: in expansion of macro 'arm_smccc_1_1_hvc'
563 | arm_smccc_1_1_hvc(__VA_ARGS__); \
| ^~~~~~~~~~~~~~~~~
arch/arm/mm/proc-v7-bugs.c:17:9: note: in expansion of macro 'arm_smccc_1_1_invoke'
17 | arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
| ^~~~~~~~~~~~~~~~~~~~
include/linux/arm-smccc.h:418:59: error: 'arg1' undeclared (first use in this function); did you mean 'r1'?
418 | #define __constraint_read_1 __constraint_read_0, "r" (arg1)
| ^~~~
include/linux/arm-smccc.h:419:33: note: in expansion of macro '__constraint_read_1'
419 | #define __constraint_read_2 __constraint_read_1, "r" (arg2)
| ^~~~~~~~~~~~~~~~~~~
include/linux/arm-smccc.h:420:33: note: in expansion of macro '__constraint_read_2'
420 | #define __constraint_read_3 __constraint_read_2, "r" (arg3)
| ^~~~~~~~~~~~~~~~~~~
include/linux/args.h:25:24: note: in expansion of macro '__constraint_read_3'
25 | #define __CONCAT(a, b) a ## b
| ^
include/linux/args.h:26:27: note: in expansion of macro '__CONCAT'
26 | #define CONCATENATE(a, b) __CONCAT(a, b)
| ^~~~~~~~
include/linux/arm-smccc.h:489:32: note: in expansion of macro 'CONCATENATE'
489 | : CONCATENATE(__constraint_read_, \
| ^~~~~~~~~~~
include/linux/arm-smccc.h:526:33: note: in expansion of macro '__arm_smccc_1_1'
526 | #define arm_smccc_1_1_hvc(...) __arm_smccc_1_1(SMCCC_HVC_INST, __VA_ARGS__)
| ^~~~~~~~~~~~~~~
include/linux/arm-smccc.h:563:25: note: in expansion of macro 'arm_smccc_1_1_hvc'
563 | arm_smccc_1_1_hvc(__VA_ARGS__); \
| ^~~~~~~~~~~~~~~~~
arch/arm/mm/proc-v7-bugs.c:17:9: note: in expansion of macro 'arm_smccc_1_1_invoke'
17 | arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
| ^~~~~~~~~~~~~~~~~~~~
include/linux/arm-smccc.h:419:59: error: 'arg2' undeclared (first use in this function); did you mean 'r2'?
419 | #define __constraint_read_2 __constraint_read_1, "r" (arg2)
| ^~~~
include/linux/arm-smccc.h:420:33: note: in expansion of macro '__constraint_read_2'
420 | #define __constraint_read_3 __constraint_read_2, "r" (arg3)
| ^~~~~~~~~~~~~~~~~~~
include/linux/args.h:25:24: note: in expansion of macro '__constraint_read_3'
25 | #define __CONCAT(a, b) a ## b
| ^
include/linux/args.h:26:27: note: in expansion of macro '__CONCAT'
26 | #define CONCATENATE(a, b) __CONCAT(a, b)
| ^~~~~~~~
include/linux/arm-smccc.h:489:32: note: in expansion of macro 'CONCATENATE'
489 | : CONCATENATE(__constraint_read_, \
| ^~~~~~~~~~~
include/linux/arm-smccc.h:526:33: note: in expansion of macro '__arm_smccc_1_1'
526 | #define arm_smccc_1_1_hvc(...) __arm_smccc_1_1(SMCCC_HVC_INST, __VA_ARGS__)
| ^~~~~~~~~~~~~~~
include/linux/arm-smccc.h:563:25: note: in expansion of macro 'arm_smccc_1_1_hvc'
563 | arm_smccc_1_1_hvc(__VA_ARGS__); \
| ^~~~~~~~~~~~~~~~~
arch/arm/mm/proc-v7-bugs.c:17:9: note: in expansion of macro 'arm_smccc_1_1_invoke'
17 | arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
| ^~~~~~~~~~~~~~~~~~~~
include/linux/arm-smccc.h:420:59: error: 'arg3' undeclared (first use in this function); did you mean 'r3'?
420 | #define __constraint_read_3 __constraint_read_2, "r" (arg3)
| ^~~~
include/linux/args.h:25:24: note: in expansion of macro '__constraint_read_3'
25 | #define __CONCAT(a, b) a ## b
| ^
include/linux/args.h:26:27: note: in expansion of macro '__CONCAT'
26 | #define CONCATENATE(a, b) __CONCAT(a, b)
| ^~~~~~~~
include/linux/arm-smccc.h:489:32: note: in expansion of macro 'CONCATENATE'
489 | : CONCATENATE(__constraint_read_, \
| ^~~~~~~~~~~
include/linux/arm-smccc.h:526:33: note: in expansion of macro '__arm_smccc_1_1'
526 | #define arm_smccc_1_1_hvc(...) __arm_smccc_1_1(SMCCC_HVC_INST, __VA_ARGS__)
| ^~~~~~~~~~~~~~~
include/linux/arm-smccc.h:563:25: note: in expansion of macro 'arm_smccc_1_1_hvc'
563 | arm_smccc_1_1_hvc(__VA_ARGS__); \
| ^~~~~~~~~~~~~~~~~
arch/arm/mm/proc-v7-bugs.c:17:9: note: in expansion of macro 'arm_smccc_1_1_invoke'
17 | arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
| ^~~~~~~~~~~~~~~~~~~~
include/linux/arm-smccc.h:492:21: error: '___res' undeclared (first use in this function)
492 | if (___res) \
| ^~~~~~
include/linux/arm-smccc.h:526:33: note: in expansion of macro '__arm_smccc_1_1'
526 | #define arm_smccc_1_1_hvc(...) __arm_smccc_1_1(SMCCC_HVC_INST, __VA_ARGS__)
| ^~~~~~~~~~~~~~~
include/linux/arm-smccc.h:563:25: note: in expansion of macro 'arm_smccc_1_1_hvc'
563 | arm_smccc_1_1_hvc(__VA_ARGS__); \
| ^~~~~~~~~~~~~~~~~
arch/arm/mm/proc-v7-bugs.c:17:9: note: in expansion of macro 'arm_smccc_1_1_invoke'
17 | arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
| ^~~~~~~~~~~~~~~~~~~~
arch/arm/mm/proc-v7-bugs.c: In function 'call_smc_arch_workaround_1':
include/linux/arm-smccc.h:485:29: error: '__declare_arg_2' undeclared (first use in this function)
485 | CONCATENATE(__declare_arg_, COUNT_ARGS(__VA_ARGS__)); \
| ^~~~~~~~~~~~~~
include/linux/args.h:25:24: note: in definition of macro '__CONCAT'
25 | #define __CONCAT(a, b) a ## b
| ^
include/linux/arm-smccc.h:485:17: note: in expansion of macro 'CONCATENATE'
485 | CONCATENATE(__declare_arg_, COUNT_ARGS(__VA_ARGS__)); \
| ^~~~~~~~~~~
include/linux/arm-smccc.h:510:33: note: in expansion of macro '__arm_smccc_1_1'
510 | #define arm_smccc_1_1_smc(...) __arm_smccc_1_1(SMCCC_SMC_INST, __VA_ARGS__)
| ^~~~~~~~~~~~~~~
arch/arm/mm/proc-v7-bugs.c:58:9: note: in expansion of macro 'arm_smccc_1_1_smc'
58 | arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_1, NULL);
| ^~~~~~~~~~~~~~~~~
include/linux/arm-smccc.h:417:38: error: 'arg0' undeclared (first use in this function); did you mean 'r0'?
417 | #define __constraint_read_0 "r" (arg0)
| ^~~~
include/linux/arm-smccc.h:418:33: note: in expansion of macro '__constraint_read_0'
418 | #define __constraint_read_1 __constraint_read_0, "r" (arg1)
| ^~~~~~~~~~~~~~~~~~~
include/linux/arm-smccc.h:419:33: note: in expansion of macro '__constraint_read_1'
419 | #define __constraint_read_2 __constraint_read_1, "r" (arg2)
| ^~~~~~~~~~~~~~~~~~~
include/linux/args.h:25:24: note: in expansion of macro '__constraint_read_2'
25 | #define __CONCAT(a, b) a ## b
| ^
include/linux/args.h:26:27: note: in expansion of macro '__CONCAT'
26 | #define CONCATENATE(a, b) __CONCAT(a, b)
| ^~~~~~~~
include/linux/arm-smccc.h:489:32: note: in expansion of macro 'CONCATENATE'
489 | : CONCATENATE(__constraint_read_, \
| ^~~~~~~~~~~
include/linux/arm-smccc.h:510:33: note: in expansion of macro '__arm_smccc_1_1'
510 | #define arm_smccc_1_1_smc(...) __arm_smccc_1_1(SMCCC_SMC_INST, __VA_ARGS__)
| ^~~~~~~~~~~~~~~
arch/arm/mm/proc-v7-bugs.c:58:9: note: in expansion of macro 'arm_smccc_1_1_smc'
58 | arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_1, NULL);
| ^~~~~~~~~~~~~~~~~
include/linux/arm-smccc.h:418:59: error: 'arg1' undeclared (first use in this function); did you mean 'r1'?
418 | #define __constraint_read_1 __constraint_read_0, "r" (arg1)
| ^~~~
include/linux/arm-smccc.h:419:33: note: in expansion of macro '__constraint_read_1'
419 | #define __constraint_read_2 __constraint_read_1, "r" (arg2)
| ^~~~~~~~~~~~~~~~~~~
include/linux/args.h:25:24: note: in expansion of macro '__constraint_read_2'
25 | #define __CONCAT(a, b) a ## b
| ^
include/linux/args.h:26:27: note: in expansion of macro '__CONCAT'
26 | #define CONCATENATE(a, b) __CONCAT(a, b)
| ^~~~~~~~
include/linux/arm-smccc.h:489:32: note: in expansion of macro 'CONCATENATE'
489 | : CONCATENATE(__constraint_read_, \
| ^~~~~~~~~~~
include/linux/arm-smccc.h:510:33: note: in expansion of macro '__arm_smccc_1_1'
510 | #define arm_smccc_1_1_smc(...) __arm_smccc_1_1(SMCCC_SMC_INST, __VA_ARGS__)
| ^~~~~~~~~~~~~~~
arch/arm/mm/proc-v7-bugs.c:58:9: note: in expansion of macro 'arm_smccc_1_1_smc'
58 | arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_1, NULL);
| ^~~~~~~~~~~~~~~~~
include/linux/arm-smccc.h:419:59: error: 'arg2' undeclared (first use in this function); did you mean 'r2'?
419 | #define __constraint_read_2 __constraint_read_1, "r" (arg2)
| ^~~~
include/linux/args.h:25:24: note: in expansion of macro '__constraint_read_2'
25 | #define __CONCAT(a, b) a ## b
| ^
include/linux/args.h:26:27: note: in expansion of macro '__CONCAT'
26 | #define CONCATENATE(a, b) __CONCAT(a, b)
| ^~~~~~~~
include/linux/arm-smccc.h:489:32: note: in expansion of macro 'CONCATENATE'
489 | : CONCATENATE(__constraint_read_, \
| ^~~~~~~~~~~
include/linux/arm-smccc.h:510:33: note: in expansion of macro '__arm_smccc_1_1'
510 | #define arm_smccc_1_1_smc(...) __arm_smccc_1_1(SMCCC_SMC_INST, __VA_ARGS__)
| ^~~~~~~~~~~~~~~
arch/arm/mm/proc-v7-bugs.c:58:9: note: in expansion of macro 'arm_smccc_1_1_smc'
58 | arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_1, NULL);
| ^~~~~~~~~~~~~~~~~
include/linux/arm-smccc.h:492:21: error: '___res' undeclared (first use in this function)
492 | if (___res) \
| ^~~~~~
include/linux/arm-smccc.h:510:33: note: in expansion of macro '__arm_smccc_1_1'
510 | #define arm_smccc_1_1_smc(...) __arm_smccc_1_1(SMCCC_SMC_INST, __VA_ARGS__)
| ^~~~~~~~~~~~~~~
arch/arm/mm/proc-v7-bugs.c:58:9: note: in expansion of macro 'arm_smccc_1_1_smc'
58 | arm_smccc_1_1_smc(ARM_SMCCC_ARCH_WORKAROUND_1, NULL);
| ^~~~~~~~~~~~~~~~~
arch/arm/mm/proc-v7-bugs.c: In function 'call_hvc_arch_workaround_1':
include/linux/arm-smccc.h:485:29: error: '__declare_arg_2' undeclared (first use in this function)
485 | CONCATENATE(__declare_arg_, COUNT_ARGS(__VA_ARGS__)); \
| ^~~~~~~~~~~~~~
include/linux/args.h:25:24: note: in definition of macro '__CONCAT'
25 | #define __CONCAT(a, b) a ## b
| ^
include/linux/arm-smccc.h:485:17: note: in expansion of macro 'CONCATENATE'
485 | CONCATENATE(__declare_arg_, COUNT_ARGS(__VA_ARGS__)); \
| ^~~~~~~~~~~
include/linux/arm-smccc.h:526:33: note: in expansion of macro '__arm_smccc_1_1'
526 | #define arm_smccc_1_1_hvc(...) __arm_smccc_1_1(SMCCC_HVC_INST, __VA_ARGS__)
| ^~~~~~~~~~~~~~~
arch/arm/mm/proc-v7-bugs.c:63:9: note: in expansion of macro 'arm_smccc_1_1_hvc'
63 | arm_smccc_1_1_hvc(ARM_SMCCC_ARCH_WORKAROUND_1, NULL);
| ^~~~~~~~~~~~~~~~~
include/linux/arm-smccc.h:417:38: error: 'arg0' undeclared (first use in this function); did you mean 'r0'?
417 | #define __constraint_read_0 "r" (arg0)
| ^~~~
include/linux/arm-smccc.h:418:33: note: in expansion of macro '__constraint_read_0'
418 | #define __constraint_read_1 __constraint_read_0, "r" (arg1)
| ^~~~~~~~~~~~~~~~~~~
include/linux/arm-smccc.h:419:33: note: in expansion of macro '__constraint_read_1'
419 | #define __constraint_read_2 __constraint_read_1, "r" (arg2)
| ^~~~~~~~~~~~~~~~~~~
include/linux/args.h:25:24: note: in expansion of macro '__constraint_read_2'
25 | #define __CONCAT(a, b) a ## b
| ^
include/linux/args.h:26:27: note: in expansion of macro '__CONCAT'
26 | #define CONCATENATE(a, b) __CONCAT(a, b)
| ^~~~~~~~
include/linux/arm-smccc.h:489:32: note: in expansion of macro 'CONCATENATE'
489 | : CONCATENATE(__constraint_read_, \
| ^~~~~~~~~~~
include/linux/arm-smccc.h:526:33: note: in expansion of macro '__arm_smccc_1_1'
526 | #define arm_smccc_1_1_hvc(...) __arm_smccc_1_1(SMCCC_HVC_INST, __VA_ARGS__)
| ^~~~~~~~~~~~~~~
arch/arm/mm/proc-v7-bugs.c:63:9: note: in expansion of macro 'arm_smccc_1_1_hvc'
63 | arm_smccc_1_1_hvc(ARM_SMCCC_ARCH_WORKAROUND_1, NULL);
| ^~~~~~~~~~~~~~~~~
include/linux/arm-smccc.h:418:59: error: 'arg1' undeclared (first use in this function); did you mean 'r1'?
418 | #define __constraint_read_1 __constraint_read_0, "r" (arg1)
| ^~~~
include/linux/arm-smccc.h:419:33: note: in expansion of macro '__constraint_read_1'
419 | #define __constraint_read_2 __constraint_read_1, "r" (arg2)
| ^~~~~~~~~~~~~~~~~~~
include/linux/args.h:25:24: note: in expansion of macro '__constraint_read_2'
25 | #define __CONCAT(a, b) a ## b
| ^
include/linux/args.h:26:27: note: in expansion of macro '__CONCAT'
26 | #define CONCATENATE(a, b) __CONCAT(a, b)
| ^~~~~~~~
include/linux/arm-smccc.h:489:32: note: in expansion of macro 'CONCATENATE'
489 | : CONCATENATE(__constraint_read_, \
| ^~~~~~~~~~~
include/linux/arm-smccc.h:526:33: note: in expansion of macro '__arm_smccc_1_1'
526 | #define arm_smccc_1_1_hvc(...) __arm_smccc_1_1(SMCCC_HVC_INST, __VA_ARGS__)
| ^~~~~~~~~~~~~~~
arch/arm/mm/proc-v7-bugs.c:63:9: note: in expansion of macro 'arm_smccc_1_1_hvc'
63 | arm_smccc_1_1_hvc(ARM_SMCCC_ARCH_WORKAROUND_1, NULL);
| ^~~~~~~~~~~~~~~~~
include/linux/arm-smccc.h:419:59: error: 'arg2' undeclared (first use in this function); did you mean 'r2'?
419 | #define __constraint_read_2 __constraint_read_1, "r" (arg2)
| ^~~~
include/linux/args.h:25:24: note: in expansion of macro '__constraint_read_2'
25 | #define __CONCAT(a, b) a ## b
| ^
include/linux/args.h:26:27: note: in expansion of macro '__CONCAT'
26 | #define CONCATENATE(a, b) __CONCAT(a, b)
| ^~~~~~~~
include/linux/arm-smccc.h:489:32: note: in expansion of macro 'CONCATENATE'
489 | : CONCATENATE(__constraint_read_, \
| ^~~~~~~~~~~
include/linux/arm-smccc.h:526:33: note: in expansion of macro '__arm_smccc_1_1'
526 | #define arm_smccc_1_1_hvc(...) __arm_smccc_1_1(SMCCC_HVC_INST, __VA_ARGS__)
| ^~~~~~~~~~~~~~~
arch/arm/mm/proc-v7-bugs.c:63:9: note: in expansion of macro 'arm_smccc_1_1_hvc'
63 | arm_smccc_1_1_hvc(ARM_SMCCC_ARCH_WORKAROUND_1, NULL);
| ^~~~~~~~~~~~~~~~~
include/linux/arm-smccc.h:492:21: error: '___res' undeclared (first use in this function)
492 | if (___res) \
| ^~~~~~
include/linux/arm-smccc.h:526:33: note: in expansion of macro '__arm_smccc_1_1'
526 | #define arm_smccc_1_1_hvc(...) __arm_smccc_1_1(SMCCC_HVC_INST, __VA_ARGS__)
| ^~~~~~~~~~~~~~~
arch/arm/mm/proc-v7-bugs.c:63:9: note: in expansion of macro 'arm_smccc_1_1_hvc'
63 | arm_smccc_1_1_hvc(ARM_SMCCC_ARCH_WORKAROUND_1, NULL);
| ^~~~~~~~~~~~~~~~~
make[5]: *** [scripts/Makefile.build:243: arch/arm/mm/proc-v7-bugs.o] Error 1
make[4]: *** [scripts/Makefile.build:477: arch/arm/mm] Error 2
make[3]: *** [scripts/Makefile.build:477: arch/arm] Error 2
make[3]: *** Waiting for unfinished jobs....
In file included from include/linux/arm-smccc.h:8,
from drivers/char/hw_random/arm_smccc_trng.c:20:
drivers/char/hw_random/arm_smccc_trng.c: In function 'smccc_trng_read':
include/linux/arm-smccc.h:485:29: error: '__declare_arg_3' undeclared (first use in this function)
485 | CONCATENATE(__declare_arg_, COUNT_ARGS(__VA_ARGS__)); \
| ^~~~~~~~~~~~~~
include/linux/args.h:25:24: note: in definition of macro '__CONCAT'
25 | #define __CONCAT(a, b) a ## b
| ^
include/linux/arm-smccc.h:485:17: note: in expansion of macro 'CONCATENATE'
485 | CONCATENATE(__declare_arg_, COUNT_ARGS(__VA_ARGS__)); \
| ^~~~~~~~~~~
include/linux/arm-smccc.h:526:33: note: in expansion of macro '__arm_smccc_1_1'
526 | #define arm_smccc_1_1_hvc(...) __arm_smccc_1_1(SMCCC_HVC_INST, __VA_ARGS__)
| ^~~~~~~~~~~~~~~
include/linux/arm-smccc.h:563:25: note: in expansion of macro 'arm_smccc_1_1_hvc'
563 | arm_smccc_1_1_hvc(__VA_ARGS__); \
| ^~~~~~~~~~~~~~~~~
drivers/char/hw_random/arm_smccc_trng.c:73:17: note: in expansion of macro 'arm_smccc_1_1_invoke'
73 | arm_smccc_1_1_invoke(ARM_SMCCC_TRNG_RND, bits, &res);
| ^~~~~~~~~~~~~~~~~~~~
include/linux/arm-smccc.h:485:29: note: each undeclared identifier is reported only once for each function it appears in
485 | CONCATENATE(__declare_arg_, COUNT_ARGS(__VA_ARGS__)); \
| ^~~~~~~~~~~~~~
include/linux/args.h:25:24: note: in definition of macro '__CONCAT'
25 | #define __CONCAT(a, b) a ## b
| ^
include/linux/arm-smccc.h:485:17: note: in expansion of macro 'CONCATENATE'
485 | CONCATENATE(__declare_arg_, COUNT_ARGS(__VA_ARGS__)); \
| ^~~~~~~~~~~
include/linux/arm-smccc.h:526:33: note: in expansion of macro '__arm_smccc_1_1'
526 | #define arm_smccc_1_1_hvc(...) __arm_smccc_1_1(SMCCC_HVC_INST, __VA_ARGS__)
| ^~~~~~~~~~~~~~~
include/linux/arm-smccc.h:563:25: note: in expansion of macro 'arm_smccc_1_1_hvc'
563 | arm_smccc_1_1_hvc(__VA_ARGS__); \
| ^~~~~~~~~~~~~~~~~
drivers/char/hw_random/arm_smccc_trng.c:73:17: note: in expansion of macro 'arm_smccc_1_1_invoke'
73 | arm_smccc_1_1_invoke(ARM_SMCCC_TRNG_RND, bits, &res);
| ^~~~~~~~~~~~~~~~~~~~
include/linux/arm-smccc.h:417:38: error: 'arg0' undeclared (first use in this function); did you mean 'r0'?
417 | #define __constraint_read_0 "r" (arg0)
| ^~~~
include/linux/arm-smccc.h:418:33: note: in expansion of macro '__constraint_read_0'
418 | #define __constraint_read_1 __constraint_read_0, "r" (arg1)
| ^~~~~~~~~~~~~~~~~~~
include/linux/arm-smccc.h:419:33: note: in expansion of macro '__constraint_read_1'
419 | #define __constraint_read_2 __constraint_read_1, "r" (arg2)
| ^~~~~~~~~~~~~~~~~~~
include/linux/arm-smccc.h:420:33: note: in expansion of macro '__constraint_read_2'
420 | #define __constraint_read_3 __constraint_read_2, "r" (arg3)
| ^~~~~~~~~~~~~~~~~~~
include/linux/args.h:25:24: note: in expansion of macro '__constraint_read_3'
25 | #define __CONCAT(a, b) a ## b
| ^
include/linux/args.h:26:27: note: in expansion of macro '__CONCAT'
26 | #define CONCATENATE(a, b) __CONCAT(a, b)
| ^~~~~~~~
include/linux/arm-smccc.h:489:32: note: in expansion of macro 'CONCATENATE'
489 | : CONCATENATE(__constraint_read_, \
| ^~~~~~~~~~~
include/linux/arm-smccc.h:526:33: note: in expansion of macro '__arm_smccc_1_1'
526 | #define arm_smccc_1_1_hvc(...) __arm_smccc_1_1(SMCCC_HVC_INST, __VA_ARGS__)
| ^~~~~~~~~~~~~~~
include/linux/arm-smccc.h:563:25: note: in expansion of macro 'arm_smccc_1_1_hvc'
563 | arm_smccc_1_1_hvc(__VA_ARGS__); \
| ^~~~~~~~~~~~~~~~~
drivers/char/hw_random/arm_smccc_trng.c:73:17: note: in expansion of macro 'arm_smccc_1_1_invoke'
73 | arm_smccc_1_1_invoke(ARM_SMCCC_TRNG_RND, bits, &res);
| ^~~~~~~~~~~~~~~~~~~~
include/linux/arm-smccc.h:418:59: error: 'arg1' undeclared (first use in this function); did you mean 'r1'?
418 | #define __constraint_read_1 __constraint_read_0, "r" (arg1)
| ^~~~
include/linux/arm-smccc.h:419:33: note: in expansion of macro '__constraint_read_1'
419 | #define __constraint_read_2 __constraint_read_1, "r" (arg2)
| ^~~~~~~~~~~~~~~~~~~
include/linux/arm-smccc.h:420:33: note: in expansion of macro '__constraint_read_2'
420 | #define __constraint_read_3 __constraint_read_2, "r" (arg3)
| ^~~~~~~~~~~~~~~~~~~
include/linux/args.h:25:24: note: in expansion of macro '__constraint_read_3'
25 | #define __CONCAT(a, b) a ## b
| ^
include/linux/args.h:26:27: note: in expansion of macro '__CONCAT'
26 | #define CONCATENATE(a, b) __CONCAT(a, b)
| ^~~~~~~~
include/linux/arm-smccc.h:489:32: note: in expansion of macro 'CONCATENATE'
489 | : CONCATENATE(__constraint_read_, \
| ^~~~~~~~~~~
include/linux/arm-smccc.h:526:33: note: in expansion of macro '__arm_smccc_1_1'
526 | #define arm_smccc_1_1_hvc(...) __arm_smccc_1_1(SMCCC_HVC_INST, __VA_ARGS__)
| ^~~~~~~~~~~~~~~
include/linux/arm-smccc.h:563:25: note: in expansion of macro 'arm_smccc_1_1_hvc'
563 | arm_smccc_1_1_hvc(__VA_ARGS__); \
| ^~~~~~~~~~~~~~~~~
drivers/char/hw_random/arm_smccc_trng.c:73:17: note: in expansion of macro 'arm_smccc_1_1_invoke'
73 | arm_smccc_1_1_invoke(ARM_SMCCC_TRNG_RND, bits, &res);
| ^~~~~~~~~~~~~~~~~~~~
include/linux/arm-smccc.h:419:59: error: 'arg2' undeclared (first use in this function); did you mean 'r2'?
419 | #define __constraint_read_2 __constraint_read_1, "r" (arg2)
| ^~~~
include/linux/arm-smccc.h:420:33: note: in expansion of macro '__constraint_read_2'
420 | #define __constraint_read_3 __constraint_read_2, "r" (arg3)
| ^~~~~~~~~~~~~~~~~~~
include/linux/args.h:25:24: note: in expansion of macro '__constraint_read_3'
25 | #define __CONCAT(a, b) a ## b
| ^
include/linux/args.h:26:27: note: in expansion of macro '__CONCAT'
26 | #define CONCATENATE(a, b) __CONCAT(a, b)
| ^~~~~~~~
include/linux/arm-smccc.h:489:32: note: in expansion of macro 'CONCATENATE'
489 | : CONCATENATE(__constraint_read_, \
| ^~~~~~~~~~~
include/linux/arm-smccc.h:526:33: note: in expansion of macro '__arm_smccc_1_1'
526 | #define arm_smccc_1_1_hvc(...) __arm_smccc_1_1(SMCCC_HVC_INST, __VA_ARGS__)
| ^~~~~~~~~~~~~~~
include/linux/arm-smccc.h:563:25: note: in expansion of macro 'arm_smccc_1_1_hvc'
563 | arm_smccc_1_1_hvc(__VA_ARGS__); \
| ^~~~~~~~~~~~~~~~~
drivers/char/hw_random/arm_smccc_trng.c:73:17: note: in expansion of macro 'arm_smccc_1_1_invoke'
73 | arm_smccc_1_1_invoke(ARM_SMCCC_TRNG_RND, bits, &res);
| ^~~~~~~~~~~~~~~~~~~~
include/linux/arm-smccc.h:420:59: error: 'arg3' undeclared (first use in this function); did you mean 'r3'?
420 | #define __constraint_read_3 __constraint_read_2, "r" (arg3)
| ^~~~
include/linux/args.h:25:24: note: in expansion of macro '__constraint_read_3'
25 | #define __CONCAT(a, b) a ## b
| ^
include/linux/args.h:26:27: note: in expansion of macro '__CONCAT'
26 | #define CONCATENATE(a, b) __CONCAT(a, b)
| ^~~~~~~~
include/linux/arm-smccc.h:489:32: note: in expansion of macro 'CONCATENATE'
489 | : CONCATENATE(__constraint_read_, \
| ^~~~~~~~~~~
include/linux/arm-smccc.h:526:33: note: in expansion of macro '__arm_smccc_1_1'
526 | #define arm_smccc_1_1_hvc(...) __arm_smccc_1_1(SMCCC_HVC_INST, __VA_ARGS__)
| ^~~~~~~~~~~~~~~
include/linux/arm-smccc.h:563:25: note: in expansion of macro 'arm_smccc_1_1_hvc'
563 | arm_smccc_1_1_hvc(__VA_ARGS__); \
| ^~~~~~~~~~~~~~~~~
drivers/char/hw_random/arm_smccc_trng.c:73:17: note: in expansion of macro 'arm_smccc_1_1_invoke'
73 | arm_smccc_1_1_invoke(ARM_SMCCC_TRNG_RND, bits, &res);
| ^~~~~~~~~~~~~~~~~~~~
include/linux/arm-smccc.h:492:21: error: '___res' undeclared (first use in this function)
492 | if (___res) \
| ^~~~~~
include/linux/arm-smccc.h:526:33: note: in expansion of macro '__arm_smccc_1_1'
526 | #define arm_smccc_1_1_hvc(...) __arm_smccc_1_1(SMCCC_HVC_INST, __VA_ARGS__)
| ^~~~~~~~~~~~~~~
include/linux/arm-smccc.h:563:25: note: in expansion of macro 'arm_smccc_1_1_hvc'
563 | arm_smccc_1_1_hvc(__VA_ARGS__); \
| ^~~~~~~~~~~~~~~~~
drivers/char/hw_random/arm_smccc_trng.c:73:17: note: in expansion of macro 'arm_smccc_1_1_invoke'
73 | arm_smccc_1_1_invoke(ARM_SMCCC_TRNG_RND, bits, &res);
| ^~~~~~~~~~~~~~~~~~~~
Presumably caused by commits
93e9856955f8 ("kernel.h: split out COUNT_ARGS() and CONCATENATE() to args.h")
fceebffabbb6 ("arm64: smccc: replace custom COUNT_ARGS() & CONCATENATE() implementations")
I have used the mm tree from next-20230717 for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* linux-next: build failure after merge of the mm tree
@ 2023-07-17 23:40 Stephen Rothwell
0 siblings, 0 replies; 138+ messages in thread
From: Stephen Rothwell @ 2023-07-17 23:40 UTC (permalink / raw)
To: Andrew Morton
Cc: Liam R. Howlett, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 992 bytes --]
Hi all,
After merging the mm tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
In file included from include/uapi/linux/posix_types.h:5,
from include/uapi/linux/types.h:14,
from include/linux/types.h:6,
from include/linux/limits.h:6,
from include/linux/kernel.h:16,
from mm/mmap.c:12:
mm/mmap.c: In function 'do_vmi_align_munmap':
include/linux/stddef.h:8:14: error: incompatible types when assigning to type 'lockdep_map_p' from type 'void *'
8 | #define NULL ((void *)0)
| ^
mm/mmap.c:2430:38: note: in expansion of macro 'NULL'
2430 | mt_detach.ma_external_lock = NULL;
| ^~~~
Caused by commit
f40b24c7c416 ("mm/mmap: change detached vma locking scheme")
CONFIG_LOCKDEP is not set for this build.
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2023-07-04 2:32 ` Linus Torvalds
@ 2023-07-04 5:51 ` Suren Baghdasaryan
0 siblings, 0 replies; 138+ messages in thread
From: Suren Baghdasaryan @ 2023-07-04 5:51 UTC (permalink / raw)
To: Linus Torvalds
Cc: Stephen Rothwell, Andrew Morton, Linux Kernel Mailing List,
Linux Next Mailing List
On Tue, Jul 4, 2023 at 2:33 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Mon, 3 Jul 2023 at 19:23, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > After merging the origin tree, today's linux-next build (arm64 defconfig)
> > failed like this:
> >
> > arch/arm64/mm/fault.c: In function 'do_page_fault':
>
> Yup, SeongJae Park sent me the same report, and it just made it to
> top-of-tree as commit 24be4d0b46bb ("arch/arm64/mm/fault: Fix
> undeclared variable error in do_page_fault()")
Thanks for fixing that! I hope to turn CONFIG_PER_VMA_LOCK back on soon.
>
> This was actually an architecture I test myself, but I think UP ends
> up turning off CONFIG_PER_VMA_LOCK.
Yes, CONFIG_PER_VMA_LOCK depends on SMP.
>
> I do wonder how much point there is to have a non-SMP build of
> architectures like x86-64 and arm64 at all...
>
> But I guess people still run them in qemu.
>
> Linus
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2023-07-04 2:23 Stephen Rothwell
@ 2023-07-04 2:32 ` Linus Torvalds
2023-07-04 5:51 ` Suren Baghdasaryan
0 siblings, 1 reply; 138+ messages in thread
From: Linus Torvalds @ 2023-07-04 2:32 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Andrew Morton, Suren Baghdasaryan, Linux Kernel Mailing List,
Linux Next Mailing List
On Mon, 3 Jul 2023 at 19:23, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the origin tree, today's linux-next build (arm64 defconfig)
> failed like this:
>
> arch/arm64/mm/fault.c: In function 'do_page_fault':
Yup, SeongJae Park sent me the same report, and it just made it to
top-of-tree as commit 24be4d0b46bb ("arch/arm64/mm/fault: Fix
undeclared variable error in do_page_fault()")
This was actually an architecture I test myself, but I think UP ends
up turning off CONFIG_PER_VMA_LOCK.
I do wonder how much point there is to have a non-SMP build of
architectures like x86-64 and arm64 at all...
But I guess people still run them in qemu.
Linus
^ permalink raw reply [flat|nested] 138+ messages in thread
* linux-next: build failure after merge of the mm tree
@ 2023-07-04 2:23 Stephen Rothwell
2023-07-04 2:32 ` Linus Torvalds
0 siblings, 1 reply; 138+ messages in thread
From: Stephen Rothwell @ 2023-07-04 2:23 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton
Cc: Suren Baghdasaryan, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1503 bytes --]
Hi all,
After merging the origin tree, today's linux-next build (arm64 defconfig)
failed like this:
arch/arm64/mm/fault.c: In function 'do_page_fault':
arch/arm64/mm/fault.c:624:9: error: 'vma' undeclared (first use in this function); did you mean 'vmap'?
624 | vma = lock_mm_and_find_vma(mm, addr, regs);
| ^~~:
| vmap
Caused by commit
ae870a68b5d1 ("arm64/mm: Convert to using lock_mm_and_find_vma()")
interacting with commit
1e72a0774792 ("mm: disable CONFIG_PER_VMA_LOCK by default until its fixed")
from the mm tree.
I applied the following for today (but have no idea if it is correct).
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 4 Jul 2023 12:14:37 +1000
Subject: [PATCH] fix up for "arm64/mm: Convert to using lock_mm_and_find_vma()"
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/arm64/mm/fault.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 9d78ff78b0e3..b8c80f7b8a5f 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -536,9 +536,7 @@ static int __kprobes do_page_fault(unsigned long far, unsigned long esr,
unsigned long vm_flags;
unsigned int mm_flags = FAULT_FLAG_DEFAULT;
unsigned long addr = untagged_addr(far);
-#ifdef CONFIG_PER_VMA_LOCK
struct vm_area_struct *vma;
-#endif
if (kprobe_page_fault(regs, esr))
return 0;
--
2.39.2
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 484 bytes --]
^ permalink raw reply related [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2023-06-13 6:21 Stephen Rothwell
@ 2023-06-13 15:58 ` Catalin Marinas
0 siblings, 0 replies; 138+ messages in thread
From: Catalin Marinas @ 2023-06-13 15:58 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Andrew Morton, Linux Kernel Mailing List,
Linux Next Mailing List, Michael Ellerman, PowerPC
Hi Stephen,
On Tue, Jun 13, 2023 at 04:21:19PM +1000, Stephen Rothwell wrote:
> After merging the mm tree, today's linux-next build (powerpc
> ppc44x_defconfig) failed like this:
>
> In file included from arch/powerpc/include/asm/page.h:247,
> from arch/powerpc/include/asm/thread_info.h:13,
> from include/linux/thread_info.h:60,
> from include/asm-generic/preempt.h:5,
> from ./arch/powerpc/include/generated/asm/preempt.h:1,
> from include/linux/preempt.h:78,
> from include/linux/spinlock.h:56,
> from include/linux/ipc.h:5,
> from include/uapi/linux/sem.h:5,
> from include/linux/sem.h:5,
> from include/linux/compat.h:14,
> from arch/powerpc/kernel/asm-offsets.c:12:
> arch/powerpc/include/asm/page_32.h:16: warning: "ARCH_DMA_MINALIGN" redefined
> 16 | #define ARCH_DMA_MINALIGN L1_CACHE_BYTES
> |
> In file included from include/linux/time.h:5,
> from include/linux/compat.h:10:
> include/linux/cache.h:104: note: this is the location of the previous definition
> 104 | #define ARCH_DMA_MINALIGN __alignof__(unsigned long long)
> |
>
> (lots of theses)
>
> Caused by commit
>
> cc7335787e73 ("mm/slab: decouple ARCH_KMALLOC_MINALIGN from ARCH_DMA_MINALIGN")
>
> I have applied the following hack for today - we need something better.
I just posted this series fixing it for powerpc, microblaze and sh. I
did not add the #ifndef __powerpc64__ line since
CONFIG_NOT_COHERENT_CACHE should not be enabled for those builds.
https://lore.kernel.org/r/20230613155245.1228274-1-catalin.marinas@arm.com
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 13 Jun 2023 16:07:16 +1000
> Subject: [PATCH] fix up for "mm/slab: decouple ARCH_KMALLOC_MINALIGN from ARCH_DMA_MINALIGN"
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> arch/powerpc/include/asm/cache.h | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/powerpc/include/asm/cache.h b/arch/powerpc/include/asm/cache.h
> index ae0a68a838e8..e9be1396dfd1 100644
> --- a/arch/powerpc/include/asm/cache.h
> +++ b/arch/powerpc/include/asm/cache.h
> @@ -142,5 +142,14 @@ static inline void iccci(void *addr)
> }
>
> #endif /* !__ASSEMBLY__ */
> +
> +#ifndef __powerpc64__
> +#ifdef CONFIG_NOT_COHERENT_CACHE
> +#ifndef ARCH_DMA_MINALIGN
> +#define ARCH_DMA_MINALIGN L1_CACHE_BYTES
> +#endif
> +#endif
> +#endif
> +
> #endif /* __KERNEL__ */
> #endif /* _ASM_POWERPC_CACHE_H */
I think it should also remove the ARCH_DMA_MINALIGN from asm/page.h (as
I did in my series; sorry I did not cc you, only noticed now that you
reported it as well).
--
Catalin
^ permalink raw reply [flat|nested] 138+ messages in thread
* linux-next: build failure after merge of the mm tree
@ 2023-06-13 6:21 Stephen Rothwell
2023-06-13 15:58 ` Catalin Marinas
0 siblings, 1 reply; 138+ messages in thread
From: Stephen Rothwell @ 2023-06-13 6:21 UTC (permalink / raw)
To: Andrew Morton
Cc: Catalin Marinas, Linux Kernel Mailing List,
Linux Next Mailing List, Michael Ellerman, PowerPC
[-- Attachment #1: Type: text/plain, Size: 2280 bytes --]
Hi all,
After merging the mm tree, today's linux-next build (powerpc
ppc44x_defconfig) failed like this:
In file included from arch/powerpc/include/asm/page.h:247,
from arch/powerpc/include/asm/thread_info.h:13,
from include/linux/thread_info.h:60,
from include/asm-generic/preempt.h:5,
from ./arch/powerpc/include/generated/asm/preempt.h:1,
from include/linux/preempt.h:78,
from include/linux/spinlock.h:56,
from include/linux/ipc.h:5,
from include/uapi/linux/sem.h:5,
from include/linux/sem.h:5,
from include/linux/compat.h:14,
from arch/powerpc/kernel/asm-offsets.c:12:
arch/powerpc/include/asm/page_32.h:16: warning: "ARCH_DMA_MINALIGN" redefined
16 | #define ARCH_DMA_MINALIGN L1_CACHE_BYTES
|
In file included from include/linux/time.h:5,
from include/linux/compat.h:10:
include/linux/cache.h:104: note: this is the location of the previous definition
104 | #define ARCH_DMA_MINALIGN __alignof__(unsigned long long)
|
(lots of theses)
Caused by commit
cc7335787e73 ("mm/slab: decouple ARCH_KMALLOC_MINALIGN from ARCH_DMA_MINALIGN")
I have applied the following hack for today - we need something better.
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 13 Jun 2023 16:07:16 +1000
Subject: [PATCH] fix up for "mm/slab: decouple ARCH_KMALLOC_MINALIGN from ARCH_DMA_MINALIGN"
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/include/asm/cache.h | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/powerpc/include/asm/cache.h b/arch/powerpc/include/asm/cache.h
index ae0a68a838e8..e9be1396dfd1 100644
--- a/arch/powerpc/include/asm/cache.h
+++ b/arch/powerpc/include/asm/cache.h
@@ -142,5 +142,14 @@ static inline void iccci(void *addr)
}
#endif /* !__ASSEMBLY__ */
+
+#ifndef __powerpc64__
+#ifdef CONFIG_NOT_COHERENT_CACHE
+#ifndef ARCH_DMA_MINALIGN
+#define ARCH_DMA_MINALIGN L1_CACHE_BYTES
+#endif
+#endif
+#endif
+
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_CACHE_H */
--
2.39.2
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2023-05-19 2:43 Stephen Rothwell
@ 2023-05-19 8:19 ` Arnd Bergmann
0 siblings, 0 replies; 138+ messages in thread
From: Arnd Bergmann @ 2023-05-19 8:19 UTC (permalink / raw)
To: Stephen Rothwell, Andrew Morton; +Cc: Linux Kernel Mailing List, linux-next
On Fri, May 19, 2023, at 04:43, Stephen Rothwell wrote:
> Hi all,
>
> After merging the mm tree, today's linux-next build (sparc64 defconfig)
> failed like this:
>
> arch/sparc/kernel/setup_64.c: In function 'start_early_boot':
> arch/sparc/kernel/setup_64.c:382:9: error: implicit declaration of
> function 'time_init_early'; did you mean 'inode_init_early'?
> [-Werror=implicit-function-declaration]
> 382 | time_init_early();
> | ^~~~~~~~~~~~~~~
> | inode_init_early
>
> Presumably caused by commit
>
> c16caa9110dd ("init: consolidate prototypes in linux/init.h")
>
> I applied this partial revert:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 19 May 2023 12:35:26 +1000
> Subject: [PATCH] fix up for "init: consolidate prototypes in linux/init.h"
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Thanks! It looks like I accidentally dropped this one while looking
for stale 'init_time()' declarations.
Arnd
^ permalink raw reply [flat|nested] 138+ messages in thread
* linux-next: build failure after merge of the mm tree
@ 2023-05-19 2:43 Stephen Rothwell
2023-05-19 8:19 ` Arnd Bergmann
0 siblings, 1 reply; 138+ messages in thread
From: Stephen Rothwell @ 2023-05-19 2:43 UTC (permalink / raw)
To: Andrew Morton
Cc: Arnd Bergmann, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1471 bytes --]
Hi all,
After merging the mm tree, today's linux-next build (sparc64 defconfig)
failed like this:
arch/sparc/kernel/setup_64.c: In function 'start_early_boot':
arch/sparc/kernel/setup_64.c:382:9: error: implicit declaration of function 'time_init_early'; did you mean 'inode_init_early'? [-Werror=implicit-function-declaration]
382 | time_init_early();
| ^~~~~~~~~~~~~~~
| inode_init_early
Presumably caused by commit
c16caa9110dd ("init: consolidate prototypes in linux/init.h")
I applied this partial revert:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 19 May 2023 12:35:26 +1000
Subject: [PATCH] fix up for "init: consolidate prototypes in linux/init.h"
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/sparc/kernel/kernel.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/sparc/kernel/kernel.h b/arch/sparc/kernel/kernel.h
index 970ef8dec86e..15da3c0597a5 100644
--- a/arch/sparc/kernel/kernel.h
+++ b/arch/sparc/kernel/kernel.h
@@ -62,6 +62,9 @@ asmlinkage void do_rt_sigreturn32(struct pt_regs *regs);
void do_signal32(struct pt_regs * regs);
asmlinkage int do_sys32_sigstack(u32 u_ssptr, u32 u_ossptr, unsigned long sp);
+/* time_64.c */
+void __init time_init_early(void);
+
/* compat_audit.c */
extern unsigned int sparc32_dir_class[];
extern unsigned int sparc32_chattr_class[];
--
2.39.2
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 138+ messages in thread
* linux-next: build failure after merge of the mm tree
@ 2023-05-17 23:59 Stephen Rothwell
0 siblings, 0 replies; 138+ messages in thread
From: Stephen Rothwell @ 2023-05-17 23:59 UTC (permalink / raw)
To: Andrew Morton
Cc: Oscar Salvador, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 2153 bytes --]
Hi all,
After merging the mm tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
In file included from include/linux/page_ext.h:7,
from include/linux/mm.h:22,
from security/min_addr.c:3:
include/linux/stackdepot.h:116:26: warning: 'struct seq_file' declared inside parameter list will not be visible outside of this definition or declaration
116 | void *stack_start(struct seq_file *m, loff_t *ppos);
| ^~~~~~~~
include/linux/stackdepot.h:117:25: warning: 'struct seq_file' declared inside parameter list will not be visible outside of this definition or declaration
117 | void *stack_next(struct seq_file *m, void *v, loff_t *ppos);
| ^~~~~~~~
include/linux/stackdepot.h:118:24: warning: 'struct seq_file' declared inside parameter list will not be visible outside of this definition or declaration
118 | int stack_print(struct seq_file *m, void *v);
| ^~~~~~~~
And many, many more ...
Caused by commit
e435b85a4aea ("mm, page_owner: add page_owner_stacks file to print out only stacks and their counte")
I have applied the following patch for today:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 18 May 2023 09:39:46 +1000
Subject: [PATCH] fix for "mm, page_owner: add page_owner_stacks file to print
out only stacks and their counte"
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
include/linux/stackdepot.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/stackdepot.h b/include/linux/stackdepot.h
index 7e9d0e9ec66b..8bbd1639ae85 100644
--- a/include/linux/stackdepot.h
+++ b/include/linux/stackdepot.h
@@ -113,6 +113,7 @@ depot_stack_handle_t stack_depot_save(unsigned long *entries,
unsigned int nr_entries, gfp_t gfp_flags);
#ifdef CONFIG_PAGE_OWNER
+struct seq_file;
void *stack_start(struct seq_file *m, loff_t *ppos);
void *stack_next(struct seq_file *m, void *v, loff_t *ppos);
int stack_print(struct seq_file *m, void *v);
--
2.39.2
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2023-03-06 0:52 Stephen Rothwell
@ 2023-03-06 21:58 ` Stephen Rothwell
0 siblings, 0 replies; 138+ messages in thread
From: Stephen Rothwell @ 2023-03-06 21:58 UTC (permalink / raw)
To: Andrew Morton
Cc: Marcelo Tosatti, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 776 bytes --]
Hi all,
On Mon, 6 Mar 2023 11:52:56 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the mm tree, today's linux-next build (sparc64 defconfig)
> failed like this:
>
> sparc64-linux-ld: mm/vmstat.o: in function `cpu_vm_stats_fold':
> vmstat.c:(.text+0x2a18): undefined reference to `__xchg_called_with_bad_pointer'
> sparc64-linux-ld: vmstat.c:(.text+0x2a98): undefined reference to `__xchg_called_with_bad_pointer'
>
> Caused by commit
>
> 676a3befc9ba ("mm/vmstat: use xchg in cpu_vm_stats_fold")
>
> Sparc does not support xchg() on 8 bit variables.
>
> I have reverted the above commit (and the 2 following ones) for today.
I have used the supplied patch instead of these reverts today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2023-03-06 2:54 Stephen Rothwell
@ 2023-03-06 3:13 ` Andrew Morton
0 siblings, 0 replies; 138+ messages in thread
From: Andrew Morton @ 2023-03-06 3:13 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Suren Baghdasaryan, Linux Kernel Mailing List, Linux Next Mailing List
On Mon, 6 Mar 2023 13:54:47 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> After merging the mm tree, today's linux-next build (various) failed
> like this:
>
> mm/khugepaged.c:1702:9: error: implicit declaration of function ‘vma_try_start_write’; did you mean ‘vma_start_write’? [-Werror=implicit-function-declaration]
>
> Caused by commit
>
> 92e3612279f9 ("mm/khugepaged: fix vm_lock/i_mmap_rwsem inversion in retract_page_tables")
>
> The definition of vma_try_start_write() is protected by
> CONFIG_PER_VMA_LOCK, but its use is not.
Thanks. Suren has a fix, but I haven't pushed it out yet :(
From: Suren Baghdasaryan <surenb@google.com>
Subject: txt-mm-khugepaged-write-lock-vma-while-collapsing-a-huge-page-fix-fix
Date: Sat, 4 Mar 2023 15:24:15 -0800
I missed vma_try_start_write() definition for CONFIG_PER_VMA_LOCK=n
configuration.
Link: https://lkml.kernel.org/r/CAJuCfpFjWhtzRE1X=J+_JjgJzNKhq-=JT8yTBSTHthwp0pqWZw@mail.gmail.com
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
--- a/include/linux/mm.h~mm-khugepaged-write-lock-vma-while-collapsing-a-huge-page-fix-fix
+++ a/include/linux/mm.h
@@ -717,6 +717,8 @@ static inline bool vma_start_read(struct
{ return false; }
static inline void vma_end_read(struct vm_area_struct *vma) {}
static inline void vma_start_write(struct vm_area_struct *vma) {}
+static inline bool vma_try_start_write(struct vm_area_struct *vma)
+ { return true; }
static inline void vma_assert_write_locked(struct vm_area_struct *vma) {}
#endif /* CONFIG_PER_VMA_LOCK */
_
^ permalink raw reply [flat|nested] 138+ messages in thread
* linux-next: build failure after merge of the mm tree
@ 2023-03-06 2:54 Stephen Rothwell
2023-03-06 3:13 ` Andrew Morton
0 siblings, 1 reply; 138+ messages in thread
From: Stephen Rothwell @ 2023-03-06 2:54 UTC (permalink / raw)
To: Andrew Morton
Cc: Suren Baghdasaryan, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 513 bytes --]
Hi all,
After merging the mm tree, today's linux-next build (various) failed
like this:
mm/khugepaged.c:1702:9: error: implicit declaration of function ‘vma_try_start_write’; did you mean ‘vma_start_write’? [-Werror=implicit-function-declaration]
Caused by commit
92e3612279f9 ("mm/khugepaged: fix vm_lock/i_mmap_rwsem inversion in retract_page_tables")
The definition of vma_try_start_write() is protected by
CONFIG_PER_VMA_LOCK, but its use is not.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* linux-next: build failure after merge of the mm tree
@ 2023-03-06 0:52 Stephen Rothwell
2023-03-06 21:58 ` Stephen Rothwell
0 siblings, 1 reply; 138+ messages in thread
From: Stephen Rothwell @ 2023-03-06 0:52 UTC (permalink / raw)
To: Andrew Morton
Cc: Marcelo Tosatti, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 596 bytes --]
Hi all,
After merging the mm tree, today's linux-next build (sparc64 defconfig)
failed like this:
sparc64-linux-ld: mm/vmstat.o: in function `cpu_vm_stats_fold':
vmstat.c:(.text+0x2a18): undefined reference to `__xchg_called_with_bad_pointer'
sparc64-linux-ld: vmstat.c:(.text+0x2a98): undefined reference to `__xchg_called_with_bad_pointer'
Caused by commit
676a3befc9ba ("mm/vmstat: use xchg in cpu_vm_stats_fold")
Sparc does not support xchg() on 8 bit variables.
I have reverted the above commit (and the 2 following ones) for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2023-02-26 22:18 ` Stephen Rothwell
@ 2023-02-27 10:36 ` Christian Brauner
0 siblings, 0 replies; 138+ messages in thread
From: Christian Brauner @ 2023-02-27 10:36 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Andrew Morton, Christian Brauner, Giuseppe Scrivano,
Catalin Marinas, Joey Gouly, Linux Kernel Mailing List,
Linux Next Mailing List
On Mon, Feb 27, 2023 at 09:18:03AM +1100, Stephen Rothwell wrote:
> Hi Christian,
>
> On Mon, 30 Jan 2023 09:09:56 +0100 Christian Brauner <brauner@kernel.org> wrote:
> >
> > On Mon, Jan 30, 2023 at 04:14:14PM +1100, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > After merging the mm tree, today's linux-next build (powerpc
> > > ppc64_defconfig) failed like this:
> > >
> > > kernel/sys.c: In function '__do_sys_prctl':
> > > kernel/sys.c:2664:9: error: duplicate case value
> > > 2664 | case PR_SET_HIDE_SELF_EXE:
> > > | ^~~~
> > > kernel/sys.c:2655:9: note: previously used here
> > > 2655 | case PR_SET_MDWE:
> > > | ^~~~
> > > kernel/sys.c:2669:9: error: duplicate case value
> > > 2669 | case PR_GET_HIDE_SELF_EXE:
> > > | ^~~~
> > > kernel/sys.c:2658:9: note: previously used here
> > > 2658 | case PR_GET_MDWE:
> > > | ^~~~
> > >
> > > Caused by commit
> > >
> > > ab30677b499c ("mm: implement memory-deny-write-execute as a prctl")
> > >
> > > interacting with commit
> > >
> > > 966eb1ba050d ("exec: add PR_HIDE_SELF_EXE prctl")
> > >
> > > from the pidfd tree.
> > >
> > > I have applied the following merge fix patch.
> > >
> > > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > > Date: Mon, 30 Jan 2023 16:08:34 +1100
> > > Subject: [PATCH] mm: fixup for "mm: implement memory-deny-write-execute as a prctl"
> > >
> > > interacting with
> > >
> > > 966eb1ba050d ("exec: add PR_HIDE_SELF_EXE prctl")
> > >
> > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > > ---
> >
> > Thanks Stephen,
> >
> > I'm moving this out of -next for now until we've settled a few more
> > details.
>
> I am still applying this to the merge of the pidfd tree. Also I
> noticed that a similar fixup will need to be applied to
> tools/testing/selftests/prctl/hide-self-exe.c
Sorry Stephen, I forgot to drop the patches from this branch. I dropped
them now. Let me know if you still see issues.
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2023-01-30 8:09 ` Christian Brauner
@ 2023-02-26 22:18 ` Stephen Rothwell
2023-02-27 10:36 ` Christian Brauner
0 siblings, 1 reply; 138+ messages in thread
From: Stephen Rothwell @ 2023-02-26 22:18 UTC (permalink / raw)
To: Christian Brauner
Cc: Andrew Morton, Christian Brauner, Giuseppe Scrivano,
Catalin Marinas, Joey Gouly, Linux Kernel Mailing List,
Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1812 bytes --]
Hi Christian,
On Mon, 30 Jan 2023 09:09:56 +0100 Christian Brauner <brauner@kernel.org> wrote:
>
> On Mon, Jan 30, 2023 at 04:14:14PM +1100, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the mm tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > kernel/sys.c: In function '__do_sys_prctl':
> > kernel/sys.c:2664:9: error: duplicate case value
> > 2664 | case PR_SET_HIDE_SELF_EXE:
> > | ^~~~
> > kernel/sys.c:2655:9: note: previously used here
> > 2655 | case PR_SET_MDWE:
> > | ^~~~
> > kernel/sys.c:2669:9: error: duplicate case value
> > 2669 | case PR_GET_HIDE_SELF_EXE:
> > | ^~~~
> > kernel/sys.c:2658:9: note: previously used here
> > 2658 | case PR_GET_MDWE:
> > | ^~~~
> >
> > Caused by commit
> >
> > ab30677b499c ("mm: implement memory-deny-write-execute as a prctl")
> >
> > interacting with commit
> >
> > 966eb1ba050d ("exec: add PR_HIDE_SELF_EXE prctl")
> >
> > from the pidfd tree.
> >
> > I have applied the following merge fix patch.
> >
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Date: Mon, 30 Jan 2023 16:08:34 +1100
> > Subject: [PATCH] mm: fixup for "mm: implement memory-deny-write-execute as a prctl"
> >
> > interacting with
> >
> > 966eb1ba050d ("exec: add PR_HIDE_SELF_EXE prctl")
> >
> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > ---
>
> Thanks Stephen,
>
> I'm moving this out of -next for now until we've settled a few more
> details.
I am still applying this to the merge of the pidfd tree. Also I
noticed that a similar fixup will need to be applied to
tools/testing/selftests/prctl/hide-self-exe.c
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2023-02-24 6:01 ` Linus Torvalds
@ 2023-02-24 20:36 ` Stephen Rothwell
0 siblings, 0 replies; 138+ messages in thread
From: Stephen Rothwell @ 2023-02-24 20:36 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andrew Morton, Matthew Wilcox (Oracle),
Jan Kara, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 413 bytes --]
Hi Linus,
On Thu, 23 Feb 2023 22:01:25 -0800 Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> End result: I explicitly left it in its minimal form, because I think
> anything else is a "future endeavor". The udf code only works with
> page-sized folios, and pretending anything else (using
> "folio_unlock()" etc) would be just that - pretending
OK, thanks.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2023-02-24 4:40 ` Stephen Rothwell
@ 2023-02-24 6:01 ` Linus Torvalds
2023-02-24 20:36 ` Stephen Rothwell
0 siblings, 1 reply; 138+ messages in thread
From: Linus Torvalds @ 2023-02-24 6:01 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Andrew Morton, Matthew Wilcox (Oracle),
Jan Kara, Linux Kernel Mailing List, Linux Next Mailing List
On Thu, Feb 23, 2023 at 8:40 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> I think Linus may have missed the last 2 changes in this merge
> resolution ...
Well, not exactly missed, in that I didn't actually even look at it,
because that one wasn't one I worried about (unlike the cifs one that
I'm very leery of).
And I actually really dislike your particular resolution and wouldn't
prefer it done that way anyway. It mixes folios and pages in ugly
ways.
Either do it all with the page pointer (like I did), or convert it
*all* to be folios, but don't do that odd "use a mixture of both
intertwined".
Of course, I do see _why_ you are mixing 'page' and 'folio' - there's
no memcpy_to_folio() helper (although once it eventually exists it
might be called "memcpy_to_file_folio()" to match the naming of the
"from" version).
But that's exactly why I stopped where I stopped - I think it's
pointless doing the other conversions when you can't easily do that
memcpy_to_page() one.
So I think the UDF folio conversion needs a bit more infrastructure to
really work well.
(There's also the whole kmap issue - we don't kmap whole folios, only
individual pages, so a "real" folio conversion would have to have a
loop).
End result: I explicitly left it in its minimal form, because I think
anything else is a "future endeavor". The udf code only works with
page-sized folios, and pretending anything else (using
"folio_unlock()" etc) would be just that - pretending
Linus
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2023-01-31 21:47 ` Stephen Rothwell
@ 2023-02-24 4:40 ` Stephen Rothwell
2023-02-24 6:01 ` Linus Torvalds
0 siblings, 1 reply; 138+ messages in thread
From: Stephen Rothwell @ 2023-02-24 4:40 UTC (permalink / raw)
To: Andrew Morton, Matthew Wilcox (Oracle)
Cc: Jan Kara, Linux Kernel Mailing List, Linux Next Mailing List,
Linus Torvalds
[-- Attachment #1: Type: text/plain, Size: 1748 bytes --]
Hi all,
On Wed, 1 Feb 2023 08:47:41 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi Jan,
>
> On Fri, 27 Jan 2023 14:11:42 +0100 Jan Kara <jack@suse.cz> wrote:
> >
> > Thanks for the fixup! The right function to replace PageLocked() with is
> > folio_test_locked(). Anyway, I'll prepare a suggested conflict resolution
> > for Linus when pushing the changes.
>
> Thanks for the hint. This is what I am using now:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 27 Jan 2023 16:50:34 +1100
> Subject: [PATCH] udf: fix up for "fs: convert writepage_t callback to pass a folio"
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> fs/udf/inode.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/fs/udf/inode.c b/fs/udf/inode.c
> index 3b2adf4cbc57..b47bf9c73f4d 100644
> --- a/fs/udf/inode.c
> +++ b/fs/udf/inode.c
> @@ -185,16 +185,17 @@ static void udf_write_failed(struct address_space *mapping, loff_t to)
> }
> }
>
> -static int udf_adinicb_writepage(struct page *page,
> +static int udf_adinicb_writepage(struct folio *folio,
> struct writeback_control *wbc, void *data)
> {
> + struct page *page = &folio->page;
> struct inode *inode = page->mapping->host;
> struct udf_inode_info *iinfo = UDF_I(inode);
>
> - BUG_ON(!PageLocked(page));
> + BUG_ON(!folio_test_locked(folio));
> memcpy_to_page(page, 0, iinfo->i_data + iinfo->i_lenEAttr,
> i_size_read(inode));
> - unlock_page(page);
> + folio_unlock(folio);
> mark_inode_dirty(inode);
>
> return 0;
> --
> 2.35.1
I think Linus may have missed the last 2 changes in this merge
resolution ...
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2023-02-07 12:17 ` Jason Gunthorpe
@ 2023-02-08 2:41 ` Stephen Rothwell
0 siblings, 0 replies; 138+ messages in thread
From: Stephen Rothwell @ 2023-02-08 2:41 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Andrew Morton, Jens Axboe, David Howells,
Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1071 bytes --]
Hi Jason,
On Tue, 7 Feb 2023 08:17:46 -0400 Jason Gunthorpe <jgg@nvidia.com> wrote:
>
> Just s/= FOLL_PIN/= 0/, it is unconditionally set internally when calling
> pin_user_pages_fast()
Thanks, I have done just that for today:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 8 Feb 2023 13:33:55 +1100
Subject: [PATCH] fixup for "mm/gup: move private gup FOLL_ flags to internal.h"
interacting with "iov_iter: Add a function to extract a page list from
an iterator" from the block tree.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
lib/iov_iter.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/iov_iter.c b/lib/iov_iter.c
index 95b8047be5a7..f6c6aef6fbfb 100644
--- a/lib/iov_iter.c
+++ b/lib/iov_iter.c
@@ -2140,7 +2140,7 @@ static ssize_t iov_iter_extract_user_pages(struct iov_iter *i,
size_t *offset0)
{
unsigned long addr;
- unsigned int gup_flags = FOLL_PIN;
+ unsigned int gup_flags = 0;
size_t offset;
int res;
--
2.35.1
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2023-02-07 4:37 Stephen Rothwell
2023-02-07 12:17 ` Jason Gunthorpe
@ 2023-02-07 14:25 ` David Howells
1 sibling, 0 replies; 138+ messages in thread
From: David Howells @ 2023-02-07 14:25 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: dhowells, Stephen Rothwell, Andrew Morton, Jens Axboe,
Linux Kernel Mailing List, Linux Next Mailing List
Jason Gunthorpe <jgg@nvidia.com> wrote:
> David can you send a patch to the block tree to fix it?
I'll see. Given that the patch series introduces a memory corruptor bug that
someone might bisect through, I want to see if Jens will let me replace it to
put the fix first, in which case I can just alter the patch that adds the
FOLL_PIN usage.
David
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2023-02-07 4:37 Stephen Rothwell
@ 2023-02-07 12:17 ` Jason Gunthorpe
2023-02-08 2:41 ` Stephen Rothwell
2023-02-07 14:25 ` David Howells
1 sibling, 1 reply; 138+ messages in thread
From: Jason Gunthorpe @ 2023-02-07 12:17 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Andrew Morton, Jens Axboe, David Howells,
Linux Kernel Mailing List, Linux Next Mailing List
On Tue, Feb 07, 2023 at 03:37:06PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the mm tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> lib/iov_iter.c: In function 'iov_iter_extract_user_pages':
> lib/iov_iter.c:2143:34: error: 'FOLL_PIN' undeclared (first use in this function); did you mean 'POLL_IN'?
> 2143 | unsigned int gup_flags = FOLL_PIN;
> | ^~~~~~~~
> | POLL_IN
> lib/iov_iter.c:2143:34: note: each undeclared identifier is reported only once for each function it appears in
>
> Caused by commit
>
> 0ff325d28700 ("mm/gup: move private gup FOLL_ flags to internal.h")
>
> interacting with commit
>
> 895d773054a2 ("iov_iter: Add a function to extract a page list from an iterator")
>
> from the block tree.
>
> I have reverted commit 0ff325d28700 for today. A better resolution
> would be appreciated.
Just s/= FOLL_PIN/= 0/, it is unconditionally set internally when calling
pin_user_pages_fast()
David can you send a patch to the block tree to fix it?
Jason
^ permalink raw reply [flat|nested] 138+ messages in thread
* linux-next: build failure after merge of the mm tree
@ 2023-02-07 4:37 Stephen Rothwell
2023-02-07 12:17 ` Jason Gunthorpe
2023-02-07 14:25 ` David Howells
0 siblings, 2 replies; 138+ messages in thread
From: Stephen Rothwell @ 2023-02-07 4:37 UTC (permalink / raw)
To: Andrew Morton, Jens Axboe
Cc: David Howells, Jason Gunthorpe, Jason Gunthorpe,
Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 903 bytes --]
Hi all,
After merging the mm tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
lib/iov_iter.c: In function 'iov_iter_extract_user_pages':
lib/iov_iter.c:2143:34: error: 'FOLL_PIN' undeclared (first use in this function); did you mean 'POLL_IN'?
2143 | unsigned int gup_flags = FOLL_PIN;
| ^~~~~~~~
| POLL_IN
lib/iov_iter.c:2143:34: note: each undeclared identifier is reported only once for each function it appears in
Caused by commit
0ff325d28700 ("mm/gup: move private gup FOLL_ flags to internal.h")
interacting with commit
895d773054a2 ("iov_iter: Add a function to extract a page list from an iterator")
from the block tree.
I have reverted commit 0ff325d28700 for today. A better resolution
would be appreciated.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2023-01-27 13:11 ` Jan Kara
@ 2023-01-31 21:47 ` Stephen Rothwell
2023-02-24 4:40 ` Stephen Rothwell
0 siblings, 1 reply; 138+ messages in thread
From: Stephen Rothwell @ 2023-01-31 21:47 UTC (permalink / raw)
To: Jan Kara
Cc: Andrew Morton, Matthew Wilcox (Oracle),
Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1478 bytes --]
Hi Jan,
On Fri, 27 Jan 2023 14:11:42 +0100 Jan Kara <jack@suse.cz> wrote:
>
> Thanks for the fixup! The right function to replace PageLocked() with is
> folio_test_locked(). Anyway, I'll prepare a suggested conflict resolution
> for Linus when pushing the changes.
Thanks for the hint. This is what I am using now:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 27 Jan 2023 16:50:34 +1100
Subject: [PATCH] udf: fix up for "fs: convert writepage_t callback to pass a folio"
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
fs/udf/inode.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/fs/udf/inode.c b/fs/udf/inode.c
index 3b2adf4cbc57..b47bf9c73f4d 100644
--- a/fs/udf/inode.c
+++ b/fs/udf/inode.c
@@ -185,16 +185,17 @@ static void udf_write_failed(struct address_space *mapping, loff_t to)
}
}
-static int udf_adinicb_writepage(struct page *page,
+static int udf_adinicb_writepage(struct folio *folio,
struct writeback_control *wbc, void *data)
{
+ struct page *page = &folio->page;
struct inode *inode = page->mapping->host;
struct udf_inode_info *iinfo = UDF_I(inode);
- BUG_ON(!PageLocked(page));
+ BUG_ON(!folio_test_locked(folio));
memcpy_to_page(page, 0, iinfo->i_data + iinfo->i_lenEAttr,
i_size_read(inode));
- unlock_page(page);
+ folio_unlock(folio);
mark_inode_dirty(inode);
return 0;
--
2.35.1
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2023-01-30 5:14 Stephen Rothwell
@ 2023-01-30 8:09 ` Christian Brauner
2023-02-26 22:18 ` Stephen Rothwell
0 siblings, 1 reply; 138+ messages in thread
From: Christian Brauner @ 2023-01-30 8:09 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Andrew Morton, Christian Brauner, Giuseppe Scrivano,
Catalin Marinas, Joey Gouly, Linux Kernel Mailing List,
Linux Next Mailing List
On Mon, Jan 30, 2023 at 04:14:14PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the mm tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> kernel/sys.c: In function '__do_sys_prctl':
> kernel/sys.c:2664:9: error: duplicate case value
> 2664 | case PR_SET_HIDE_SELF_EXE:
> | ^~~~
> kernel/sys.c:2655:9: note: previously used here
> 2655 | case PR_SET_MDWE:
> | ^~~~
> kernel/sys.c:2669:9: error: duplicate case value
> 2669 | case PR_GET_HIDE_SELF_EXE:
> | ^~~~
> kernel/sys.c:2658:9: note: previously used here
> 2658 | case PR_GET_MDWE:
> | ^~~~
>
> Caused by commit
>
> ab30677b499c ("mm: implement memory-deny-write-execute as a prctl")
>
> interacting with commit
>
> 966eb1ba050d ("exec: add PR_HIDE_SELF_EXE prctl")
>
> from the pidfd tree.
>
> I have applied the following merge fix patch.
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 30 Jan 2023 16:08:34 +1100
> Subject: [PATCH] mm: fixup for "mm: implement memory-deny-write-execute as a prctl"
>
> interacting with
>
> 966eb1ba050d ("exec: add PR_HIDE_SELF_EXE prctl")
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
Thanks Stephen,
I'm moving this out of -next for now until we've settled a few more
details.
Christian
^ permalink raw reply [flat|nested] 138+ messages in thread
* linux-next: build failure after merge of the mm tree
@ 2023-01-30 5:14 Stephen Rothwell
2023-01-30 8:09 ` Christian Brauner
0 siblings, 1 reply; 138+ messages in thread
From: Stephen Rothwell @ 2023-01-30 5:14 UTC (permalink / raw)
To: Andrew Morton, Christian Brauner
Cc: Giuseppe Scrivano, Catalin Marinas, Joey Gouly,
Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1845 bytes --]
Hi all,
After merging the mm tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
kernel/sys.c: In function '__do_sys_prctl':
kernel/sys.c:2664:9: error: duplicate case value
2664 | case PR_SET_HIDE_SELF_EXE:
| ^~~~
kernel/sys.c:2655:9: note: previously used here
2655 | case PR_SET_MDWE:
| ^~~~
kernel/sys.c:2669:9: error: duplicate case value
2669 | case PR_GET_HIDE_SELF_EXE:
| ^~~~
kernel/sys.c:2658:9: note: previously used here
2658 | case PR_GET_MDWE:
| ^~~~
Caused by commit
ab30677b499c ("mm: implement memory-deny-write-execute as a prctl")
interacting with commit
966eb1ba050d ("exec: add PR_HIDE_SELF_EXE prctl")
from the pidfd tree.
I have applied the following merge fix patch.
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 30 Jan 2023 16:08:34 +1100
Subject: [PATCH] mm: fixup for "mm: implement memory-deny-write-execute as a prctl"
interacting with
966eb1ba050d ("exec: add PR_HIDE_SELF_EXE prctl")
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
include/uapi/linux/prctl.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/uapi/linux/prctl.h b/include/uapi/linux/prctl.h
index ccc92b92037c..99b5592cf297 100644
--- a/include/uapi/linux/prctl.h
+++ b/include/uapi/linux/prctl.h
@@ -282,10 +282,10 @@ struct prctl_mm_map {
# define PR_SME_VL_INHERIT (1 << 17) /* inherit across exec */
/* Memory deny write / execute */
-#define PR_SET_MDWE 65
+#define PR_SET_MDWE 67
# define PR_MDWE_REFUSE_EXEC_GAIN 1
-#define PR_GET_MDWE 66
+#define PR_GET_MDWE 68
#define PR_SET_VMA 0x53564d41
# define PR_SET_VMA_ANON_NAME 0
--
2.35.1
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2023-01-27 5:59 Stephen Rothwell
@ 2023-01-27 13:11 ` Jan Kara
2023-01-31 21:47 ` Stephen Rothwell
0 siblings, 1 reply; 138+ messages in thread
From: Jan Kara @ 2023-01-27 13:11 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Andrew Morton, Jan Kara, Matthew Wilcox (Oracle),
Linux Kernel Mailing List, Linux Next Mailing List
On Fri 27-01-23 16:59:12, Stephen Rothwell wrote:
> Hi all,
>
> After merging the mm tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> fs/udf/inode.c: In function 'udf_writepages':
> fs/udf/inode.c:211:48: error: passing argument 3 of 'write_cache_pages' from incompatible pointer type [-Werror=incompatible-pointer-types]
> 211 | return write_cache_pages(mapping, wbc, udf_adinicb_writepage, NULL);
> | ^~~~~~~~~~~~~~~~~~~~~
> | |
> | int (*)(struct page *, struct writeback_control *, void *)
> In file included from fs/udf/inode.c:36:
> include/linux/writeback.h:375:66: note: expected 'writepage_t' {aka 'int (*)(struct folio *, struct writeback_control *, void *)'} but argument is of type 'int (*)(struct page *, struct writeback_control *, void *)'
> 375 | struct writeback_control *wbc, writepage_t writepage,
> | ~~~~~~~~~~~~^~~~~~~~~
>
> Caused by commit
>
> a36a897cc496 ("fs: convert writepage_t callback to pass a folio")
>
> interacting with commit
>
> 79d3c6dbada4 ("udf: Convert in-ICB files to use udf_writepages()")
>
> from the ext3 tree.
>
> I have applied the following merge fix patch (I wasn't sure what to do
> with the PageLocked()).
Thanks for the fixup! The right function to replace PageLocked() with is
folio_test_locked(). Anyway, I'll prepare a suggested conflict resolution
for Linus when pushing the changes.
Honza
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 27 Jan 2023 16:50:34 +1100
> Subject: [PATCH] udf: fix up for "fs: convert writepage_t callback to pass a folio"
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> fs/udf/inode.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/fs/udf/inode.c b/fs/udf/inode.c
> index 3b2adf4cbc57..b47bf9c73f4d 100644
> --- a/fs/udf/inode.c
> +++ b/fs/udf/inode.c
> @@ -185,16 +185,17 @@ static void udf_write_failed(struct address_space *mapping, loff_t to)
> }
> }
>
> -static int udf_adinicb_writepage(struct page *page,
> +static int udf_adinicb_writepage(struct folio *folio,
> struct writeback_control *wbc, void *data)
> {
> + struct page *page = &folio->page;
> struct inode *inode = page->mapping->host;
> struct udf_inode_info *iinfo = UDF_I(inode);
>
> - BUG_ON(!PageLocked(page));
> +// BUG_ON(!PageLocked(page));
> memcpy_to_page(page, 0, iinfo->i_data + iinfo->i_lenEAttr,
> i_size_read(inode));
> - unlock_page(page);
> + folio_unlock(folio);
> mark_inode_dirty(inode);
>
> return 0;
> --
> 2.35.1
>
> --
> Cheers,
> Stephen Rothwell
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply [flat|nested] 138+ messages in thread
* linux-next: build failure after merge of the mm tree
@ 2023-01-27 6:36 Stephen Rothwell
0 siblings, 0 replies; 138+ messages in thread
From: Stephen Rothwell @ 2023-01-27 6:36 UTC (permalink / raw)
To: Andrew Morton
Cc: Andreas Gruenbacher, Matthew Wilcox (Oracle),
Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 2371 bytes --]
Hi all,
After merging the mm tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
fs/gfs2/log.c: In function 'gfs2_ail1_start_one':
fs/gfs2/log.c:143:55: error: passing argument 3 of 'write_cache_pages' from incompatible pointer type [-Werror=incompatible-pointer-types]
143 | ret = write_cache_pages(mapping, wbc, __gfs2_writepage, mapping);
| ^~~~~~~~~~~~~~~~
| |
| int (*)(struct page *, struct writeback_control *, void *)
In file included from fs/gfs2/log.c:20:
include/linux/writeback.h:375:66: note: expected 'writepage_t' {aka 'int (*)(struct folio *, struct writeback_control *, void *)'} but argument is of type 'int (*)(struct page *, struct writeback_control *, void *)'
375 | struct writeback_control *wbc, writepage_t writepage,
| ~~~~~~~~~~~~^~~~~~~~~
Caused by commit
a36a897cc496 ("fs: convert writepage_t callback to pass a folio")
interacting with commit
95ecbd0f162f ("Revert "gfs2: stop using generic_writepages in gfs2_ail1_start_one"")
from Linus' tree (post v6.2-rc4).
I have applied the following merge fix patch for today.
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 27 Jan 2023 17:26:08 +1100
Subject: [PATCH] gfs2: fix up for "fs: convert writepage_t callback to pass a folio"
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
fs/gfs2/log.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/gfs2/log.c b/fs/gfs2/log.c
index 25fd21a9dec8..d750d1128bed 100644
--- a/fs/gfs2/log.c
+++ b/fs/gfs2/log.c
@@ -80,11 +80,11 @@ void gfs2_remove_from_ail(struct gfs2_bufdata *bd)
brelse(bd->bd_bh);
}
-static int __gfs2_writepage(struct page *page, struct writeback_control *wbc,
+static int __gfs2_writepage(struct folio *folio, struct writeback_control *wbc,
void *data)
{
struct address_space *mapping = data;
- int ret = mapping->a_ops->writepage(page, wbc);
+ int ret = mapping->a_ops->writepage(&folio->page, wbc);
mapping_set_error(mapping, ret);
return ret;
}
--
2.35.1
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 138+ messages in thread
* linux-next: build failure after merge of the mm tree
@ 2023-01-27 6:16 Stephen Rothwell
0 siblings, 0 replies; 138+ messages in thread
From: Stephen Rothwell @ 2023-01-27 6:16 UTC (permalink / raw)
To: Andrew Morton, Dave Airlie
Cc: Daniel Vetter, Jacek Lawrynowicz, Suren Baghdasaryan, DRI,
Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1524 bytes --]
Hi all,
After merging the mm tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
drivers/accel/ivpu/ivpu_gem.c: In function 'ivpu_bo_mmap':
drivers/accel/ivpu/ivpu_gem.c:449:23: error: assignment of read-only member 'vm_flags'
449 | vma->vm_flags |= VM_PFNMAP | VM_DONTEXPAND;
| ^~
Caused by commit
b95a895848b9 ("mm: introduce vma->vm_flags wrapper functions")
interacting with commit
647371a6609d ("accel/ivpu: Add GEM buffer object management")
from the drm tree.
I have applied the following merge fix patch for today.
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 27 Jan 2023 17:12:37 +1100
Subject: [PATCH] accel/ivpu: fix up for "mm: introduce vma->vm_flags wrapper functions"
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/accel/ivpu/ivpu_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/accel/ivpu/ivpu_gem.c b/drivers/accel/ivpu/ivpu_gem.c
index d1f923971b4c..12b219dd4f36 100644
--- a/drivers/accel/ivpu/ivpu_gem.c
+++ b/drivers/accel/ivpu/ivpu_gem.c
@@ -446,7 +446,7 @@ static int ivpu_bo_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma)
return dma_buf_mmap(obj->dma_buf, vma, 0);
}
- vma->vm_flags |= VM_PFNMAP | VM_DONTEXPAND;
+ vm_flags_set(vma, VM_PFNMAP | VM_DONTEXPAND);
vma->vm_page_prot = ivpu_bo_pgprot(bo, vm_get_page_prot(vma->vm_flags));
return 0;
--
2.35.1
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 138+ messages in thread
* linux-next: build failure after merge of the mm tree
@ 2023-01-27 5:59 Stephen Rothwell
2023-01-27 13:11 ` Jan Kara
0 siblings, 1 reply; 138+ messages in thread
From: Stephen Rothwell @ 2023-01-27 5:59 UTC (permalink / raw)
To: Andrew Morton, Jan Kara
Cc: Matthew Wilcox (Oracle),
Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 2521 bytes --]
Hi all,
After merging the mm tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
fs/udf/inode.c: In function 'udf_writepages':
fs/udf/inode.c:211:48: error: passing argument 3 of 'write_cache_pages' from incompatible pointer type [-Werror=incompatible-pointer-types]
211 | return write_cache_pages(mapping, wbc, udf_adinicb_writepage, NULL);
| ^~~~~~~~~~~~~~~~~~~~~
| |
| int (*)(struct page *, struct writeback_control *, void *)
In file included from fs/udf/inode.c:36:
include/linux/writeback.h:375:66: note: expected 'writepage_t' {aka 'int (*)(struct folio *, struct writeback_control *, void *)'} but argument is of type 'int (*)(struct page *, struct writeback_control *, void *)'
375 | struct writeback_control *wbc, writepage_t writepage,
| ~~~~~~~~~~~~^~~~~~~~~
Caused by commit
a36a897cc496 ("fs: convert writepage_t callback to pass a folio")
interacting with commit
79d3c6dbada4 ("udf: Convert in-ICB files to use udf_writepages()")
from the ext3 tree.
I have applied the following merge fix patch (I wasn't sure what to do
with the PageLocked()).
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 27 Jan 2023 16:50:34 +1100
Subject: [PATCH] udf: fix up for "fs: convert writepage_t callback to pass a folio"
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
fs/udf/inode.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/fs/udf/inode.c b/fs/udf/inode.c
index 3b2adf4cbc57..b47bf9c73f4d 100644
--- a/fs/udf/inode.c
+++ b/fs/udf/inode.c
@@ -185,16 +185,17 @@ static void udf_write_failed(struct address_space *mapping, loff_t to)
}
}
-static int udf_adinicb_writepage(struct page *page,
+static int udf_adinicb_writepage(struct folio *folio,
struct writeback_control *wbc, void *data)
{
+ struct page *page = &folio->page;
struct inode *inode = page->mapping->host;
struct udf_inode_info *iinfo = UDF_I(inode);
- BUG_ON(!PageLocked(page));
+// BUG_ON(!PageLocked(page));
memcpy_to_page(page, 0, iinfo->i_data + iinfo->i_lenEAttr,
i_size_read(inode));
- unlock_page(page);
+ folio_unlock(folio);
mark_inode_dirty(inode);
return 0;
--
2.35.1
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 138+ messages in thread
* linux-next: build failure after merge of the mm tree
@ 2023-01-25 3:05 Stephen Rothwell
0 siblings, 0 replies; 138+ messages in thread
From: Stephen Rothwell @ 2023-01-25 3:05 UTC (permalink / raw)
To: Andrew Morton
Cc: Vishal Moola (Oracle),
Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 5254 bytes --]
Hi all,
After merging the mm tree, today's linux-next build (x86_64 allnoconfig)
failed like this:
In file included from arch/x86/include/asm/page.h:85,
from arch/x86/include/asm/thread_info.h:12,
from include/linux/thread_info.h:60,
from arch/x86/include/asm/preempt.h:9,
from include/linux/preempt.h:78,
from include/linux/spinlock.h:56,
from include/linux/mmzone.h:8,
from include/linux/gfp.h:7,
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 'folio_estimated_mapcount':
include/asm-generic/memory_model.h:35:21: error: implicit declaration of function 'page_to_section'; did you mean 'present_section'? [-Werror=implicit-function-declaration]
35 | int __sec = page_to_section(__pg); \
| ^~~~~~~~~~~~~~~
include/asm-generic/memory_model.h:40:32: note: in definition of macro '__pfn_to_page'
40 | ({ unsigned long __pfn = (pfn); \
| ^~~
include/asm-generic/memory_model.h:52:21: note: in expansion of macro '__page_to_pfn'
52 | #define page_to_pfn __page_to_pfn
| ^~~~~~~~~~~~~
include/linux/mm.h:216:38: note: in expansion of macro 'page_to_pfn'
216 | #define nth_page(page,n) pfn_to_page(page_to_pfn((page)) + (n))
| ^~~~~~~~~~~
include/linux/page-flags.h:286:33: note: in expansion of macro 'nth_page'
286 | #define folio_page(folio, n) nth_page(&(folio)->page, n)
| ^~~~~~~~
include/linux/mm.h:918:30: note: in expansion of macro 'folio_page'
918 | return page_mapcount(folio_page(folio, 0));
| ^~~~~~~~~~
In file included from include/linux/memcontrol.h:20,
from include/linux/swap.h:9,
from include/linux/suspend.h:5,
from arch/x86/kernel/asm-offsets.c:14:
include/linux/mm.h: At top level:
include/linux/mm.h:1626:29: error: conflicting types for 'page_to_section'; have 'long unsigned int(const struct page *)'
1626 | static inline unsigned long page_to_section(const struct page *page)
| ^~~~~~~~~~~~~~~
include/asm-generic/memory_model.h:35:21: note: previous implicit declaration of 'page_to_section' with type 'int()'
35 | int __sec = page_to_section(__pg); \
| ^~~~~~~~~~~~~~~
include/asm-generic/memory_model.h:40:32: note: in definition of macro '__pfn_to_page'
40 | ({ unsigned long __pfn = (pfn); \
| ^~~
include/asm-generic/memory_model.h:52:21: note: in expansion of macro '__page_to_pfn'
52 | #define page_to_pfn __page_to_pfn
| ^~~~~~~~~~~~~
include/linux/mm.h:216:38: note: in expansion of macro 'page_to_pfn'
216 | #define nth_page(page,n) pfn_to_page(page_to_pfn((page)) + (n))
| ^~~~~~~~~~~
include/linux/page-flags.h:286:33: note: in expansion of macro 'nth_page'
286 | #define folio_page(folio, n) nth_page(&(folio)->page, n)
| ^~~~~~~~
include/linux/mm.h:918:30: note: in expansion of macro 'folio_page'
918 | return page_mapcount(folio_page(folio, 0));
| ^~~~~~~~~~
cc1: some warnings being treated as errors
Caused by commit
59c975083d37 ("mm: add folio_estimated_mapcount()")
I applied the following fix patch (hack):
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 25 Jan 2023 13:42:20 +1100
Subject: [PATCH] fix up for "mm: add folio_estimated_mapcount()"
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
include/linux/mm.h | 5 -----
mm/mempolicy.c | 7 +++++++
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index b7d6e290df99..78c766859fb7 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -913,11 +913,6 @@ static inline int page_mapcount(struct page *page)
return mapcount;
}
-static inline int folio_estimated_mapcount(struct folio *folio)
-{
- return page_mapcount(folio_page(folio, 0));
-}
-
int folio_total_mapcount(struct folio *folio);
/**
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index 03220ba94074..c81db10612eb 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -558,6 +558,13 @@ static int queue_folios_pte_range(pmd_t *pmd, unsigned long addr,
return addr != end ? -EIO : 0;
}
+#if defined(CONFIG_HUGETLB_PAGE) || defined(CONFIG_MIGRATION)
+static inline int folio_estimated_mapcount(struct folio *folio)
+{
+ return page_mapcount(folio_page(folio, 0));
+}
+#endif
+
static int queue_folios_hugetlb(pte_t *pte, unsigned long hmask,
unsigned long addr, unsigned long end,
struct mm_walk *walk)
--
2.35.1
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2022-12-16 1:26 Stephen Rothwell
@ 2022-12-16 3:04 ` Andrew Morton
0 siblings, 0 replies; 138+ messages in thread
From: Andrew Morton @ 2022-12-16 3:04 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Daniel Verkamp, Jeff Xu, Linux Kernel Mailing List,
Linux Next Mailing List
On Fri, 16 Dec 2022 12:26:27 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> After merging the mm tree, today's linux-next build (sparc defconfig)
> failed like this:
>
> kernel/pid_namespace.c: In function 'create_pid_namespace':
> kernel/pid_namespace.c:114:9: error: implicit declaration of function 'initialize_memfd_noexec_scope'; did you mean 'set_memfd_noexec_scope'? [-Werror=implicit-function-declaration]
> 114 | initialize_memfd_noexec_scope(ns);
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> | set_memfd_noexec_scope
> kernel/pid_namespace.c: In function 'pid_namespaces_init':
> kernel/pid_namespace.c:462:9: error: implicit declaration of function 'register_pid_ns_sysctl_table_vm'; did you mean 'register_pid_ns_ctl_table_vm'? [-Werror=implicit-function-declaration]
> 462 | register_pid_ns_sysctl_table_vm();
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> | register_pid_ns_ctl_table_vm
>
> Caused by commit
>
> 70ebb551866e ("mm/memfd: add MFD_NOEXEC_SEAL and MFD_EXEC")
>
Thanks.
--- a/kernel/pid_sysctl.h~mm-memfd-add-mfd_noexec_seal-and-mfd_exec-fix
+++ a/kernel/pid_sysctl.h
@@ -52,8 +52,10 @@ static inline void register_pid_ns_sysct
register_sysctl_paths(vm_path, pid_ns_ctl_table_vm);
}
#else
+static inline void initialize_memfd_noexec_scope(struct pid_namespace *ns) {}
static inline void set_memfd_noexec_scope(struct pid_namespace *ns) {}
static inline void register_pid_ns_ctl_table_vm(void) {}
+static inline void register_pid_ns_sysctl_table_vm(void) {}
#endif
#endif /* LINUX_PID_SYSCTL_H */
_
^ permalink raw reply [flat|nested] 138+ messages in thread
* linux-next: build failure after merge of the mm tree
@ 2022-12-16 1:26 Stephen Rothwell
2022-12-16 3:04 ` Andrew Morton
0 siblings, 1 reply; 138+ messages in thread
From: Stephen Rothwell @ 2022-12-16 1:26 UTC (permalink / raw)
To: Andrew Morton
Cc: Daniel Verkamp, Jeff Xu, Linux Kernel Mailing List,
Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1067 bytes --]
Hi all,
After merging the mm tree, today's linux-next build (sparc defconfig)
failed like this:
kernel/pid_namespace.c: In function 'create_pid_namespace':
kernel/pid_namespace.c:114:9: error: implicit declaration of function 'initialize_memfd_noexec_scope'; did you mean 'set_memfd_noexec_scope'? [-Werror=implicit-function-declaration]
114 | initialize_memfd_noexec_scope(ns);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| set_memfd_noexec_scope
kernel/pid_namespace.c: In function 'pid_namespaces_init':
kernel/pid_namespace.c:462:9: error: implicit declaration of function 'register_pid_ns_sysctl_table_vm'; did you mean 'register_pid_ns_ctl_table_vm'? [-Werror=implicit-function-declaration]
462 | register_pid_ns_sysctl_table_vm();
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| register_pid_ns_ctl_table_vm
Caused by commit
70ebb551866e ("mm/memfd: add MFD_NOEXEC_SEAL and MFD_EXEC")
I have reverted that commit (and the following 2) for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2022-12-16 0:35 ` Andrew Morton
@ 2022-12-16 1:03 ` Masami Hiramatsu
0 siblings, 0 replies; 138+ messages in thread
From: Masami Hiramatsu @ 2022-12-16 1:03 UTC (permalink / raw)
To: Andrew Morton
Cc: Stephen Rothwell, Masami Hiramatsu (Google),
Linux Kernel Mailing List, Linux Next Mailing List
On Thu, 15 Dec 2022 16:35:48 -0800
Andrew Morton <akpm@linux-foundation.org> wrote:
> On Fri, 16 Dec 2022 11:21:21 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> > Hi all,
> >
> > After merging the mm tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > In file included from fs/btrfs/tree-checker.c:20:
> > include/linux/error-injection.h: In function 'get_injectable_error_type':
> > include/linux/error-injection.h:22:17: error: 'EOPNOTSUPP' undeclared (first use in this function)
> > 22 | return -EOPNOTSUPP;
> > | ^~~~~~~~~~
> > include/linux/error-injection.h:22:17: note: each undeclared identifier is reported only once for each function it appears in
> >
> > Caused by commit
> >
> > fcb9954aa1dc ("error-injection: remove EI_ETYPE_NONE")
> >
> > I have reverted that commit for today (and the following one).
>
> Thanks. I'll try the obvious:
I sent v2 but it seems to be missed.
https://lore.kernel.org/all/167094068123.608798.9238149148720683524.stgit@devnote3/T/#u
Either your patch or v2 are OK for me. (doing the same thing)
Thank you,
>
> --- a/include/linux/error-injection.h~error-injection-remove-ei_etype_none-fix
> +++ a/include/linux/error-injection.h
> @@ -4,6 +4,7 @@
>
> #include <linux/compiler.h>
> #include <asm-generic/error-injection.h>
> +#include <linux/errno.h>
>
> #ifdef CONFIG_FUNCTION_ERROR_INJECTION
>
> _
>
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2022-12-16 0:21 Stephen Rothwell
@ 2022-12-16 0:35 ` Andrew Morton
2022-12-16 1:03 ` Masami Hiramatsu
0 siblings, 1 reply; 138+ messages in thread
From: Andrew Morton @ 2022-12-16 0:35 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Masami Hiramatsu (Google),
Linux Kernel Mailing List, Linux Next Mailing List
On Fri, 16 Dec 2022 11:21:21 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> After merging the mm tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> In file included from fs/btrfs/tree-checker.c:20:
> include/linux/error-injection.h: In function 'get_injectable_error_type':
> include/linux/error-injection.h:22:17: error: 'EOPNOTSUPP' undeclared (first use in this function)
> 22 | return -EOPNOTSUPP;
> | ^~~~~~~~~~
> include/linux/error-injection.h:22:17: note: each undeclared identifier is reported only once for each function it appears in
>
> Caused by commit
>
> fcb9954aa1dc ("error-injection: remove EI_ETYPE_NONE")
>
> I have reverted that commit for today (and the following one).
Thanks. I'll try the obvious:
--- a/include/linux/error-injection.h~error-injection-remove-ei_etype_none-fix
+++ a/include/linux/error-injection.h
@@ -4,6 +4,7 @@
#include <linux/compiler.h>
#include <asm-generic/error-injection.h>
+#include <linux/errno.h>
#ifdef CONFIG_FUNCTION_ERROR_INJECTION
_
^ permalink raw reply [flat|nested] 138+ messages in thread
* linux-next: build failure after merge of the mm tree
@ 2022-12-16 0:21 Stephen Rothwell
2022-12-16 0:35 ` Andrew Morton
0 siblings, 1 reply; 138+ messages in thread
From: Stephen Rothwell @ 2022-12-16 0:21 UTC (permalink / raw)
To: Andrew Morton
Cc: Masami Hiramatsu (Google),
Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 717 bytes --]
Hi all,
After merging the mm tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
In file included from fs/btrfs/tree-checker.c:20:
include/linux/error-injection.h: In function 'get_injectable_error_type':
include/linux/error-injection.h:22:17: error: 'EOPNOTSUPP' undeclared (first use in this function)
22 | return -EOPNOTSUPP;
| ^~~~~~~~~~
include/linux/error-injection.h:22:17: note: each undeclared identifier is reported only once for each function it appears in
Caused by commit
fcb9954aa1dc ("error-injection: remove EI_ETYPE_NONE")
I have reverted that commit for today (and the following one).
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2022-11-22 6:53 Stephen Rothwell
@ 2022-11-22 10:31 ` David Hildenbrand
0 siblings, 0 replies; 138+ messages in thread
From: David Hildenbrand @ 2022-11-22 10:31 UTC (permalink / raw)
To: Stephen Rothwell, Andrew Morton, Sidhartha Kumar
Cc: Yang Li, Linux Kernel Mailing List, Linux Next Mailing List
On 22.11.22 07:53, Stephen Rothwell wrote:
> Hi all,
>
> After merging the mm tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> In file included from include/uapi/linux/posix_types.h:5,
> from include/uapi/linux/types.h:14,
> from include/linux/types.h:6,
> from include/linux/kasan-checks.h:5,
> from include/asm-generic/rwonce.h:26,
> from ./arch/powerpc/include/generated/asm/rwonce.h:1,
> from include/linux/compiler.h:247,
> from include/linux/build_bug.h:5,
> from include/linux/container_of.h:5,
> from include/linux/list.h:5,
> from mm/hugetlb.c:6:
> mm/hugetlb.c: In function 'add_hugetlb_page':
> include/linux/stddef.h:8:14: warning: passing argument 2 of 'set_page_private' makes integer from pointer without a cast [-Wint-conversion]
> 8 | #define NULL ((void *)0)
> | ^~~~~~~~~~~
> | |
> | void *
> mm/hugetlb.c:1533:32: note: in expansion of macro 'NULL'
> 1533 | set_page_private(page, NULL);
> | ^~~~
> In file included from include/linux/mmzone.h:21,
> from include/linux/gfp.h:7,
> from include/linux/mm.h:7,
> from mm/hugetlb.c:8:
> include/linux/mm_types.h:464:70: note: expected 'long unsigned int' but argument is of type 'void *'
> 464 | static inline void set_page_private(struct page *page, unsigned long private)
> | ~~~~~~~~~~~~~~^~~~~~~
>
> Caused by commit
>
> 1f0d844bcc5b ("mm/hugetlb: stop using 0 as NULL pointer")
>
> set_page_private() have taken an unsigned long as its second argument
> since (at least) v5.8-rc1. The cited bugzilla refers to next-20221121,
> but even there:
>
> $ git grep set_page_private next-20221121:include/linux/mm_types.h
> next-20221121:include/linux/mm_types.h:static inline void set_page_private(struct page *page, unsigned long private)
>
> In fact the bugzilla refers to mm/hugetlb.c line 1531. In next-20221121
> that is:
>
> folio_change_private(folio, 0);
>
> I have reverted that commit for today. Please take more care :-(
>
Heh, that warning complains about the call to folio_change_private():
$ git show e4cd8d3ff7f9efeb97330e5e9b99eeb2a68f5cf9:mm/hugetlb.c | sed -n '1531p'
folio_change_private(folio, 0);
And that one is indeed:
$ git grep folio_change_private e4cd8d3ff7f9efeb97330e5e9b99eeb2a68f5cf9:include/linux/pagemap.h
e4cd8d3ff7f9efeb97330e5e9b99eeb2a68f5cf9:include/linux/pagemap.h: * folio_change_private - Change private data on a folio.
e4cd8d3ff7f9efeb97330e5e9b99eeb2a68f5cf9:include/linux/pagemap.h:static inline void *folio_change_private(struct folio *folio, void *data)
I missed in my review that the patch changes set_page_private()
instead because it was applied to the wrong tree ...
The folio_change_private() change is/was from Sidhartha Kumar:
commit 032158fde0b2a59cda2c66a8773135af2a04535e
Author: Sidhartha Kumar <sidhartha.kumar@oracle.com>
Date: Thu Nov 17 13:14:57 2022 -0800
mm/hugetlb: convert add_hugetlb_page() to folios and add hugetlb_cma_folio()
Convert add_hugetlb_page() to take in a folio, also convert
hugetlb_cma_page() to take in a folio.
Link: https://lkml.kernel.org/r/20221117211501.17150-7-sidhartha.kumar@oracle.com
Signed-off-by: Sidhartha Kumar <sidhartha.kumar@oracle.com>
--
Thanks,
David / dhildenb
^ permalink raw reply [flat|nested] 138+ messages in thread
* linux-next: build failure after merge of the mm tree
@ 2022-11-22 6:53 Stephen Rothwell
2022-11-22 10:31 ` David Hildenbrand
0 siblings, 1 reply; 138+ messages in thread
From: Stephen Rothwell @ 2022-11-22 6:53 UTC (permalink / raw)
To: Andrew Morton
Cc: Yang Li, David Hildenbrand, Linux Kernel Mailing List,
Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 2277 bytes --]
Hi all,
After merging the mm tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
In file included from include/uapi/linux/posix_types.h:5,
from include/uapi/linux/types.h:14,
from include/linux/types.h:6,
from include/linux/kasan-checks.h:5,
from include/asm-generic/rwonce.h:26,
from ./arch/powerpc/include/generated/asm/rwonce.h:1,
from include/linux/compiler.h:247,
from include/linux/build_bug.h:5,
from include/linux/container_of.h:5,
from include/linux/list.h:5,
from mm/hugetlb.c:6:
mm/hugetlb.c: In function 'add_hugetlb_page':
include/linux/stddef.h:8:14: warning: passing argument 2 of 'set_page_private' makes integer from pointer without a cast [-Wint-conversion]
8 | #define NULL ((void *)0)
| ^~~~~~~~~~~
| |
| void *
mm/hugetlb.c:1533:32: note: in expansion of macro 'NULL'
1533 | set_page_private(page, NULL);
| ^~~~
In file included from include/linux/mmzone.h:21,
from include/linux/gfp.h:7,
from include/linux/mm.h:7,
from mm/hugetlb.c:8:
include/linux/mm_types.h:464:70: note: expected 'long unsigned int' but argument is of type 'void *'
464 | static inline void set_page_private(struct page *page, unsigned long private)
| ~~~~~~~~~~~~~~^~~~~~~
Caused by commit
1f0d844bcc5b ("mm/hugetlb: stop using 0 as NULL pointer")
set_page_private() have taken an unsigned long as its second argument
since (at least) v5.8-rc1. The cited bugzilla refers to next-20221121,
but even there:
$ git grep set_page_private next-20221121:include/linux/mm_types.h
next-20221121:include/linux/mm_types.h:static inline void set_page_private(struct page *page, unsigned long private)
In fact the bugzilla refers to mm/hugetlb.c line 1531. In next-20221121
that is:
folio_change_private(folio, 0);
I have reverted that commit for today. Please take more care :-(
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* linux-next: build failure after merge of the mm tree
@ 2022-11-03 5:02 Stephen Rothwell
0 siblings, 0 replies; 138+ messages in thread
From: Stephen Rothwell @ 2022-11-03 5:02 UTC (permalink / raw)
To: Andrew Morton; +Cc: wuqiang, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 589 bytes --]
Hi all,
After merging the mm tree, today's linux-next build (sparc defconfig)
failed like this:
lib/objpool.c: In function '__objpool_try_get_slot':
lib/objpool.c:378:17: error: implicit declaration of function 'prefetch' [-Werror=implicit-function-declaration]
378 | prefetch(&ents[id]);
| ^~~~~~~~
cc1: some warnings being treated as errors
Caused by commit
080ae5bb93cd ("kprobes,lib: kretprobe scalability improvement")
I have reverted that commit for today (and its followup fix patch).
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2022-11-02 3:55 Stephen Rothwell
@ 2022-11-02 21:26 ` Andrew Morton
0 siblings, 0 replies; 138+ messages in thread
From: Andrew Morton @ 2022-11-02 21:26 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Sidhartha Kumar, Linux Kernel Mailing List, Linux Next Mailing List
On Wed, 2 Nov 2022 14:55:32 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> After merging the mm tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> mm/migrate.c: In function 'unmap_and_move_huge_page':
> mm/migrate.c:1315:13: error: implicit declaration of function 'hugetlb_folio_subpool'; did you mean 'hugetlb_page_subpool'? [-Werror=implicit-function-declaration]
> 1315 | if (hugetlb_folio_subpool(src) && !folio_mapping(src)) {
> | ^~~~~~~~~~~~~~~~~~~~~
> | hugetlb_page_subpool
> cc1: some warnings being treated as errors
>
> Caused by commit
>
> fa7dc4d80445 ("mm/hugetlb: convert move_hugetlb_state() to folios")
>
> This build does *not* have CONFIG_HUGETLB_PAGE set.
>
Thanks, let's try this:
--- a/include/linux/hugetlb.h~mm-hugetlb-convert-move_hugetlb_state-to-folios-fix
+++ a/include/linux/hugetlb.h
@@ -991,6 +991,11 @@ void hugetlb_unregister_node(struct node
#else /* CONFIG_HUGETLB_PAGE */
struct hstate {};
+static inline struct hugepage_subpool *hugetlb_folio_subpool(struct folio *folio)
+{
+ return NULL;
+}
+
static inline struct hugepage_subpool *hugetlb_page_subpool(struct page *hpage)
{
return NULL;
_
^ permalink raw reply [flat|nested] 138+ messages in thread
* linux-next: build failure after merge of the mm tree
@ 2022-11-02 3:55 Stephen Rothwell
2022-11-02 21:26 ` Andrew Morton
0 siblings, 1 reply; 138+ messages in thread
From: Stephen Rothwell @ 2022-11-02 3:55 UTC (permalink / raw)
To: Andrew Morton
Cc: Sidhartha Kumar, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 757 bytes --]
Hi all,
After merging the mm tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
mm/migrate.c: In function 'unmap_and_move_huge_page':
mm/migrate.c:1315:13: error: implicit declaration of function 'hugetlb_folio_subpool'; did you mean 'hugetlb_page_subpool'? [-Werror=implicit-function-declaration]
1315 | if (hugetlb_folio_subpool(src) && !folio_mapping(src)) {
| ^~~~~~~~~~~~~~~~~~~~~
| hugetlb_page_subpool
cc1: some warnings being treated as errors
Caused by commit
fa7dc4d80445 ("mm/hugetlb: convert move_hugetlb_state() to folios")
This build does *not* have CONFIG_HUGETLB_PAGE set.
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* linux-next: build failure after merge of the mm tree
@ 2022-10-18 1:24 Stephen Rothwell
0 siblings, 0 replies; 138+ messages in thread
From: Stephen Rothwell @ 2022-10-18 1:24 UTC (permalink / raw)
To: Andrew Morton
Cc: Sergey Shtylyov, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1891 bytes --]
Hi all,
After merging the mm tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
arch/powerpc/kernel/ptrace/ptrace-view.c: In function 'gpr32_set_common':
arch/powerpc/kernel/ptrace/ptrace-view.c:709:16: error: void value not ignored as it ought to be
709 | return user_regset_copyin_ignore(&pos, &count, &kbuf, &ubuf,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
710 | (PT_TRAP + 1) * sizeof(reg), -1);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Caused by commit
1afca3ae915b ("regset: make user_regset_copyin_ignore() *void*")
after commit
8541413ac862 ("powerpc: ptrace: user_regset_copyin_ignore() always returns 0")
missed one call site.
I have applied the following patch for today.
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 18 Oct 2022 12:19:20 +1100
Subject: [PATCH] fix up for "powerpc: ptrace: user_regset_copyin_ignore() always returns 0"
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/kernel/ptrace/ptrace-view.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/ptrace/ptrace-view.c b/arch/powerpc/kernel/ptrace/ptrace-view.c
index ca0bf8da48fd..2087a785f05f 100644
--- a/arch/powerpc/kernel/ptrace/ptrace-view.c
+++ b/arch/powerpc/kernel/ptrace/ptrace-view.c
@@ -706,8 +706,9 @@ int gpr32_set_common(struct task_struct *target,
ubuf = u;
pos *= sizeof(reg);
count *= sizeof(reg);
- return user_regset_copyin_ignore(&pos, &count, &kbuf, &ubuf,
- (PT_TRAP + 1) * sizeof(reg), -1);
+ user_regset_copyin_ignore(&pos, &count, &kbuf, &ubuf,
+ (PT_TRAP + 1) * sizeof(reg), -1);
+ return 0;
Efault:
user_read_access_end();
--
2.35.1
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2022-09-23 9:50 ` Michael Walle
@ 2022-09-23 11:01 ` Naoya Horiguchi
0 siblings, 0 replies; 138+ messages in thread
From: Naoya Horiguchi @ 2022-09-23 11:01 UTC (permalink / raw)
To: Michael Walle; +Cc: sfr, akpm, linux-kernel, linux-next, naoya.horiguchi
On Fri, Sep 23, 2022 at 11:50:13AM +0200, Michael Walle wrote:
> Hi,
>
> > After merging the mm tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > drivers/base/memory.c: In function 'memory_block_online':
> > drivers/base/memory.c:186:34: error: 'struct memory_block' has no member na=
> > med 'nr_hwpoison'
> > 186 | if (atomic_long_read(&mem->nr_hwpoison))
> > | ^~
> > drivers/base/memory.c: In function 'remove_memory_block_devices':
> > drivers/base/memory.c:870:61: error: 'struct memory_block' has no member na=
> > med 'nr_hwpoison'
> > 870 | clear_hwpoisoned_pages(atomic_long_read(&mem->nr_hw=
> > poison));
> > | ^~
> >
> > Caused by commit
> >
> > 69b496f03bb4 ("mm/hwpoison: introduce per-memory_block hwpoison counter")
> >
> > This build has CONFIG_MEMORY_FAILURE not set.
Sorry for inconvenience, I submitted a possible fix hours ago,
https://lore.kernel.org/linux-mm/20220923081827.GA1357512@ik1-406-35019.vs.sakura.ne.jp/T/#t
I think the above build error should be fixed by this.
(the updated patch is here https://lore.kernel.org/linux-mm/20220923082613.GB1357512@ik1-406-35019.vs.sakura.ne.jp/T/#u)
But ...
>
> There also seems be more missing stubs. I'm getting:
>
> aarch64-linux-gnu-ld: mm/memory-failure.o: in function `unpoison_memory':
> memory-failure.c:(.text+0x1c38): undefined reference to `memblk_nr_poison_sub'
> aarch64-linux-gnu-ld: mm/memory-failure.o: in function `num_poisoned_pages_inc':
> memory-failure.c:(.text+0x2c8c): undefined reference to `memblk_nr_poison_inc'
> aarch64-linux-gnu-ld: memory-failure.c:(.text+0x2cbc): undefined reference to `memblk_nr_poison_inc'
>
> On a board where CONFIG_MEMORY_HOTPLUG is not set, but
> CONFIG_MEMORY_FAILURE is. So either there are stubs missing or
> MEMORY_FAILURE should depend MEMORY_HOTPLUG (?!).
Yes, the new field ->nr_hwpoison is meaningful only when both settings are
enabled, so I need/will update #ifdef condition to check MEMORY_HOTPLUG.
In x86, CONFIG_MEMORY_HOTPLUG=n and CONFIG_MEMORY_FAILURE=y does not show
this error. So this error might be caused by arch dependency.
Anyway I'll update the patch again soon.
Thank you for the report.
- Naoya Horiguchi
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2022-09-23 7:55 Stephen Rothwell
@ 2022-09-23 9:50 ` Michael Walle
2022-09-23 11:01 ` Naoya Horiguchi
0 siblings, 1 reply; 138+ messages in thread
From: Michael Walle @ 2022-09-23 9:50 UTC (permalink / raw)
To: sfr; +Cc: akpm, linux-kernel, linux-next, naoya.horiguchi, Michael Walle
Hi,
> After merging the mm tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> drivers/base/memory.c: In function 'memory_block_online':
> drivers/base/memory.c:186:34: error: 'struct memory_block' has no member na=
> med 'nr_hwpoison'
> 186 | if (atomic_long_read(&mem->nr_hwpoison))
> | ^~
> drivers/base/memory.c: In function 'remove_memory_block_devices':
> drivers/base/memory.c:870:61: error: 'struct memory_block' has no member na=
> med 'nr_hwpoison'
> 870 | clear_hwpoisoned_pages(atomic_long_read(&mem->nr_hw=
> poison));
> | ^~
>
> Caused by commit
>
> 69b496f03bb4 ("mm/hwpoison: introduce per-memory_block hwpoison counter")
>
> This build has CONFIG_MEMORY_FAILURE not set.
There also seems be more missing stubs. I'm getting:
aarch64-linux-gnu-ld: mm/memory-failure.o: in function `unpoison_memory':
memory-failure.c:(.text+0x1c38): undefined reference to `memblk_nr_poison_sub'
aarch64-linux-gnu-ld: mm/memory-failure.o: in function `num_poisoned_pages_inc':
memory-failure.c:(.text+0x2c8c): undefined reference to `memblk_nr_poison_inc'
aarch64-linux-gnu-ld: memory-failure.c:(.text+0x2cbc): undefined reference to `memblk_nr_poison_inc'
On a board where CONFIG_MEMORY_HOTPLUG is not set, but
CONFIG_MEMORY_FAILURE is. So either there are stubs missing or
MEMORY_FAILURE should depend MEMORY_HOTPLUG (?!).
-michael
^ permalink raw reply [flat|nested] 138+ messages in thread
* linux-next: build failure after merge of the mm tree
@ 2022-09-23 7:55 Stephen Rothwell
2022-09-23 9:50 ` Michael Walle
0 siblings, 1 reply; 138+ messages in thread
From: Stephen Rothwell @ 2022-09-23 7:55 UTC (permalink / raw)
To: Andrew Morton
Cc: Naoya Horiguchi, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 2095 bytes --]
Hi all,
After merging the mm tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
drivers/base/memory.c: In function 'memory_block_online':
drivers/base/memory.c:186:34: error: 'struct memory_block' has no member named 'nr_hwpoison'
186 | if (atomic_long_read(&mem->nr_hwpoison))
| ^~
drivers/base/memory.c: In function 'remove_memory_block_devices':
drivers/base/memory.c:870:61: error: 'struct memory_block' has no member named 'nr_hwpoison'
870 | clear_hwpoisoned_pages(atomic_long_read(&mem->nr_hwpoison));
| ^~
Caused by commit
69b496f03bb4 ("mm/hwpoison: introduce per-memory_block hwpoison counter")
This build has CONFIG_MEMORY_FAILURE not set.
I have applied the following fix patch for today.
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 23 Sep 2022 17:50:50 +1000
Subject: [PATCH] fix up for "mm/hwpoison: introduce per-memory_block hwpoison counter"
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/base/memory.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index c9bde4c4ffdf..143c63ceb4c3 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -183,8 +183,10 @@ static int memory_block_online(struct memory_block *mem)
struct zone *zone;
int ret;
+#ifdef CONFIG_MEMORY_FAILURE
if (atomic_long_read(&mem->nr_hwpoison))
return -EHWPOISON;
+#endif
zone = zone_for_pfn_range(mem->online_type, mem->nid, mem->group,
start_pfn, nr_pages);
@@ -867,7 +869,9 @@ void remove_memory_block_devices(unsigned long start, unsigned long size)
mem = find_memory_block_by_id(block_id);
if (WARN_ON_ONCE(!mem))
continue;
+#ifdef CONFIG_MEMORY_FAILURE
clear_hwpoisoned_pages(atomic_long_read(&mem->nr_hwpoison));
+#endif
unregister_memory_block_under_nodes(mem);
remove_memory_block(mem);
}
--
2.35.1
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2022-09-15 16:37 ` Mike Kravetz
@ 2022-09-15 20:06 ` Andrew Morton
0 siblings, 0 replies; 138+ messages in thread
From: Andrew Morton @ 2022-09-15 20:06 UTC (permalink / raw)
To: Mike Kravetz
Cc: Stephen Rothwell, Linux Kernel Mailing List, Linux Next Mailing List
On Thu, 15 Sep 2022 09:37:08 -0700 Mike Kravetz <mike.kravetz@oracle.com> wrote:
> Andrew, the following change to 47bc61e7caf9 ("hugetlb: add vma based lock for
> pmd sharing") will fix the issue. Would you like to just add the fix, or
> would you like another version of 47bc61e7caf9, or perhaps another version of
> the series? Happy to do whatever is easier for you.
This simple fix is easiest for me. More importantly, I think it's
easier for reviewers, who don't have to plough through a whole new
series unsure what might have changed.
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2022-09-15 7:07 Stephen Rothwell
@ 2022-09-15 16:37 ` Mike Kravetz
2022-09-15 20:06 ` Andrew Morton
0 siblings, 1 reply; 138+ messages in thread
From: Mike Kravetz @ 2022-09-15 16:37 UTC (permalink / raw)
To: Stephen Rothwell, Andrew Morton
Cc: Linux Kernel Mailing List, Linux Next Mailing List
On 09/15/22 17:07, Stephen Rothwell wrote:
> Hi all,
>
> After merging the mm tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> ld: warning: discarding dynamic section .glink
> ld: warning: discarding dynamic section .plt
> ld: linkage table error against `hugetlb_vma_lock_release'
> ld: stubs don't match calculated size
> ld: can not build stubs: bad value
> ld: fs/hugetlbfs/inode.o: in function `.remove_inode_hugepages':
> inode.c:(.text+0x2538): undefined reference to `.hugetlb_vma_lock_release'
> ld: inode.c:(.text+0x25f4): undefined reference to `.hugetlb_vma_lock_release'
>
> Caused by commits
>
> d56100904028 ("hugetlb: use new vma_lock for pmd sharing synchronization")
> 47bc61e7caf9 ("hugetlb: add vma based lock for pmd sharing")
>
> The definition of hugetlb_vma_lock_release() is guarded by
> CONFIG_ARCH_WANT_HUGE_PMD_SHARE, but the usage in fs/hugetlbfs/inode.c
> is not.
Sorry about that! When thinking about the need for a stub, I only
considered the !CONFIG_HUGETLB_PAGE case. :(
Andrew, the following change to 47bc61e7caf9 ("hugetlb: add vma based lock for
pmd sharing") will fix the issue. Would you like to just add the fix, or
would you like another version of 47bc61e7caf9, or perhaps another version of
the series? Happy to do whatever is easier for you.
From 8b3031350154e8e401ccfbc5e71cb95ef654d017 Mon Sep 17 00:00:00 2001
From: Mike Kravetz <mike.kravetz@oracle.com>
Date: Thu, 15 Sep 2022 09:33:44 -0700
Subject: [PATCH] hugetlb: fix build issue for missing hugetlb_vma_lock_release
Add a stub for hugetlb_vma_lock_release to build in the case
CONFIG_HUGETLB_PAGE && !CONFIG_ARCH_WANT_HUGE_PMD_SHARE.
Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
---
mm/hugetlb.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 2207300791e5..cc7877da18d7 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -7008,6 +7008,10 @@ void hugetlb_vma_assert_locked(struct vm_area_struct *vma)
{
}
+void hugetlb_vma_lock_release(struct kref *kref)
+{
+}
+
static void hugetlb_vma_lock_free(struct vm_area_struct *vma)
{
}
--
2.37.2
^ permalink raw reply related [flat|nested] 138+ messages in thread
* linux-next: build failure after merge of the mm tree
@ 2022-09-15 7:07 Stephen Rothwell
2022-09-15 16:37 ` Mike Kravetz
0 siblings, 1 reply; 138+ messages in thread
From: Stephen Rothwell @ 2022-09-15 7:07 UTC (permalink / raw)
To: Andrew Morton
Cc: Mike Kravetz, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 980 bytes --]
Hi all,
After merging the mm tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
ld: warning: discarding dynamic section .glink
ld: warning: discarding dynamic section .plt
ld: linkage table error against `hugetlb_vma_lock_release'
ld: stubs don't match calculated size
ld: can not build stubs: bad value
ld: fs/hugetlbfs/inode.o: in function `.remove_inode_hugepages':
inode.c:(.text+0x2538): undefined reference to `.hugetlb_vma_lock_release'
ld: inode.c:(.text+0x25f4): undefined reference to `.hugetlb_vma_lock_release'
Caused by commits
d56100904028 ("hugetlb: use new vma_lock for pmd sharing synchronization")
47bc61e7caf9 ("hugetlb: add vma based lock for pmd sharing")
The definition of hugetlb_vma_lock_release() is guarded by
CONFIG_ARCH_WANT_HUGE_PMD_SHARE, but the usage in fs/hugetlbfs/inode.c
is not.
I have reverted commit d56100904028 (and the following commit) for
today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2022-09-06 12:05 ` Rob Clark
@ 2022-09-06 18:05 ` Stephen Rothwell
0 siblings, 0 replies; 138+ messages in thread
From: Stephen Rothwell @ 2022-09-06 18:05 UTC (permalink / raw)
To: Rob Clark
Cc: Andrew Morton, Rob Clark, Sean Paul, NeilBrown,
Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 446 bytes --]
Hi Rob,
On Tue, 6 Sep 2022 05:05:32 -0700 Rob Clark <robdclark@chromium.org> wrote:
>
> It looks like, at least for now, I can replace `sc->gfp_mask &
> __GFP_ATOMIC` with `!(sc->gfp_mask & __GFP_DIRECT_RECLAIM)`.. I'm not
> sure if there would be any cases where we could otherwise sleep but
> __GFP_DIRECT_RECLAIM is not set?
The commit message for 9178e3dcb121 seems to say that would be correct.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2022-09-06 11:03 Stephen Rothwell
@ 2022-09-06 12:05 ` Rob Clark
2022-09-06 18:05 ` Stephen Rothwell
0 siblings, 1 reply; 138+ messages in thread
From: Rob Clark @ 2022-09-06 12:05 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Andrew Morton, Rob Clark, Sean Paul, NeilBrown,
Linux Kernel Mailing List, Linux Next Mailing List
It looks like, at least for now, I can replace `sc->gfp_mask &
__GFP_ATOMIC` with `!(sc->gfp_mask & __GFP_DIRECT_RECLAIM)`.. I'm not
sure if there would be any cases where we could otherwise sleep but
__GFP_DIRECT_RECLAIM is not set?
BR,
-R
On Tue, Sep 6, 2022 at 4:03 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> After merging the mm tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> drivers/gpu/drm/msm/msm_gem_shrinker.c: In function 'can_block':
> drivers/gpu/drm/msm/msm_gem_shrinker.c:29:28: error: '__GFP_ATOMIC' undeclared (first use in this function); did you mean 'GFP_ATOMIC'?
> 29 | if (sc->gfp_mask & __GFP_ATOMIC)
> | ^~~~~~~~~~~~
> | GFP_ATOMIC
>
> Caused by commit
>
> 9178e3dcb121 ("mm: discard __GFP_ATOMIC")
>
> interacting with commit
>
> 025d27239a2f ("drm/msm/gem: Evict active GEM objects when necessary")
>
> from the drm-msm tree.
>
> I have reverted the drm-msm tree commit for today.
>
> --
> Cheers,
> Stephen Rothwell
^ permalink raw reply [flat|nested] 138+ messages in thread
* linux-next: build failure after merge of the mm tree
@ 2022-09-06 11:03 Stephen Rothwell
2022-09-06 12:05 ` Rob Clark
0 siblings, 1 reply; 138+ messages in thread
From: Stephen Rothwell @ 2022-09-06 11:03 UTC (permalink / raw)
To: Andrew Morton, Rob Clark, Sean Paul
Cc: NeilBrown, Rob Clark, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 742 bytes --]
Hi all,
After merging the mm tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
drivers/gpu/drm/msm/msm_gem_shrinker.c: In function 'can_block':
drivers/gpu/drm/msm/msm_gem_shrinker.c:29:28: error: '__GFP_ATOMIC' undeclared (first use in this function); did you mean 'GFP_ATOMIC'?
29 | if (sc->gfp_mask & __GFP_ATOMIC)
| ^~~~~~~~~~~~
| GFP_ATOMIC
Caused by commit
9178e3dcb121 ("mm: discard __GFP_ATOMIC")
interacting with commit
025d27239a2f ("drm/msm/gem: Evict active GEM objects when necessary")
from the drm-msm tree.
I have reverted the drm-msm tree commit for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2022-08-26 7:10 Stephen Rothwell
@ 2022-08-26 7:32 ` Michal Hocko
0 siblings, 0 replies; 138+ messages in thread
From: Michal Hocko @ 2022-08-26 7:32 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Andrew Morton, Linux Kernel Mailing List, Linux Next Mailing List
On Fri 26-08-22 17:10:20, Stephen Rothwell wrote:
> Hi all,
>
> After merging the mm tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> arch/powerpc/xmon/xmon.c: In function 'cmds':
> arch/powerpc/xmon/xmon.c:1089:33: error: too few arguments to function 'show_mem'
> 1089 | show_mem(0, NULL);
> | ^~~~~~~~
> In file included from arch/powerpc/xmon/xmon.c:14:
> include/linux/mm.h:2585:13: note: declared here
> 2585 | extern void show_mem(unsigned int flags, nodemask_t *nodemask, gfp_t gfp_mask);
> | ^~~~~~~~
>
> Caused by commit
>
> 9ea9abc5cd7e ("mm: reduce noise in show_mem for lowmem allocations")
>
> I have reverted that commit for today (and the following fix).
This should fix it. Andrew, could you fold it into the patch please?
git grep doesn't suggest more instances AFAICS
---
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index 3d9782ea3fa7..19b1a94b0c00 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -1086,7 +1086,7 @@ cmds(struct pt_regs *excp)
memzcan();
break;
case 'i':
- show_mem(0, NULL);
+ show_mem(0, NULL, GFP_HIGHUSER_MOVABLE);
break;
default:
termch = cmd;
--
Michal Hocko
SUSE Labs
^ permalink raw reply related [flat|nested] 138+ messages in thread
* linux-next: build failure after merge of the mm tree
@ 2022-08-26 7:10 Stephen Rothwell
2022-08-26 7:32 ` Michal Hocko
0 siblings, 1 reply; 138+ messages in thread
From: Stephen Rothwell @ 2022-08-26 7:10 UTC (permalink / raw)
To: Andrew Morton
Cc: Michal Hocko, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 765 bytes --]
Hi all,
After merging the mm tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
arch/powerpc/xmon/xmon.c: In function 'cmds':
arch/powerpc/xmon/xmon.c:1089:33: error: too few arguments to function 'show_mem'
1089 | show_mem(0, NULL);
| ^~~~~~~~
In file included from arch/powerpc/xmon/xmon.c:14:
include/linux/mm.h:2585:13: note: declared here
2585 | extern void show_mem(unsigned int flags, nodemask_t *nodemask, gfp_t gfp_mask);
| ^~~~~~~~
Caused by commit
9ea9abc5cd7e ("mm: reduce noise in show_mem for lowmem allocations")
I have reverted that commit for today (and the following fix).
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2022-07-08 15:17 ` Darrick J. Wong
@ 2022-07-10 22:28 ` Stephen Rothwell
0 siblings, 0 replies; 138+ messages in thread
From: Stephen Rothwell @ 2022-07-10 22:28 UTC (permalink / raw)
To: Darrick J. Wong
Cc: Andrew Morton, David Chinner, linux-xfs, Shiyang Ruan,
Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1232 bytes --]
Hi Darrick,
On Fri, 8 Jul 2022 08:17:51 -0700 "Darrick J. Wong" <djwong@kernel.org> wrote:
>
> This isn't quite correct -- references to xfs_perag objects must be
> released once they are acquired. The following patch against today's
> tree fixes this problem:
>
> diff --git a/fs/xfs/xfs_notify_failure.c b/fs/xfs/xfs_notify_failure.c
> index f3c62c19475e..69d9c83ea4b2 100644
> --- a/fs/xfs/xfs_notify_failure.c
> +++ b/fs/xfs/xfs_notify_failure.c
> @@ -127,10 +127,12 @@ xfs_dax_notify_ddev_failure(
>
> pag = xfs_perag_get(mp, agno);
> error = xfs_alloc_read_agf(pag, tp, 0, &agf_bp);
> - if (error)
> + if (error) {
> + xfs_perag_put(pag);
> break;
> + }
>
> - cur = xfs_rmapbt_init_cursor(mp, tp, agf_bp, agf_bp->b_pag);
> + cur = xfs_rmapbt_init_cursor(mp, tp, agf_bp, pag);
>
> /*
> * Set the rmap range from ri_low to ri_high, which represents
> @@ -151,6 +153,7 @@ xfs_dax_notify_ddev_failure(
> xfs_dax_failure_fn, ¬ify);
> xfs_btree_del_cursor(cur, error);
> xfs_trans_brelse(tp, agf_bp);
> + xfs_perag_put(pag);
> if (error)
> break;
>
Thanks, I will add that to the resolution from today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2022-07-08 9:44 Stephen Rothwell
@ 2022-07-08 15:17 ` Darrick J. Wong
2022-07-10 22:28 ` Stephen Rothwell
0 siblings, 1 reply; 138+ messages in thread
From: Darrick J. Wong @ 2022-07-08 15:17 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Andrew Morton, David Chinner, linux-xfs, Shiyang Ruan,
Linux Kernel Mailing List, Linux Next Mailing List
On Fri, Jul 08, 2022 at 07:44:37PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the mm tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> fs/xfs/xfs_notify_failure.c: In function 'xfs_dax_notify_ddev_failure':
> fs/xfs/xfs_notify_failure.c:126:44: error: passing argument 1 of 'xfs_alloc_read_agf' from incompatible pointer type [-Werror=incompatible-pointer-types]
> 126 | error = xfs_alloc_read_agf(mp, tp, agno, 0, &agf_bp);
> | ^~
> | |
> | struct xfs_mount *
> In file included from fs/xfs/xfs_notify_failure.c:12:
> fs/xfs/libxfs/xfs_alloc.h:173:42: note: expected 'struct xfs_perag *' but argument is of type 'struct xfs_mount *'
> 173 | int xfs_alloc_read_agf(struct xfs_perag *pag, struct xfs_trans *tp, int flags,
> | ~~~~~~~~~~~~~~~~~~^~~
> fs/xfs/xfs_notify_failure.c:126:25: error: too many arguments to function 'xfs_alloc_read_agf'
> 126 | error = xfs_alloc_read_agf(mp, tp, agno, 0, &agf_bp);
> | ^~~~~~~~~~~~~~~~~~
> In file included from fs/xfs/xfs_notify_failure.c:12:
> fs/xfs/libxfs/xfs_alloc.h:173:5: note: declared here
> 173 | int xfs_alloc_read_agf(struct xfs_perag *pag, struct xfs_trans *tp, int flags,
> | ^~~~~~~~~~~~~~~~~~
> cc1: all warnings being treated as errors
>
> Caused by commit
>
> 469a9c74c119 ("xfs: implement ->notify_failure() for XFS")
>
> interacting with commit
>
> c4829aba9c8d ("xfs: pass perag to xfs_alloc_read_agf()")
>
> from the xfs tree.
>
> I have applied the following merge fix patch.
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 8 Jul 2022 19:11:56 +1000
> Subject: [PATCH] fix up for "xfs: pass perag to xfs_alloc_read_agf()"
>
> interacting with "xfs: implement ->notify_failure() for XFS"
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> fs/xfs/xfs_notify_failure.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/fs/xfs/xfs_notify_failure.c b/fs/xfs/xfs_notify_failure.c
> index aa8dc27c599c..f3c62c19475e 100644
> --- a/fs/xfs/xfs_notify_failure.c
> +++ b/fs/xfs/xfs_notify_failure.c
> @@ -18,6 +18,7 @@
> #include "xfs_rmap_btree.h"
> #include "xfs_rtalloc.h"
> #include "xfs_trans.h"
> +#include "xfs_ag.h"
>
> #include <linux/mm.h>
> #include <linux/dax.h>
> @@ -122,8 +123,10 @@ xfs_dax_notify_ddev_failure(
> struct failure_info notify;
> struct xfs_agf *agf;
> xfs_agblock_t agend;
> + struct xfs_perag *pag;
>
> - error = xfs_alloc_read_agf(mp, tp, agno, 0, &agf_bp);
> + pag = xfs_perag_get(mp, agno);
> + error = xfs_alloc_read_agf(pag, tp, 0, &agf_bp);
> if (error)
> break;
This isn't quite correct -- references to xfs_perag objects must be
released once they are acquired. The following patch against today's
tree fixes this problem:
diff --git a/fs/xfs/xfs_notify_failure.c b/fs/xfs/xfs_notify_failure.c
index f3c62c19475e..69d9c83ea4b2 100644
--- a/fs/xfs/xfs_notify_failure.c
+++ b/fs/xfs/xfs_notify_failure.c
@@ -127,10 +127,12 @@ xfs_dax_notify_ddev_failure(
pag = xfs_perag_get(mp, agno);
error = xfs_alloc_read_agf(pag, tp, 0, &agf_bp);
- if (error)
+ if (error) {
+ xfs_perag_put(pag);
break;
+ }
- cur = xfs_rmapbt_init_cursor(mp, tp, agf_bp, agf_bp->b_pag);
+ cur = xfs_rmapbt_init_cursor(mp, tp, agf_bp, pag);
/*
* Set the rmap range from ri_low to ri_high, which represents
@@ -151,6 +153,7 @@ xfs_dax_notify_ddev_failure(
xfs_dax_failure_fn, ¬ify);
xfs_btree_del_cursor(cur, error);
xfs_trans_brelse(tp, agf_bp);
+ xfs_perag_put(pag);
if (error)
break;
--D
>
> --
> 2.35.1
>
> --
> Cheers,
> Stephen Rothwell
^ permalink raw reply related [flat|nested] 138+ messages in thread
* linux-next: build failure after merge of the mm tree
@ 2022-07-08 9:44 Stephen Rothwell
2022-07-08 15:17 ` Darrick J. Wong
0 siblings, 1 reply; 138+ messages in thread
From: Stephen Rothwell @ 2022-07-08 9:44 UTC (permalink / raw)
To: Andrew Morton, Darrick J. Wong, David Chinner
Cc: linux-xfs, Shiyang Ruan, Linux Kernel Mailing List,
Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 2772 bytes --]
Hi all,
After merging the mm tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
fs/xfs/xfs_notify_failure.c: In function 'xfs_dax_notify_ddev_failure':
fs/xfs/xfs_notify_failure.c:126:44: error: passing argument 1 of 'xfs_alloc_read_agf' from incompatible pointer type [-Werror=incompatible-pointer-types]
126 | error = xfs_alloc_read_agf(mp, tp, agno, 0, &agf_bp);
| ^~
| |
| struct xfs_mount *
In file included from fs/xfs/xfs_notify_failure.c:12:
fs/xfs/libxfs/xfs_alloc.h:173:42: note: expected 'struct xfs_perag *' but argument is of type 'struct xfs_mount *'
173 | int xfs_alloc_read_agf(struct xfs_perag *pag, struct xfs_trans *tp, int flags,
| ~~~~~~~~~~~~~~~~~~^~~
fs/xfs/xfs_notify_failure.c:126:25: error: too many arguments to function 'xfs_alloc_read_agf'
126 | error = xfs_alloc_read_agf(mp, tp, agno, 0, &agf_bp);
| ^~~~~~~~~~~~~~~~~~
In file included from fs/xfs/xfs_notify_failure.c:12:
fs/xfs/libxfs/xfs_alloc.h:173:5: note: declared here
173 | int xfs_alloc_read_agf(struct xfs_perag *pag, struct xfs_trans *tp, int flags,
| ^~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
Caused by commit
469a9c74c119 ("xfs: implement ->notify_failure() for XFS")
interacting with commit
c4829aba9c8d ("xfs: pass perag to xfs_alloc_read_agf()")
from the xfs tree.
I have applied the following merge fix patch.
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 8 Jul 2022 19:11:56 +1000
Subject: [PATCH] fix up for "xfs: pass perag to xfs_alloc_read_agf()"
interacting with "xfs: implement ->notify_failure() for XFS"
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
fs/xfs/xfs_notify_failure.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/fs/xfs/xfs_notify_failure.c b/fs/xfs/xfs_notify_failure.c
index aa8dc27c599c..f3c62c19475e 100644
--- a/fs/xfs/xfs_notify_failure.c
+++ b/fs/xfs/xfs_notify_failure.c
@@ -18,6 +18,7 @@
#include "xfs_rmap_btree.h"
#include "xfs_rtalloc.h"
#include "xfs_trans.h"
+#include "xfs_ag.h"
#include <linux/mm.h>
#include <linux/dax.h>
@@ -122,8 +123,10 @@ xfs_dax_notify_ddev_failure(
struct failure_info notify;
struct xfs_agf *agf;
xfs_agblock_t agend;
+ struct xfs_perag *pag;
- error = xfs_alloc_read_agf(mp, tp, agno, 0, &agf_bp);
+ pag = xfs_perag_get(mp, agno);
+ error = xfs_alloc_read_agf(pag, tp, 0, &agf_bp);
if (error)
break;
--
2.35.1
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2022-05-12 11:07 ` Catalin Marinas
2022-05-12 11:13 ` Baolin Wang
@ 2022-05-13 7:18 ` Stephen Rothwell
1 sibling, 0 replies; 138+ messages in thread
From: Stephen Rothwell @ 2022-05-13 7:18 UTC (permalink / raw)
To: Catalin Marinas
Cc: Andrew Morton, Will Deacon, Anshuman Khandual, Baolin Wang,
Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 2331 bytes --]
Hi Catalin,
On Thu, 12 May 2022 12:07:41 +0100 Catalin Marinas <catalin.marinas@arm.com> wrote:
>
> Note that after the arm64 commit, get_clear_contig() no longer flushes
> the TLB. So maybe something like:
>
> diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
> index 30f5b76aabe9..9a999550df8e 100644
> --- a/arch/arm64/mm/hugetlbpage.c
> +++ b/arch/arm64/mm/hugetlbpage.c
> @@ -485,12 +485,15 @@ pte_t huge_ptep_clear_flush(struct vm_area_struct *vma,
> {
> size_t pgsize;
> int ncontig;
> + pte_t orig_pte;
>
> if (!pte_cont(READ_ONCE(*ptep)))
> return ptep_clear_flush(vma, addr, ptep);
>
> ncontig = find_num_contig(vma->vm_mm, addr, ptep, &pgsize);
> - return get_clear_contig(vma->vm_mm, addr, ptep, pgsize, ncontig);
> + orig_pte = get_clear_contig(vma->vm_mm, addr, ptep, pgsize, ncontig);
> + flush_tlb_range(vma, addr, addr + pgsize * ncontig);
> + return orig_pte;
> }
>
> static int __init hugetlbpage_init(void)
I have modified my merge resolution patch to as in the above so it
looks like this now:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 13 May 2022 17:08:07 +1000
Subject: [PATCH] fixup for "mm: change huge_ptep_clear_flush() to return the original pte"
It interacts with commit
fb396bb459c1 ("arm64/hugetlb: Drop TLB flush from get_clear_flush()")
from the arm64 tree
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/arm64/mm/hugetlbpage.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
index 5bdf913dedc7..10b4a19ed6a2 100644
--- a/arch/arm64/mm/hugetlbpage.c
+++ b/arch/arm64/mm/hugetlbpage.c
@@ -485,12 +485,15 @@ pte_t huge_ptep_clear_flush(struct vm_area_struct *vma,
{
size_t pgsize;
int ncontig;
+ pte_t orig_pte;
if (!pte_cont(READ_ONCE(*ptep)))
return ptep_clear_flush(vma, addr, ptep);
ncontig = find_num_contig(vma->vm_mm, addr, ptep, &pgsize);
- return get_clear_flush(vma->vm_mm, addr, ptep, pgsize, ncontig);
+ orig_pte = get_clear_contig(vma->vm_mm, addr, ptep, pgsize, ncontig);
+ flush_tlb_range(vma, addr, addr + pgsize * ncontig);
+ return orig_pte;
}
static int __init hugetlbpage_init(void)
--
2.35.1
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2022-05-12 13:28 ` Catalin Marinas
@ 2022-05-12 19:10 ` Andrew Morton
0 siblings, 0 replies; 138+ messages in thread
From: Andrew Morton @ 2022-05-12 19:10 UTC (permalink / raw)
To: Catalin Marinas
Cc: Baolin Wang, Stephen Rothwell, Will Deacon, Anshuman Khandual,
Linux Kernel Mailing List, Linux Next Mailing List
On Thu, 12 May 2022 14:28:18 +0100 Catalin Marinas <catalin.marinas@arm.com> wrote:
> > > - return get_clear_contig(vma->vm_mm, addr, ptep, pgsize, ncontig);
> > > + orig_pte = get_clear_contig(vma->vm_mm, addr, ptep, pgsize, ncontig);
> > > + flush_tlb_range(vma, addr, addr + pgsize * ncontig);
> > > + return orig_pte;
> > > }
> >
> > Yes, after checking this fb396bb459c1 ("arm64/hugetlb: Drop TLB flush from
> > get_clear_flush()"), I also realized it will miss TLB flush.
> >
> > So I am not sure I need send a incremental patch to fix this issue? Or
> > resend my patch set [1] with rebasing on the arm64 changes?
> >
> > Catalin and Andrew, how do you think? Thanks.
>
> Andrew folding the diff in is fine by me. I presume the mm patches are
> applied on top of the rest of linux-next (and the arm64 commits).
No, the mm patches are based on
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm master branch,
which is -rc4 or thereabouts.
So one of us needs to ensure that Linus gets that patch after the
second of us merges up. I can't test it so I nominate you ;) Against
linux-next or the mm-everything branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm?
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2022-05-12 11:13 ` Baolin Wang
@ 2022-05-12 13:28 ` Catalin Marinas
2022-05-12 19:10 ` Andrew Morton
0 siblings, 1 reply; 138+ messages in thread
From: Catalin Marinas @ 2022-05-12 13:28 UTC (permalink / raw)
To: Baolin Wang
Cc: Stephen Rothwell, Andrew Morton, Will Deacon, Anshuman Khandual,
Linux Kernel Mailing List, Linux Next Mailing List
On Thu, May 12, 2022 at 07:13:18PM +0800, Baolin Wang wrote:
> On 5/12/2022 7:07 PM, Catalin Marinas wrote:
> > On Thu, May 12, 2022 at 07:38:55PM +1000, Stephen Rothwell wrote:
> > > After merging the mm tree, today's linux-next build (arm64 defconfig)
> > > failed like this:
> > >
> > > arch/arm64/mm/hugetlbpage.c: In function 'huge_ptep_clear_flush':
> > > arch/arm64/mm/hugetlbpage.c:493:16: error: implicit declaration of function 'get_clear_flush'; did you mean 'ptep_clear_flush'? [-Werror=implicit-function-declaration]
> > > 493 | return get_clear_flush(vma->vm_mm, addr, ptep, pgsize, ncontig);
> > > | ^~~~~~~~~~~~~~~
> > > | ptep_clear_flush
> > > arch/arm64/mm/hugetlbpage.c:493:16: error: incompatible types when returning type 'int' but 'pte_t' was expected
> > > 493 | return get_clear_flush(vma->vm_mm, addr, ptep, pgsize, ncontig);
> > > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > arch/arm64/mm/hugetlbpage.c:494:1: error: control reaches end of non-void function [-Werror=return-type]
> > > 494 | }
> > > | ^
> > >
> > > Caused by commit
> > >
> > > 00df1f1a133b ("mm: change huge_ptep_clear_flush() to return the original pte")
> > >
> > > interacting with commit
> > >
> > > fb396bb459c1 ("arm64/hugetlb: Drop TLB flush from get_clear_flush()")
> > >
> > > I have applied the following merg fix patch for today.
> > >
> > > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > > Date: Thu, 12 May 2022 19:33:11 +1000
> > > Subject: [PATCH] fixup for "mm: change huge_ptep_clear_flush() to return the original pte"
> > >
> > > It interacts with commit
> > >
> > > fb396bb459c1 ("arm64/hugetlb: Drop TLB flush from get_clear_flush()")
> > >
> > > from the arm64 tree
> > >
> > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > > ---
> > > arch/arm64/mm/hugetlbpage.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
> > > index 5bdf913dedc7..30f5b76aabe9 100644
> > > --- a/arch/arm64/mm/hugetlbpage.c
> > > +++ b/arch/arm64/mm/hugetlbpage.c
> > > @@ -490,7 +490,7 @@ pte_t huge_ptep_clear_flush(struct vm_area_struct *vma,
> > > return ptep_clear_flush(vma, addr, ptep);
> > > ncontig = find_num_contig(vma->vm_mm, addr, ptep, &pgsize);
> > > - return get_clear_flush(vma->vm_mm, addr, ptep, pgsize, ncontig);
> > > + return get_clear_contig(vma->vm_mm, addr, ptep, pgsize, ncontig);
> > > }
> >
> > Note that after the arm64 commit, get_clear_contig() no longer flushes
> > the TLB. So maybe something like:
> >
> > diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
> > index 30f5b76aabe9..9a999550df8e 100644
> > --- a/arch/arm64/mm/hugetlbpage.c
> > +++ b/arch/arm64/mm/hugetlbpage.c
> > @@ -485,12 +485,15 @@ pte_t huge_ptep_clear_flush(struct vm_area_struct *vma,
> > {
> > size_t pgsize;
> > int ncontig;
> > + pte_t orig_pte;
> >
> > if (!pte_cont(READ_ONCE(*ptep)))
> > return ptep_clear_flush(vma, addr, ptep);
> >
> > ncontig = find_num_contig(vma->vm_mm, addr, ptep, &pgsize);
> > - return get_clear_contig(vma->vm_mm, addr, ptep, pgsize, ncontig);
> > + orig_pte = get_clear_contig(vma->vm_mm, addr, ptep, pgsize, ncontig);
> > + flush_tlb_range(vma, addr, addr + pgsize * ncontig);
> > + return orig_pte;
> > }
>
> Yes, after checking this fb396bb459c1 ("arm64/hugetlb: Drop TLB flush from
> get_clear_flush()"), I also realized it will miss TLB flush.
>
> So I am not sure I need send a incremental patch to fix this issue? Or
> resend my patch set [1] with rebasing on the arm64 changes?
>
> Catalin and Andrew, how do you think? Thanks.
Andrew folding the diff in is fine by me. I presume the mm patches are
applied on top of the rest of linux-next (and the arm64 commits).
--
Catalin
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2022-05-12 11:07 ` Catalin Marinas
@ 2022-05-12 11:13 ` Baolin Wang
2022-05-12 13:28 ` Catalin Marinas
2022-05-13 7:18 ` Stephen Rothwell
1 sibling, 1 reply; 138+ messages in thread
From: Baolin Wang @ 2022-05-12 11:13 UTC (permalink / raw)
To: Catalin Marinas, Stephen Rothwell
Cc: Andrew Morton, Will Deacon, Anshuman Khandual,
Linux Kernel Mailing List, Linux Next Mailing List
On 5/12/2022 7:07 PM, Catalin Marinas wrote:
> On Thu, May 12, 2022 at 07:38:55PM +1000, Stephen Rothwell wrote:
>> After merging the mm tree, today's linux-next build (arm64 defconfig)
>> failed like this:
>>
>> arch/arm64/mm/hugetlbpage.c: In function 'huge_ptep_clear_flush':
>> arch/arm64/mm/hugetlbpage.c:493:16: error: implicit declaration of function 'get_clear_flush'; did you mean 'ptep_clear_flush'? [-Werror=implicit-function-declaration]
>> 493 | return get_clear_flush(vma->vm_mm, addr, ptep, pgsize, ncontig);
>> | ^~~~~~~~~~~~~~~
>> | ptep_clear_flush
>> arch/arm64/mm/hugetlbpage.c:493:16: error: incompatible types when returning type 'int' but 'pte_t' was expected
>> 493 | return get_clear_flush(vma->vm_mm, addr, ptep, pgsize, ncontig);
>> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> arch/arm64/mm/hugetlbpage.c:494:1: error: control reaches end of non-void function [-Werror=return-type]
>> 494 | }
>> | ^
>>
>> Caused by commit
>>
>> 00df1f1a133b ("mm: change huge_ptep_clear_flush() to return the original pte")
>>
>> interacting with commit
>>
>> fb396bb459c1 ("arm64/hugetlb: Drop TLB flush from get_clear_flush()")
>>
>> I have applied the following merg fix patch for today.
>>
>> From: Stephen Rothwell <sfr@canb.auug.org.au>
>> Date: Thu, 12 May 2022 19:33:11 +1000
>> Subject: [PATCH] fixup for "mm: change huge_ptep_clear_flush() to return the original pte"
>>
>> It interacts with commit
>>
>> fb396bb459c1 ("arm64/hugetlb: Drop TLB flush from get_clear_flush()")
>>
>> from the arm64 tree
>>
>> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
>> ---
>> arch/arm64/mm/hugetlbpage.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
>> index 5bdf913dedc7..30f5b76aabe9 100644
>> --- a/arch/arm64/mm/hugetlbpage.c
>> +++ b/arch/arm64/mm/hugetlbpage.c
>> @@ -490,7 +490,7 @@ pte_t huge_ptep_clear_flush(struct vm_area_struct *vma,
>> return ptep_clear_flush(vma, addr, ptep);
>>
>> ncontig = find_num_contig(vma->vm_mm, addr, ptep, &pgsize);
>> - return get_clear_flush(vma->vm_mm, addr, ptep, pgsize, ncontig);
>> + return get_clear_contig(vma->vm_mm, addr, ptep, pgsize, ncontig);
>> }
>
> Note that after the arm64 commit, get_clear_contig() no longer flushes
> the TLB. So maybe something like:
>
> diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
> index 30f5b76aabe9..9a999550df8e 100644
> --- a/arch/arm64/mm/hugetlbpage.c
> +++ b/arch/arm64/mm/hugetlbpage.c
> @@ -485,12 +485,15 @@ pte_t huge_ptep_clear_flush(struct vm_area_struct *vma,
> {
> size_t pgsize;
> int ncontig;
> + pte_t orig_pte;
>
> if (!pte_cont(READ_ONCE(*ptep)))
> return ptep_clear_flush(vma, addr, ptep);
>
> ncontig = find_num_contig(vma->vm_mm, addr, ptep, &pgsize);
> - return get_clear_contig(vma->vm_mm, addr, ptep, pgsize, ncontig);
> + orig_pte = get_clear_contig(vma->vm_mm, addr, ptep, pgsize, ncontig);
> + flush_tlb_range(vma, addr, addr + pgsize * ncontig);
> + return orig_pte;
> }
Yes, after checking this fb396bb459c1 ("arm64/hugetlb: Drop TLB flush
from get_clear_flush()"), I also realized it will miss TLB flush.
So I am not sure I need send a incremental patch to fix this issue? Or
resend my patch set [1] with rebasing on the arm64 changes?
Catalin and Andrew, how do you think? Thanks.
[1]
https://lore.kernel.org/all/cover.1652270205.git.baolin.wang@linux.alibaba.com/
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2022-05-12 9:38 Stephen Rothwell
2022-05-12 10:13 ` Baolin Wang
@ 2022-05-12 11:07 ` Catalin Marinas
2022-05-12 11:13 ` Baolin Wang
2022-05-13 7:18 ` Stephen Rothwell
1 sibling, 2 replies; 138+ messages in thread
From: Catalin Marinas @ 2022-05-12 11:07 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Andrew Morton, Will Deacon, Anshuman Khandual, Baolin Wang,
Linux Kernel Mailing List, Linux Next Mailing List
On Thu, May 12, 2022 at 07:38:55PM +1000, Stephen Rothwell wrote:
> After merging the mm tree, today's linux-next build (arm64 defconfig)
> failed like this:
>
> arch/arm64/mm/hugetlbpage.c: In function 'huge_ptep_clear_flush':
> arch/arm64/mm/hugetlbpage.c:493:16: error: implicit declaration of function 'get_clear_flush'; did you mean 'ptep_clear_flush'? [-Werror=implicit-function-declaration]
> 493 | return get_clear_flush(vma->vm_mm, addr, ptep, pgsize, ncontig);
> | ^~~~~~~~~~~~~~~
> | ptep_clear_flush
> arch/arm64/mm/hugetlbpage.c:493:16: error: incompatible types when returning type 'int' but 'pte_t' was expected
> 493 | return get_clear_flush(vma->vm_mm, addr, ptep, pgsize, ncontig);
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> arch/arm64/mm/hugetlbpage.c:494:1: error: control reaches end of non-void function [-Werror=return-type]
> 494 | }
> | ^
>
> Caused by commit
>
> 00df1f1a133b ("mm: change huge_ptep_clear_flush() to return the original pte")
>
> interacting with commit
>
> fb396bb459c1 ("arm64/hugetlb: Drop TLB flush from get_clear_flush()")
>
> I have applied the following merg fix patch for today.
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 12 May 2022 19:33:11 +1000
> Subject: [PATCH] fixup for "mm: change huge_ptep_clear_flush() to return the original pte"
>
> It interacts with commit
>
> fb396bb459c1 ("arm64/hugetlb: Drop TLB flush from get_clear_flush()")
>
> from the arm64 tree
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> arch/arm64/mm/hugetlbpage.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
> index 5bdf913dedc7..30f5b76aabe9 100644
> --- a/arch/arm64/mm/hugetlbpage.c
> +++ b/arch/arm64/mm/hugetlbpage.c
> @@ -490,7 +490,7 @@ pte_t huge_ptep_clear_flush(struct vm_area_struct *vma,
> return ptep_clear_flush(vma, addr, ptep);
>
> ncontig = find_num_contig(vma->vm_mm, addr, ptep, &pgsize);
> - return get_clear_flush(vma->vm_mm, addr, ptep, pgsize, ncontig);
> + return get_clear_contig(vma->vm_mm, addr, ptep, pgsize, ncontig);
> }
Note that after the arm64 commit, get_clear_contig() no longer flushes
the TLB. So maybe something like:
diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
index 30f5b76aabe9..9a999550df8e 100644
--- a/arch/arm64/mm/hugetlbpage.c
+++ b/arch/arm64/mm/hugetlbpage.c
@@ -485,12 +485,15 @@ pte_t huge_ptep_clear_flush(struct vm_area_struct *vma,
{
size_t pgsize;
int ncontig;
+ pte_t orig_pte;
if (!pte_cont(READ_ONCE(*ptep)))
return ptep_clear_flush(vma, addr, ptep);
ncontig = find_num_contig(vma->vm_mm, addr, ptep, &pgsize);
- return get_clear_contig(vma->vm_mm, addr, ptep, pgsize, ncontig);
+ orig_pte = get_clear_contig(vma->vm_mm, addr, ptep, pgsize, ncontig);
+ flush_tlb_range(vma, addr, addr + pgsize * ncontig);
+ return orig_pte;
}
static int __init hugetlbpage_init(void)
--
Catalin
^ permalink raw reply related [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2022-05-12 9:38 Stephen Rothwell
@ 2022-05-12 10:13 ` Baolin Wang
2022-05-12 11:07 ` Catalin Marinas
1 sibling, 0 replies; 138+ messages in thread
From: Baolin Wang @ 2022-05-12 10:13 UTC (permalink / raw)
To: Stephen Rothwell, Andrew Morton, Catalin Marinas, Will Deacon
Cc: Anshuman Khandual, Linux Kernel Mailing List, Linux Next Mailing List
On 5/12/2022 5:38 PM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the mm tree, today's linux-next build (arm64 defconfig)
> failed like this:
>
> arch/arm64/mm/hugetlbpage.c: In function 'huge_ptep_clear_flush':
> arch/arm64/mm/hugetlbpage.c:493:16: error: implicit declaration of function 'get_clear_flush'; did you mean 'ptep_clear_flush'? [-Werror=implicit-function-declaration]
> 493 | return get_clear_flush(vma->vm_mm, addr, ptep, pgsize, ncontig);
> | ^~~~~~~~~~~~~~~
> | ptep_clear_flush
> arch/arm64/mm/hugetlbpage.c:493:16: error: incompatible types when returning type 'int' but 'pte_t' was expected
> 493 | return get_clear_flush(vma->vm_mm, addr, ptep, pgsize, ncontig);
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> arch/arm64/mm/hugetlbpage.c:494:1: error: control reaches end of non-void function [-Werror=return-type]
> 494 | }
> | ^
>
> Caused by commit
>
> 00df1f1a133b ("mm: change huge_ptep_clear_flush() to return the original pte")
>
> interacting with commit
>
> fb396bb459c1 ("arm64/hugetlb: Drop TLB flush from get_clear_flush()")
>
> I have applied the following merg fix patch for today.
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 12 May 2022 19:33:11 +1000
> Subject: [PATCH] fixup for "mm: change huge_ptep_clear_flush() to return the original pte"
>
> It interacts with commit
>
> fb396bb459c1 ("arm64/hugetlb: Drop TLB flush from get_clear_flush()")
>
> from the arm64 tree
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Thanks. Looks good to me.
Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com>
> ---
> arch/arm64/mm/hugetlbpage.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
> index 5bdf913dedc7..30f5b76aabe9 100644
> --- a/arch/arm64/mm/hugetlbpage.c
> +++ b/arch/arm64/mm/hugetlbpage.c
> @@ -490,7 +490,7 @@ pte_t huge_ptep_clear_flush(struct vm_area_struct *vma,
> return ptep_clear_flush(vma, addr, ptep);
>
> ncontig = find_num_contig(vma->vm_mm, addr, ptep, &pgsize);
> - return get_clear_flush(vma->vm_mm, addr, ptep, pgsize, ncontig);
> + return get_clear_contig(vma->vm_mm, addr, ptep, pgsize, ncontig);
> }
>
> static int __init hugetlbpage_init(void)
^ permalink raw reply [flat|nested] 138+ messages in thread
* linux-next: build failure after merge of the mm tree
@ 2022-05-12 9:38 Stephen Rothwell
2022-05-12 10:13 ` Baolin Wang
2022-05-12 11:07 ` Catalin Marinas
0 siblings, 2 replies; 138+ messages in thread
From: Stephen Rothwell @ 2022-05-12 9:38 UTC (permalink / raw)
To: Andrew Morton, Catalin Marinas, Will Deacon
Cc: Anshuman Khandual, Baolin Wang, Linux Kernel Mailing List,
Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 2233 bytes --]
Hi all,
After merging the mm tree, today's linux-next build (arm64 defconfig)
failed like this:
arch/arm64/mm/hugetlbpage.c: In function 'huge_ptep_clear_flush':
arch/arm64/mm/hugetlbpage.c:493:16: error: implicit declaration of function 'get_clear_flush'; did you mean 'ptep_clear_flush'? [-Werror=implicit-function-declaration]
493 | return get_clear_flush(vma->vm_mm, addr, ptep, pgsize, ncontig);
| ^~~~~~~~~~~~~~~
| ptep_clear_flush
arch/arm64/mm/hugetlbpage.c:493:16: error: incompatible types when returning type 'int' but 'pte_t' was expected
493 | return get_clear_flush(vma->vm_mm, addr, ptep, pgsize, ncontig);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/arm64/mm/hugetlbpage.c:494:1: error: control reaches end of non-void function [-Werror=return-type]
494 | }
| ^
Caused by commit
00df1f1a133b ("mm: change huge_ptep_clear_flush() to return the original pte")
interacting with commit
fb396bb459c1 ("arm64/hugetlb: Drop TLB flush from get_clear_flush()")
I have applied the following merg fix patch for today.
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 12 May 2022 19:33:11 +1000
Subject: [PATCH] fixup for "mm: change huge_ptep_clear_flush() to return the original pte"
It interacts with commit
fb396bb459c1 ("arm64/hugetlb: Drop TLB flush from get_clear_flush()")
from the arm64 tree
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/arm64/mm/hugetlbpage.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
index 5bdf913dedc7..30f5b76aabe9 100644
--- a/arch/arm64/mm/hugetlbpage.c
+++ b/arch/arm64/mm/hugetlbpage.c
@@ -490,7 +490,7 @@ pte_t huge_ptep_clear_flush(struct vm_area_struct *vma,
return ptep_clear_flush(vma, addr, ptep);
ncontig = find_num_contig(vma->vm_mm, addr, ptep, &pgsize);
- return get_clear_flush(vma->vm_mm, addr, ptep, pgsize, ncontig);
+ return get_clear_contig(vma->vm_mm, addr, ptep, pgsize, ncontig);
}
static int __init hugetlbpage_init(void)
--
2.35.1
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2022-05-11 8:42 ` Baolin Wang
@ 2022-05-11 23:28 ` Stephen Rothwell
0 siblings, 0 replies; 138+ messages in thread
From: Stephen Rothwell @ 2022-05-11 23:28 UTC (permalink / raw)
To: Baolin Wang
Cc: Andrew Morton, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 314 bytes --]
Hi Baolin,
On Wed, 11 May 2022 16:42:17 +0800 Baolin Wang <baolin.wang@linux.alibaba.com> wrote:
>
> Sorry again. I think I also missed other ARCHs' changes. Need include below fixes.
I will add that to my fix up patch today (unless Andrew does a new
release).
Thanks.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2022-05-11 8:15 Stephen Rothwell
2022-05-11 8:27 ` Baolin Wang
@ 2022-05-11 8:42 ` Baolin Wang
2022-05-11 23:28 ` Stephen Rothwell
1 sibling, 1 reply; 138+ messages in thread
From: Baolin Wang @ 2022-05-11 8:42 UTC (permalink / raw)
To: Stephen Rothwell, Andrew Morton
Cc: Linux Kernel Mailing List, Linux Next Mailing List
On 5/11/2022 4:15 PM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the mm tree, today's linux-next build (sparc64 defconfig)
> failed like this:
>
> In file included from include/linux/hugetlb.h:757,
> from arch/sparc/mm/hugetlbpage.c:11:
> arch/sparc/include/asm/hugetlb.h: In function 'huge_ptep_clear_flush':
> arch/sparc/include/asm/hugetlb.h:27:1: error: no return statement in function returning non-void [-Werror=return-type]
> 27 | }
> | ^
>
> (and many more)
>
> Caused by commit
>
> 083af99303b9 ("mm: change huge_ptep_clear_flush() to return the original pte")
>
> I applied the following hack to make it build.
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 11 May 2022 18:10:56 +1000
> Subject: [PATCH] fix up for "mm: change huge_ptep_clear_flush() to return the original pte"
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Sorry again. I think I also missed other ARCHs' changes. Need include
below fixes.
diff --git a/arch/ia64/include/asm/hugetlb.h
b/arch/ia64/include/asm/hugetlb.h
index 65d3811..026ead4 100644
--- a/arch/ia64/include/asm/hugetlb.h
+++ b/arch/ia64/include/asm/hugetlb.h
@@ -26,6 +26,7 @@ static inline int is_hugepage_only_range(struct
mm_struct *mm,
static inline pte_t huge_ptep_clear_flush(struct vm_area_struct *vma,
unsigned long addr, pte_t *ptep)
{
+ return *ptep;
}
#include <asm-generic/hugetlb.h>
diff --git a/arch/parisc/include/asm/hugetlb.h
b/arch/parisc/include/asm/hugetlb.h
index 25bc560..f7f078c 100644
--- a/arch/parisc/include/asm/hugetlb.h
+++ b/arch/parisc/include/asm/hugetlb.h
@@ -31,6 +31,7 @@ static inline int prepare_hugepage_range(struct file
*file,
static inline pte_t huge_ptep_clear_flush(struct vm_area_struct *vma,
unsigned long addr, pte_t *ptep)
{
+ return *ptep;
}
#define __HAVE_ARCH_HUGE_PTEP_SET_WRPROTECT
diff --git a/arch/sh/include/asm/hugetlb.h b/arch/sh/include/asm/hugetlb.h
index e727cc9..4d3ba39 100644
--- a/arch/sh/include/asm/hugetlb.h
+++ b/arch/sh/include/asm/hugetlb.h
@@ -24,6 +24,7 @@ static inline int prepare_hugepage_range(struct file
*file,
static inline pte_t huge_ptep_clear_flush(struct vm_area_struct *vma,
unsigned long addr, pte_t *ptep)
{
+ return *ptep;
}
static inline void arch_clear_hugepage_flags(struct page *page)
diff --git a/arch/sparc/include/asm/hugetlb.h
b/arch/sparc/include/asm/hugetlb.h
index b50aa6f..0a26cca 100644
--- a/arch/sparc/include/asm/hugetlb.h
+++ b/arch/sparc/include/asm/hugetlb.h
@@ -24,6 +24,7 @@ pte_t huge_ptep_get_and_clear(struct mm_struct *mm,
unsigned long addr,
static inline pte_t huge_ptep_clear_flush(struct vm_area_struct *vma,
unsigned long addr, pte_t *ptep)
{
+ return *ptep;
}
#define __HAVE_ARCH_HUGE_PTEP_SET_WRPROTECT
> ---
> arch/sparc/include/asm/hugetlb.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/sparc/include/asm/hugetlb.h b/arch/sparc/include/asm/hugetlb.h
> index b50aa6f8f9ab..0a26cca24232 100644
> --- a/arch/sparc/include/asm/hugetlb.h
> +++ b/arch/sparc/include/asm/hugetlb.h
> @@ -24,6 +24,7 @@ pte_t huge_ptep_get_and_clear(struct mm_struct *mm, unsigned long addr,
> static inline pte_t huge_ptep_clear_flush(struct vm_area_struct *vma,
> unsigned long addr, pte_t *ptep)
> {
> + return *ptep;
> }
>
> #define __HAVE_ARCH_HUGE_PTEP_SET_WRPROTECT
^ permalink raw reply related [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2022-05-11 8:15 Stephen Rothwell
@ 2022-05-11 8:27 ` Baolin Wang
2022-05-11 8:42 ` Baolin Wang
1 sibling, 0 replies; 138+ messages in thread
From: Baolin Wang @ 2022-05-11 8:27 UTC (permalink / raw)
To: Stephen Rothwell, Andrew Morton
Cc: Linux Kernel Mailing List, Linux Next Mailing List
Hi Stephen,
On 5/11/2022 4:15 PM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the mm tree, today's linux-next build (sparc64 defconfig)
> failed like this:
>
> In file included from include/linux/hugetlb.h:757,
> from arch/sparc/mm/hugetlbpage.c:11:
> arch/sparc/include/asm/hugetlb.h: In function 'huge_ptep_clear_flush':
> arch/sparc/include/asm/hugetlb.h:27:1: error: no return statement in function returning non-void [-Werror=return-type]
> 27 | }
> | ^
>
> (and many more)
>
> Caused by commit
>
> 083af99303b9 ("mm: change huge_ptep_clear_flush() to return the original pte")
>
> I applied the following hack to make it build.
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 11 May 2022 18:10:56 +1000
> Subject: [PATCH] fix up for "mm: change huge_ptep_clear_flush() to return the original pte"
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Sorry for my mistake. LGTM.
Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com>
> ---
> arch/sparc/include/asm/hugetlb.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/sparc/include/asm/hugetlb.h b/arch/sparc/include/asm/hugetlb.h
> index b50aa6f8f9ab..0a26cca24232 100644
> --- a/arch/sparc/include/asm/hugetlb.h
> +++ b/arch/sparc/include/asm/hugetlb.h
> @@ -24,6 +24,7 @@ pte_t huge_ptep_get_and_clear(struct mm_struct *mm, unsigned long addr,
> static inline pte_t huge_ptep_clear_flush(struct vm_area_struct *vma,
> unsigned long addr, pte_t *ptep)
> {
> + return *ptep;
> }
>
> #define __HAVE_ARCH_HUGE_PTEP_SET_WRPROTECT
^ permalink raw reply [flat|nested] 138+ messages in thread
* linux-next: build failure after merge of the mm tree
@ 2022-05-11 8:15 Stephen Rothwell
2022-05-11 8:27 ` Baolin Wang
2022-05-11 8:42 ` Baolin Wang
0 siblings, 2 replies; 138+ messages in thread
From: Stephen Rothwell @ 2022-05-11 8:15 UTC (permalink / raw)
To: Andrew Morton
Cc: Baolin Wang, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1448 bytes --]
Hi all,
After merging the mm tree, today's linux-next build (sparc64 defconfig)
failed like this:
In file included from include/linux/hugetlb.h:757,
from arch/sparc/mm/hugetlbpage.c:11:
arch/sparc/include/asm/hugetlb.h: In function 'huge_ptep_clear_flush':
arch/sparc/include/asm/hugetlb.h:27:1: error: no return statement in function returning non-void [-Werror=return-type]
27 | }
| ^
(and many more)
Caused by commit
083af99303b9 ("mm: change huge_ptep_clear_flush() to return the original pte")
I applied the following hack to make it build.
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 11 May 2022 18:10:56 +1000
Subject: [PATCH] fix up for "mm: change huge_ptep_clear_flush() to return the original pte"
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/sparc/include/asm/hugetlb.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/sparc/include/asm/hugetlb.h b/arch/sparc/include/asm/hugetlb.h
index b50aa6f8f9ab..0a26cca24232 100644
--- a/arch/sparc/include/asm/hugetlb.h
+++ b/arch/sparc/include/asm/hugetlb.h
@@ -24,6 +24,7 @@ pte_t huge_ptep_get_and_clear(struct mm_struct *mm, unsigned long addr,
static inline pte_t huge_ptep_clear_flush(struct vm_area_struct *vma,
unsigned long addr, pte_t *ptep)
{
+ return *ptep;
}
#define __HAVE_ARCH_HUGE_PTEP_SET_WRPROTECT
--
2.35.1
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 138+ messages in thread
* linux-next: build failure after merge of the mm tree
@ 2022-05-10 11:25 Stephen Rothwell
0 siblings, 0 replies; 138+ messages in thread
From: Stephen Rothwell @ 2022-05-10 11:25 UTC (permalink / raw)
To: Andrew Morton
Cc: Liam R. Howlett, Matthew Wilcox (Oracle),
Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 719 bytes --]
Hi all,
After merging the mm tree, today's linux-next build (powerpc allyesconfig)
failed like this:
In file included from mm/damon/vaddr.c:703:
mm/damon/vaddr-test.h: In function '__link_vmas':
mm/damon/vaddr-test.h:29:17: error: implicit declaration of function 'vma_mas_store'; did you mean 'mas_store'? [-Werror=implicit-function-declaration]
29 | vma_mas_store(&vmas[i], &mas);
| ^~~~~~~~~~~~~
| mas_store
Caused by commit
59904daa2b0c ("damon: convert __damon_va_three_regions to use the VMA iterator")
I have merged the mm-stable, mm-nonmm-stable and mm trees from
next-20220509 for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* linux-next: build failure after merge of the mm tree
@ 2022-05-05 21:37 Stephen Rothwell
0 siblings, 0 replies; 138+ messages in thread
From: Stephen Rothwell @ 2022-05-05 21:37 UTC (permalink / raw)
To: Andrew Morton
Cc: Matthew Wilcox (Oracle),
Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 353 bytes --]
Hi all,
After merging the mm tree, today's linux-next build (i386 allmodconfig
clang14) failed like this:
mm/shmem.c:2337:8: error: variable 'page' is uninitialized when used here [-Werror,-Wuninitialized]
Introduced by commit
b0bb08b2d5f3 ("mm/shmem: turn shmem_alloc_page() into shmem_alloc_folio()")
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2022-05-02 11:19 ` Matthew Wilcox
@ 2022-05-03 6:45 ` Stephen Rothwell
0 siblings, 0 replies; 138+ messages in thread
From: Stephen Rothwell @ 2022-05-03 6:45 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Andrew Morton, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 3422 bytes --]
Hi all,
On Mon, 2 May 2022 12:19:36 +0100 Matthew Wilcox <willy@infradead.org> wrote:
>
> On Mon, May 02, 2022 at 08:49:03PM +1000, Stephen Rothwell wrote:
> >
> > After merging the mm tree, today's linux-next build (arm
> > multi_v7_defconfig) failed like this:
> [... i wish our BUILD_BUGs produced nicer output from the compiler ...]
> > Reverting the following commits makes the problem go away:
> >
> > 2b58b3f33ba2 ("mm/shmem: convert shmem_swapin_page() to shmem_swapin_folio()")
> > 94cdf3e8c0bf ("mm/shmem: convert shmem_getpage_gfp to use a folio")
> > 3674fd6cadf5 ("mm/shmem: convert shmem_alloc_and_acct_page to use a folio")
> > b0bb08b2d5f3 ("mm/shmem: turn shmem_alloc_page() into shmem_alloc_folio()")
> > 8d657a77c6fe ("mm/shmem: turn shmem_should_replace_page into shmem_should_replace_folio")
> > 9a44f3462edc ("mm/shmem: convert shmem_add_to_page_cache to take a folio")
> > 561fd8bee1dc ("mm/swap: add folio_throttle_swaprate")
> > cb4e56ee240d ("mm/shmem: use a folio in shmem_unused_huge_shrink")
> > 22bf1b68e572 ("vmscan: remove remaining uses of page in shrink_page_list")
> > 7d15d41b7c4a ("vmscan: convert the activate_locked portion of shrink_page_list to folios")
> > 8a6aff9c51c7 ("vmscan: move initialisation of mapping down")
> > b79338b3d217 ("vmscan: convert lazy freeing to folios")
> > 719426e40146 ("vmscan: convert page buffer handling to use folios")
> > 339ba7502e13 ("vmscan: convert dirty page handling to folios")
>
> Oops. allnoconfig on x86 reproduces the problem. This fixes it;
> happy to go back and produce a new set of patches for Andrew to
> preserve bisectability.
>
> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
> index 2999190adc22..e9e0d591061d 100644
> --- a/include/linux/huge_mm.h
> +++ b/include/linux/huge_mm.h
> @@ -347,7 +347,6 @@ static inline void prep_transhuge_page(struct page *page) {}
> static inline bool
> can_split_folio(struct folio *folio, int *pextra_pins)
> {
> - BUILD_BUG();
> return false;
> }
> static inline int
> diff --git a/mm/shmem.c b/mm/shmem.c
> index 673a0e783496..d62936ffe74d 100644
> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -738,7 +738,7 @@ static int shmem_add_to_page_cache(struct folio *folio,
> xas_store(&xas, folio);
> if (xas_error(&xas))
> goto unlock;
> - if (folio_test_large(folio)) {
> + if (folio_test_pmd_mappable(folio)) {
> count_vm_event(THP_FILE_ALLOC);
> __lruvec_stat_mod_folio(folio, NR_SHMEM_THPS, nr);
> }
> @@ -1887,10 +1887,7 @@ static int shmem_getpage_gfp(struct inode *inode, pgoff_t index,
> goto unlock;
> }
>
> - if (folio_test_large(folio))
> - hindex = round_down(index, HPAGE_PMD_NR);
> - else
> - hindex = index;
> + hindex = round_down(index, folio_nr_pages(folio));
>
> if (sgp == SGP_WRITE)
> __folio_set_referenced(folio);
> @@ -1909,7 +1906,7 @@ static int shmem_getpage_gfp(struct inode *inode, pgoff_t index,
> spin_unlock_irq(&info->lock);
> alloced = true;
>
> - if (folio_test_large(folio) &&
> + if (folio_test_pmd_mappable(folio) &&
> DIV_ROUND_UP(i_size_read(inode), PAGE_SIZE) <
> hindex + HPAGE_PMD_NR - 1) {
> /*
>
I applied the above patch to the mm tree merge today (instead of all
the reverts) and it fixed the build problems for me.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: linux-next: build failure after merge of the mm tree
2022-05-02 10:49 Stephen Rothwell
@ 2022-05-02 11:19 ` Matthew Wilcox
2022-05-03 6:45 ` Stephen Rothwell
0 siblings, 1 reply; 138+ messages in thread
From: Matthew Wilcox @ 2022-05-02 11:19 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Andrew Morton, Linux Kernel Mailing List, Linux Next Mailing List
On Mon, May 02, 2022 at 08:49:03PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the mm tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
[... i wish our BUILD_BUGs produced nicer output from the compiler ...]
> Reverting the following commits makes the problem go away:
>
> 2b58b3f33ba2 ("mm/shmem: convert shmem_swapin_page() to shmem_swapin_folio()")
> 94cdf3e8c0bf ("mm/shmem: convert shmem_getpage_gfp to use a folio")
> 3674fd6cadf5 ("mm/shmem: convert shmem_alloc_and_acct_page to use a folio")
> b0bb08b2d5f3 ("mm/shmem: turn shmem_alloc_page() into shmem_alloc_folio()")
> 8d657a77c6fe ("mm/shmem: turn shmem_should_replace_page into shmem_should_replace_folio")
> 9a44f3462edc ("mm/shmem: convert shmem_add_to_page_cache to take a folio")
> 561fd8bee1dc ("mm/swap: add folio_throttle_swaprate")
> cb4e56ee240d ("mm/shmem: use a folio in shmem_unused_huge_shrink")
> 22bf1b68e572 ("vmscan: remove remaining uses of page in shrink_page_list")
> 7d15d41b7c4a ("vmscan: convert the activate_locked portion of shrink_page_list to folios")
> 8a6aff9c51c7 ("vmscan: move initialisation of mapping down")
> b79338b3d217 ("vmscan: convert lazy freeing to folios")
> 719426e40146 ("vmscan: convert page buffer handling to use folios")
> 339ba7502e13 ("vmscan: convert dirty page handling to folios")
Oops. allnoconfig on x86 reproduces the problem. This fixes it;
happy to go back and produce a new set of patches for Andrew to
preserve bisectability.
diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
index 2999190adc22..e9e0d591061d 100644
--- a/include/linux/huge_mm.h
+++ b/include/linux/huge_mm.h
@@ -347,7 +347,6 @@ static inline void prep_transhuge_page(struct page *page) {}
static inline bool
can_split_folio(struct folio *folio, int *pextra_pins)
{
- BUILD_BUG();
return false;
}
static inline int
diff --git a/mm/shmem.c b/mm/shmem.c
index 673a0e783496..d62936ffe74d 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -738,7 +738,7 @@ static int shmem_add_to_page_cache(struct folio *folio,
xas_store(&xas, folio);
if (xas_error(&xas))
goto unlock;
- if (folio_test_large(folio)) {
+ if (folio_test_pmd_mappable(folio)) {
count_vm_event(THP_FILE_ALLOC);
__lruvec_stat_mod_folio(folio, NR_SHMEM_THPS, nr);
}
@@ -1887,10 +1887,7 @@ static int shmem_getpage_gfp(struct inode *inode, pgoff_t index,
goto unlock;
}
- if (folio_test_large(folio))
- hindex = round_down(index, HPAGE_PMD_NR);
- else
- hindex = index;
+ hindex = round_down(index, folio_nr_pages(folio));
if (sgp == SGP_WRITE)
__folio_set_referenced(folio);
@@ -1909,7 +1906,7 @@ static int shmem_getpage_gfp(struct inode *inode, pgoff_t index,
spin_unlock_irq(&info->lock);
alloced = true;
- if (folio_test_large(folio) &&
+ if (folio_test_pmd_mappable(folio) &&
DIV_ROUND_UP(i_size_read(inode), PAGE_SIZE) <
hindex + HPAGE_PMD_NR - 1) {
/*
^ permalink raw reply related [flat|nested] 138+ messages in thread
* linux-next: build failure after merge of the mm tree
@ 2022-05-02 10:49 Stephen Rothwell
2022-05-02 11:19 ` Matthew Wilcox
0 siblings, 1 reply; 138+ messages in thread
From: Stephen Rothwell @ 2022-05-02 10:49 UTC (permalink / raw)
To: Andrew Morton, Matthew Wilcox (Oracle)
Cc: Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 9010 bytes --]
Hi all,
After merging the mm tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
In file included from <command-line>:
mm/shmem.c: In function 'shmem_add_to_page_cache.constprop':
include/linux/compiler_types.h:352:45: error: call to '__compiletime_assert_267' declared with attribute error: BUILD_BUG failed
352 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
| ^
include/linux/compiler_types.h:333:25: note: in definition of macro '__compiletime_assert'
333 | prefix ## suffix(); \
| ^~~~~~
include/linux/compiler_types.h:352:9: note: in expansion of macro '_compiletime_assert'
352 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
| ^~~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert'
39 | #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'
59 | #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
| ^~~~~~~~~~~~~~~~
include/linux/vm_event_item.h:147:27: note: in expansion of macro 'BUILD_BUG'
147 | #define THP_FILE_ALLOC ({ BUILD_BUG(); 0; })
| ^~~~~~~~~
mm/shmem.c:743:40: note: in expansion of macro 'THP_FILE_ALLOC'
743 | count_vm_event(THP_FILE_ALLOC);
| ^~~~~~~~~~~~~~
In file included from include/linux/math64.h:6,
from include/linux/time64.h:5,
from include/linux/restart_block.h:10,
from include/linux/thread_info.h:14,
from include/asm-generic/preempt.h:5,
from ./arch/arm/include/generated/asm/preempt.h:1,
from include/linux/preempt.h:78,
from include/linux/spinlock.h:55,
from include/linux/wait.h:9,
from include/linux/wait_bit.h:8,
from include/linux/fs.h:6,
from mm/shmem.c:24:
mm/shmem.c: In function 'shmem_getpage_gfp.constprop':
include/linux/compiler_types.h:352:45: error: call to '__compiletime_assert_275' declared with attribute error: BUILD_BUG failed
352 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
| ^
include/linux/math.h:15:46: note: in definition of macro '__round_mask'
15 | #define __round_mask(x, y) ((__typeof__(x))((y)-1))
| ^
mm/shmem.c:1892:26: note: in expansion of macro 'round_down'
1892 | hindex = round_down(index, HPAGE_PMD_NR);
| ^~~~~~~~~~
include/linux/compiler_types.h:340:9: note: in expansion of macro '__compiletime_assert'
340 | __compiletime_assert(condition, msg, prefix, suffix)
| ^~~~~~~~~~~~~~~~~~~~
include/linux/compiler_types.h:352:9: note: in expansion of macro '_compiletime_assert'
352 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
| ^~~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert'
39 | #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'
59 | #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
| ^~~~~~~~~~~~~~~~
include/linux/huge_mm.h:307:28: note: in expansion of macro 'BUILD_BUG'
307 | #define HPAGE_PMD_SHIFT ({ BUILD_BUG(); 0; })
| ^~~~~~~~~
include/linux/huge_mm.h:105:26: note: in expansion of macro 'HPAGE_PMD_SHIFT'
105 | #define HPAGE_PMD_ORDER (HPAGE_PMD_SHIFT-PAGE_SHIFT)
| ^~~~~~~~~~~~~~~
include/linux/huge_mm.h:106:26: note: in expansion of macro 'HPAGE_PMD_ORDER'
106 | #define HPAGE_PMD_NR (1<<HPAGE_PMD_ORDER)
| ^~~~~~~~~~~~~~~
mm/shmem.c:1892:44: note: in expansion of macro 'HPAGE_PMD_NR'
1892 | hindex = round_down(index, HPAGE_PMD_NR);
| ^~~~~~~~~~~~
In file included from <command-line>:
include/linux/compiler_types.h:352:45: error: call to '__compiletime_assert_276' declared with attribute error: BUILD_BUG failed
352 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
| ^
include/linux/compiler_types.h:333:25: note: in definition of macro '__compiletime_assert'
333 | prefix ## suffix(); \
| ^~~~~~
include/linux/compiler_types.h:352:9: note: in expansion of macro '_compiletime_assert'
352 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
| ^~~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert'
39 | #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'
59 | #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
| ^~~~~~~~~~~~~~~~
include/linux/huge_mm.h:307:28: note: in expansion of macro 'BUILD_BUG'
307 | #define HPAGE_PMD_SHIFT ({ BUILD_BUG(); 0; })
| ^~~~~~~~~
include/linux/huge_mm.h:105:26: note: in expansion of macro 'HPAGE_PMD_SHIFT'
105 | #define HPAGE_PMD_ORDER (HPAGE_PMD_SHIFT-PAGE_SHIFT)
| ^~~~~~~~~~~~~~~
include/linux/huge_mm.h:106:26: note: in expansion of macro 'HPAGE_PMD_ORDER'
106 | #define HPAGE_PMD_NR (1<<HPAGE_PMD_ORDER)
| ^~~~~~~~~~~~~~~
mm/shmem.c:1915:34: note: in expansion of macro 'HPAGE_PMD_NR'
1915 | hindex + HPAGE_PMD_NR - 1) {
| ^~~~~~~~~~~~
In file included from <command-line>:
In function 'can_split_folio',
inlined from 'shrink_page_list' at mm/vmscan.c:1719:11:
include/linux/compiler_types.h:352:45: error: call to '__compiletime_assert_195' declared with attribute error: BUILD_BUG failed
352 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
| ^
include/linux/compiler_types.h:333:25: note: in definition of macro '__compiletime_assert'
333 | prefix ## suffix(); \
| ^~~~~~
include/linux/compiler_types.h:352:9: note: in expansion of macro '_compiletime_assert'
352 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
| ^~~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert'
39 | #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'
59 | #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
| ^~~~~~~~~~~~~~~~
include/linux/huge_mm.h:351:9: note: in expansion of macro 'BUILD_BUG'
351 | BUILD_BUG();
| ^~~~~~~~~
Reverting the following commits makes the problem go away:
2b58b3f33ba2 ("mm/shmem: convert shmem_swapin_page() to shmem_swapin_folio()")
94cdf3e8c0bf ("mm/shmem: convert shmem_getpage_gfp to use a folio")
3674fd6cadf5 ("mm/shmem: convert shmem_alloc_and_acct_page to use a folio")
b0bb08b2d5f3 ("mm/shmem: turn shmem_alloc_page() into shmem_alloc_folio()")
8d657a77c6fe ("mm/shmem: turn shmem_should_replace_page into shmem_should_replace_folio")
9a44f3462edc ("mm/shmem: convert shmem_add_to_page_cache to take a folio")
561fd8bee1dc ("mm/swap: add folio_throttle_swaprate")
cb4e56ee240d ("mm/shmem: use a folio in shmem_unused_huge_shrink")
22bf1b68e572 ("vmscan: remove remaining uses of page in shrink_page_list")
7d15d41b7c4a ("vmscan: convert the activate_locked portion of shrink_page_list to folios")
8a6aff9c51c7 ("vmscan: move initialisation of mapping down")
b79338b3d217 ("vmscan: convert lazy freeing to folios")
719426e40146 ("vmscan: convert page buffer handling to use folios")
339ba7502e13 ("vmscan: convert dirty page handling to folios")
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 138+ messages in thread
end of thread, other threads:[~2024-04-12 6:40 UTC | newest]
Thread overview: 138+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-09-23 8:12 linux-next: build failure after merge of the mm tree Stephen Rothwell
2022-09-23 8:15 ` David Hildenbrand
-- strict thread matches above, loose matches on Subject: below --
2024-04-12 6:39 Stephen Rothwell
2024-04-11 23:14 Stephen Rothwell
2024-04-07 23:15 Stephen Rothwell
2024-04-08 1:44 ` Barry Song
2024-04-05 2:55 Stephen Rothwell
2024-03-28 4:34 Stephen Rothwell
2024-03-05 4:26 Stephen Rothwell
2024-03-05 6:39 ` Qi Zheng
2024-02-14 3:57 Stephen Rothwell
2024-02-14 15:19 ` Andrew Morton
2024-02-15 3:47 ` Stephen Rothwell
2024-02-07 6:17 Stephen Rothwell
2024-02-01 2:57 Stephen Rothwell
2024-02-01 8:35 ` Marco Elver
2024-01-25 3:29 Stephen Rothwell
2024-01-25 14:29 ` Baoquan He
2024-01-25 18:03 ` Stephen Rothwell
2024-01-24 23:23 Stephen Rothwell
2024-01-24 23:52 ` Suren Baghdasaryan
2024-01-25 2:40 ` Baoquan He
2024-01-23 23:05 Stephen Rothwell
2024-01-23 23:14 ` Suren Baghdasaryan
2023-12-21 7:38 Stephen Rothwell
2023-12-21 7:45 ` Changbin Du
2023-11-28 21:45 Stephen Rothwell
2023-11-28 22:45 ` Andrew Morton
2023-11-29 8:17 ` Dmitry Rokosov
2023-11-30 22:12 ` Stephen Rothwell
2023-11-27 3:44 Stephen Rothwell
2023-12-22 0:16 ` Stephen Rothwell
2023-12-22 6:26 ` Andrew Morton
2023-11-27 2:28 Stephen Rothwell
2023-11-27 3:48 ` Stephen Rothwell
2023-11-30 22:04 ` Stephen Rothwell
2023-11-30 22:32 ` Andrew Morton
2023-11-30 22:39 ` Michael Ellerman
2023-11-30 22:52 ` Andrew Morton
2023-12-01 3:12 ` Michael Ellerman
2023-12-07 12:38 ` Michael Ellerman
2023-10-03 22:50 Stephen Rothwell
2023-09-27 23:22 Stephen Rothwell
2023-09-28 6:47 ` Arnd Bergmann
2023-09-25 23:18 Stephen Rothwell
2023-08-22 22:52 Stephen Rothwell
2023-08-21 23:55 Stephen Rothwell
2023-08-22 1:11 ` Matthew Wilcox
2023-08-22 1:22 ` Stephen Rothwell
2023-08-22 1:34 ` Matthew Wilcox
2023-08-22 4:00 ` Darrick J. Wong
2023-08-22 20:20 ` Matthew Wilcox
2023-08-22 7:12 ` Michael Ellerman
2023-08-08 4:40 Stephen Rothwell
2023-08-08 15:20 ` Eric DeVolder
2023-08-11 17:16 ` Eric DeVolder
2023-07-26 5:14 Stephen Rothwell
2023-07-26 13:22 ` Kuan-Ying Lee (李冠穎)
2023-07-26 4:53 Stephen Rothwell
2023-07-26 5:22 ` Aneesh Kumar K.V
2023-07-26 6:51 ` Stephen Rothwell
2023-07-19 4:32 Stephen Rothwell
2023-07-19 5:55 ` Alistair Popple
2023-07-18 0:02 Stephen Rothwell
2023-07-18 13:43 ` Andy Shevchenko
2023-07-18 17:34 ` Andrew Morton
2023-07-18 21:07 ` Andy Shevchenko
2023-07-17 23:40 Stephen Rothwell
2023-07-04 2:23 Stephen Rothwell
2023-07-04 2:32 ` Linus Torvalds
2023-07-04 5:51 ` Suren Baghdasaryan
2023-06-13 6:21 Stephen Rothwell
2023-06-13 15:58 ` Catalin Marinas
2023-05-19 2:43 Stephen Rothwell
2023-05-19 8:19 ` Arnd Bergmann
2023-05-17 23:59 Stephen Rothwell
2023-03-06 2:54 Stephen Rothwell
2023-03-06 3:13 ` Andrew Morton
2023-03-06 0:52 Stephen Rothwell
2023-03-06 21:58 ` Stephen Rothwell
2023-02-07 4:37 Stephen Rothwell
2023-02-07 12:17 ` Jason Gunthorpe
2023-02-08 2:41 ` Stephen Rothwell
2023-02-07 14:25 ` David Howells
2023-01-30 5:14 Stephen Rothwell
2023-01-30 8:09 ` Christian Brauner
2023-02-26 22:18 ` Stephen Rothwell
2023-02-27 10:36 ` Christian Brauner
2023-01-27 6:36 Stephen Rothwell
2023-01-27 6:16 Stephen Rothwell
2023-01-27 5:59 Stephen Rothwell
2023-01-27 13:11 ` Jan Kara
2023-01-31 21:47 ` Stephen Rothwell
2023-02-24 4:40 ` Stephen Rothwell
2023-02-24 6:01 ` Linus Torvalds
2023-02-24 20:36 ` Stephen Rothwell
2023-01-25 3:05 Stephen Rothwell
2022-12-16 1:26 Stephen Rothwell
2022-12-16 3:04 ` Andrew Morton
2022-12-16 0:21 Stephen Rothwell
2022-12-16 0:35 ` Andrew Morton
2022-12-16 1:03 ` Masami Hiramatsu
2022-11-22 6:53 Stephen Rothwell
2022-11-22 10:31 ` David Hildenbrand
2022-11-03 5:02 Stephen Rothwell
2022-11-02 3:55 Stephen Rothwell
2022-11-02 21:26 ` Andrew Morton
2022-10-18 1:24 Stephen Rothwell
2022-09-23 7:55 Stephen Rothwell
2022-09-23 9:50 ` Michael Walle
2022-09-23 11:01 ` Naoya Horiguchi
2022-09-15 7:07 Stephen Rothwell
2022-09-15 16:37 ` Mike Kravetz
2022-09-15 20:06 ` Andrew Morton
2022-09-06 11:03 Stephen Rothwell
2022-09-06 12:05 ` Rob Clark
2022-09-06 18:05 ` Stephen Rothwell
2022-08-26 7:10 Stephen Rothwell
2022-08-26 7:32 ` Michal Hocko
2022-07-08 9:44 Stephen Rothwell
2022-07-08 15:17 ` Darrick J. Wong
2022-07-10 22:28 ` Stephen Rothwell
2022-05-12 9:38 Stephen Rothwell
2022-05-12 10:13 ` Baolin Wang
2022-05-12 11:07 ` Catalin Marinas
2022-05-12 11:13 ` Baolin Wang
2022-05-12 13:28 ` Catalin Marinas
2022-05-12 19:10 ` Andrew Morton
2022-05-13 7:18 ` Stephen Rothwell
2022-05-11 8:15 Stephen Rothwell
2022-05-11 8:27 ` Baolin Wang
2022-05-11 8:42 ` Baolin Wang
2022-05-11 23:28 ` Stephen Rothwell
2022-05-10 11:25 Stephen Rothwell
2022-05-05 21:37 Stephen Rothwell
2022-05-02 10:49 Stephen Rothwell
2022-05-02 11:19 ` Matthew Wilcox
2022-05-03 6:45 ` Stephen Rothwell
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).