Message-ID: <fffefe4-adce-a7d-23e0-9f8afc7ce6cf@google.com>
Date:   Wed, 26 Oct 2022 18:48:29 -0700 (PDT)
From:   Hugh Dickins <hughd@...gle.com>
To:     Peter Xu <peterx@...hat.com>
cc:     Hugh Dickins <hughd@...gle.com>,
        Yuanzheng Song <songyuanzheng@...wei.com>,
        akpm@...ux-foundation.org, gregkh@...uxfoundation.org,
        david@...hat.com, linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        stable@...r.kernel.org
Subject: Re: [PATCH STABLE 5.10] mm/memory: add non-anonymous page check in
 the copy_present_page()

On Wed, 26 Oct 2022, Peter Xu wrote:

> Hi, Yuanzheng,
> 
> On Wed, Oct 26, 2022 at 02:51:16PM -0700, Hugh Dickins wrote:
> > On Mon, 24 Oct 2022, Yuanzheng Song wrote:
> > 
> > > The vma->anon_vma of the child process may be NULL because
> > > the entire vma does not contain anonymous pages. In this
> > > case, a BUG will occur when the copy_present_page() passes
> > > a copy of a non-anonymous page of that vma to the
> > > page_add_new_anon_rmap() to set up new anonymous rmap.
> > > 
> > > ------------[ cut here ]------------
> > > kernel BUG at mm/rmap.c:1044!
> > > Internal error: Oops - BUG: 0 [#1] SMP
> > > Modules linked in:
> > > CPU: 2 PID: 3617 Comm: test Not tainted 5.10.149 #1
> > > Hardware name: linux,dummy-virt (DT)
> > > pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--)
> > > pc : __page_set_anon_rmap+0xbc/0xf8
> > > lr : __page_set_anon_rmap+0xbc/0xf8
> > > sp : ffff800014c1b870
> > > x29: ffff800014c1b870 x28: 0000000000000001
> > > x27: 0000000010100073 x26: ffff1d65c517baa8
> > > x25: ffff1d65cab0f000 x24: ffff1d65c416d800
> > > x23: ffff1d65cab5f248 x22: 0000000020000000
> > > x21: 0000000000000001 x20: 0000000000000000
> > > x19: fffffe75970023c0 x18: 0000000000000000
> > > x17: 0000000000000000 x16: 0000000000000000
> > > x15: 0000000000000000 x14: 0000000000000000
> > > x13: 0000000000000000 x12: 0000000000000000
> > > x11: 0000000000000000 x10: 0000000000000000
> > > x9 : ffffc3096d5fb858 x8 : 0000000000000000
> > > x7 : 0000000000000011 x6 : ffff5a5c9089c000
> > > x5 : 0000000000020000 x4 : ffff5a5c9089c000
> > > x3 : ffffc3096d200000 x2 : ffffc3096e8d0000
> > > x1 : ffff1d65ca3da740 x0 : 0000000000000000
> > > Call trace:
> > >  __page_set_anon_rmap+0xbc/0xf8
> > >  page_add_new_anon_rmap+0x1e0/0x390
> > >  copy_pte_range+0xd00/0x1248
> > >  copy_page_range+0x39c/0x620
> > >  dup_mmap+0x2e0/0x5a8
> > >  dup_mm+0x78/0x140
> > >  copy_process+0x918/0x1a20
> > >  kernel_clone+0xac/0x638
> > >  __do_sys_clone+0x78/0xb0
> > >  __arm64_sys_clone+0x30/0x40
> > >  el0_svc_common.constprop.0+0xb0/0x308
> > >  do_el0_svc+0x48/0xb8
> > >  el0_svc+0x24/0x38
> > >  el0_sync_handler+0x160/0x168
> > >  el0_sync+0x180/0x1c0
> > > Code: 97f8ff85 f9400294 17ffffeb 97f8ff82 (d4210000)
> > > ---[ end trace a972347688dc9bd4 ]---
> > > Kernel panic - not syncing: Oops - BUG: Fatal exception
> > > SMP: stopping secondary CPUs
> > > Kernel Offset: 0x43095d200000 from 0xffff800010000000
> > > PHYS_OFFSET: 0xffffe29a80000000
> > > CPU features: 0x08200022,61806082
> > > Memory Limit: none
> > > ---[ end Kernel panic - not syncing: Oops - BUG: Fatal exception ]---
> > > 
> > > This problem has been fixed by the fb3d824d1a46
> > > ("mm/rmap: split page_dup_rmap() into page_dup_file_rmap() and page_try_dup_anon_rmap()"),
> > > but still exists in the linux-5.10.y branch.
> > > 
> > > This patch is not applicable to this version because
> > > of the large version differences. Therefore, fix it by
> > > adding non-anonymous page check in the copy_present_page().
> > > 
> > > Fixes: 70e806e4e645 ("mm: Do early cow for pinned pages during fork() for ptes")
> > > Signed-off-by: Yuanzheng Song <songyuanzheng@...wei.com>
> > 
> > It's a good point, but this patch should not go into any stable release
> > without an explicit Ack from either Peter Xu or David Hildenbrand.
> > 
> > To my eye, it's simply avoiding the issue, rather than fixing
> > it properly; and even if the issue is so rare, and fixing properly
> > too difficult or inefficent (a cached anon_vma?), that a workaround
> > is good enough, it still looks like the wrong workaround (checking
> > dst_vma->anon_vma instead of PageAnon seems more to the point, and
> > less lenient).
> 
> Sorry to have missed this patch. I agree with Hugh that this patch may not
> really fix the issue.
> 
> IIUC it's the case where the vma is privately mapping a file.  Some shared
> pages got pinned, and here we're trying to trigger the CoW assuming it's
> anonymous page but it's not.
> 
> The pin should be RO - if it was a write pin, CoW should have happened on
> the page cache and there should be an anonymous page, and anon_vma should
> be there, no issue should happen.  Only if with RO pin, we won't trigger
> CoW, we won't have any anonymous page, we won't have anon_vma, hence the
> panic.
> 
> The thing is if the page is RO pinned, skip copying it (as what was done in
> this patch) is not correct either, because e.g. a follow up write after
> fork() from the parent will trigger CoW and the dma RO page that was pinned
> will be inconsistent to the page in pgtable anymore, I think.
> 
> IIUC the correct fix is what David worked on with unshare - when RO pin the
> page cache we should have triggered CoR already before fork().  But as you
> mentioned, that's too much change for stable.
> 
> So besides this workaround which seems feasible to at least not panic the
> system (Hugh: I can't quickly tell what'll be the difference here to check
> dst anon_vma or PageAnon, they all seem to work?  I could have missed

Thanks for all the helpful elucidation above.

My thought here, in favour of checking dst anon_vma rather than PageAnon,
was that a common case would be that the private file vma does already
have an anon_vma attached (from earlier CoW on some other page), and
in that case there is no justification for taking this short cut to
avoid the BUG in __page_set_anon_rmap() on every !PageAnon in the vma.

And I imagined that the correct fix (short of going forward with David's
full changes) would be to back out to a context where one could add an
anon_vma_prepare(), then retry after that - involves dropping pt lock,
maybe gets nasty (tedious, anyway).

> something for sure..), the other workaround is teach the user app to switch
> to use RW pin for any DMA pages even if RO, so that it'll always guarantee
> page coherence even with the old kernel, and afaict that's what RDMA relied
> on for years.  I don't know an easy way to make old kernel work with RO pin
> solidly if without the unsharing logic.
> 
> Thanks,
> 
> -- 
> Peter Xu

Powered by blists - more mailing lists