Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp483731imm; Wed, 17 Oct 2018 03:32:58 -0700 (PDT) X-Google-Smtp-Source: ACcGV61aPBDSH+gTiwVPfd/1DiEy/L0Ta6Hp/yoHeGeM47MzUy0j3KOUjeI4jbiGavCsRWgSkmQ5 X-Received: by 2002:a63:89c1:: with SMTP id v184-v6mr23237601pgd.79.1539772378435; Wed, 17 Oct 2018 03:32:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539772378; cv=none; d=google.com; s=arc-20160816; b=FoWlxAR5W/mgbhYi4RXlGmU4i/lobKpRs6ZlWYbtudD6+1dTNSiokhEHyGSLC9Tr4a FO/erxqLnvBN3voDusTtNVEg03cVhjDNYZdFq7R9rPfxu7MiIBlb0DaigOVdiLplnaJi Iyv9rMiv4eFuvcAfdhVE2xg9orrxaxllGi4jh+3f4TeH5WdbAb4WjO973/aBO9J27Nh2 sDmLzhmnMPn7Ru8dYu+PmM/ySBtBpsuLKQWRL680/zZDfItAdNhalMVqmY1T3llyWp0/ YPMTHeq9R8nJOhSx3zYq4pU2qfe5x2YFTT0RaIInLnv8MGNhrjI92WByAspH12ViEM0W 8kIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from; bh=XYwLD+50tWi7Mb7cszFmE2+gg4OVy6mLrcZ9sueJcjc=; b=S5iL8ucjzK/QQzpzrlrv7xGD3HJ04CfmniS7e64yfFNgnZ58kd2Iz5yEDeMHDqCp7M MTzijUgjy06q11EVBaUpIzny64B5ai7uSZFAtxUpCzsi0MhezAUWtHRE2XKvMfiLiHfi BzjTY+o3JCDcVFsgDGWTaqDYoQooURP7dB61ID/ghiYSbXcBHw3lF6do2HG14IaSssUb WmAVWuAzoUqrlDGaEd7HwbNJljGYFlqD5zEFcB5kUk7nLdi2tds5IAgfD3p1X6wR7vM3 PAUbTyxBpKMcC5eCw1U2qz906rd1Pd1V1LVpf36bqOOWlGCpuk0rkWosmQAef8/JuPC0 HWLw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 24-v6si16777567pgn.428.2018.10.17.03.32.41; Wed, 17 Oct 2018 03:32:58 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727048AbeJQS1W (ORCPT + 99 others); Wed, 17 Oct 2018 14:27:22 -0400 Received: from ozlabs.org ([203.11.71.1]:49039 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726947AbeJQS1W (ORCPT ); Wed, 17 Oct 2018 14:27:22 -0400 Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPSA id 42ZpQP4HQMz9sC2; Wed, 17 Oct 2018 21:32:13 +1100 (AEDT) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=ellerman.id.au From: Michael Ellerman To: Christophe Leroy , Bartlomiej Zolnierkiewicz , Benjamin Herrenschmidt , Dominik Brodowski , Geoff Levand , Jens Axboe , Kumar Gala , Li Yang , Nicholas Piggin , Paul Mackerras , Scott Wood , aneesh.kumar@linux.vnet.ibm.com Cc: linux-arm-kernel@lists.infradead.org, linux-block@vger.kernel.org, linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, dri-devel@lists.freedesktop.org Subject: Re: Crash on FSL Book3E due to pte_pgprot()? (was Re: [PATCH v3 12/24] powerpc/mm: use pte helpers in generic code) In-Reply-To: <236d72cd-e6d7-61e5-2c80-e4311e41b4f6@c-s.fr> References: <343c844bbc5081d13ee4c9aa27ff3118f607e1cc.1539092112.git.christophe.leroy@c-s.fr> <87va61jsma.fsf@concordia.ellerman.id.au> <236d72cd-e6d7-61e5-2c80-e4311e41b4f6@c-s.fr> Date: Wed, 17 Oct 2018 21:32:10 +1100 Message-ID: <87efcoeudx.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Christophe Leroy writes: > On 10/17/2018 12:59 AM, Michael Ellerman wrote: ... >> The question is what's the right way to fix it? Should pte_pgprot() not >> be filtering those bits out on book3e? > > I think we should not use pte_pggrot() for that then. What about the > below fix ? Thanks, that almost works. pte_mkprivileged() also needs to not strip _PAGE_BAP_SR. But there's also a use of pte_pgprot() in mm/memory.c, and I think that is also broken now that we don't add PAGE_KERNEL back in. Aneesh is going to do a patch to make pte_pgprot() only mask the PFN which is what other arches do. cheers > From: Christophe Leroy > Date: Wed, 17 Oct 2018 05:56:25 +0000 > Subject: [PATCH] powerpc/mm: don't use pte_pgprot() in ioremap_prot() > > pte_pgprot() filters out some required flags like _PAGE_PRESENT. > > This patch replaces pte_pgprot() by __pgprot(pte_val()) > in ioremap_prot() > > Fixes: 26973fa5ac0e ("powerpc/mm: use pte helpers in generic code") > Signed-off-by: Christophe Leroy > --- > arch/powerpc/mm/pgtable_32.c | 3 ++- > arch/powerpc/mm/pgtable_64.c | 4 ++-- > 2 files changed, 4 insertions(+), 3 deletions(-) > > diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c > index 5877f5aa8f5d..a606e2f4937b 100644 > --- a/arch/powerpc/mm/pgtable_32.c > +++ b/arch/powerpc/mm/pgtable_32.c > @@ -122,7 +122,8 @@ ioremap_prot(phys_addr_t addr, unsigned long size, > unsigned long flags) > pte = pte_exprotect(pte); > pte = pte_mkprivileged(pte); > > - return __ioremap_caller(addr, size, pte_pgprot(pte), > __builtin_return_address(0)); > + return __ioremap_caller(addr, size, __pgprot(pte_val(pte)), > + __builtin_return_address(0)); > } > EXPORT_SYMBOL(ioremap_prot); > > diff --git a/arch/powerpc/mm/pgtable_64.c b/arch/powerpc/mm/pgtable_64.c > index fb1375c07e8c..836bf436cabb 100644 > --- a/arch/powerpc/mm/pgtable_64.c > +++ b/arch/powerpc/mm/pgtable_64.c > @@ -245,8 +245,8 @@ void __iomem * ioremap_prot(phys_addr_t addr, > unsigned long size, > pte = pte_mkprivileged(pte); > > if (ppc_md.ioremap) > - return ppc_md.ioremap(addr, size, pte_pgprot(pte), caller); > - return __ioremap_caller(addr, size, pte_pgprot(pte), caller); > + return ppc_md.ioremap(addr, size, __pgprot(pte_val(pte)), caller); > + return __ioremap_caller(addr, size, __pgprot(pte_val(pte)), caller); > } > > > -- > 2.13.3