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=-4.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_PASS 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 27CEFC282D8 for ; Wed, 30 Jan 2019 10:48:18 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D29B420857 for ; Wed, 30 Jan 2019 10:48:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D29B420857 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ellerman.id.au Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 43qKpR6gV6zDqTl for ; Wed, 30 Jan 2019 21:48:15 +1100 (AEDT) Received: from ozlabs.org (bilbo.ozlabs.org [203.11.71.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 43qKmc5xg7zDqTL for ; Wed, 30 Jan 2019 21:46:40 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=ellerman.id.au Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPSA id 43qKmc3XpFz9s3q; Wed, 30 Jan 2019 21:46:40 +1100 (AEDT) From: Michael Ellerman To: "Aneesh Kumar K.V" , npiggin@gmail.com, benh@kernel.crashing.org, paulus@samba.org, akpm@linux-foundation.org, x86@kernel.org Subject: Re: [PATCH V5 2/5] mm: update ptep_modify_prot_commit to take old pte value as arg In-Reply-To: <20190116085035.29729-3-aneesh.kumar@linux.ibm.com> References: <20190116085035.29729-1-aneesh.kumar@linux.ibm.com> <20190116085035.29729-3-aneesh.kumar@linux.ibm.com> Date: Wed, 30 Jan 2019 21:46:39 +1100 Message-ID: <87imy6qv74.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, "Aneesh Kumar K.V" Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" "Aneesh Kumar K.V" writes: > Architectures like ppc64 require to do a conditional tlb flush based on the old > and new value of pte. Enable that by passing old pte value as the arg. It's not actually the architecture, it's to work around a specific bug on Power9. > diff --git a/mm/mprotect.c b/mm/mprotect.c > index c89ce07923c8..028c724dcb1a 100644 > --- a/mm/mprotect.c > +++ b/mm/mprotect.c > @@ -110,8 +110,8 @@ static unsigned long change_pte_range(struct vm_area_struct *vma, pmd_t *pmd, > continue; > } > > - ptent = ptep_modify_prot_start(vma, addr, pte); > - ptent = pte_modify(ptent, newprot); > + oldpte = ptep_modify_prot_start(vma, addr, pte); > + ptent = pte_modify(oldpte, newprot); > if (preserve_write) > ptent = pte_mk_savedwrite(ptent); Is it OK to reuse oldpte here? It was set at the top of the loop with: oldpte = *pte; Is it guaranteed that ptep_modify_prot_start() returns the old value unmodified, or could an implementation conceivably filter some bits out? If so then it could be confusing for oldpte to have its value change half way through the loop. cheers