public inbox for linux-next@vger.kernel.org
 help / color / mirror / Atom feed
From: Will Deacon <will@kernel.org>
To: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	"Liam R. Howlett" <Liam.Howlett@oracle.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Next Mailing List <linux-next@vger.kernel.org>,
	catalin.marinas@arm.com
Subject: Re: linux-next: manual merge of the mm tree with Linus' tree
Date: Mon, 19 Jun 2023 21:43:11 +0100	[thread overview]
Message-ID: <20230619204309.GA13937@willie-the-truck> (raw)
In-Reply-To: <20230619092355.133c5cdb@canb.auug.org.au>

Hi Stephen,

On Mon, Jun 19, 2023 at 09:23:55AM +1000, Stephen Rothwell wrote:
> Today's linux-next merge of the mm tree got a conflict in:
> 
>   mm/mmap.c
> 
> between commit:
> 
>   606c812eb1d5 ("mm/mmap: Fix error path in do_vmi_align_munmap()")
> 
> from the origin tree and commits:
> 
>   66106c364147 ("mm: change do_vmi_align_munmap() side tree index")
>   47b1d8de18f5 ("mm/mmap: change vma iteration order in do_vmi_align_munmap()")
> 
> from the mm tree.
> 
> I fixed it up (I think - see below) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging.  You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc mm/mmap.c
> index 98cda6f72605,474a0d856622..000000000000
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@@ -2398,15 -2409,27 +2396,29 @@@ do_vmi_align_munmap(struct vma_iterato
>   			if (error)
>   				goto end_split_failed;
>   		}
>  -		mas_set(&mas_detach, count);
>  -		error = munmap_sidetree(next, &mas_detach);
>  -		if (error)
>  -			goto munmap_sidetree_failed;
>  +		vma_start_write(next);
> - 		mas_set_range(&mas_detach, next->vm_start, next->vm_end - 1);
>  +		if (mas_store_gfp(&mas_detach, next, GFP_KERNEL))
>  +			goto munmap_gather_failed;
>  +		vma_mark_detached(next, true);
>  +		if (next->vm_flags & VM_LOCKED)
>  +			locked_vm += vma_pages(next);
>   
>   		count++;
> + 		if (unlikely(uf)) {
> + 			/*
> + 			 * If userfaultfd_unmap_prep returns an error the vmas
> + 			 * will remain split, but userland will get a
> + 			 * highly unexpected error anyway. This is no
> + 			 * different than the case where the first of the two
> + 			 * __split_vma fails, but we don't undo the first
> + 			 * split, despite we could. This is unlikely enough
> + 			 * failure that it's not worth optimizing it for.
> + 			 */
> + 			error = userfaultfd_unmap_prep(next, start, end, uf);
> + 
> + 			if (error)
> + 				goto userfaultfd_error;
> + 		}
>   #ifdef CONFIG_DEBUG_VM_MAPLE_TREE
>   		BUG_ON(next->vm_start < start);
>   		BUG_ON(next->vm_start > end);
> @@@ -2454,14 -2455,18 +2444,20 @@@
>   		BUG_ON(count != test_count);
>   	}
>   #endif
> - 	/* Point of no return */
>  +	error = -ENOMEM;
> - 	vma_iter_set(vmi, start);
> + 	while (vma_iter_addr(vmi) > start)
> + 		vma_iter_prev_range(vmi);
> + 
>   	if (vma_iter_clear_gfp(vmi, start, end, GFP_KERNEL))
>  -		return -ENOMEM;
>  +		goto clear_tree_failed;
>   
>  +	mm->locked_vm -= locked_vm;
>   	mm->map_count -= count;
> + 	prev = vma_iter_prev_range(vmi);
> + 	next = vma_next(vmi);
> + 	if (next)
> + 		vma_iter_prev_range(vmi);
> + 
>   	/*
>   	 * Do not downgrade mmap_lock if we are next to VM_GROWSDOWN or
>   	 * VM_GROWSUP VMA. Such VMAs can change their size under

This resolution seems to be causing horrible problems on arm64 with 16k
pages. I see things like the crash below, but the two branches being merged
are fine on their own.

Will

--->8

[ 1353.914809] BUG: Bad rss-counter state mm:fffffff001065580 type:MM_ANONPAGES val:4
[ 1354.145486] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
[ 1354.146465] Mem abort info:
[ 1354.146894]   ESR = 0x0000000096000006
[ 1354.148049]   EC = 0x25: DABT (current EL), IL = 32 bits
[ 1354.148754]   SET = 0, FnV = 0
[ 1354.149030]   EA = 0, S1PTW = 0
[ 1354.149429]   FSC = 0x06: level 2 translation fault
[ 1354.149948] Data abort info:
[ 1354.150278]   ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000
[ 1354.150822]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 1354.151725]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 1354.152293] user pgtable: 16k pages, 36-bit VAs, pgdp=0000000045928000
[ 1354.152882] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000, pmd=0000000000000000
[ 1354.155005] Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP
[ 1354.156871] Modules linked in:
[ 1354.158072] CPU: 3 PID: 289 Comm: (sd-pam) Not tainted 6.4.0-rc7-next-20230619 #1
[ 1354.160463] Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015
[ 1354.161566] pstate: 63400009 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)
[ 1354.162179] pc : __rb_erase_color+0xb8/0x24c
[ 1354.164370] lr : vma_interval_tree_remove+0x2b4/0x2c8
[ 1354.165267] sp : fffffff880b13940
[ 1354.165648] x29: fffffff880b13940 x28: fffffff001b81c30 x27: 0000000000000001
[ 1354.166570] x26: fffffff001b81760 x25: 0000000f9c000000 x24: ffffffffffffffff
[ 1354.167722] x23: fffffff880b13a98 x22: 0000000000000000 x21: fffffff002d57068
[ 1354.168422] x20: fffffff00450fc10 x19: fffffffe1c02f098 x18: fffffff000705f41
[ 1354.170661] x17: fffffff001947600 x16: 0000000000000003 x15: 0000000000000001
[ 1354.171717] x14: fffffffe1d7de5d8 x13: fffffff00450fc18 x12: 0000000000000000
[ 1354.172636] x11: 000000000000000a x10: 000000000000000a x9 : 000000000000000a
[ 1354.173118] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000
[ 1354.173555] x5 : 00000000810000dd x4 : fffffffff004ede0 x3 : 00000000810000dd
[ 1354.174061] x2 : fffffffe1c02f098 x1 : fffffff002d57068 x0 : fffffff00450fc10
[ 1354.174684] Call trace:
[ 1354.175325]  __rb_erase_color+0xb8/0x24c
[ 1354.176114]  vma_interval_tree_remove+0x2b4/0x2c8
[ 1354.176558]  unlink_file_vma+0x54/0x94
[ 1354.176822]  free_pgtables+0xe4/0x1ac
[ 1354.177181]  exit_mmap+0x164/0x288
[ 1354.177473]  __mmput+0x40/0x140
[ 1354.177667]  mmput+0x28/0x60
[ 1354.177977]  exit_mm+0x94/0xd4
[ 1354.178362]  do_exit+0x238/0x83c
[ 1354.179301]  do_group_exit+0x70/0x98
[ 1354.179773]  get_signal+0x67c/0x708
[ 1354.180092]  do_notify_resume+0x150/0x1350
[ 1354.180597]  el0_interrupt+0x80/0x150
[ 1354.181068]  __el0_irq_handler_common+0x18/0x24
[ 1354.181438]  el0t_64_irq_handler+0x10/0x1c
[ 1354.181788]  el0t_64_irq+0x190/0x194
[ 1354.182908] Code: 394002e8 37000428 1400002c f9400a96 (394002c8) 
[ 1354.184629] ---[ end trace 0000000000000000 ]---


  parent reply	other threads:[~2023-06-19 20:43 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-18 23:23 linux-next: manual merge of the mm tree with Linus' tree Stephen Rothwell
2023-06-19 20:25 ` Andrew Morton
2023-06-19 20:43 ` Will Deacon [this message]
2023-06-19 21:39   ` Andrew Morton
2023-06-20  9:43     ` Will Deacon
2023-06-20 15:00       ` Jain, Ayush
  -- strict thread matches above, loose matches on Subject: below --
2025-02-09 22:39 Stephen Rothwell
2024-09-29 23:56 Stephen Rothwell
2024-09-30  6:01 ` Miguel Ojeda
2024-09-16 23:27 Stephen Rothwell
2024-09-17 23:40 ` Stephen Rothwell
2024-09-09  0:00 Stephen Rothwell
2024-09-09  1:53 ` Huang, Ying
2024-09-17 23:36 ` Stephen Rothwell
2024-07-28 22:41 Stephen Rothwell
2024-07-28 22:45 ` Stephen Rothwell
2024-07-28 23:31   ` Andrew Morton
2024-05-09 23:22 Stephen Rothwell
2023-07-27 23:18 Stephen Rothwell
2023-07-27 23:29 ` Stephen Rothwell
2023-07-27 23:40   ` Suren Baghdasaryan
2023-07-27 23:50     ` Matthew Wilcox
2023-07-28  0:08       ` Suren Baghdasaryan
2023-07-28  0:00   ` Stephen Rothwell
2023-07-28  3:13     ` Matthew Wilcox
2023-07-27 23:49 ` Matthew Wilcox
2023-07-28  0:21   ` Stephen Rothwell
2023-07-28  0:23     ` Suren Baghdasaryan
2023-07-28  0:29       ` Stephen Rothwell
2023-07-28  0:30         ` Suren Baghdasaryan
2023-07-06 22:54 Stephen Rothwell
2023-07-07  4:52 ` Baoquan He
2023-02-24 23:39 Stephen Rothwell
2023-02-25  2:04 ` Andrew Morton
2023-02-25  7:13   ` Christian Brauner
2023-02-25 20:52     ` Andrew Morton
2023-02-27 10:18       ` Christian Brauner
2023-02-27 17:55         ` Andrew Morton
2022-11-07  2:52 Stephen Rothwell
2022-09-06  9:01 Stephen Rothwell
2022-09-06  9:21 ` Rolf Eike Beer
2022-05-26  6:09 Stephen Rothwell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230619204309.GA13937@willie-the-truck \
    --to=will@kernel.org \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=catalin.marinas@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=sfr@canb.auug.org.au \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox