Skip to contentSkip to conversation

FAILED: patch "[PATCH] mm: use vma_init() to initialize VMAs on stack and data" failed to apply to 4.17-stable tree

PATCH [email protected] 3 participants 4 messages Jul 28, 2018 – Jul 30, 2018

Subsystems (12)
Stable branch Memory management Arm (32-bit) x86 +8 more subsystems
lore
Share & tools
lore

[email protected]

author maintainer
#0 lore raw

The patch below does not apply to the 4.17-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.

thanks,

greg k-h

------------------ original commit in Linus's tree ------------------

Quoted 1 line

From 2c4541e24c55e2847bede93e33d749280edd429a Mon Sep 17 00:00:00 2001

From: "Kirill A. Shutemov" <[email protected]>
Date: Thu, 26 Jul 2018 16:37:30 -0700
Subject: [PATCH] mm: use vma_init() to initialize VMAs on stack and data
segments

Make sure to initialize all VMAs properly, not only those which come from vm_area_cachep.

Link http://lkml.kernel.org/r/[email protected] open here
Signed-off-by Kirill A. Shutemov <[email protected]>
Acked-by Linus Torvalds <[email protected]>
Reviewed-by Andrew Morton <[email protected]>
Cc Dmitry Vyukov <[email protected]>
Cc Oleg Nesterov <[email protected]>
Cc Andrea Arcangeli <[email protected]>
Cc <[email protected]>
Signed-off-by Andrew Morton <[email protected]>
Signed-off-by Linus Torvalds <[email protected]>
arch/arm/kernel/process.c +1 -0
index 225d1c58d2de..d9c299133111 100644
@@ -338,6 +338,7 @@ static struct vm_area_struct gate_vma = {
 
 static int __init gate_vma_init(void)
 {
+	vma_init(&gate_vma, NULL);
 	gate_vma.vm_page_prot = PAGE_READONLY_EXEC;
 	return 0;
 }
arch/arm/mach-rpc/ecard.c +1 -1
index 39aef4876ed4..8db62cc54a6a 100644
@@ -237,8 +237,8 @@ static void ecard_init_pgtables(struct mm_struct *mm)
 
 	memcpy(dst_pgd, src_pgd, sizeof(pgd_t) * (EASI_SIZE / PGDIR_SIZE));
 
+	vma_init(&vma, mm);
 	vma.vm_flags = VM_EXEC;
-	vma.vm_mm = mm;
 
 	flush_tlb_range(&vma, IO_START, IO_START + IO_SIZE);
 	flush_tlb_range(&vma, EASI_START, EASI_START + EASI_SIZE);
arch/arm64/include/asm/tlb.h +3 -1
index ffdaea7954bb..d87f2d646caa 100644
@@ -37,7 +37,9 @@ static inline void __tlb_remove_table(void *_table)
 
 static inline void tlb_flush(struct mmu_gather *tlb)
 {
-	struct vm_area_struct vma = { .vm_mm = tlb->mm, };
+	struct vm_area_struct vma;
+
+	vma_init(&vma, tlb->mm);
 
 	/*
 	 * The ASID allocator will either invalidate the ASID or mark
arch/arm64/mm/hugetlbpage.c +5 -2
index ecc6818191df..1854e49aa18a 100644
@@ -108,11 +108,13 @@ static pte_t get_clear_flush(struct mm_struct *mm,
 			     unsigned long pgsize,
 			     unsigned long ncontig)
 {
-	struct vm_area_struct vma = { .vm_mm = mm };
+	struct vm_area_struct vma;
 	pte_t orig_pte = huge_ptep_get(ptep);
 	bool valid = pte_valid(orig_pte);
 	unsigned long i, saddr = addr;
 
+	vma_init(&vma, mm);
+
 	for (i = 0; i < ncontig; i++, addr += pgsize, ptep++) {
 		pte_t pte = ptep_get_and_clear(mm, addr, ptep);
 

@@ -145,9 +147,10 @@ static void clear_flush(struct mm_struct *mm,
 			     unsigned long pgsize,
 			     unsigned long ncontig)
 {
-	struct vm_area_struct vma = { .vm_mm = mm };
+	struct vm_area_struct vma;
 	unsigned long i, saddr = addr;
 
+	vma_init(&vma, mm);
 	for (i = 0; i < ncontig; i++, addr += pgsize, ptep++)
 		pte_clear(mm, addr, ptep);
arch/ia64/include/asm/tlb.h +1 -1
index 44f0ac0df308..db89e7306081 100644
@@ -120,7 +120,7 @@ ia64_tlb_flush_mmu_tlbonly(struct mmu_gather *tlb, unsigned long start, unsigned
 		 */
 		struct vm_area_struct vma;
 
-		vma.vm_mm = tlb->mm;
+		vma_init(&vma, tlb->mm);
 		/* flush the address range from the tlb: */
 		flush_tlb_range(&vma, start, end);
 		/* now flush the virt. page-table area mapping the address range: */
arch/ia64/mm/init.c +1 -1
index bdb14a369137..e6c6dfd98de2 100644
@@ -273,7 +273,7 @@ static struct vm_area_struct gate_vma;
 
 static int __init gate_vma_init(void)
 {
-	gate_vma.vm_mm = NULL;
+	vma_init(&gate_vma, NULL);
 	gate_vma.vm_start = FIXADDR_USER_START;
 	gate_vma.vm_end = FIXADDR_USER_END;
 	gate_vma.vm_flags = VM_READ | VM_MAYREAD | VM_EXEC | VM_MAYEXEC;
arch/x86/um/mem_32.c +1 -1
index 744afdc18cf3..56c44d865f7b 100644
@@ -16,7 +16,7 @@ static int __init gate_vma_init(void)
 	if (!FIXADDR_USER_START)
 		return 0;
 
-	gate_vma.vm_mm = NULL;
+	vma_init(&gate_vma, NULL);
 	gate_vma.vm_start = FIXADDR_USER_START;
 	gate_vma.vm_end = FIXADDR_USER_END;
 	gate_vma.vm_flags = VM_READ | VM_MAYREAD | VM_EXEC | VM_MAYEXEC;
fs/hugetlbfs/inode.c +2 -0
index d508c7844681..40d4c66c7751 100644
@@ -411,6 +411,7 @@ static void remove_inode_hugepages(struct inode *inode, loff_t lstart,
 	bool truncate_op = (lend == LLONG_MAX);
 
 	memset(&pseudo_vma, 0, sizeof(struct vm_area_struct));
+	vma_init(&pseudo_vma, current->mm);
 	pseudo_vma.vm_flags = (VM_HUGETLB | VM_MAYSHARE | VM_SHARED);
 	pagevec_init(&pvec);
 	next = start;

@@ -595,6 +596,7 @@ static long hugetlbfs_fallocate(struct file *file, int mode, loff_t offset,
 	 * as input to create an allocation policy.
 	 */
 	memset(&pseudo_vma, 0, sizeof(struct vm_area_struct));
+	vma_init(&pseudo_vma, mm);
 	pseudo_vma.vm_flags = (VM_HUGETLB | VM_MAYSHARE | VM_SHARED);
 	pseudo_vma.vm_file = file;
mm/mempolicy.c +1 -0
index 9ac49ef17b4e..01f1a14facc4 100644
@@ -2505,6 +2505,7 @@ void mpol_shared_policy_init(struct shared_policy *sp, struct mempolicy *mpol)
 
 		/* Create pseudo-vma that contains just the policy */
 		memset(&pvma, 0, sizeof(struct vm_area_struct));
+		vma_init(&pvma, NULL);
 		pvma.vm_end = TASK_SIZE;	/* policy covers entire file */
 		mpol_set_shared_policy(sp, &pvma, new); /* adds ref */
mm/shmem.c +1 -0
index 2cab84403055..41b9bbf24e16 100644
@@ -1421,6 +1421,7 @@ static void shmem_pseudo_vma_init(struct vm_area_struct *vma,
 {
 	/* Create a pseudo vma that just contains the policy */
 	memset(vma, 0, sizeof(*vma));
+	vma_init(vma, NULL);
 	/* Bias interleave by inode number to distribute better across nodes */
 	vma->vm_pgoff = index + info->vfs_inode.i_ino;
 	vma->vm_policy = mpol_shared_policy_lookup(&info->policy, index);
#1 lore raw
Quoted 2 lines · On Sat, Jul 28, 2018 at 1:00 AM <[email protected]> wrote:

The patch below does not apply to the 4.17-stable tree.

I suspect these three patches from Kirill just need these three preparatory cleanup patches applied first:

490fc053865c mm: make vm_area_alloc() initialize core fields 95faf6992df4 mm: make vm_area_dup() actually copy the old vma data 3928d4f5ee37 mm: use helper functions for allocating and freeing
vm_area structs

they weren't marked for stable, because they didn't actually change any semantics (and I thought Kirill's patches would be delayed to the next merge window).

Linus

author maintainer
#2 lore raw
Quoted 7 lines · Linus Torvalds
Quoted 2 lines · On Sat, Jul 28, 2018 at 1:00 AM <[email protected]> wrote:

The patch below does not apply to the 4.17-stable tree.

I suspect these three patches from Kirill just need these three preparatory cleanup patches applied first:

Quoted 8 lines

490fc053865c mm: make vm_area_alloc() initialize core fields 95faf6992df4 mm: make vm_area_dup() actually copy the old vma data 3928d4f5ee37 mm: use helper functions for allocating and freeing
vm_area structs

they weren't marked for stable, because they didn't actually change any semantics (and I thought Kirill's patches would be delayed to the next merge window).

Ok, so are these even needed now? Kirill, if they are, how far back should they go to?

thanks,

greg k-h

#3 lore raw
Quoted 13 lines · Greg Kroah-Hartman
Quoted 12 lines · Linus Torvalds
Quoted 2 lines · On Sat, Jul 28, 2018 at 1:00 AM <[email protected]> wrote:

The patch below does not apply to the 4.17-stable tree.

I suspect these three patches from Kirill just need these three preparatory cleanup patches applied first:

490fc053865c mm: make vm_area_alloc() initialize core fields 95faf6992df4 mm: make vm_area_dup() actually copy the old vma data 3928d4f5ee37 mm: use helper functions for allocating and freeing
vm_area structs

Quoted 5 lines
Quoted 3 lines

they weren't marked for stable, because they didn't actually change any semantics (and I thought Kirill's patches would be delayed to the next merge window).

Ok, so are these even needed now?

Yes, I think so.

But please postpone it for now. There's regression report on android.

Quoted 1 line

Kirill, if they are, how far back should they go to?

Looks like the problem was there forever. Even before vma_is_anonymous() was introduced.

Signature · 1 line
 Kirill A. Shutemov