From: "Justin He (Arm Technology China)" <Justin.He@arm.com>
To: Catalin Marinas <Catalin.Marinas@arm.com>,
Anshuman Khandual <Anshuman.Khandual@arm.com>
Cc: "Andrew Morton" <akpm@linux-foundation.org>,
"Matthew Wilcox" <willy@infradead.org>,
"Jérôme Glisse" <jglisse@redhat.com>,
"Ralph Campbell" <rcampbell@nvidia.com>,
"Jason Gunthorpe" <jgg@ziepe.ca>,
"Peter Zijlstra" <peterz@infradead.org>,
"Dave Airlie" <airlied@redhat.com>,
"Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>,
"Thomas Hellstrom" <thellstrom@vmware.com>,
"Souptick Joarder" <jrdr.linux@gmail.com>,
linux-mm <linux-mm@kvack.org>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH] mm: fix double page fault on arm64 if PTE_AF is cleared
Date: Thu, 5 Sep 2019 01:18:51 +0000 [thread overview]
Message-ID: <DB7PR08MB3082ED2077384FD8F962B3BEF7BB0@DB7PR08MB3082.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <CAHkRjk6cQTu7N+UanTspWm_LyABRhfPHQn1+PPdaHYrTC3PtfQ@mail.gmail.com>
Hi Catalin
> -----Original Message-----
> From: Catalin Marinas <catalin.marinas@arm.com>
> Sent: 2019年9月4日 22:22
> To: Anshuman Khandual <Anshuman.Khandual@arm.com>
> Cc: Justin He (Arm Technology China) <Justin.He@arm.com>; Andrew
> Morton <akpm@linux-foundation.org>; Matthew Wilcox
> <willy@infradead.org>; Jérôme Glisse <jglisse@redhat.com>; Ralph
> Campbell <rcampbell@nvidia.com>; Jason Gunthorpe <jgg@ziepe.ca>;
> Peter Zijlstra <peterz@infradead.org>; Dave Airlie <airlied@redhat.com>;
> Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>; Thomas Hellstrom
> <thellstrom@vmware.com>; Souptick Joarder <jrdr.linux@gmail.com>;
> linux-mm <linux-mm@kvack.org>; Linux Kernel Mailing List <linux-
> kernel@vger.kernel.org>
> Subject: Re: [PATCH] mm: fix double page fault on arm64 if PTE_AF is
> cleared
>
> On Wed, 4 Sep 2019 at 04:20, Anshuman Khandual
> <anshuman.khandual@arm.com> wrote:
> > On 09/04/2019 06:28 AM, Jia He wrote:
> > > @@ -2152,20 +2153,30 @@ static inline void cow_user_page(struct
> page *dst, struct page *src, unsigned lo
> > > */
> > > if (unlikely(!src)) {
> > > void *kaddr = kmap_atomic(dst);
> > > - void __user *uaddr = (void __user *)(va & PAGE_MASK);
> > > + void __user *uaddr = (void __user *)(vmf->address &
> PAGE_MASK);
> > > + pte_t entry;
> > >
> > > /*
> > > * This really shouldn't fail, because the page is there
> > > * in the page tables. But it might just be unreadable,
> > > * in which case we just give up and fill the result with
> > > - * zeroes.
> > > + * zeroes. If PTE_AF is cleared on arm64, it might
> > > + * cause double page fault here. so makes pte young here
> > > */
> > > + if (!pte_young(vmf->orig_pte)) {
> > > + entry = pte_mkyoung(vmf->orig_pte);
> > > + if (ptep_set_access_flags(vmf->vma, vmf->address,
> > > + vmf->pte, entry, vmf->flags & FAULT_FLAG_WRITE))
> > > + update_mmu_cache(vmf->vma, vmf->address,
> > > + vmf->pte);
> > > + }
> > > +
> > > if (__copy_from_user_inatomic(kaddr, uaddr, PAGE_SIZE))
> >
> > Should not page fault be disabled when doing this ?
>
> Page faults are already disabled by the kmap_atomic(). But that only
> means that you don't deadlock trying to take the mmap_sem again.
>
> > Ideally it should
> > have also called access_ok() on the user address range first.
>
> Not necessary, we've already got a vma and the access to the vma checked.
>
> > The point
> > is that the caller of __copy_from_user_inatomic() must make sure that
> > there cannot be any page fault while doing the actual copy.
>
> When you copy from a user address, in general that's not guaranteed,
> more of a best effort.
>
> > But also it
> > should be done in generic way, something like in access_ok(). The current
> > proposal here seems very specific to arm64 case.
>
> The commit log didn't explain the problem properly. On arm64 without
> hardware Access Flag, copying from user will fail because the pte is
> old and cannot be marked young. So we always end up with zeroed page
> after fork() + CoW for pfn mappings.
>
Ok I will update it, thanks
--
Cheers,
Justin (Jia He)
> --
> Catalin
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
next prev parent reply other threads:[~2019-09-05 1:19 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-04 0:58 Jia He
2019-09-04 3:19 ` Anshuman Khandual
2019-09-04 4:37 ` Anshuman Khandual
2019-09-04 4:57 ` Justin He (Arm Technology China)
2019-09-04 5:28 ` Anshuman Khandual
2019-09-04 5:41 ` Justin He (Arm Technology China)
2019-09-04 14:22 ` Catalin Marinas
2019-09-05 1:18 ` Justin He (Arm Technology China) [this message]
2019-09-04 13:49 ` Catalin Marinas
2019-09-05 1:21 ` Justin He (Arm Technology China)
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=DB7PR08MB3082ED2077384FD8F962B3BEF7BB0@DB7PR08MB3082.eurprd08.prod.outlook.com \
--to=justin.he@arm.com \
--cc=Anshuman.Khandual@arm.com \
--cc=Catalin.Marinas@arm.com \
--cc=airlied@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@linux.ibm.com \
--cc=jgg@ziepe.ca \
--cc=jglisse@redhat.com \
--cc=jrdr.linux@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=peterz@infradead.org \
--cc=rcampbell@nvidia.com \
--cc=thellstrom@vmware.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox