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=-9.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 83306C4363A for ; Mon, 5 Oct 2020 13:37:40 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 16C5E20756 for ; Mon, 5 Oct 2020 13:37:40 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="qpBCwpUS"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="O7DIN5qy" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 16C5E20756 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=a9iet9JJl9DSs6rhmYMwMb7K0XeJ4ddTF9wx1IGQ1AA=; b=qpBCwpUSpwu9HYCH4agya/QaD GZfYXTzbxH5MmCjBV4tY+ycmBQLeeqfvDBEYt1TJB+/D20shDW6gMz5p/OLVxAIcTJv92bHEvmE5J GeNAROYn2TD6yco/dvll5qrQBMNWLjRvEsm9U7J8J+bI7D0zcu2+a9zGb3IGYGJ7dTXTooVQfG4+R 9s7+6HreqVEeJiWDnx0m1mTYOG0pcOhhJKIiqYQ/KqAXvYCQ+paFvd0iSm3W4PU7dihcnP+vOz4vG 8EeN8LjEWh7VJb4AQdwey7qCSxGVsalFN4wPqCjppF0/s5bnrZqkYJ9HGBEVS/M6WryMvKdXgg9b3 y1pb76ZRA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kPQf4-0002Ir-Er; Mon, 05 Oct 2020 13:36:18 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kPQez-0002Hf-7d for linux-arm-kernel@lists.infradead.org; Mon, 05 Oct 2020 13:36:14 +0000 Received: from mail-oo1-f43.google.com (mail-oo1-f43.google.com [209.85.161.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 2430F208A9 for ; Mon, 5 Oct 2020 13:36:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1601904972; bh=I/8dk2c0jptYOZdTrT5xMGb65GNUanSVVIaHY2jcxRU=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=O7DIN5qyjbdhNjRKqFmS4m7Z/UXSlRXEaSF3uFuWy183Dvr+wSXvqoAmI6WCid/0t aWFou+RnjOboqwq8t+NEXs6vqtfgP69UuRisYk2m4Q9VBQ+1yz8J/6i3cZdoKBB8mf FfHbS7b4FVv1Q2QLLriuWb9FOX9PyJ/LPmtJxhXk= Received: by mail-oo1-f43.google.com with SMTP id c4so2232013oou.6 for ; Mon, 05 Oct 2020 06:36:12 -0700 (PDT) X-Gm-Message-State: AOAM5334PfAZGmoS56vtgzGeLATVggRJwNxmtHOweTyswQmaxqpW5RTP Puxq3Avy+f5bpDn7g4bqo4hic05/Xdb8VQgnTd8= X-Google-Smtp-Source: ABdhPJxRaZnrQ0MLh8kWE6q13j6wxbUZIYAtxqJ0odlRWvRqbyZA/LyrfZkBIV4xYZbNu4IV2BNBANljUEpneq4IUyY= X-Received: by 2002:a4a:b443:: with SMTP id h3mr12324151ooo.45.1601904971403; Mon, 05 Oct 2020 06:36:11 -0700 (PDT) MIME-Version: 1.0 References: <20201001152232.274367-1-linus.walleij@linaro.org> <20201001152232.274367-2-linus.walleij@linaro.org> In-Reply-To: From: Ard Biesheuvel Date: Mon, 5 Oct 2020 15:36:00 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 1/6 v14] ARM: Handle a device tree in lowmem To: Linus Walleij X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201005_093613_432268_D577F410 X-CRM114-Status: GOOD ( 36.34 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Florian Fainelli , Arnd Bergmann , Abbott Liu , Russell King , Mike Rapoport , Andrey Ryabinin , Linux ARM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, 5 Oct 2020 at 15:27, Linus Walleij wrote: > > On Mon, Oct 5, 2020 at 11:14 AM Ard Biesheuvel wrote: > > On Mon, 5 Oct 2020 at 09:14, Ard Biesheuvel wrote: > > > > Let me see if I can code up a PoC > > > > I pushed a branch to > > > > https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=arm-dt-mapping > > > > that moves the DT mapping to a read-only region at the top of the > > kernel VA space: there happened to be a 4 MB hole there (between > > VMALLOC_END and FIXADDR_START) that we can use, even if the purpose of > > that hole was as a guard region, as a read-only mapping still catches > > stray writes. > > I will test it when I'm back at the hardware. > I tried to do this thing as well but couldn't figure out a good > place to map it, putting it between VMALLOC_END > and FIXADDR_START seems like a good idea! > > But this is going to be a problem: > > + map.type = MT_ROM; > > Because the current code calls unflatten_device_tree() which > will unflatten the device tree right where it is. > So then the memory needs to be RW. > I don't think this is the case. Note that arm64 has been using r/o mappings for the device tree for a long time, and it calls unflatten_device_tree() without any problems. > This is why in my patch I change that to > unflatten_and_copy_device_tree() so I can treat > it as a ROM, unflatten and copy that and then > ditch the memory where the device tree is so the > kernel does not need to work around that. > > (unflatten_and_copy_device_tree() > will not delete the memblock around the device > tree, so that would need to be fixed in my patch.) > > With your patch, if we call > unflatten_and_copy_device_tree() we can use > MT_ROM but then we would want to get rid of the > remapped memory and memblock > for the device tree after copying and unflattening > it, but since there is no delete_mapping() > counterpart to create_mapping() I guess that > is going to be hard? > > > What I don't get is why the DT *contents* get clobbered - > > arm_memblock_init() memblock_reserve's the DT contents, and wiping > > reserved memblocks is something we really shouldn't be doing. > > The contents are fine on my system, just the two section > mappings get wiped. > Ah ok. > I hope my previous mail explains that, the code in > prepare_page_table() simply just wipes the lowmem > PMDs without any regard for any reserved memblocks being > in that range. > In that case, mapping the DT outside of the linear region should solve this entirely. Note that this code boots fine for me. The only question I have is whether the ATAGS based systems require the ability to make changes to the data structure at runtime. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel