From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 34070C4360C for ; Tue, 8 Oct 2019 12:39:53 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E87D120815 for ; Tue, 8 Oct 2019 12:39:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="iwaHKDts" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E87D120815 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 8A7A68E0005; Tue, 8 Oct 2019 08:39:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8576A8E0003; Tue, 8 Oct 2019 08:39:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 76EA88E0005; Tue, 8 Oct 2019 08:39:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0164.hostedemail.com [216.40.44.164]) by kanga.kvack.org (Postfix) with ESMTP id 57E908E0003 for ; Tue, 8 Oct 2019 08:39:52 -0400 (EDT) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with SMTP id 0D9E3180AD803 for ; Tue, 8 Oct 2019 12:39:52 +0000 (UTC) X-FDA: 76020574224.17.beam82_38e949b881e40 X-HE-Tag: beam82_38e949b881e40 X-Filterd-Recvd-Size: 5357 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf33.hostedemail.com (Postfix) with ESMTP for ; Tue, 8 Oct 2019 12:39:50 +0000 (UTC) Received: from willie-the-truck (236.31.169.217.in-addr.arpa [217.169.31.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 1A5F3206B6; Tue, 8 Oct 2019 12:39:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1570538389; bh=VOehHrjoEEH/9k1qS9ryy1x3ms6XAZCSJcvTxw4RJFY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=iwaHKDtsfJzVVQq4/IuDx7OPcJ1OZEk1TNgWyf3KSKHP241RRMNvK2Y5lbwky4ez7 LhZK0baYberKH77q90rA/AcHKfjADNwNqDvstzw6/4+SHednGlG0qZ90g5niGw+Fn7 kBQ2DxxS+dqLZTW/evaUTo8vP3LSBCsoOgQsv7Q8= Date: Tue, 8 Oct 2019 13:39:44 +0100 From: Will Deacon To: "Justin He (Arm Technology China)" Cc: Catalin Marinas , Mark Rutland , James Morse , Marc Zyngier , Matthew Wilcox , "Kirill A. Shutemov" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , Punit Agrawal , Thomas Gleixner , Andrew Morton , "hejianet@gmail.com" , "Kaly Xin (Arm Technology China)" , nd Subject: Re: [PATCH v10 3/3] mm: fix double page fault on arm64 if PTE_AF is cleared Message-ID: <20191008123943.j7q6dlu2qb2az6xa@willie-the-truck> References: <20190930015740.84362-1-justin.he@arm.com> <20190930015740.84362-4-justin.he@arm.com> <20191001125413.mhxa6qszwnuhglky@willie-the-truck> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Oct 08, 2019 at 02:19:05AM +0000, Justin He (Arm Technology China= ) wrote: > > -----Original Message----- > > From: Will Deacon > > Sent: 2019=E5=B9=B410=E6=9C=881=E6=97=A5 20:54 > > To: Justin He (Arm Technology China) > > Cc: Catalin Marinas ; Mark Rutland > > ; James Morse ; Marc > > Zyngier ; Matthew Wilcox ; Kiril= l A. > > Shutemov ; linux-arm- > > kernel@lists.infradead.org; linux-kernel@vger.kernel.org; linux- > > mm@kvack.org; Punit Agrawal ; Thomas > > Gleixner ; Andrew Morton > foundation.org>; hejianet@gmail.com; Kaly Xin (Arm Technology China) > > > > Subject: Re: [PATCH v10 3/3] mm: fix double page fault on arm64 if PT= E_AF > > is cleared > >=20 > > On Mon, Sep 30, 2019 at 09:57:40AM +0800, Jia He wrote: > > > diff --git a/mm/memory.c b/mm/memory.c > > > index b1ca51a079f2..1f56b0118ef5 100644 > > > --- a/mm/memory.c > > > +++ b/mm/memory.c > > > @@ -118,6 +118,13 @@ int randomize_va_space __read_mostly =3D > > > 2; > > > #endif > > > > > > +#ifndef arch_faults_on_old_pte > > > +static inline bool arch_faults_on_old_pte(void) > > > +{ > > > + return false; > > > +} > > > +#endif > >=20 > > Kirill has acked this, so I'm happy to take the patch as-is, however = isn't > > it the case that /most/ architectures will want to return true for > > arch_faults_on_old_pte()? In which case, wouldn't it make more sense = for > > that to be the default, and have x86 and arm64 provide an override? F= or > > example, aren't most architectures still going to hit the double faul= t > > scenario even with your patch applied? >=20 > No, after applying my patch series, only those architectures which don'= t provide > setting access flag by hardware AND don't implement their arch_faults_o= n_old_pte > will hit the double page fault. >=20 > The meaning of true for arch_faults_on_old_pte() is "this arch doesn't = have the hardware > setting access flag way, it might cause page fault on an old pte" > I don't want to change other architectures' default behavior here. So b= y default,=20 > arch_faults_on_old_pte() is false. ...and my complaint is that this is the majority of supported architectur= es, so you're fixing something for arm64 which also affects arm, powerpc, alpha, mips, riscv, ... Chances are, they won't even realise they need to implement arch_faults_on_old_pte() until somebody runs into the double fault and wastes lots of time debugging it before they spot your patch. > Btw, currently I only observed this double pagefault on arm64's guest > (host is ThunderX2). On X86 guest (host is Intel(R) Core(TM) i7-4790 C= PU > @ 3.60GHz ), there is no such double pagefault. It has the similar sett= ing > access flag way by hardware. Right, and that's why I'm not concerned about x86 for this problem. Will