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=-3.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 27BF6ECE599 for ; Wed, 16 Oct 2019 23:22:04 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B6BAB20872 for ; Wed, 16 Oct 2019 23:22:03 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B6BAB20872 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=sifive.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 278158E0005; Wed, 16 Oct 2019 19:22:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 228D48E0001; Wed, 16 Oct 2019 19:22:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 13EB58E0005; Wed, 16 Oct 2019 19:22:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0161.hostedemail.com [216.40.44.161]) by kanga.kvack.org (Postfix) with ESMTP id E13E78E0001 for ; Wed, 16 Oct 2019 19:22:02 -0400 (EDT) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id 40ECE40EE for ; Wed, 16 Oct 2019 23:22:02 +0000 (UTC) X-FDA: 76051222884.09.fang54_11b636836cc58 X-HE-Tag: fang54_11b636836cc58 X-Filterd-Recvd-Size: 6214 Received: from mail-pl1-f193.google.com (mail-pl1-f193.google.com [209.85.214.193]) by imf29.hostedemail.com (Postfix) with ESMTP for ; Wed, 16 Oct 2019 23:22:01 +0000 (UTC) Received: by mail-pl1-f193.google.com with SMTP id q15so148620pll.11 for ; Wed, 16 Oct 2019 16:22:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:subject:in-reply-to:cc:from:to:message-id :mime-version:content-transfer-encoding; bh=HsCb3Mo3Xna7EYoMwhTJhD9MwGz7SJTZ9CRewHqki9A=; b=FpfXWaUnBF5FcNdQJP4npRO9WlWk+z/gkOFeV81e5z5wMqItw39PbLA/zfLwgMby5p ocDHwHzAbJ2e5UNtkkRVSuZNDJRnOozF7A6z+lQgIPhMFrI2q/GoMNYHyihs8GATYmjQ CuuItYQR+6raZVEo/Jkp1VUIgcnBPz2m6gAQMKSeCyYcHgTkV9BN3lyfB76z7Cqq7UDZ reIyjYCun8Y10q4MxdMUg+KPnG/guw5DSnq0w3OqldEFvrgjOyZhcU/dnj8RKPg+Kkvn 0nbmXhwPmRt+r1iyXs72uNUfvo/s1uUtAMbtZyHP4GLLe27aQd6TUG4h3ztPEPGY5+7i dOzA== X-Gm-Message-State: APjAAAW0OcZZc2MqfeqRE9S7ZtFm3GL2P4Ou/Am7+icn5w0M7UpgeZWK jnH0GKsVR3gvyXaoASHyNy/J0A== X-Google-Smtp-Source: APXvYqzC7/HZK7+EXjzcJodZ++wliiU8C+JhMyLSizkgklN8FOVzzDMtBBSarQIk1rdVlB0KCrwo5w== X-Received: by 2002:a17:902:122:: with SMTP id 31mr749931plb.274.1571268119937; Wed, 16 Oct 2019 16:21:59 -0700 (PDT) Received: from localhost ([12.206.222.5]) by smtp.gmail.com with ESMTPSA id 14sm167819pfn.21.2019.10.16.16.21.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Oct 2019 16:21:59 -0700 (PDT) Date: Wed, 16 Oct 2019 16:21:59 -0700 (PDT) X-Google-Original-Date: Wed, 16 Oct 2019 16:21:55 PDT (-0700) Subject: Re: [PATCH v10 3/3] mm: fix double page fault on arm64 if PTE_AF is cleared In-Reply-To: <20191008123943.j7q6dlu2qb2az6xa@willie-the-truck> CC: Justin.He@arm.com, Catalin.Marinas@arm.com, Mark.Rutland@arm.com, James.Morse@arm.com, maz@kernel.org, willy@infradead.org, kirill.shutemov@linux.intel.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, punitagrawal@gmail.com, tglx@linutronix.de, akpm@linux-foundation.org, hejianet@gmail.com, Kaly.Xin@arm.com, nd@arm.com From: Palmer Dabbelt To: will@kernel.org Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed 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, 08 Oct 2019 05:39:44 PDT (-0700), will@kernel.org wrote: > On Tue, Oct 08, 2019 at 02:19:05AM +0000, Justin He (Arm Technology Chi= na) 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 ; Kiri= ll 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 P= TE_AF >> > is cleared >> > >> > 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 >> > >> > 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? = For >> > example, aren't most architectures still going to hit the double fau= lt >> > scenario even with your patch applied? >> >> 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_= on_old_pte >> will hit the double page fault. >> >> 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 = by default, >> arch_faults_on_old_pte() is false. > > ...and my complaint is that this is the majority of supported architect= ures, > 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. If I understand the semantics correctly, we should have this set to true.= I=20 don't have any context here, but we've got /* * The kernel assumes that TLBs don't cache invalid * entries, but in RISC-V, SFENCE.VMA specifies an * ordering constraint, not a cache flush; it is * necessary even after writing invalid entries. */ local_flush_tlb_page(addr); in do_page_fault(). >> 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 = CPU >> @ 3.60GHz ), there is no such double pagefault. It has the similar set= ting >> access flag way by hardware. > > Right, and that's why I'm not concerned about x86 for this problem. > > Will