Received: by 2002:a25:824b:0:0:0:0:0 with SMTP id d11csp4401482ybn; Fri, 27 Sep 2019 23:24:09 -0700 (PDT) X-Google-Smtp-Source: APXvYqx8WKbv+gQI5isBiLnpPRMT/8gbkQXs8JT0h3czCD1sH35u/e99XTs+k6nYmgPaCIWxU1p9 X-Received: by 2002:a17:906:6c98:: with SMTP id s24mr10600303ejr.28.1569651849761; Fri, 27 Sep 2019 23:24:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569651849; cv=none; d=google.com; s=arc-20160816; b=B5q7Jiij3/cSd3VZ9BB1Cr0snu8fDRQA3zJ10Xu18u/3BtHwBQPLfG4/0Uu4fGQnTm p1QlSFnNQU/HKQx+RWAqg02vel7UDatEUQOzdv0Am8oeMQbbTMBChcrDupXoc36+fe6C DnAYj5z/mp27Oox6DBdczIbL88hP6rxmbaAl6nttXTEo8FARTp4xOAwM5vhI66u2Zsgu UlVwXQPzSpYZpPVnLFk2FKbQgYqDzzlUILPAgQcjQNr10ITAIZ+U50MhihNKo0X7o3Bw USXdKIcVEs8LjrtYliB8Iea1C5hBB3ln6dRumah4qu667xlqq+fiu86ZQ6P75kmBQli7 MlrQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=Bg7uM/vqGqsjyM9H0Hgoy0WYnWDjhpVkIU5063YeccE=; b=sJR6b5SpGYgRQ7eacz1d1OK93xDDhqR1sn4+Fem/9c34vVMqVd+y7V98asPrn6JhsQ 5SrlAe1Nz/5SSXqdAyGyp3+Pqk0tBo+2TtHFLsMk8SEhcCuejZpoUPx0kFjOs91R2Bkm CO7jpzRdJUX0VZ2/UQDp2oUcPqe7w1kdXHFNIuHQpQ0lpig6tDABPOX3eV6jqLzC2+E+ ZJeJQvGKldT3SKVHJNQ8tw6Vd5AZBYDs2AX/YaMXJSPJuyFLlVAd7rXcWdXW48uOvDkW sSUTK5oyJnyGF+OnucR0NUfw/36VVE7S7liTwo10s6Sf+gh4SogV2txOWKkFlN+Wp2I8 y0Zg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=hoW52JNO; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n8si3738981eju.311.2019.09.27.23.23.31; Fri, 27 Sep 2019 23:24:09 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=hoW52JNO; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725957AbfI1GWg (ORCPT + 99 others); Sat, 28 Sep 2019 02:22:36 -0400 Received: from mail-yb1-f193.google.com ([209.85.219.193]:34808 "EHLO mail-yb1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725857AbfI1GWg (ORCPT ); Sat, 28 Sep 2019 02:22:36 -0400 Received: by mail-yb1-f193.google.com with SMTP id p11so2764186ybc.1 for ; Fri, 27 Sep 2019 23:22:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Bg7uM/vqGqsjyM9H0Hgoy0WYnWDjhpVkIU5063YeccE=; b=hoW52JNOW+UrzwDPyp5y+OJVXfOYJeQM61QNHfj8TFQE5loHjsGS/anBQbi0gKJABo 97Zfz7DYXT+PnmSh2VqJv3UbJD4lU4TEs8B7Ke88pNI/1boVCi7XFzlrGyDBzCS1eQyQ 3GaRUJppIwhTL2O9pfuhoXou00xPoRpo2V2f0LatTw2E9nGFgHSGiIbpxexc/n4DF4hH j6CV8smroWMwONQFcrKCx0mblkNb6XyshYOE6VhynxtjgGPMBAyRRkuZl8104ym+ZIV9 5V9HOp49sSMIF1BJ0mmcB68XI8X5MCL+AjVI0+FwYXrbof7VwpfIn4k2SYvTZMSvtO8p 47Ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Bg7uM/vqGqsjyM9H0Hgoy0WYnWDjhpVkIU5063YeccE=; b=c+UR9aFXH44kAEuwZYt7sSJ78EuJBNEI4/oYSuDUxaTVh2DKMasJ4cOt3GSXabQIqD 0yNRsvK5JRkAO7y0MCF1aYCMPjhuwasFL9U7crY8cKNoqHq2OLYjnDoWn7QylsHijYnc SBuclpL/HY0WSIMoC9TFdUjmkGh3C7tW1/13PxcQYZg1AGbKU6ee6cJPDIjVwbUNBqvu aYFlWyXH6ctZrokQDH3nQgUBnOwDr7hUZ18IeYE/Go8V+c0qy04AhYAMYyBKLGZXGuDS B4ASWAGYPoPGQ/RyFG/ifpkKy9RK+8nUnxqwxhC00vr8It43YvTHnHVh1gfyqpcd4hs1 p8dQ== X-Gm-Message-State: APjAAAUaqZ/x47M+TLJZA+LIBmuHHKObxe/H4I2FZz2Vexgrpnb9cVmS mQydu3msBemzN112pqhlCGWJMGgo38AwWWWzBbo= X-Received: by 2002:a25:a87:: with SMTP id 129mr8587098ybk.203.1569651755563; Fri, 27 Sep 2019 23:22:35 -0700 (PDT) MIME-Version: 1.0 References: <20190927231418.83100-1-aou@eecs.berkeley.edu> In-Reply-To: <20190927231418.83100-1-aou@eecs.berkeley.edu> From: Bin Meng Date: Sat, 28 Sep 2019 14:22:22 +0800 Message-ID: Subject: Re: [PATCH v2] riscv: Fix memblock reservation for device tree blob To: Albert Ou Cc: Palmer Dabbelt , Paul Walmsley , Anup Patel , linux-riscv , linux-kernel Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Sep 28, 2019 at 7:14 AM Albert Ou wrote: > > This fixes an error with how the FDT blob is reserved in memblock. > An incorrect physical address calculation exposed the FDT header to > unintended corruption, which typically manifested with of_fdt_raw_init() > faulting during late boot after fdt_totalsize() returned a wrong value. > Systems with smaller physical memory sizes more frequently trigger this > issue, as the kernel is more likely to allocate from the DMA32 zone > where bbl places the DTB after the kernel image. > > Commit 671f9a3e2e24 ("RISC-V: Setup initial page tables in two stages") > changed the mapping of the DTB to reside in the fixmap area. > Consequently, early_init_fdt_reserve_self() cannot be used anymore in > setup_bootmem() since it relies on __pa() to derive a physical address, > which does not work with dtb_early_va that is no longer a valid kernel > logical address. > > The reserved[0x1] region shows the effect of the pointer underflow > resulting from the __pa(initial_boot_params) offset subtraction: > > [ 0.000000] MEMBLOCK configuration: > [ 0.000000] memory size = 0x000000001fe00000 reserved size = 0x0000000000a2e514 > [ 0.000000] memory.cnt = 0x1 > [ 0.000000] memory[0x0] [0x0000000080200000-0x000000009fffffff], 0x000000001fe00000 bytes flags: 0x0 > [ 0.000000] reserved.cnt = 0x2 > [ 0.000000] reserved[0x0] [0x0000000080200000-0x0000000080c2dfeb], 0x0000000000a2dfec bytes flags: 0x0 > [ 0.000000] reserved[0x1] [0xfffffff080100000-0xfffffff080100527], 0x0000000000000528 bytes flags: 0x0 > > With the fix applied: > > [ 0.000000] MEMBLOCK configuration: > [ 0.000000] memory size = 0x000000001fe00000 reserved size = 0x0000000000a2e514 > [ 0.000000] memory.cnt = 0x1 > [ 0.000000] memory[0x0] [0x0000000080200000-0x000000009fffffff], 0x000000001fe00000 bytes flags: 0x0 > [ 0.000000] reserved.cnt = 0x2 > [ 0.000000] reserved[0x0] [0x0000000080200000-0x0000000080c2dfeb], 0x0000000000a2dfec bytes flags: 0x0 > [ 0.000000] reserved[0x1] [0x0000000080e00000-0x0000000080e00527], 0x0000000000000528 bytes flags: 0x0 > > Fixes: 671f9a3e2e24 ("RISC-V: Setup initial page tables in two stages") I also found that with commit 671f9a3e2e24 ("RISC-V: Setup initial page tables in two stages"), when booting the kernel from U-Boot via: => bootm $kernel_addr_t - $fdtcontroladdr ($kernel_addr_t = 0x84000000 and $fdtcontroladdr = 0xff741c60) kernel does not boot. I looked at people's instructions of booting Linux kernel, and they seem to have such: => cp.l ${fdtcontroladdr} ${fdt_addr_r} 0x10000 => bootm ${kernel_addr_r} - ${fdt_addr_r} where ${fdt_addr_r} is 0x88000000, and "bootm 84000000 - 88000000" can make the kernel boot. Thanks for the patch. Now "bootm $kernel_addr_t - $fdtcontroladdr" works again! Tested-by: Bin Meng > Signed-off-by: Albert Ou > --- > > Changes in v2: > * Changed variable identifier to dtb_early_pa per reviewer feedback. > * Removed whitespace change. > > arch/riscv/mm/init.c | 12 +++++++++++- > 1 file changed, 11 insertions(+), 1 deletion(-) > Regards, Bin