* linux-next: build failure after merge of the maple tree
@ 2022-02-17 8:18 Stephen Rothwell
2022-02-17 19:24 ` Will Deacon
0 siblings, 1 reply; 17+ messages in thread
From: Stephen Rothwell @ 2022-02-17 8:18 UTC (permalink / raw)
To: Liam Howlett, Catalin Marinas, Will Deacon
Cc: Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 6176 bytes --]
Hi all,
After merging the maple tree, today's linux-next build (arm64 defconfig)
failed like this:
arch/arm64/kernel/elfcore.c: In function 'elf_core_extra_phdrs':
arch/arm64/kernel/elfcore.c:13:35: error: 'struct mm_struct' has no member named 'mmap'
13 | for (vma = tsk->mm->mmap; vma; vma = vma->vm_next) \
| ^~
arch/arm64/kernel/elfcore.c:69:9: note: in expansion of macro 'for_each_mte_vma'
69 | for_each_mte_vma(current, vma)
| ^~~~~~~~~~~~~~~~
arch/arm64/kernel/elfcore.c:13:57: error: 'struct vm_area_struct' has no member named 'vm_next'
13 | for (vma = tsk->mm->mmap; vma; vma = vma->vm_next) \
| ^~
arch/arm64/kernel/elfcore.c:69:9: note: in expansion of macro 'for_each_mte_vma'
69 | for_each_mte_vma(current, vma)
| ^~~~~~~~~~~~~~~~
arch/arm64/kernel/elfcore.c: In function 'elf_core_write_extra_phdrs':
arch/arm64/kernel/elfcore.c:13:35: error: 'struct mm_struct' has no member named 'mmap'
13 | for (vma = tsk->mm->mmap; vma; vma = vma->vm_next) \
| ^~
arch/arm64/kernel/elfcore.c:79:9: note: in expansion of macro 'for_each_mte_vma'
79 | for_each_mte_vma(current, vma) {
| ^~~~~~~~~~~~~~~~
arch/arm64/kernel/elfcore.c:13:57: error: 'struct vm_area_struct' has no member named 'vm_next'
13 | for (vma = tsk->mm->mmap; vma; vma = vma->vm_next) \
| ^~
arch/arm64/kernel/elfcore.c:79:9: note: in expansion of macro 'for_each_mte_vma'
79 | for_each_mte_vma(current, vma) {
| ^~~~~~~~~~~~~~~~
arch/arm64/kernel/elfcore.c: In function 'elf_core_extra_data_size':
arch/arm64/kernel/elfcore.c:13:35: error: 'struct mm_struct' has no member named 'mmap'
13 | for (vma = tsk->mm->mmap; vma; vma = vma->vm_next) \
| ^~
arch/arm64/kernel/elfcore.c:104:9: note: in expansion of macro 'for_each_mte_vma'
104 | for_each_mte_vma(current, vma)
| ^~~~~~~~~~~~~~~~
arch/arm64/kernel/elfcore.c:13:57: error: 'struct vm_area_struct' has no member named 'vm_next'
13 | for (vma = tsk->mm->mmap; vma; vma = vma->vm_next) \
| ^~
arch/arm64/kernel/elfcore.c:104:9: note: in expansion of macro 'for_each_mte_vma'
104 | for_each_mte_vma(current, vma)
| ^~~~~~~~~~~~~~~~
arch/arm64/kernel/elfcore.c: In function 'elf_core_write_extra_data':
arch/arm64/kernel/elfcore.c:13:35: error: 'struct mm_struct' has no member named 'mmap'
13 | for (vma = tsk->mm->mmap; vma; vma = vma->vm_next) \
| ^~
arch/arm64/kernel/elfcore.c:114:9: note: in expansion of macro 'for_each_mte_vma'
114 | for_each_mte_vma(current, vma) {
| ^~~~~~~~~~~~~~~~
arch/arm64/kernel/elfcore.c:13:57: error: 'struct vm_area_struct' has no member named 'vm_next'
13 | for (vma = tsk->mm->mmap; vma; vma = vma->vm_next) \
| ^~
arch/arm64/kernel/elfcore.c:114:9: note: in expansion of macro 'for_each_mte_vma'
114 | for_each_mte_vma(current, vma) {
| ^~~~~~~~~~~~~~~~
Caused by commit
b09e8361a4c3 ("mm: Remove the vma linked list")
interacting with commit
6dd8b1a0b6cb ("arm64: mte: Dump the MTE tags in the core file")
from the arm64 tree.
I have applied the following merge fix patch for today:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 17 Feb 2022 19:12:41 +1100
Subject: [PATCH] fix up for "arm64: mte: Dump the MTE tags in the core file"
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/arm64/kernel/elfcore.c | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/kernel/elfcore.c b/arch/arm64/kernel/elfcore.c
index 3455ee4acc04..35f99088825e 100644
--- a/arch/arm64/kernel/elfcore.c
+++ b/arch/arm64/kernel/elfcore.c
@@ -8,9 +8,9 @@
#include <asm/cpufeature.h>
#include <asm/mte.h>
-#define for_each_mte_vma(tsk, vma) \
+#define for_each_mte_vma(mas, vma) \
if (system_supports_mte()) \
- for (vma = tsk->mm->mmap; vma; vma = vma->vm_next) \
+ mas_for_each(&mas, vma, ULONG_MAX) \
if (vma->vm_flags & VM_MTE)
static unsigned long mte_vma_tag_dump_size(struct vm_area_struct *vma)
@@ -64,9 +64,10 @@ static int mte_dump_tag_range(struct coredump_params *cprm,
Elf_Half elf_core_extra_phdrs(void)
{
struct vm_area_struct *vma;
+ MA_STATE(mas, ¤t->mm->mm_mt, 0, 0);
int vma_count = 0;
- for_each_mte_vma(current, vma)
+ for_each_mte_vma(mas, vma)
vma_count++;
return vma_count;
@@ -75,8 +76,9 @@ Elf_Half elf_core_extra_phdrs(void)
int elf_core_write_extra_phdrs(struct coredump_params *cprm, loff_t offset)
{
struct vm_area_struct *vma;
+ MA_STATE(mas, ¤t->mm->mm_mt, 0, 0);
- for_each_mte_vma(current, vma) {
+ for_each_mte_vma(mas, vma) {
struct elf_phdr phdr;
phdr.p_type = PT_ARM_MEMTAG_MTE;
@@ -99,9 +101,10 @@ int elf_core_write_extra_phdrs(struct coredump_params *cprm, loff_t offset)
size_t elf_core_extra_data_size(void)
{
struct vm_area_struct *vma;
+ MA_STATE(mas, ¤t->mm->mm_mt, 0, 0);
size_t data_size = 0;
- for_each_mte_vma(current, vma)
+ for_each_mte_vma(mas, vma)
data_size += mte_vma_tag_dump_size(vma);
return data_size;
@@ -110,8 +113,9 @@ size_t elf_core_extra_data_size(void)
int elf_core_write_extra_data(struct coredump_params *cprm)
{
struct vm_area_struct *vma;
+ MA_STATE(mas, ¤t->mm->mm_mt, 0, 0);
- for_each_mte_vma(current, vma) {
+ for_each_mte_vma(mas, vma) {
if (vma->vm_flags & VM_DONTDUMP)
continue;
--
2.34.1
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: linux-next: build failure after merge of the maple tree
2022-02-17 8:18 linux-next: build failure after merge of the maple tree Stephen Rothwell
@ 2022-02-17 19:24 ` Will Deacon
2022-02-18 1:46 ` Liam Howlett
0 siblings, 1 reply; 17+ messages in thread
From: Will Deacon @ 2022-02-17 19:24 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Liam Howlett, Catalin Marinas, Linux Kernel Mailing List,
Linux Next Mailing List
On Thu, Feb 17, 2022 at 07:18:57PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the maple tree, today's linux-next build (arm64 defconfig)
> failed like this:
>
> arch/arm64/kernel/elfcore.c: In function 'elf_core_extra_phdrs':
> arch/arm64/kernel/elfcore.c:13:35: error: 'struct mm_struct' has no member named 'mmap'
> 13 | for (vma = tsk->mm->mmap; vma; vma = vma->vm_next) \
> | ^~
> arch/arm64/kernel/elfcore.c:69:9: note: in expansion of macro 'for_each_mte_vma'
> 69 | for_each_mte_vma(current, vma)
> | ^~~~~~~~~~~~~~~~
> arch/arm64/kernel/elfcore.c:13:57: error: 'struct vm_area_struct' has no member named 'vm_next'
> 13 | for (vma = tsk->mm->mmap; vma; vma = vma->vm_next) \
> | ^~
> arch/arm64/kernel/elfcore.c:69:9: note: in expansion of macro 'for_each_mte_vma'
> 69 | for_each_mte_vma(current, vma)
> | ^~~~~~~~~~~~~~~~
> arch/arm64/kernel/elfcore.c: In function 'elf_core_write_extra_phdrs':
> arch/arm64/kernel/elfcore.c:13:35: error: 'struct mm_struct' has no member named 'mmap'
> 13 | for (vma = tsk->mm->mmap; vma; vma = vma->vm_next) \
> | ^~
> arch/arm64/kernel/elfcore.c:79:9: note: in expansion of macro 'for_each_mte_vma'
> 79 | for_each_mte_vma(current, vma) {
> | ^~~~~~~~~~~~~~~~
> arch/arm64/kernel/elfcore.c:13:57: error: 'struct vm_area_struct' has no member named 'vm_next'
> 13 | for (vma = tsk->mm->mmap; vma; vma = vma->vm_next) \
> | ^~
> arch/arm64/kernel/elfcore.c:79:9: note: in expansion of macro 'for_each_mte_vma'
> 79 | for_each_mte_vma(current, vma) {
> | ^~~~~~~~~~~~~~~~
> arch/arm64/kernel/elfcore.c: In function 'elf_core_extra_data_size':
> arch/arm64/kernel/elfcore.c:13:35: error: 'struct mm_struct' has no member named 'mmap'
> 13 | for (vma = tsk->mm->mmap; vma; vma = vma->vm_next) \
> | ^~
> arch/arm64/kernel/elfcore.c:104:9: note: in expansion of macro 'for_each_mte_vma'
> 104 | for_each_mte_vma(current, vma)
> | ^~~~~~~~~~~~~~~~
> arch/arm64/kernel/elfcore.c:13:57: error: 'struct vm_area_struct' has no member named 'vm_next'
> 13 | for (vma = tsk->mm->mmap; vma; vma = vma->vm_next) \
> | ^~
> arch/arm64/kernel/elfcore.c:104:9: note: in expansion of macro 'for_each_mte_vma'
> 104 | for_each_mte_vma(current, vma)
> | ^~~~~~~~~~~~~~~~
> arch/arm64/kernel/elfcore.c: In function 'elf_core_write_extra_data':
> arch/arm64/kernel/elfcore.c:13:35: error: 'struct mm_struct' has no member named 'mmap'
> 13 | for (vma = tsk->mm->mmap; vma; vma = vma->vm_next) \
> | ^~
> arch/arm64/kernel/elfcore.c:114:9: note: in expansion of macro 'for_each_mte_vma'
> 114 | for_each_mte_vma(current, vma) {
> | ^~~~~~~~~~~~~~~~
> arch/arm64/kernel/elfcore.c:13:57: error: 'struct vm_area_struct' has no member named 'vm_next'
> 13 | for (vma = tsk->mm->mmap; vma; vma = vma->vm_next) \
> | ^~
> arch/arm64/kernel/elfcore.c:114:9: note: in expansion of macro 'for_each_mte_vma'
> 114 | for_each_mte_vma(current, vma) {
> | ^~~~~~~~~~~~~~~~
>
> Caused by commit
>
> b09e8361a4c3 ("mm: Remove the vma linked list")
>
> interacting with commit
>
> 6dd8b1a0b6cb ("arm64: mte: Dump the MTE tags in the core file")
>
> from the arm64 tree.
Yikes, this is quite a mess. Liam -- how would you like to resolve this?
Will
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: linux-next: build failure after merge of the maple tree
2022-02-17 19:24 ` Will Deacon
@ 2022-02-18 1:46 ` Liam Howlett
2022-02-18 2:37 ` [PATCH] arm64: Change elfcore for_each_mte_vma() to use VMA iterator Liam Howlett
0 siblings, 1 reply; 17+ messages in thread
From: Liam Howlett @ 2022-02-18 1:46 UTC (permalink / raw)
To: Will Deacon
Cc: Stephen Rothwell, Catalin Marinas, Linux Kernel Mailing List,
Linux Next Mailing List
* Will Deacon <will@kernel.org> [220217 14:24]:
> On Thu, Feb 17, 2022 at 07:18:57PM +1100, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the maple tree, today's linux-next build (arm64 defconfig)
> > failed like this:
> >
> > arch/arm64/kernel/elfcore.c: In function 'elf_core_extra_phdrs':
> > arch/arm64/kernel/elfcore.c:13:35: error: 'struct mm_struct' has no member named 'mmap'
> > 13 | for (vma = tsk->mm->mmap; vma; vma = vma->vm_next) \
> > | ^~
> > arch/arm64/kernel/elfcore.c:69:9: note: in expansion of macro 'for_each_mte_vma'
> > 69 | for_each_mte_vma(current, vma)
> > | ^~~~~~~~~~~~~~~~
> > arch/arm64/kernel/elfcore.c:13:57: error: 'struct vm_area_struct' has no member named 'vm_next'
> > 13 | for (vma = tsk->mm->mmap; vma; vma = vma->vm_next) \
> > | ^~
> > arch/arm64/kernel/elfcore.c:69:9: note: in expansion of macro 'for_each_mte_vma'
> > 69 | for_each_mte_vma(current, vma)
> > | ^~~~~~~~~~~~~~~~
> > arch/arm64/kernel/elfcore.c: In function 'elf_core_write_extra_phdrs':
> > arch/arm64/kernel/elfcore.c:13:35: error: 'struct mm_struct' has no member named 'mmap'
> > 13 | for (vma = tsk->mm->mmap; vma; vma = vma->vm_next) \
> > | ^~
> > arch/arm64/kernel/elfcore.c:79:9: note: in expansion of macro 'for_each_mte_vma'
> > 79 | for_each_mte_vma(current, vma) {
> > | ^~~~~~~~~~~~~~~~
> > arch/arm64/kernel/elfcore.c:13:57: error: 'struct vm_area_struct' has no member named 'vm_next'
> > 13 | for (vma = tsk->mm->mmap; vma; vma = vma->vm_next) \
> > | ^~
> > arch/arm64/kernel/elfcore.c:79:9: note: in expansion of macro 'for_each_mte_vma'
> > 79 | for_each_mte_vma(current, vma) {
> > | ^~~~~~~~~~~~~~~~
> > arch/arm64/kernel/elfcore.c: In function 'elf_core_extra_data_size':
> > arch/arm64/kernel/elfcore.c:13:35: error: 'struct mm_struct' has no member named 'mmap'
> > 13 | for (vma = tsk->mm->mmap; vma; vma = vma->vm_next) \
> > | ^~
> > arch/arm64/kernel/elfcore.c:104:9: note: in expansion of macro 'for_each_mte_vma'
> > 104 | for_each_mte_vma(current, vma)
> > | ^~~~~~~~~~~~~~~~
> > arch/arm64/kernel/elfcore.c:13:57: error: 'struct vm_area_struct' has no member named 'vm_next'
> > 13 | for (vma = tsk->mm->mmap; vma; vma = vma->vm_next) \
> > | ^~
> > arch/arm64/kernel/elfcore.c:104:9: note: in expansion of macro 'for_each_mte_vma'
> > 104 | for_each_mte_vma(current, vma)
> > | ^~~~~~~~~~~~~~~~
> > arch/arm64/kernel/elfcore.c: In function 'elf_core_write_extra_data':
> > arch/arm64/kernel/elfcore.c:13:35: error: 'struct mm_struct' has no member named 'mmap'
> > 13 | for (vma = tsk->mm->mmap; vma; vma = vma->vm_next) \
> > | ^~
> > arch/arm64/kernel/elfcore.c:114:9: note: in expansion of macro 'for_each_mte_vma'
> > 114 | for_each_mte_vma(current, vma) {
> > | ^~~~~~~~~~~~~~~~
> > arch/arm64/kernel/elfcore.c:13:57: error: 'struct vm_area_struct' has no member named 'vm_next'
> > 13 | for (vma = tsk->mm->mmap; vma; vma = vma->vm_next) \
> > | ^~
> > arch/arm64/kernel/elfcore.c:114:9: note: in expansion of macro 'for_each_mte_vma'
> > 114 | for_each_mte_vma(current, vma) {
> > | ^~~~~~~~~~~~~~~~
> >
> > Caused by commit
> >
> > b09e8361a4c3 ("mm: Remove the vma linked list")
> >
> > interacting with commit
> >
> > 6dd8b1a0b6cb ("arm64: mte: Dump the MTE tags in the core file")
> >
> > from the arm64 tree.
>
> Yikes, this is quite a mess. Liam -- how would you like to resolve this?
The removal of the vma linked list means tsk->mm->mmap and vma->vm_next
are no longer usable. for_each_mte_vma() could be altered to take a vma
iterator:
#define for_each_mte_vma(vmi, vma) \
if (system_supports_mte()) \
for_each_vma(vmi, vma) \
if (vma->vm_flags & VM_MTE)
Then used as such:
VMA_ITERATOR(vmi, tsk->mm, 0);
...
for_each_mte_vma(vmi, vma) {
...
}
Where might I find a branch containing this patch? Is it a stand alone
or part of a larger series?
Liam
^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH] arm64: Change elfcore for_each_mte_vma() to use VMA iterator
2022-02-18 1:46 ` Liam Howlett
@ 2022-02-18 2:37 ` Liam Howlett
2022-02-21 18:06 ` Catalin Marinas
2022-02-25 15:50 ` Will Deacon
0 siblings, 2 replies; 17+ messages in thread
From: Liam Howlett @ 2022-02-18 2:37 UTC (permalink / raw)
To: Will Deacon, Stephen Rothwell
Cc: Catalin Marinas, Linux Kernel Mailing List, Linux Next Mailing List
This is an untested fix for the merge conflict of maple tree next and
arm64 next.
Instead of using the linked list, use the vma iterator.
Signed-off-by: Liam R. Howlett <Liam.Howlett@oracle.com>
---
arch/arm64/kernel/elfcore.c | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/kernel/elfcore.c b/arch/arm64/kernel/elfcore.c
index 3455ee4acc04..930a0bc4cac4 100644
--- a/arch/arm64/kernel/elfcore.c
+++ b/arch/arm64/kernel/elfcore.c
@@ -8,9 +8,9 @@
#include <asm/cpufeature.h>
#include <asm/mte.h>
-#define for_each_mte_vma(tsk, vma) \
+#define for_each_mte_vma(vmi, vma) \
if (system_supports_mte()) \
- for (vma = tsk->mm->mmap; vma; vma = vma->vm_next) \
+ for_each_vma(vmi, vma) \
if (vma->vm_flags & VM_MTE)
static unsigned long mte_vma_tag_dump_size(struct vm_area_struct *vma)
@@ -65,8 +65,9 @@ Elf_Half elf_core_extra_phdrs(void)
{
struct vm_area_struct *vma;
int vma_count = 0;
+ VMA_ITERATOR(vmi, current->mm, 0);
- for_each_mte_vma(current, vma)
+ for_each_mte_vma(vmi, vma)
vma_count++;
return vma_count;
@@ -75,8 +76,9 @@ Elf_Half elf_core_extra_phdrs(void)
int elf_core_write_extra_phdrs(struct coredump_params *cprm, loff_t offset)
{
struct vm_area_struct *vma;
+ VMA_ITERATOR(vmi, current->mm, 0);
- for_each_mte_vma(current, vma) {
+ for_each_mte_vma(vmi, vma) {
struct elf_phdr phdr;
phdr.p_type = PT_ARM_MEMTAG_MTE;
@@ -100,8 +102,9 @@ size_t elf_core_extra_data_size(void)
{
struct vm_area_struct *vma;
size_t data_size = 0;
+ VMA_ITERATOR(vmi, current->mm, 0);
- for_each_mte_vma(current, vma)
+ for_each_mte_vma(vmi, vma)
data_size += mte_vma_tag_dump_size(vma);
return data_size;
@@ -110,8 +113,9 @@ size_t elf_core_extra_data_size(void)
int elf_core_write_extra_data(struct coredump_params *cprm)
{
struct vm_area_struct *vma;
+ VMA_ITERATOR(vmi, current->mm, 0);
- for_each_mte_vma(current, vma) {
+ for_each_mte_vma(vmi, vma) {
if (vma->vm_flags & VM_DONTDUMP)
continue;
--
2.34.1
^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [PATCH] arm64: Change elfcore for_each_mte_vma() to use VMA iterator
2022-02-18 2:37 ` [PATCH] arm64: Change elfcore for_each_mte_vma() to use VMA iterator Liam Howlett
@ 2022-02-21 18:06 ` Catalin Marinas
2022-02-22 14:26 ` Liam Howlett
2022-02-25 15:50 ` Will Deacon
1 sibling, 1 reply; 17+ messages in thread
From: Catalin Marinas @ 2022-02-21 18:06 UTC (permalink / raw)
To: Liam Howlett
Cc: Will Deacon, Stephen Rothwell, Linux Kernel Mailing List,
Linux Next Mailing List
On Fri, Feb 18, 2022 at 02:37:04AM +0000, Liam Howlett wrote:
> diff --git a/arch/arm64/kernel/elfcore.c b/arch/arm64/kernel/elfcore.c
> index 3455ee4acc04..930a0bc4cac4 100644
> --- a/arch/arm64/kernel/elfcore.c
> +++ b/arch/arm64/kernel/elfcore.c
> @@ -8,9 +8,9 @@
> #include <asm/cpufeature.h>
> #include <asm/mte.h>
>
> -#define for_each_mte_vma(tsk, vma) \
> +#define for_each_mte_vma(vmi, vma) \
> if (system_supports_mte()) \
> - for (vma = tsk->mm->mmap; vma; vma = vma->vm_next) \
> + for_each_vma(vmi, vma) \
> if (vma->vm_flags & VM_MTE)
>
> static unsigned long mte_vma_tag_dump_size(struct vm_area_struct *vma)
> @@ -65,8 +65,9 @@ Elf_Half elf_core_extra_phdrs(void)
> {
> struct vm_area_struct *vma;
> int vma_count = 0;
> + VMA_ITERATOR(vmi, current->mm, 0);
>
> - for_each_mte_vma(current, vma)
> + for_each_mte_vma(vmi, vma)
> vma_count++;
I'm fine with the patch but it can't be applied to arm64 for-next/mte
branch as it won't build and the maple tree doesn't have the MTE
patches. Do you have a stable branch with the for_each_vma() iterator?
Anyway, if you find a way to solve the problem, for this patch:
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] arm64: Change elfcore for_each_mte_vma() to use VMA iterator
2022-02-21 18:06 ` Catalin Marinas
@ 2022-02-22 14:26 ` Liam Howlett
2022-02-22 16:20 ` Will Deacon
0 siblings, 1 reply; 17+ messages in thread
From: Liam Howlett @ 2022-02-22 14:26 UTC (permalink / raw)
To: Catalin Marinas
Cc: Will Deacon, Stephen Rothwell, Linux Kernel Mailing List,
Linux Next Mailing List
* Catalin Marinas <catalin.marinas@arm.com> [220221 13:07]:
> On Fri, Feb 18, 2022 at 02:37:04AM +0000, Liam Howlett wrote:
> > diff --git a/arch/arm64/kernel/elfcore.c b/arch/arm64/kernel/elfcore.c
> > index 3455ee4acc04..930a0bc4cac4 100644
> > --- a/arch/arm64/kernel/elfcore.c
> > +++ b/arch/arm64/kernel/elfcore.c
> > @@ -8,9 +8,9 @@
> > #include <asm/cpufeature.h>
> > #include <asm/mte.h>
> >
> > -#define for_each_mte_vma(tsk, vma) \
> > +#define for_each_mte_vma(vmi, vma) \
> > if (system_supports_mte()) \
> > - for (vma = tsk->mm->mmap; vma; vma = vma->vm_next) \
> > + for_each_vma(vmi, vma) \
> > if (vma->vm_flags & VM_MTE)
> >
> > static unsigned long mte_vma_tag_dump_size(struct vm_area_struct *vma)
> > @@ -65,8 +65,9 @@ Elf_Half elf_core_extra_phdrs(void)
> > {
> > struct vm_area_struct *vma;
> > int vma_count = 0;
> > + VMA_ITERATOR(vmi, current->mm, 0);
> >
> > - for_each_mte_vma(current, vma)
> > + for_each_mte_vma(vmi, vma)
> > vma_count++;
>
> I'm fine with the patch but it can't be applied to arm64 for-next/mte
> branch as it won't build and the maple tree doesn't have the MTE
> patches. Do you have a stable branch with the for_each_vma() iterator?
The vma iterator uses the maple tree, so this patch would resolve the
conflict but both branches are needed.
>
> Anyway, if you find a way to solve the problem, for this patch:
>
> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] arm64: Change elfcore for_each_mte_vma() to use VMA iterator
2022-02-22 14:26 ` Liam Howlett
@ 2022-02-22 16:20 ` Will Deacon
2022-02-22 17:26 ` Catalin Marinas
0 siblings, 1 reply; 17+ messages in thread
From: Will Deacon @ 2022-02-22 16:20 UTC (permalink / raw)
To: Liam Howlett
Cc: Catalin Marinas, Stephen Rothwell, Linux Kernel Mailing List,
Linux Next Mailing List
On Tue, Feb 22, 2022 at 02:26:03PM +0000, Liam Howlett wrote:
> * Catalin Marinas <catalin.marinas@arm.com> [220221 13:07]:
> > On Fri, Feb 18, 2022 at 02:37:04AM +0000, Liam Howlett wrote:
> > > diff --git a/arch/arm64/kernel/elfcore.c b/arch/arm64/kernel/elfcore.c
> > > index 3455ee4acc04..930a0bc4cac4 100644
> > > --- a/arch/arm64/kernel/elfcore.c
> > > +++ b/arch/arm64/kernel/elfcore.c
> > > @@ -8,9 +8,9 @@
> > > #include <asm/cpufeature.h>
> > > #include <asm/mte.h>
> > >
> > > -#define for_each_mte_vma(tsk, vma) \
> > > +#define for_each_mte_vma(vmi, vma) \
> > > if (system_supports_mte()) \
> > > - for (vma = tsk->mm->mmap; vma; vma = vma->vm_next) \
> > > + for_each_vma(vmi, vma) \
> > > if (vma->vm_flags & VM_MTE)
> > >
> > > static unsigned long mte_vma_tag_dump_size(struct vm_area_struct *vma)
> > > @@ -65,8 +65,9 @@ Elf_Half elf_core_extra_phdrs(void)
> > > {
> > > struct vm_area_struct *vma;
> > > int vma_count = 0;
> > > + VMA_ITERATOR(vmi, current->mm, 0);
> > >
> > > - for_each_mte_vma(current, vma)
> > > + for_each_mte_vma(vmi, vma)
> > > vma_count++;
> >
> > I'm fine with the patch but it can't be applied to arm64 for-next/mte
> > branch as it won't build and the maple tree doesn't have the MTE
> > patches. Do you have a stable branch with the for_each_vma() iterator?
>
> The vma iterator uses the maple tree, so this patch would resolve the
> conflict but both branches are needed.
I'm not really sure what to do here, then. I think the conflict is nasty
enough that we should resolve it before the trees reach Linus, but there
doesn't seem to be a way forward other than one of us merging the other
branch. I'd like to avoid having MTE coredump support depend on the maple
tree work.
Is there some way you could provide a branch which implements
for_each_vma() using the old vma list, and then the maple tree series
could switch that over to the maple tree without breaking things?
Will
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] arm64: Change elfcore for_each_mte_vma() to use VMA iterator
2022-02-22 16:20 ` Will Deacon
@ 2022-02-22 17:26 ` Catalin Marinas
2022-02-22 18:54 ` Liam Howlett
0 siblings, 1 reply; 17+ messages in thread
From: Catalin Marinas @ 2022-02-22 17:26 UTC (permalink / raw)
To: Will Deacon
Cc: Liam Howlett, Stephen Rothwell, Linux Kernel Mailing List,
Linux Next Mailing List
On Tue, Feb 22, 2022 at 04:20:16PM +0000, Will Deacon wrote:
> On Tue, Feb 22, 2022 at 02:26:03PM +0000, Liam Howlett wrote:
> > * Catalin Marinas <catalin.marinas@arm.com> [220221 13:07]:
> > > On Fri, Feb 18, 2022 at 02:37:04AM +0000, Liam Howlett wrote:
> > > > diff --git a/arch/arm64/kernel/elfcore.c b/arch/arm64/kernel/elfcore.c
> > > > index 3455ee4acc04..930a0bc4cac4 100644
> > > > --- a/arch/arm64/kernel/elfcore.c
> > > > +++ b/arch/arm64/kernel/elfcore.c
> > > > @@ -8,9 +8,9 @@
> > > > #include <asm/cpufeature.h>
> > > > #include <asm/mte.h>
> > > >
> > > > -#define for_each_mte_vma(tsk, vma) \
> > > > +#define for_each_mte_vma(vmi, vma) \
> > > > if (system_supports_mte()) \
> > > > - for (vma = tsk->mm->mmap; vma; vma = vma->vm_next) \
> > > > + for_each_vma(vmi, vma) \
> > > > if (vma->vm_flags & VM_MTE)
> > > >
> > > > static unsigned long mte_vma_tag_dump_size(struct vm_area_struct *vma)
> > > > @@ -65,8 +65,9 @@ Elf_Half elf_core_extra_phdrs(void)
> > > > {
> > > > struct vm_area_struct *vma;
> > > > int vma_count = 0;
> > > > + VMA_ITERATOR(vmi, current->mm, 0);
> > > >
> > > > - for_each_mte_vma(current, vma)
> > > > + for_each_mte_vma(vmi, vma)
> > > > vma_count++;
> > >
> > > I'm fine with the patch but it can't be applied to arm64 for-next/mte
> > > branch as it won't build and the maple tree doesn't have the MTE
> > > patches. Do you have a stable branch with the for_each_vma() iterator?
> >
> > The vma iterator uses the maple tree, so this patch would resolve the
> > conflict but both branches are needed.
>
> I'm not really sure what to do here, then. I think the conflict is nasty
> enough that we should resolve it before the trees reach Linus, but there
> doesn't seem to be a way forward other than one of us merging the other
> branch. I'd like to avoid having MTE coredump support depend on the maple
> tree work.
>
> Is there some way you could provide a branch which implements
> for_each_vma() using the old vma list, and then the maple tree series
> could switch that over to the maple tree without breaking things?
Without a branch, we could apply something like below on top of Liam's
patch and revert it once the maple tree is upstream:
diff --git a/arch/arm64/kernel/elfcore.c b/arch/arm64/kernel/elfcore.c
index 930a0bc4cac4..400ec7a902df 100644
--- a/arch/arm64/kernel/elfcore.c
+++ b/arch/arm64/kernel/elfcore.c
@@ -8,6 +8,13 @@
#include <asm/cpufeature.h>
#include <asm/mte.h>
+#ifndef VMA_ITERATOR
+#define VMA_ITERATOR(name, mm, addr) \
+ struct mm_struct *name = mm
+#define for_each_vma(vmi, vma) \
+ for (vma = vmi->mmap; vma; vma = vma->vm_next)
+#endif
+
#define for_each_mte_vma(vmi, vma) \
if (system_supports_mte()) \
for_each_vma(vmi, vma) \
--
Catalin
^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [PATCH] arm64: Change elfcore for_each_mte_vma() to use VMA iterator
2022-02-22 17:26 ` Catalin Marinas
@ 2022-02-22 18:54 ` Liam Howlett
2022-02-23 9:39 ` Catalin Marinas
2022-02-23 11:37 ` Catalin Marinas
0 siblings, 2 replies; 17+ messages in thread
From: Liam Howlett @ 2022-02-22 18:54 UTC (permalink / raw)
To: Catalin Marinas
Cc: Will Deacon, Stephen Rothwell, Linux Kernel Mailing List,
Linux Next Mailing List
* Catalin Marinas <catalin.marinas@arm.com> [220222 12:26]:
> On Tue, Feb 22, 2022 at 04:20:16PM +0000, Will Deacon wrote:
> > On Tue, Feb 22, 2022 at 02:26:03PM +0000, Liam Howlett wrote:
> > > * Catalin Marinas <catalin.marinas@arm.com> [220221 13:07]:
> > > > On Fri, Feb 18, 2022 at 02:37:04AM +0000, Liam Howlett wrote:
> > > > > diff --git a/arch/arm64/kernel/elfcore.c b/arch/arm64/kernel/elfcore.c
> > > > > index 3455ee4acc04..930a0bc4cac4 100644
> > > > > --- a/arch/arm64/kernel/elfcore.c
> > > > > +++ b/arch/arm64/kernel/elfcore.c
> > > > > @@ -8,9 +8,9 @@
> > > > > #include <asm/cpufeature.h>
> > > > > #include <asm/mte.h>
> > > > >
> > > > > -#define for_each_mte_vma(tsk, vma) \
> > > > > +#define for_each_mte_vma(vmi, vma) \
> > > > > if (system_supports_mte()) \
> > > > > - for (vma = tsk->mm->mmap; vma; vma = vma->vm_next) \
> > > > > + for_each_vma(vmi, vma) \
> > > > > if (vma->vm_flags & VM_MTE)
> > > > >
> > > > > static unsigned long mte_vma_tag_dump_size(struct vm_area_struct *vma)
> > > > > @@ -65,8 +65,9 @@ Elf_Half elf_core_extra_phdrs(void)
> > > > > {
> > > > > struct vm_area_struct *vma;
> > > > > int vma_count = 0;
> > > > > + VMA_ITERATOR(vmi, current->mm, 0);
> > > > >
> > > > > - for_each_mte_vma(current, vma)
> > > > > + for_each_mte_vma(vmi, vma)
> > > > > vma_count++;
> > > >
> > > > I'm fine with the patch but it can't be applied to arm64 for-next/mte
> > > > branch as it won't build and the maple tree doesn't have the MTE
> > > > patches. Do you have a stable branch with the for_each_vma() iterator?
> > >
> > > The vma iterator uses the maple tree, so this patch would resolve the
> > > conflict but both branches are needed.
> >
> > I'm not really sure what to do here, then. I think the conflict is nasty
> > enough that we should resolve it before the trees reach Linus, but there
> > doesn't seem to be a way forward other than one of us merging the other
> > branch. I'd like to avoid having MTE coredump support depend on the maple
> > tree work.
> >
> > Is there some way you could provide a branch which implements
> > for_each_vma() using the old vma list, and then the maple tree series
> > could switch that over to the maple tree without breaking things?
>
> Without a branch, we could apply something like below on top of Liam's
> patch and revert it once the maple tree is upstream:
>
> diff --git a/arch/arm64/kernel/elfcore.c b/arch/arm64/kernel/elfcore.c
> index 930a0bc4cac4..400ec7a902df 100644
> --- a/arch/arm64/kernel/elfcore.c
> +++ b/arch/arm64/kernel/elfcore.c
> @@ -8,6 +8,13 @@
> #include <asm/cpufeature.h>
> #include <asm/mte.h>
>
> +#ifndef VMA_ITERATOR
> +#define VMA_ITERATOR(name, mm, addr) \
> + struct mm_struct *name = mm
> +#define for_each_vma(vmi, vma) \
> + for (vma = vmi->mmap; vma; vma = vma->vm_next)
> +#endif
> +
> #define for_each_mte_vma(vmi, vma) \
> if (system_supports_mte()) \
> for_each_vma(vmi, vma) \
>
Note that the current VMA_ITERATOR takes a new type and not the mm.
Since I am removing the linked list (mm->mmap and vma->vm_next), then
the build will fail if this patch and the maple tree branch exist
together. The iterator may also not start at the start of the list (but
usually does) and may not run through the entire list; see
vma_for_each_range() in the patch set.
Once the maple tree is upstream, then you can take the patch I posted.
I think this is a situation that Linus could take the fixup?
Thanks,
Liam
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] arm64: Change elfcore for_each_mte_vma() to use VMA iterator
2022-02-22 18:54 ` Liam Howlett
@ 2022-02-23 9:39 ` Catalin Marinas
2022-02-23 13:57 ` Liam Howlett
2022-02-23 11:37 ` Catalin Marinas
1 sibling, 1 reply; 17+ messages in thread
From: Catalin Marinas @ 2022-02-23 9:39 UTC (permalink / raw)
To: Liam Howlett
Cc: Will Deacon, Stephen Rothwell, Linux Kernel Mailing List,
Linux Next Mailing List
On Tue, Feb 22, 2022 at 06:54:38PM +0000, Liam Howlett wrote:
> * Catalin Marinas <catalin.marinas@arm.com> [220222 12:26]:
> > On Tue, Feb 22, 2022 at 04:20:16PM +0000, Will Deacon wrote:
> > > On Tue, Feb 22, 2022 at 02:26:03PM +0000, Liam Howlett wrote:
> > > > The vma iterator uses the maple tree, so this patch would resolve the
> > > > conflict but both branches are needed.
> > >
> > > I'm not really sure what to do here, then. I think the conflict is nasty
> > > enough that we should resolve it before the trees reach Linus, but there
> > > doesn't seem to be a way forward other than one of us merging the other
> > > branch. I'd like to avoid having MTE coredump support depend on the maple
> > > tree work.
> > >
> > > Is there some way you could provide a branch which implements
> > > for_each_vma() using the old vma list, and then the maple tree series
> > > could switch that over to the maple tree without breaking things?
> >
> > Without a branch, we could apply something like below on top of Liam's
> > patch and revert it once the maple tree is upstream:
> >
> > diff --git a/arch/arm64/kernel/elfcore.c b/arch/arm64/kernel/elfcore.c
> > index 930a0bc4cac4..400ec7a902df 100644
> > --- a/arch/arm64/kernel/elfcore.c
> > +++ b/arch/arm64/kernel/elfcore.c
> > @@ -8,6 +8,13 @@
> > #include <asm/cpufeature.h>
> > #include <asm/mte.h>
> >
> > +#ifndef VMA_ITERATOR
> > +#define VMA_ITERATOR(name, mm, addr) \
> > + struct mm_struct *name = mm
> > +#define for_each_vma(vmi, vma) \
> > + for (vma = vmi->mmap; vma; vma = vma->vm_next)
> > +#endif
> > +
> > #define for_each_mte_vma(vmi, vma) \
> > if (system_supports_mte()) \
> > for_each_vma(vmi, vma) \
>
> Note that the current VMA_ITERATOR takes a new type and not the mm.
Well, in you proposed fix, it does take current->mm.
> Since I am removing the linked list (mm->mmap and vma->vm_next), then
> the build will fail if this patch and the maple tree branch exist
> together. The iterator may also not start at the start of the list (but
> usually does) and may not run through the entire list; see
> vma_for_each_range() in the patch set.
My hack above is only temporary to allow building the arm64 tree on its
own (no maple tree branch) and with your patch on top. In -next, when
merged with the maple tree branch, the VMA_ITERATOR macro is already
defined and the above hack skipped. We'll revert this hack around -rc1.
Note that the hack above is only in the arm64 elfcore.c, not a generic
API solution.
--
Catalin
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] arm64: Change elfcore for_each_mte_vma() to use VMA iterator
2022-02-22 18:54 ` Liam Howlett
2022-02-23 9:39 ` Catalin Marinas
@ 2022-02-23 11:37 ` Catalin Marinas
2022-02-23 14:11 ` Liam Howlett
1 sibling, 1 reply; 17+ messages in thread
From: Catalin Marinas @ 2022-02-23 11:37 UTC (permalink / raw)
To: Liam Howlett
Cc: Will Deacon, Stephen Rothwell, Linux Kernel Mailing List,
Linux Next Mailing List, Mark Brown, Matthew Wilcox
On Tue, Feb 22, 2022 at 06:54:38PM +0000, Liam Howlett wrote:
> Once the maple tree is upstream, then you can take the patch I posted.
BTW, on the maple tree branch alone
(https://github.com/oracle/linux-uek.git maple/mainline), I get the
warning below and no core file generated. It's not MTE related as it
doesn't have my patches.
[ 67.887638] WARNING: CPU: 1 PID: 528 at fs/coredump.c:1116 dump_vma_snapshot+0x98/0x18c
[ 67.888594] Modules linked in: crct10dif_ce sm3_ce sm3_generic sha3_ce sha3_generic sha512_ce sha512_arm64 drm fuse ip_tables x_tables ipv6
[ 67.890017] CPU: 1 PID: 528 Comm: mte-coredump Not tainted 5.17.0-rc4-00071-gc8cf067d6a99 #1
[ 67.890494] Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015
[ 67.891054] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 67.891469] pc : dump_vma_snapshot+0x98/0x18c
[ 67.891787] lr : dump_vma_snapshot+0x74/0x18c
[ 67.892071] sp : ffff80000839b8f0
[ 67.892278] x29: ffff80000839b8f0 x28: ffffd4a81d76255c x27: 0000000000000000
[ 67.892894] x26: ffffd4a81da308e0 x25: 0000000000000000 x24: ffff80000839bc78
[ 67.893436] x23: ffff00000557cf00 x22: ffff00000557cf60 x21: ffff80000839b9e0
[ 67.893922] x20: ffff80000839b9e8 x19: ffff80000839b9dc x18: 0000000000000000
[ 67.894497] x17: 0000000000000000 x16: 0000ffff9e8effff x15: 0000000000000000
[ 67.895061] x14: 0000000000000000 x13: ffff0000025f9000 x12: ffff000001a2eb94
[ 67.895590] x11: ffff80000839b100 x10: ffff80000839b108 x9 : 0000000000000000
[ 67.896057] x8 : ffff80000839bb68 x7 : 0000000000000000 x6 : 0000000000896101
[ 67.896537] x5 : ffff0000016bf000 x4 : ffff80000839b8b0 x3 : 0000000000000001
[ 67.896961] x2 : 0000000000000000 x1 : 0000000000000001 x0 : 0000000000000011
[ 67.897493] Call trace:
[ 67.897679] dump_vma_snapshot+0x98/0x18c
[ 67.898034] elf_core_dump+0x50/0xcf0
[ 67.898274] do_coredump+0xbdc/0xfc4
[ 67.898553] get_signal+0x524/0x7f0
[ 67.898775] do_notify_resume+0x224/0x1330
[ 67.899046] el0_da+0x50/0x60
[ 67.899431] el0t_64_sync_handler+0xec/0x130
[ 67.899726] el0t_64_sync+0x1a0/0x1a4
--
Catalin
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] arm64: Change elfcore for_each_mte_vma() to use VMA iterator
2022-02-23 9:39 ` Catalin Marinas
@ 2022-02-23 13:57 ` Liam Howlett
0 siblings, 0 replies; 17+ messages in thread
From: Liam Howlett @ 2022-02-23 13:57 UTC (permalink / raw)
To: Catalin Marinas
Cc: Will Deacon, Stephen Rothwell, Linux Kernel Mailing List,
Linux Next Mailing List
* Catalin Marinas <catalin.marinas@arm.com> [220223 04:39]:
> On Tue, Feb 22, 2022 at 06:54:38PM +0000, Liam Howlett wrote:
> > * Catalin Marinas <catalin.marinas@arm.com> [220222 12:26]:
> > > On Tue, Feb 22, 2022 at 04:20:16PM +0000, Will Deacon wrote:
> > > > On Tue, Feb 22, 2022 at 02:26:03PM +0000, Liam Howlett wrote:
> > > > > The vma iterator uses the maple tree, so this patch would resolve the
> > > > > conflict but both branches are needed.
> > > >
> > > > I'm not really sure what to do here, then. I think the conflict is nasty
> > > > enough that we should resolve it before the trees reach Linus, but there
> > > > doesn't seem to be a way forward other than one of us merging the other
> > > > branch. I'd like to avoid having MTE coredump support depend on the maple
> > > > tree work.
> > > >
> > > > Is there some way you could provide a branch which implements
> > > > for_each_vma() using the old vma list, and then the maple tree series
> > > > could switch that over to the maple tree without breaking things?
> > >
> > > Without a branch, we could apply something like below on top of Liam's
> > > patch and revert it once the maple tree is upstream:
> > >
> > > diff --git a/arch/arm64/kernel/elfcore.c b/arch/arm64/kernel/elfcore.c
> > > index 930a0bc4cac4..400ec7a902df 100644
> > > --- a/arch/arm64/kernel/elfcore.c
> > > +++ b/arch/arm64/kernel/elfcore.c
> > > @@ -8,6 +8,13 @@
> > > #include <asm/cpufeature.h>
> > > #include <asm/mte.h>
> > >
> > > +#ifndef VMA_ITERATOR
> > > +#define VMA_ITERATOR(name, mm, addr) \
> > > + struct mm_struct *name = mm
> > > +#define for_each_vma(vmi, vma) \
> > > + for (vma = vmi->mmap; vma; vma = vma->vm_next)
> > > +#endif
> > > +
> > > #define for_each_mte_vma(vmi, vma) \
> > > if (system_supports_mte()) \
> > > for_each_vma(vmi, vma) \
> >
> > Note that the current VMA_ITERATOR takes a new type and not the mm.
>
> Well, in you proposed fix, it does take current->mm.
Sorry. Yes, you are correct. The VMA_ITERATOR() takes the mm. The for
each takes the vmi.
>
> > Since I am removing the linked list (mm->mmap and vma->vm_next), then
> > the build will fail if this patch and the maple tree branch exist
> > together. The iterator may also not start at the start of the list (but
> > usually does) and may not run through the entire list; see
> > vma_for_each_range() in the patch set.
>
> My hack above is only temporary to allow building the arm64 tree on its
> own (no maple tree branch) and with your patch on top. In -next, when
> merged with the maple tree branch, the VMA_ITERATOR macro is already
> defined and the above hack skipped. We'll revert this hack around -rc1.
>
> Note that the hack above is only in the arm64 elfcore.c, not a generic
> API solution.
Okay, thanks. This sounds good if it works on your side. Sorry for not
getting it earlier.
Liam
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] arm64: Change elfcore for_each_mte_vma() to use VMA iterator
2022-02-23 11:37 ` Catalin Marinas
@ 2022-02-23 14:11 ` Liam Howlett
2022-02-24 2:00 ` Liam Howlett
0 siblings, 1 reply; 17+ messages in thread
From: Liam Howlett @ 2022-02-23 14:11 UTC (permalink / raw)
To: Catalin Marinas
Cc: Will Deacon, Stephen Rothwell, Linux Kernel Mailing List,
Linux Next Mailing List, Mark Brown, Matthew Wilcox
* Catalin Marinas <catalin.marinas@arm.com> [220223 06:37]:
> On Tue, Feb 22, 2022 at 06:54:38PM +0000, Liam Howlett wrote:
> > Once the maple tree is upstream, then you can take the patch I posted.
>
> BTW, on the maple tree branch alone
> (https://github.com/oracle/linux-uek.git maple/mainline), I get the
> warning below and no core file generated. It's not MTE related as it
> doesn't have my patches.
>
> [ 67.887638] WARNING: CPU: 1 PID: 528 at fs/coredump.c:1116 dump_vma_snapshot+0x98/0x18c
> [ 67.888594] Modules linked in: crct10dif_ce sm3_ce sm3_generic sha3_ce sha3_generic sha512_ce sha512_arm64 drm fuse ip_tables x_tables ipv6
> [ 67.890017] CPU: 1 PID: 528 Comm: mte-coredump Not tainted 5.17.0-rc4-00071-gc8cf067d6a99 #1
> [ 67.890494] Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015
> [ 67.891054] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [ 67.891469] pc : dump_vma_snapshot+0x98/0x18c
> [ 67.891787] lr : dump_vma_snapshot+0x74/0x18c
> [ 67.892071] sp : ffff80000839b8f0
> [ 67.892278] x29: ffff80000839b8f0 x28: ffffd4a81d76255c x27: 0000000000000000
> [ 67.892894] x26: ffffd4a81da308e0 x25: 0000000000000000 x24: ffff80000839bc78
> [ 67.893436] x23: ffff00000557cf00 x22: ffff00000557cf60 x21: ffff80000839b9e0
> [ 67.893922] x20: ffff80000839b9e8 x19: ffff80000839b9dc x18: 0000000000000000
> [ 67.894497] x17: 0000000000000000 x16: 0000ffff9e8effff x15: 0000000000000000
> [ 67.895061] x14: 0000000000000000 x13: ffff0000025f9000 x12: ffff000001a2eb94
> [ 67.895590] x11: ffff80000839b100 x10: ffff80000839b108 x9 : 0000000000000000
> [ 67.896057] x8 : ffff80000839bb68 x7 : 0000000000000000 x6 : 0000000000896101
> [ 67.896537] x5 : ffff0000016bf000 x4 : ffff80000839b8b0 x3 : 0000000000000001
> [ 67.896961] x2 : 0000000000000000 x1 : 0000000000000001 x0 : 0000000000000011
> [ 67.897493] Call trace:
> [ 67.897679] dump_vma_snapshot+0x98/0x18c
> [ 67.898034] elf_core_dump+0x50/0xcf0
> [ 67.898274] do_coredump+0xbdc/0xfc4
> [ 67.898553] get_signal+0x524/0x7f0
> [ 67.898775] do_notify_resume+0x224/0x1330
> [ 67.899046] el0_da+0x50/0x60
> [ 67.899431] el0t_64_sync_handler+0xec/0x130
> [ 67.899726] el0t_64_sync+0x1a0/0x1a4
>
Thank you. I will look into this immediately. Was this with default
config for arm64? Was it with a vm or real hardware?
Cheers,
Liam
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] arm64: Change elfcore for_each_mte_vma() to use VMA iterator
2022-02-23 14:11 ` Liam Howlett
@ 2022-02-24 2:00 ` Liam Howlett
0 siblings, 0 replies; 17+ messages in thread
From: Liam Howlett @ 2022-02-24 2:00 UTC (permalink / raw)
To: Catalin Marinas
Cc: Will Deacon, Stephen Rothwell, Linux Kernel Mailing List,
Linux Next Mailing List, Mark Brown, Matthew Wilcox
* Liam R. Howlett <Liam.Howlett@Oracle.com> [220223 09:11]:
> * Catalin Marinas <catalin.marinas@arm.com> [220223 06:37]:
> > On Tue, Feb 22, 2022 at 06:54:38PM +0000, Liam Howlett wrote:
> > > Once the maple tree is upstream, then you can take the patch I posted.
> >
> > BTW, on the maple tree branch alone
> > (https://github.com/oracle/linux-uek.git maple/mainline), I get the
> > warning below and no core file generated. It's not MTE related as it
> > doesn't have my patches.
> >
> > [ 67.887638] WARNING: CPU: 1 PID: 528 at fs/coredump.c:1116 dump_vma_snapshot+0x98/0x18c
> > [ 67.888594] Modules linked in: crct10dif_ce sm3_ce sm3_generic sha3_ce sha3_generic sha512_ce sha512_arm64 drm fuse ip_tables x_tables ipv6
> > [ 67.890017] CPU: 1 PID: 528 Comm: mte-coredump Not tainted 5.17.0-rc4-00071-gc8cf067d6a99 #1
> > [ 67.890494] Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015
> > [ 67.891054] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> > [ 67.891469] pc : dump_vma_snapshot+0x98/0x18c
> > [ 67.891787] lr : dump_vma_snapshot+0x74/0x18c
> > [ 67.892071] sp : ffff80000839b8f0
> > [ 67.892278] x29: ffff80000839b8f0 x28: ffffd4a81d76255c x27: 0000000000000000
> > [ 67.892894] x26: ffffd4a81da308e0 x25: 0000000000000000 x24: ffff80000839bc78
> > [ 67.893436] x23: ffff00000557cf00 x22: ffff00000557cf60 x21: ffff80000839b9e0
> > [ 67.893922] x20: ffff80000839b9e8 x19: ffff80000839b9dc x18: 0000000000000000
> > [ 67.894497] x17: 0000000000000000 x16: 0000ffff9e8effff x15: 0000000000000000
> > [ 67.895061] x14: 0000000000000000 x13: ffff0000025f9000 x12: ffff000001a2eb94
> > [ 67.895590] x11: ffff80000839b100 x10: ffff80000839b108 x9 : 0000000000000000
> > [ 67.896057] x8 : ffff80000839bb68 x7 : 0000000000000000 x6 : 0000000000896101
> > [ 67.896537] x5 : ffff0000016bf000 x4 : ffff80000839b8b0 x3 : 0000000000000001
> > [ 67.896961] x2 : 0000000000000000 x1 : 0000000000000001 x0 : 0000000000000011
> > [ 67.897493] Call trace:
> > [ 67.897679] dump_vma_snapshot+0x98/0x18c
> > [ 67.898034] elf_core_dump+0x50/0xcf0
> > [ 67.898274] do_coredump+0xbdc/0xfc4
> > [ 67.898553] get_signal+0x524/0x7f0
> > [ 67.898775] do_notify_resume+0x224/0x1330
> > [ 67.899046] el0_da+0x50/0x60
> > [ 67.899431] el0t_64_sync_handler+0xec/0x130
> > [ 67.899726] el0t_64_sync+0x1a0/0x1a4
> >
>
> Thank you. I will look into this immediately. Was this with default
> config for arm64? Was it with a vm or real hardware?
I was able to reproduce it and have a fix for tomorrow.
Thanks,
Liam
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] arm64: Change elfcore for_each_mte_vma() to use VMA iterator
2022-02-18 2:37 ` [PATCH] arm64: Change elfcore for_each_mte_vma() to use VMA iterator Liam Howlett
2022-02-21 18:06 ` Catalin Marinas
@ 2022-02-25 15:50 ` Will Deacon
1 sibling, 0 replies; 17+ messages in thread
From: Will Deacon @ 2022-02-25 15:50 UTC (permalink / raw)
To: Stephen Rothwell, Liam Howlett
Cc: catalin.marinas, kernel-team, Will Deacon,
Linux Next Mailing List, Linux Kernel Mailing List
On Fri, 18 Feb 2022 02:37:04 +0000, Liam Howlett wrote:
> This is an untested fix for the merge conflict of maple tree next and
> arm64 next.
>
> Instead of using the linked list, use the vma iterator.
>
>
Applied to arm64 (for-next/coredump), thanks!
[1/1] arm64: Change elfcore for_each_mte_vma() to use VMA iterator
https://git.kernel.org/arm64/c/3a4f7ef4bed5
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] arm64: Change elfcore for_each_mte_vma() to use VMA iterator
2022-02-23 2:32 linux-next: build failure after merge of the maple tree Liam Howlett
2022-02-23 12:47 ` [PATCH] arm64: Change elfcore for_each_mte_vma() to use VMA iterator kernel test robot
@ 2022-02-23 13:08 ` kernel test robot
1 sibling, 0 replies; 17+ messages in thread
From: kernel test robot @ 2022-02-23 13:08 UTC (permalink / raw)
To: Liam Howlett, broonie
Cc: kbuild-all, Linux Kernel Mailing List, Linux Next Mailing List,
Catalin Marinas, Will Deacon
Hi Liam,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on arm64/for-next/core]
[also build test ERROR on next-20220222]
[cannot apply to linux/master linus/master v5.17-rc5]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Liam-Howlett/arm64-Change-elfcore-for_each_mte_vma-to-use-VMA-iterator/20220223-104149
base: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/core
config: arm64-randconfig-p001-20220221 (https://download.01.org/0day-ci/archive/20220223/202202232114.VBMtKcTj-lkp@intel.com/config)
compiler: aarch64-linux-gcc (GCC) 11.2.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/0day-ci/linux/commit/e416e64fe4e04c43daa48131e564c9f2f64ec333
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Liam-Howlett/arm64-Change-elfcore-for_each_mte_vma-to-use-VMA-iterator/20220223-104149
git checkout e416e64fe4e04c43daa48131e564c9f2f64ec333
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross O=build_dir ARCH=arm64 SHELL=/bin/bash
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
arch/arm64/kernel/elfcore.c: In function 'elf_core_extra_phdrs':
>> arch/arm64/kernel/elfcore.c:68:9: error: implicit declaration of function 'VMA_ITERATOR' [-Werror=implicit-function-declaration]
68 | VMA_ITERATOR(vmi, current->mm, 0);
| ^~~~~~~~~~~~
>> arch/arm64/kernel/elfcore.c:68:22: error: 'vmi' undeclared (first use in this function); did you mean 'vma'?
68 | VMA_ITERATOR(vmi, current->mm, 0);
| ^~~
| vma
arch/arm64/kernel/elfcore.c:68:22: note: each undeclared identifier is reported only once for each function it appears in
>> arch/arm64/kernel/elfcore.c:13:17: error: implicit declaration of function 'for_each_vma'; did you mean 'for_each_cpu'? [-Werror=implicit-function-declaration]
13 | for_each_vma(vmi, vma) \
| ^~~~~~~~~~~~
arch/arm64/kernel/elfcore.c:70:9: note: in expansion of macro 'for_each_mte_vma'
70 | for_each_mte_vma(vmi, vma)
| ^~~~~~~~~~~~~~~~
In file included from include/asm-generic/bug.h:5,
from arch/arm64/include/asm/bug.h:26,
from include/linux/bug.h:5,
from include/linux/mmdebug.h:5,
from include/linux/mm.h:9,
from include/linux/coredump.h:6,
from arch/arm64/kernel/elfcore.c:3:
>> include/linux/compiler.h:56:23: error: expected ';' before 'if'
56 | #define if(cond, ...) if ( __trace_if_var( !!(cond , ## __VA_ARGS__) ) )
| ^~
arch/arm64/kernel/elfcore.c:14:25: note: in expansion of macro 'if'
14 | if (vma->vm_flags & VM_MTE)
| ^~
arch/arm64/kernel/elfcore.c:70:9: note: in expansion of macro 'for_each_mte_vma'
70 | for_each_mte_vma(vmi, vma)
| ^~~~~~~~~~~~~~~~
arch/arm64/kernel/elfcore.c: In function 'elf_core_write_extra_phdrs':
arch/arm64/kernel/elfcore.c:79:22: error: 'vmi' undeclared (first use in this function); did you mean 'vma'?
79 | VMA_ITERATOR(vmi, current->mm, 0);
| ^~~
| vma
In file included from include/asm-generic/bug.h:5,
from arch/arm64/include/asm/bug.h:26,
from include/linux/bug.h:5,
from include/linux/mmdebug.h:5,
from include/linux/mm.h:9,
from include/linux/coredump.h:6,
from arch/arm64/kernel/elfcore.c:3:
>> include/linux/compiler.h:56:23: error: expected ';' before 'if'
56 | #define if(cond, ...) if ( __trace_if_var( !!(cond , ## __VA_ARGS__) ) )
| ^~
arch/arm64/kernel/elfcore.c:14:25: note: in expansion of macro 'if'
14 | if (vma->vm_flags & VM_MTE)
| ^~
arch/arm64/kernel/elfcore.c:81:9: note: in expansion of macro 'for_each_mte_vma'
81 | for_each_mte_vma(vmi, vma) {
| ^~~~~~~~~~~~~~~~
arch/arm64/kernel/elfcore.c: In function 'elf_core_extra_data_size':
arch/arm64/kernel/elfcore.c:105:22: error: 'vmi' undeclared (first use in this function); did you mean 'vma'?
105 | VMA_ITERATOR(vmi, current->mm, 0);
| ^~~
| vma
In file included from include/asm-generic/bug.h:5,
from arch/arm64/include/asm/bug.h:26,
from include/linux/bug.h:5,
from include/linux/mmdebug.h:5,
from include/linux/mm.h:9,
from include/linux/coredump.h:6,
from arch/arm64/kernel/elfcore.c:3:
>> include/linux/compiler.h:56:23: error: expected ';' before 'if'
56 | #define if(cond, ...) if ( __trace_if_var( !!(cond , ## __VA_ARGS__) ) )
| ^~
arch/arm64/kernel/elfcore.c:14:25: note: in expansion of macro 'if'
14 | if (vma->vm_flags & VM_MTE)
| ^~
arch/arm64/kernel/elfcore.c:107:9: note: in expansion of macro 'for_each_mte_vma'
107 | for_each_mte_vma(vmi, vma)
| ^~~~~~~~~~~~~~~~
arch/arm64/kernel/elfcore.c: In function 'elf_core_write_extra_data':
arch/arm64/kernel/elfcore.c:116:22: error: 'vmi' undeclared (first use in this function); did you mean 'vma'?
116 | VMA_ITERATOR(vmi, current->mm, 0);
| ^~~
| vma
In file included from include/asm-generic/bug.h:5,
from arch/arm64/include/asm/bug.h:26,
from include/linux/bug.h:5,
from include/linux/mmdebug.h:5,
from include/linux/mm.h:9,
from include/linux/coredump.h:6,
from arch/arm64/kernel/elfcore.c:3:
>> include/linux/compiler.h:56:23: error: expected ';' before 'if'
56 | #define if(cond, ...) if ( __trace_if_var( !!(cond , ## __VA_ARGS__) ) )
| ^~
arch/arm64/kernel/elfcore.c:14:25: note: in expansion of macro 'if'
14 | if (vma->vm_flags & VM_MTE)
| ^~
arch/arm64/kernel/elfcore.c:118:9: note: in expansion of macro 'for_each_mte_vma'
118 | for_each_mte_vma(vmi, vma) {
| ^~~~~~~~~~~~~~~~
arch/arm64/kernel/elfcore.c: In function 'elf_core_write_extra_phdrs':
arch/arm64/kernel/elfcore.c:99:1: error: control reaches end of non-void function [-Werror=return-type]
99 | }
| ^
arch/arm64/kernel/elfcore.c: In function 'elf_core_write_extra_data':
arch/arm64/kernel/elfcore.c:127:1: error: control reaches end of non-void function [-Werror=return-type]
127 | }
| ^
At top level:
arch/arm64/kernel/elfcore.c:25:12: warning: 'mte_dump_tag_range' defined but not used [-Wunused-function]
25 | static int mte_dump_tag_range(struct coredump_params *cprm,
| ^~~~~~~~~~~~~~~~~~
arch/arm64/kernel/elfcore.c:16:22: warning: 'mte_vma_tag_dump_size' defined but not used [-Wunused-function]
16 | static unsigned long mte_vma_tag_dump_size(struct vm_area_struct *vma)
| ^~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
vim +/VMA_ITERATOR +68 arch/arm64/kernel/elfcore.c
10
11 #define for_each_mte_vma(vmi, vma) \
12 if (system_supports_mte()) \
> 13 for_each_vma(vmi, vma) \
14 if (vma->vm_flags & VM_MTE)
15
16 static unsigned long mte_vma_tag_dump_size(struct vm_area_struct *vma)
17 {
18 if (vma->vm_flags & VM_DONTDUMP)
19 return 0;
20
21 return vma_pages(vma) * MTE_PAGE_TAG_STORAGE;
22 }
23
24 /* Derived from dump_user_range(); start/end must be page-aligned */
25 static int mte_dump_tag_range(struct coredump_params *cprm,
26 unsigned long start, unsigned long end)
27 {
28 unsigned long addr;
29
30 for (addr = start; addr < end; addr += PAGE_SIZE) {
31 char tags[MTE_PAGE_TAG_STORAGE];
32 struct page *page = get_dump_page(addr);
33
34 /*
35 * get_dump_page() returns NULL when encountering an empty
36 * page table entry that would otherwise have been filled with
37 * the zero page. Skip the equivalent tag dump which would
38 * have been all zeros.
39 */
40 if (!page) {
41 dump_skip(cprm, MTE_PAGE_TAG_STORAGE);
42 continue;
43 }
44
45 /*
46 * Pages mapped in user space as !pte_access_permitted() (e.g.
47 * PROT_EXEC only) may not have the PG_mte_tagged flag set.
48 */
49 if (!test_bit(PG_mte_tagged, &page->flags)) {
50 put_page(page);
51 dump_skip(cprm, MTE_PAGE_TAG_STORAGE);
52 continue;
53 }
54
55 mte_save_page_tags(page_address(page), tags);
56 put_page(page);
57 if (!dump_emit(cprm, tags, MTE_PAGE_TAG_STORAGE))
58 return 0;
59 }
60
61 return 1;
62 }
63
64 Elf_Half elf_core_extra_phdrs(void)
65 {
66 struct vm_area_struct *vma;
67 int vma_count = 0;
> 68 VMA_ITERATOR(vmi, current->mm, 0);
69
70 for_each_mte_vma(vmi, vma)
71 vma_count++;
72
73 return vma_count;
74 }
75
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] arm64: Change elfcore for_each_mte_vma() to use VMA iterator
2022-02-23 2:32 linux-next: build failure after merge of the maple tree Liam Howlett
@ 2022-02-23 12:47 ` kernel test robot
2022-02-23 13:08 ` kernel test robot
1 sibling, 0 replies; 17+ messages in thread
From: kernel test robot @ 2022-02-23 12:47 UTC (permalink / raw)
To: Liam Howlett, broonie
Cc: kbuild-all, Linux Kernel Mailing List, Linux Next Mailing List,
Catalin Marinas, Will Deacon
Hi Liam,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on arm64/for-next/core]
[also build test ERROR on next-20220222]
[cannot apply to linux/master linus/master v5.17-rc5]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Liam-Howlett/arm64-Change-elfcore-for_each_mte_vma-to-use-VMA-iterator/20220223-104149
base: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/core
config: arm64-randconfig-r033-20220221 (https://download.01.org/0day-ci/archive/20220223/202202231935.aUY0YIgf-lkp@intel.com/config)
compiler: aarch64-linux-gcc (GCC) 11.2.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/0day-ci/linux/commit/e416e64fe4e04c43daa48131e564c9f2f64ec333
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Liam-Howlett/arm64-Change-elfcore-for_each_mte_vma-to-use-VMA-iterator/20220223-104149
git checkout e416e64fe4e04c43daa48131e564c9f2f64ec333
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross O=build_dir ARCH=arm64 SHELL=/bin/bash
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
arch/arm64/kernel/elfcore.c: In function 'elf_core_extra_phdrs':
arch/arm64/kernel/elfcore.c:68:9: error: implicit declaration of function 'VMA_ITERATOR' [-Werror=implicit-function-declaration]
68 | VMA_ITERATOR(vmi, current->mm, 0);
| ^~~~~~~~~~~~
arch/arm64/kernel/elfcore.c:68:22: error: 'vmi' undeclared (first use in this function); did you mean 'vma'?
68 | VMA_ITERATOR(vmi, current->mm, 0);
| ^~~
| vma
arch/arm64/kernel/elfcore.c:68:22: note: each undeclared identifier is reported only once for each function it appears in
arch/arm64/kernel/elfcore.c:13:17: error: implicit declaration of function 'for_each_vma'; did you mean 'for_each_cpu'? [-Werror=implicit-function-declaration]
13 | for_each_vma(vmi, vma) \
| ^~~~~~~~~~~~
arch/arm64/kernel/elfcore.c:70:9: note: in expansion of macro 'for_each_mte_vma'
70 | for_each_mte_vma(vmi, vma)
| ^~~~~~~~~~~~~~~~
>> arch/arm64/kernel/elfcore.c:14:25: error: expected ';' before 'if'
14 | if (vma->vm_flags & VM_MTE)
| ^~
arch/arm64/kernel/elfcore.c:70:9: note: in expansion of macro 'for_each_mte_vma'
70 | for_each_mte_vma(vmi, vma)
| ^~~~~~~~~~~~~~~~
arch/arm64/kernel/elfcore.c: In function 'elf_core_write_extra_phdrs':
arch/arm64/kernel/elfcore.c:79:22: error: 'vmi' undeclared (first use in this function); did you mean 'vma'?
79 | VMA_ITERATOR(vmi, current->mm, 0);
| ^~~
| vma
>> arch/arm64/kernel/elfcore.c:14:25: error: expected ';' before 'if'
14 | if (vma->vm_flags & VM_MTE)
| ^~
arch/arm64/kernel/elfcore.c:81:9: note: in expansion of macro 'for_each_mte_vma'
81 | for_each_mte_vma(vmi, vma) {
| ^~~~~~~~~~~~~~~~
arch/arm64/kernel/elfcore.c: In function 'elf_core_extra_data_size':
arch/arm64/kernel/elfcore.c:105:22: error: 'vmi' undeclared (first use in this function); did you mean 'vma'?
105 | VMA_ITERATOR(vmi, current->mm, 0);
| ^~~
| vma
>> arch/arm64/kernel/elfcore.c:14:25: error: expected ';' before 'if'
14 | if (vma->vm_flags & VM_MTE)
| ^~
arch/arm64/kernel/elfcore.c:107:9: note: in expansion of macro 'for_each_mte_vma'
107 | for_each_mte_vma(vmi, vma)
| ^~~~~~~~~~~~~~~~
arch/arm64/kernel/elfcore.c: In function 'elf_core_write_extra_data':
arch/arm64/kernel/elfcore.c:116:22: error: 'vmi' undeclared (first use in this function); did you mean 'vma'?
116 | VMA_ITERATOR(vmi, current->mm, 0);
| ^~~
| vma
>> arch/arm64/kernel/elfcore.c:14:25: error: expected ';' before 'if'
14 | if (vma->vm_flags & VM_MTE)
| ^~
arch/arm64/kernel/elfcore.c:118:9: note: in expansion of macro 'for_each_mte_vma'
118 | for_each_mte_vma(vmi, vma) {
| ^~~~~~~~~~~~~~~~
arch/arm64/kernel/elfcore.c: In function 'elf_core_write_extra_phdrs':
arch/arm64/kernel/elfcore.c:99:1: error: control reaches end of non-void function [-Werror=return-type]
99 | }
| ^
arch/arm64/kernel/elfcore.c: In function 'elf_core_write_extra_data':
arch/arm64/kernel/elfcore.c:127:1: error: control reaches end of non-void function [-Werror=return-type]
127 | }
| ^
At top level:
arch/arm64/kernel/elfcore.c:25:12: warning: 'mte_dump_tag_range' defined but not used [-Wunused-function]
25 | static int mte_dump_tag_range(struct coredump_params *cprm,
| ^~~~~~~~~~~~~~~~~~
arch/arm64/kernel/elfcore.c:16:22: warning: 'mte_vma_tag_dump_size' defined but not used [-Wunused-function]
16 | static unsigned long mte_vma_tag_dump_size(struct vm_area_struct *vma)
| ^~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
vim +14 arch/arm64/kernel/elfcore.c
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 10
e416e64fe4e04c Liam Howlett 2022-02-23 11 #define for_each_mte_vma(vmi, vma) \
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 12 if (system_supports_mte()) \
e416e64fe4e04c Liam Howlett 2022-02-23 13 for_each_vma(vmi, vma) \
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 @14 if (vma->vm_flags & VM_MTE)
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 15
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 16 static unsigned long mte_vma_tag_dump_size(struct vm_area_struct *vma)
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 17 {
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 18 if (vma->vm_flags & VM_DONTDUMP)
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 19 return 0;
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 20
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 21 return vma_pages(vma) * MTE_PAGE_TAG_STORAGE;
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 22 }
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 23
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 24 /* Derived from dump_user_range(); start/end must be page-aligned */
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 25 static int mte_dump_tag_range(struct coredump_params *cprm,
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 26 unsigned long start, unsigned long end)
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 27 {
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 28 unsigned long addr;
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 29
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 30 for (addr = start; addr < end; addr += PAGE_SIZE) {
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 31 char tags[MTE_PAGE_TAG_STORAGE];
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 32 struct page *page = get_dump_page(addr);
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 33
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 34 /*
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 35 * get_dump_page() returns NULL when encountering an empty
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 36 * page table entry that would otherwise have been filled with
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 37 * the zero page. Skip the equivalent tag dump which would
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 38 * have been all zeros.
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 39 */
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 40 if (!page) {
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 41 dump_skip(cprm, MTE_PAGE_TAG_STORAGE);
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 42 continue;
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 43 }
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 44
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 45 /*
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 46 * Pages mapped in user space as !pte_access_permitted() (e.g.
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 47 * PROT_EXEC only) may not have the PG_mte_tagged flag set.
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 48 */
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 49 if (!test_bit(PG_mte_tagged, &page->flags)) {
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 50 put_page(page);
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 51 dump_skip(cprm, MTE_PAGE_TAG_STORAGE);
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 52 continue;
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 53 }
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 54
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 55 mte_save_page_tags(page_address(page), tags);
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 56 put_page(page);
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 57 if (!dump_emit(cprm, tags, MTE_PAGE_TAG_STORAGE))
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 58 return 0;
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 59 }
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 60
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 61 return 1;
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 62 }
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 63
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 64 Elf_Half elf_core_extra_phdrs(void)
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 65 {
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 66 struct vm_area_struct *vma;
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 67 int vma_count = 0;
e416e64fe4e04c Liam Howlett 2022-02-23 @68 VMA_ITERATOR(vmi, current->mm, 0);
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 69
e416e64fe4e04c Liam Howlett 2022-02-23 70 for_each_mte_vma(vmi, vma)
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 71 vma_count++;
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 72
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 73 return vma_count;
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 74 }
6dd8b1a0b6cb3e Catalin Marinas 2022-01-31 75
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2022-02-25 15:50 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-02-17 8:18 linux-next: build failure after merge of the maple tree Stephen Rothwell
2022-02-17 19:24 ` Will Deacon
2022-02-18 1:46 ` Liam Howlett
2022-02-18 2:37 ` [PATCH] arm64: Change elfcore for_each_mte_vma() to use VMA iterator Liam Howlett
2022-02-21 18:06 ` Catalin Marinas
2022-02-22 14:26 ` Liam Howlett
2022-02-22 16:20 ` Will Deacon
2022-02-22 17:26 ` Catalin Marinas
2022-02-22 18:54 ` Liam Howlett
2022-02-23 9:39 ` Catalin Marinas
2022-02-23 13:57 ` Liam Howlett
2022-02-23 11:37 ` Catalin Marinas
2022-02-23 14:11 ` Liam Howlett
2022-02-24 2:00 ` Liam Howlett
2022-02-25 15:50 ` Will Deacon
2022-02-23 2:32 linux-next: build failure after merge of the maple tree Liam Howlett
2022-02-23 12:47 ` [PATCH] arm64: Change elfcore for_each_mte_vma() to use VMA iterator kernel test robot
2022-02-23 13:08 ` kernel test robot
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.