All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lorenzo Stoakes <lstoakes@gmail.com>
To: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	David Hildenbrand <david@redhat.com>,
	Matthew Wilcox <willy@infradead.org>,
	Vlastimil Babka <vbabka@suse.cz>,
	"Liam R . Howlett" <Liam.Howlett@oracle.com>,
	maple-tree@lists.infradead.org, Vernon Yang <vernon2gm@gmail.com>
Subject: Re: [PATCH v2 3/4] mm/mmap/vma_merge: extend invariants, avoid invalid res, vma
Date: Thu, 23 Mar 2023 17:08:19 +0000	[thread overview]
Message-ID: <5f88b7f9-d9f9-44ef-9a74-b338d0ba9895@lucifer.local> (raw)
In-Reply-To: <a5d567b6-a067-c3e2-e500-e459cf47851f@samsung.com>

On Thu, Mar 23, 2023 at 06:00:45PM +0100, Marek Szyprowski wrote:
> On 21.03.2023 21:45, Lorenzo Stoakes wrote:
> > Previously, vma was an uninitialised variable which was only definitely
> > assigned as a result of the logic covering all possible input cases - for
> > it to have remained uninitialised, prev would have to be NULL, and next
> > would _have_ to be mergeable.
> >
> > We now reuse vma to assign curr and next, so to be absolutely explicit,
> > ensure this variable is _always_ assigned, and while we're at it remove the
> > redundant assignment of both res and vma (if prev is NULL then we simply
> > assign to NULL).
> >
> > In addition, we absolutely do rely on addr == curr->vm_start should curr
> > exist, so assert as much.
> >
> > Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com>
>
> This patch has been merged into today's linux next-20230323 as commit
> 6426bbcc76be ("mm/mmap/vma_merge: extend invariants, avoid invalid res,
> vma").
>
> Unfortunately it breaks booting of some ARM 32bit machines, like Samsung
> Exynos5422-based Odroid XU3 board. This shortened log shows the issue:

I'm very sorry about this. This was due to a bug with uninitiased
state. This was fixed in v3 of this series, which is now at v5 [1]. This
has already been taken to mm-unstable in Andrew's repo, hopefully it will
be taken to -next soon!

I have made sure to reply quickly whenever this is raised to ensure people
are aware, and I will also buy anybody affected a pint if I meet them in
person :)

[1]:https://lore.kernel.org/all/over.1679516210.git.lstoakes@gmail.com/

