Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp4567438imu; Tue, 18 Dec 2018 18:04:04 -0800 (PST) X-Google-Smtp-Source: AFSGD/X6vXsF9rwVOgWmp2qlhyCH74JzEFL7mm8TV6O7gFFVSPVH5vTiURtdNMpUn6d9XFtajB0d X-Received: by 2002:a62:ea09:: with SMTP id t9mr19842361pfh.228.1545185044022; Tue, 18 Dec 2018 18:04:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1545185043; cv=none; d=google.com; s=arc-20160816; b=DIDCTlUT5hPmIDDOpl04j4K3WdxmGpwzcInM/7XC8jZavzF8ffXvvIGoPDfv4ITtmq bzGRRtwW1GCQxrZ56sgtGFLzo351MNI5kNTJsg3mU4qeuq7t8cAfBTKW++1CDnJHitha QTuZfki8P/t5QtTmILYskxkBWA+97T+YWsC9KYjMk9hlR67odxxbJWEHRL9Ofve3r7Ws BTN2JXHSB8usGyEP8lsEt7s5opa7b/b2HrHWhg2N4dC3zhuwUlIH0TU61xoIpUq0HYEx HdGoWcrtcmLl3EbcKHVYNiABFP3+QuRwHlDRGprS+PMEIGNdd9831TQbZwUnknIjfN0n 6GRw== 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=vc9Q5Mymjq+F01gwL+cO3kNu6m7NW7df56F09nJ3m3s=; b=awhJhCCzTi7/3oJUS3VDf5b0SbCVQtQABtguCP4euo54ij5nNY6PgGsEqwk3ZEM/UP 1ZVrjYPA4/HZ0e747q7MPmYIPsOoULI3SyooTGv+2TqdM99QnL8tbrmVvOVGLAU0nIFg ZO6B2LkdHaPad3Rg4LGqsu+i9ScmX9Kt/LNitQkjIIwgA9fvy5g0WMwgYqw8J+wd31A1 J7TPkdbQeqPhLcmG8XIB8SuANJOqLPZStqBk1t4HrB6k93Z2pegUSUv3ZVHnzqVY1aMM CQs5tufsbYOiEKNqwOwc+/vGkWgx1eju6uXwdYpSs0yUFZGYXYaJHLboTdWwmiDPrHbx EiSA== 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 g5si13879833plo.108.2018.12.18.18.03.46; Tue, 18 Dec 2018 18:04:03 -0800 (PST) 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 S1727510AbeLSA0C (ORCPT + 99 others); Tue, 18 Dec 2018 19:26:02 -0500 Received: from ozlabs.org ([203.11.71.1]:55409 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726512AbeLSA0C (ORCPT ); Tue, 18 Dec 2018 19:26:02 -0500 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 43KFzr2MJkz9s3Z; Wed, 19 Dec 2018 11:26:00 +1100 (AEDT) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=ellerman.id.au From: Michael Ellerman To: Christophe Leroy , Benjamin Herrenschmidt , Paul Mackerras Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH v3] powerpc: implement CONFIG_DEBUG_VIRTUAL In-Reply-To: <87y38nrkto.fsf@concordia.ellerman.id.au> References: <87y38nrkto.fsf@concordia.ellerman.id.au> Date: Wed, 19 Dec 2018 11:26:00 +1100 Message-ID: <87a7l2s6p3.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 Michael Ellerman writes: > Christophe Leroy writes: > >> This patch implements CONFIG_DEBUG_VIRTUAL to warn about >> incorrect use of virt_to_phys() and page_to_phys() > > This commit is breaking my p5020ds booting a 32-bit kernel with: > > smp: Bringing up secondary CPUs ... > __ioremap(): phys addr 0x7fef5000 is RAM lr ioremap_coherent > Unable to handle kernel paging request for data at address 0x00000000 > Faulting instruction address: 0xc002e950 > Oops: Kernel access of bad area, sig: 11 [#1] > BE SMP NR_CPUS=24 CoreNet Generic > Modules linked in: > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.20.0-rc2-gcc-7.0.1-00138-g9a0380d299e9 #148 > NIP: c002e950 LR: c002eb20 CTR: 00000001 > REGS: e804bd20 TRAP: 0300 Not tainted (4.20.0-rc2-gcc-7.0.1-00138-g9a0380d299e9) > MSR: 00021002 CR: 28004222 XER: 00000000 > DEAR: 00000000 ESR: 00000000 > GPR00: c002eb20 e804bdd0 e8050000 00000000 00021002 00000000 00000050 00021002 > GPR08: 2d3f0000 00000001 00000000 00000004 24000842 00000000 c00026d0 00000000 > GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001 > GPR24: 00029002 7fef5140 30000000 00000000 00000000 00000040 00000001 00000000 > NIP [c002e950] smp_85xx_kick_cpu+0x120/0x410 > LR [c002eb20] smp_85xx_kick_cpu+0x2f0/0x410 > Call Trace: > [e804bdd0] [c002eb20] smp_85xx_kick_cpu+0x2f0/0x410 (unreliable) > [e804be20] [c0012e38] __cpu_up+0xc8/0x230 > [e804be50] [c0040b34] bringup_cpu+0x34/0x110 > [e804be70] [c00418a8] cpu_up+0x128/0x250 > [e804beb0] [c0b84b14] smp_init+0xc4/0x10c > [e804bee0] [c0b75c1c] kernel_init_freeable+0xc8/0x250 > [e804bf20] [c00026e8] kernel_init+0x18/0x120 > [e804bf40] [c0011298] ret_from_kernel_thread+0x14/0x1c > Instruction dump: > 7fb3e850 57bdd1be 2e1d0000 41d20250 57bd3032 393dffc0 7e6a9b78 5529d1be > 39290001 7d2903a6 60000000 60000000 <7c0050ac> 394a0040 4200fff8 7c0004ac > ---[ end trace edcab2a1dfd5b38c ]--- > > > Which is obviously this hunk: > >> diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c >> index 4fc77a99c9bf..68d204a45cd0 100644 >> --- a/arch/powerpc/mm/pgtable_32.c >> +++ b/arch/powerpc/mm/pgtable_32.c >> @@ -143,7 +143,7 @@ __ioremap_caller(phys_addr_t addr, unsigned long size, pgprot_t prot, void *call >> * Don't allow anybody to remap normal RAM that we're using. >> * mem_init() sets high_memory so only do the check after that. >> */ >> - if (slab_is_available() && (p < virt_to_phys(high_memory)) && >> + if (slab_is_available() && virt_addr_valid(p) && >> page_is_ram(__phys_to_pfn(p))) { >> printk("__ioremap(): phys addr 0x%llx is RAM lr %ps\n", >> (unsigned long long)p, __builtin_return_address(0)); > > > I'll try and come up with a fix tomorrow. Actually I think that change is just wrong. virt_addr_valid() takes a virtual address, but p is a physical address. So I'll drop this hunk for now, which makes the patch a no-op when DEBUG_VIRTUAL is n which is probably the way it should be. cheers