Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Mon, 17 Aug 2020 00:17:49 -0700 (PDT)
From:   Hugh Dickins <hughd@google.com>
To:     Song Liu <songliubraving@fb.com>
cc:     Hugh Dickins <hughd@google.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
        Srikar Dronamraju <srikar@linux.vnet.ibm.com>,
        Oleg Nesterov <oleg@redhat.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: [PATCH] uprobes: __replace_page() avoid BUG in
 munlock_vma_page()
In-Reply-To: <852258AE-75B6-404A-B236-9EEF37AEE43F@fb.com>
Message-ID: <alpine.LSU.2.11.2008162340320.1025@eggly.anvils>
References: <alpine.LSU.2.11.2008161338360.20413@eggly.anvils> <852258AE-75B6-404A-B236-9EEF37AEE43F@fb.com>
User-Agent: Alpine 2.11 (LSU 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, 17 Aug 2020, Song Liu wrote:
> > On Aug 16, 2020, at 1:44 PM, Hugh Dickins <hughd@google.com> wrote:
> > 
> > syzbot crashed on the VM_BUG_ON_PAGE(PageTail) in munlock_vma_page(),
> > when called from uprobes __replace_page().  Which of many ways to fix it?
> > Settled on not calling when PageCompound (since Head and Tail are equals
> > in this context, PageCompound the usual check in uprobes.c, and the prior
> > use of FOLL_SPLIT_PMD will have cleared PageMlocked already).
> > 
> > Reported-by: syzbot <syzkaller@googlegroups.com>
> > Fixes: 5a52c9df62b4 ("uprobe: use FOLL_SPLIT_PMD instead of FOLL_SPLIT")
> > Signed-off-by: Hugh Dickins <hughd@google.com>
> > Cc: stable@vger.kernel.org # v5.4+
> > ---
> > This one is not a 5.9-rc regression, but still good to fix.
> > 
> > kernel/events/uprobes.c |    2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > --- v5.9-rc/kernel/events/uprobes.c	2020-08-12 19:46:50.851196584 -0700
> > +++ linux/kernel/events/uprobes.c	2020-08-16 13:18:35.292821674 -0700
> > @@ -205,7 +205,7 @@ static int __replace_page(struct vm_area
> > 		try_to_free_swap(old_page);
> > 	page_vma_mapped_walk_done(&pvmw);
> > 
> > -	if (vma->vm_flags & VM_LOCKED)
> > +	if ((vma->vm_flags & VM_LOCKED) && !PageCompound(old_page))
> 
> Do we need munlock_vma_page() for THP page head? 

No: as the commit message says "the prior use of FOLL_SPLIT_PMD
will have cleared PageMlocked already" - our THP implementation
has difficulty supporting Mlocked consistently when the huge page is
somewhere mapped by ptes, so one of the things that __split_huge_pmd()
does is clear_page_mlock(), then PageDoubleMap will prevent Mlocked
being set again once GUP has brought the old_page pte back in.

But if you'd prefer us to munlock_vma_page(compound_head(old_page))
instead, I can certainly change the patch: it's one of the options
I considered, but couldn't quite bring myself to do it that way,
knowing that actually it would never find PageMlocked set.  (If
PageMlocked were allowed on tail pages, I'd have used a PageMlocked
test instead of the PageCompound one: I spent nearly an hour
bikeshedding the alternatives here!)

(One day I must remind myself of when munlock_vma_page() should be
used, versus when clear_page_mlock() should be used: I think it comes
down to a choice of which stats get incremented, but I may also be
forgetting something more important: anyway, no obvious reason to
depart from the munlock_vma_page() that's always been used here.)

Hugh