Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp420137yba; Wed, 15 May 2019 03:47:39 -0700 (PDT) X-Google-Smtp-Source: APXvYqzwppHOjdSU59Z+zEoG/D3+l2QLdvYR9LAdCFJRB967COBHcZMH5gnJoeZc5IJ7+uGQ4ZGJ X-Received: by 2002:a63:374b:: with SMTP id g11mr43996748pgn.421.1557917259272; Wed, 15 May 2019 03:47:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557917259; cv=none; d=google.com; s=arc-20160816; b=CFL5bUa/zvD+8pBdbB0O/2gT6BknRBSlsyH6vy+Jjh9+QoqznYQgObqhmtobmV+uK5 u4pWDbONtjHVeJaCFTfXJh+6Dk3ewHgBkb5z1DtSSa0UUkYhLQT9rF4F4YBa0rSa6gz5 SzWDgGrCV3+xapd2PwvXLAc02R1DnsQ60LSBvZjQik/ETP3HR/4kEcTbIrQuQnAosXa8 OPs0Bqr8WLQat80Gs1nhsAJ+/LS3tI2kScJ/+Hi0fHvx5zykalt7Yw7AJflr2/DEWCpX Ic/2F01OlUvyguY5dChN9dTaRPvCMh+meFgQUYx8nXUd+LKOTiRlZtJyZUFalba87iE9 Etdg== 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=wBnzaBIfj+VJI+Xtrd1Dlp5yMK/LG93WwPhwqIDDvn4=; b=E8BvDEi43/wYu6vDzi+Xz48sPD7OjkZ1rbYsxsy5FS9uIwprEiwacFEA/aGXXMFNKk ov7Vaw43yMiMSF4Mu20dmy7OXhO/Bio/1Jxkwdh7p/vuevVZHkWf+CNnLhrIOfvwoi7A JykamEzEVif0gbrVSujlAESFEvsZAo+/bFgOrLndfElKoEzevCBiy8Nk0XJPGyjndXkD yFM61re3CF6LkKr6pfskhTUehUIeMpkA0z9yQmk9VQAkbw8OsaaxiZsKYonD+jWOLcy1 K0CT+saI6Ha4DaWiDHH7+MyMmhjvbnT3hQuc3mWxcwPcFhVCan2lu891ZvbM1xOVZuCr 8wVA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=YwxCRQ0S; 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=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e6si1476006pls.113.2019.05.15.03.47.22; Wed, 15 May 2019 03:47:39 -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=@chromium.org header.s=google header.b=YwxCRQ0S; 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=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726283AbfEOKed (ORCPT + 99 others); Wed, 15 May 2019 06:34:33 -0400 Received: from mail-qk1-f196.google.com ([209.85.222.196]:44897 "EHLO mail-qk1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726084AbfEOKed (ORCPT ); Wed, 15 May 2019 06:34:33 -0400 Received: by mail-qk1-f196.google.com with SMTP id w25so1110558qkj.11 for ; Wed, 15 May 2019 03:34:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wBnzaBIfj+VJI+Xtrd1Dlp5yMK/LG93WwPhwqIDDvn4=; b=YwxCRQ0Sftfr2BZal7AHb+p7cshOTkpVOdkSUGAChfZfPJbU6wba/NR76m4J30rnFT iBBMrikElQYf6bsXWI93nYm2OXWc8wOSuuxMuoyQgrQIsV2ccOvzgronYIMhL940cz8N jolmhnNoGaiC+eqT26fs74q5eJmU6K9lXIg3I= 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=wBnzaBIfj+VJI+Xtrd1Dlp5yMK/LG93WwPhwqIDDvn4=; b=FFLRWcRkzWtwb06ExHMBL3U2juOsMCH4UmVY0ad3lKxOd4K3vav6uuW7eskVN/XDU6 lcvT8z9F1o8agPKx2jrHDA2qxO4Q2FG7ze1BZSOxldHkRlCr8NtgCfEKa9T3j18Iy/3f V+nbmXjs69LbCgK6gi9kKk0z71mOmYqhmxhIaWhQW4KQOA9wNtfvOZDPBmZNnl8EewMb xY41AjnBDWFwc6Vj9ajAa/zPqX2GxazXmktjyHK/Te0rtvjmpqIEkqkP7CRNEEehBJm1 PhlGWFaMnUs+SOmmdH3oFZ1h84sG4dWD2z5/QFSH8vR1UmSh4P96FVqopKHCwUCMv2Ed 3m1w== X-Gm-Message-State: APjAAAWgJNPYxgBp+vqzBvlUABKDwiQ5DRdk7epCSwuMkYkgOxxD3LFO b+fIZb+1Esa+bilXN15XWj8LGchINMF7ASHIV8j9ew== X-Received: by 2002:a05:620a:1278:: with SMTP id b24mr31171654qkl.265.1557916472423; Wed, 15 May 2019 03:34:32 -0700 (PDT) MIME-Version: 1.0 References: <20190513003819.356-1-hsinyi@chromium.org> <20190513003819.356-2-hsinyi@chromium.org> <20190513085853.GB9271@rapoport-lnx> <155786794318.14659.2925897827978978040@swboyd.mtv.corp.google.com> <20190515050059.GA4081@rapoport-lnx> In-Reply-To: <20190515050059.GA4081@rapoport-lnx> From: Hsin-Yi Wang Date: Wed, 15 May 2019 18:34:06 +0800 Message-ID: Subject: Re: [PATCH v2 2/2] amr64: map FDT as RW for early_init_dt_scan() To: Mike Rapoport Cc: Stephen Boyd , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" , Rob Herring , Mark Rutland , Frank Rowand , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Kees Cook , Rasmus Villemoes , Architecture Mailman List , Catalin Marinas , Will Deacon , Andrew Morton , Michal Hocko , Ard Biesheuvel , Miles Chen , James Morse , Andrew Murray 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 Wed, May 15, 2019 at 1:01 PM Mike Rapoport wrote: > > > > Why not just have fixmap_remap_fdt() that maps it as RW and reserves > > memblock once, and then call __fixmap_remap_fdt() with RO after > > early_init_dt_scan() or unflatten_device_tree() is called? Why the > > desire to call memblock_reserve() twice or even three times? > > There's no desire to call memblock_reserve() twice. It's just that leaving > the call for it in kaslr rather than in setup_arch() may end up with > unreserved FDT because kaslr was disabled or even compiled out. > > I've suggested to use fixmap_remap_fdt() everywhere because IMHO this > improves readability and allows to un-export __fixmap_remap_fdt(). > > -- > Sincerely yours, > Mike. > How about adding an arch hook that's not limited to be called at init (like fixmap_remap_fdt). In this way we don't have to change currently arm64 setup structure and only map fdt to RW before we need to modify it (and can map back to RO after write). Since it can be called after init, for CONFIG_KEXEC, we can also use it before updating fdt with a new seed. Does nothing by default, and for arm64 it can be like[1]. It's similar to __fixmap_remap_fdt on counting fdt size but using update_mapping_prot() (will flush the TLBs). And suppose fixmap_remap_fdt() is called at least once, region checking is skipped. diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c index 8080c9f489c3..e0fff8a009da 100644 --- a/arch/arm64/mm/mmu.c +++ b/arch/arm64/mm/mmu.c @@ -32,6 +32,7 @@ #include #include #include +#include #include #include @@ -919,6 +920,22 @@ void *__init fixmap_remap_fdt(phys_addr_t dt_phys) return dt_virt; } +extern phys_addr_t fdt_pointer; + +/* Should be called after fixmap_remap_fdt() is called. */ +void update_fdt_pgprot(pgprot_t prot) +{ + u64 dt_virt_base = __fix_to_virt(FIX_FDT); + int offset, size; + + offset = fdt_pointer % SWAPPER_BLOCK_SIZE; + size = fdt_totalsize((void *)dt_virt_base + offset); + + update_mapping_prot(round_down(fdt_pointer, SWAPPER_BLOCK_SIZE), + dt_virt_base, + round_up(offset + size, SWAPPER_BLOCK_SIZE), prot); +} + example use: update_fdt_pgprot(PAGE_KERNEL); fdt_delprop(initial_boot_params, node, "rng-seed"); update_fdt_pgprot(PAGE_KERNEL_RO); I tested on arm64 device and it works. But if this doesn't seems right, I'll probably just don't don't map fdt back to RO if kexec is set. Is this reasonable? Thanks!