>
> Run /sbin/init as init process
>    with arguments:
>      /sbin/init
>    with environment:
>      HOME=/
>      TERM=linux
> 8<--- cut here ---
> Unhandled fault: page domain fault (0x01b) at 0xb6f03010
> [b6f03010] *pgd=b5e84835
> Internal error: : 1b [#1] PREEMPT SMP ARM
> Modules linked in:
> CPU: 2 PID: 1 Comm: init Not tainted 6.3.0-rc1-00296-g6426bbcc76be #6445
> Hardware name: Samsung Exynos (Flattened Device Tree)
> PC is at vma_merge+0xa0/0x728
> LR is at vma_merge+0x294/0x728
> pc : [<c02b08a8>]    lr : [<c02b0a9c>]    psr: a0000013
> ...
> Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
> Control: 10c5387d  Table: 4f11406a  DAC: 00000051
> ...
> Process init (pid: 1, stack limit = 0x5219a5c7)
> Stack: (0xf0835e30 to 0xf0836000)
> ...
>   vma_merge from mprotect_fixup+0xc8/0x290
>   mprotect_fixup from do_mprotect_pkey.constprop.0+0x210/0x338
>   do_mprotect_pkey.constprop.0 from ret_fast_syscall+0x0/0x1c
> Exception stack(0xf0835fa8 to 0xf0835ff0)
> ...
> ---[ end trace 0000000000000000 ]---
> note: init[1] exited with irqs disabled
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
>
> Reverting it on top of linux-next, together with 183b2bced4c9
> ("mm/mmap/vma_merge: init cleanup, be explicit about the non-mergeable
> case"), which depends on this patch, fixes the boot issue.
>
>
> > ---
> >   mm/mmap.c | 19 ++++++++++++++-----
> >   1 file changed, 14 insertions(+), 5 deletions(-)
> >
> > diff --git a/mm/mmap.c b/mm/mmap.c
> > index 6361baf75601..7aec49c3bc74 100644
> > --- a/mm/mmap.c
> > +++ b/mm/mmap.c
> > @@ -911,7 +911,7 @@ struct vm_area_struct *vma_merge(struct vma_iterator *vmi, struct mm_struct *mm,
> >   {
> >   	pgoff_t pglen = (end - addr) >> PAGE_SHIFT;
> >   	pgoff_t vma_pgoff;
> > -	struct vm_area_struct *curr, *next, *res = NULL;
> > +	struct vm_area_struct *curr, *next, *res;
> >   	struct vm_area_struct *vma, *adjust, *remove, *remove2;
> >   	int err = -1;
> >   	bool merge_prev = false;
> > @@ -940,14 +940,18 @@ struct vm_area_struct *vma_merge(struct vma_iterator *vmi, struct mm_struct *mm,
> >   		/* Is there a VMA next to a hole (case 1 - 3) or prev (4)? */
> >   		next = vma_lookup(mm, end);
> >
> > -	/* verify some invariant that must be enforced by the caller */
> > +	/*
> > +	 * By default, we return prev. Cases 3, 4, 8 will instead return next
> > +	 * and cases 3, 8 will also update vma to point at next.
> > +	 */
> > +	res = vma = prev;
> > +
> > +	/* Verify some invariant that must be enforced by the caller. */
> >   	VM_WARN_ON(prev && addr <= prev->vm_start);
> > -	VM_WARN_ON(curr && end > curr->vm_end);
> > +	VM_WARN_ON(curr && (addr != curr->vm_start || end > curr->vm_end));
> >   	VM_WARN_ON(addr >= end);
> >
> >   	if (prev) {
> > -		res = prev;
> > -		vma = prev;
> >   		vma_start = prev->vm_start;
> >   		vma_pgoff = prev->vm_pgoff;
> >   		/* Can we merge the predecessor? */
> > @@ -958,6 +962,7 @@ struct vm_area_struct *vma_merge(struct vma_iterator *vmi, struct mm_struct *mm,
> >   			vma_prev(vmi);
> >   		}
> >   	}
> > +
> >   	/* Can we merge the successor? */
> >   	if (next && mpol_equal(policy, vma_policy(next)) &&
> >   	    can_vma_merge_before(next, vm_flags,
> > @@ -998,6 +1003,10 @@ struct vm_area_struct *vma_merge(struct vma_iterator *vmi, struct mm_struct *mm,
> >   			adj_start = -(prev->vm_end - addr);
> >   			err = dup_anon_vma(next, prev);
> >   		} else {
> > +			/*
> > +			 * Note that cases 3 and 8 are the ONLY ones where prev
> > +			 * is permitted to be (but is not necessarily) NULL.
> > +			 */
> >   			vma = next;			/* case 3 */
> >   			vma_start = addr;
> >   			vma_end = next->vm_end;
>
> Best regards
> --
> Marek Szyprowski, PhD
> Samsung R&D Institute Poland
>

  reply	other threads:[~2023-03-23 17:08 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-21 20:45 [PATCH v2 0/4] further cleanup of vma_merge() Lorenzo Stoakes
2023-03-21 20:45 ` [PATCH v2 1/4] mm/mmap/vma_merge: further improve prev/next VMA naming Lorenzo Stoakes
2023-03-21 20:45 ` [PATCH v2 2/4] mm/mmap/vma_merge: set next to NULL if not applicable Lorenzo Stoakes
2023-03-22  1:42   ` Liam R. Howlett
2023-03-22  6:23     ` Lorenzo Stoakes
2023-03-21 20:45 ` [PATCH v2 3/4] mm/mmap/vma_merge: extend invariants, avoid invalid res, vma Lorenzo Stoakes
2023-03-22  9:16   ` Vlastimil Babka
     [not found]   ` <CGME20230323170046eucas1p2483ab0fcc3d6bc56d4b6d09143bbadda@eucas1p2.samsung.com>
2023-03-23 17:00     ` Marek Szyprowski
2023-03-23 17:08       ` Lorenzo Stoakes [this message]
2023-03-23 17:10         ` Lorenzo Stoakes
2023-03-21 20:45 ` [PATCH v2 4/4] mm/mmap/vma_merge: init cleanup, be explicit about the non-mergeable case Lorenzo Stoakes
2023-03-22  2:08   ` Liam R. Howlett
2023-03-22  6:07     ` Lorenzo Stoakes

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=5f88b7f9-d9f9-44ef-9a74-b338d0ba9895@lucifer.local \
    --to=lstoakes@gmail.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=david@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=m.szyprowski@samsung.com \
    --cc=maple-tree@lists.infradead.org \
    --cc=vbabka@suse.cz \
    --cc=vernon2gm@gmail.com \
    --cc=willy@infradead.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 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.