linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Will Deacon <will@kernel.org>
To: Jia He <justin.he@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	James Morse <james.morse@arm.com>, Marc Zyngier <maz@kernel.org>,
	Matthew Wilcox <willy@infradead.org>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	Punit Agrawal <punitagrawal@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	hejianet@gmail.com, Kaly Xin <Kaly.Xin@arm.com>
Subject: Re: [PATCH v10 2/3] arm64: mm: implement arch_faults_on_old_pte() on arm64
Date: Tue, 1 Oct 2019 13:50:32 +0100	[thread overview]
Message-ID: <20191001125031.7ddm5dlwss6m3dth@willie-the-truck> (raw)
In-Reply-To: <20190930015740.84362-3-justin.he@arm.com>

On Mon, Sep 30, 2019 at 09:57:39AM +0800, Jia He wrote:
> On arm64 without hardware Access Flag, copying fromuser 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. we don't always have a
> hardware-managed access flag on arm64.
> 
> Hence implement arch_faults_on_old_pte on arm64 to indicate that it might
> cause page fault when accessing old pte.
> 
> Signed-off-by: Jia He <justin.he@arm.com>
> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
> ---
>  arch/arm64/include/asm/pgtable.h | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> index 7576df00eb50..e96fb82f62de 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -885,6 +885,20 @@ static inline void update_mmu_cache(struct vm_area_struct *vma,
>  #define phys_to_ttbr(addr)	(addr)
>  #endif
>  
> +/*
> + * 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. We don't always have a
> + * hardware-managed access flag on arm64.
> + */
> +static inline bool arch_faults_on_old_pte(void)
> +{
> +	WARN_ON(preemptible());
> +
> +	return !cpu_has_hw_af();
> +}

Does this work correctly in a KVM guest? (i.e. is the MMFR sanitised in that
case, despite not being the case on the host?)

Will


  reply	other threads:[~2019-10-01 12:50 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-30  1:57 [PATCH v10 0/3] fix double page fault on arm64 Jia He
2019-09-30  1:57 ` [PATCH v10 1/3] arm64: cpufeature: introduce helper cpu_has_hw_af() Jia He
2019-10-01 12:54   ` Will Deacon
2019-10-01 13:18     ` Marc Zyngier
2019-10-08  1:12       ` Justin He (Arm Technology China)
2019-10-08 15:32         ` Suzuki K Poulose
2019-10-09  6:29           ` Jia He
2019-09-30  1:57 ` [PATCH v10 2/3] arm64: mm: implement arch_faults_on_old_pte() on arm64 Jia He
2019-10-01 12:50   ` Will Deacon [this message]
2019-10-01 13:32     ` Marc Zyngier
2019-10-08  1:55       ` Justin He (Arm Technology China)
2019-10-08  2:30         ` Justin He (Arm Technology China)
2019-10-08  7:46         ` Marc Zyngier
2019-09-30  1:57 ` [PATCH v10 3/3] mm: fix double page fault on arm64 if PTE_AF is cleared Jia He
2019-10-01 12:54   ` Will Deacon
2019-10-08  2:19     ` Justin He (Arm Technology China)
2019-10-08 12:39       ` Will Deacon
2019-10-08 12:58         ` Justin He (Arm Technology China)
2019-10-08 14:32           ` Kirill A. Shutemov
2019-10-16 23:21         ` Palmer Dabbelt
2019-10-16 23:46           ` Will Deacon

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=20191001125031.7ddm5dlwss6m3dth@willie-the-truck \
    --to=will@kernel.org \
    --cc=Kaly.Xin@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=catalin.marinas@arm.com \
    --cc=hejianet@gmail.com \
    --cc=james.morse@arm.com \
    --cc=justin.he@arm.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mark.rutland@arm.com \
    --cc=maz@kernel.org \
    --cc=punitagrawal@gmail.com \
    --cc=tglx@linutronix.de \
    --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;
as well as URLs for NNTP newsgroup(s).