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=-3.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, URIBL_BLOCKED,USER_AGENT_NEOMUTT 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 A1600C10F13 for ; Thu, 11 Apr 2019 15:41:42 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 63C5F2083E for ; Thu, 11 Apr 2019 15:41:42 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Lm1Zv5bs"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b="xzd8jKWk" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 63C5F2083E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=armlinux.org.uk Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-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=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=K9aQMmo25dTNxvGWwlPXeXGSp6/9U69AD5u3GU1MPZ4=; b=Lm1Zv5bsiYfCbb avcaNN8oYAjS/rjGwVxsLz7VLB06uMkcmgxSS1jL+YgYpIaD/HgVfhrJJLr7f7zCP3IXtfVPh+P1t 1Hsz8tdaaMXMiHIc97MFytQogERiJeVIUOLtyKkHIuOzYPZ9VgUn2fpK7gEZh7reFGgN5SB1he4aS 8tt4Wth2MXbBOiDv7j5k1oHlUGScMSbSU4G0nJVLbHsL2bzF560y6KfkD19JP5fd/4wGUy6EEhRHR M9rVUYhSbmnSm4G/HWQi+gP183+EE9I/C/V4XuXRo/eKxVIWHyjIcP82ELOAO/Si7GVg+tXX/Xxy1 BAa7U/ugIhOq5Hq2xLeg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hEbpc-0001eF-T0; Thu, 11 Apr 2019 15:41:40 +0000 Received: from pandora.armlinux.org.uk ([2001:4d48:ad52:3201:214:fdff:fe10:1be6]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hEbpZ-0001dn-QB for linux-arm-kernel@lists.infradead.org; Thu, 11 Apr 2019 15:41:39 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=+I+J0ydblqwfp+Gs3zvi5qbUyQhD4Wgk586equJ7Rak=; b=xzd8jKWknu/29/9m0bch1w4Yg W9+kWTxaPhHucx0fnXX3o9c0gqGl90swha/vJ8XVfMXtwzwXj2m9ToeOSrJ6mJigA0MouZP8KfCBK fOiNQbKwr/ieWuxw33UZFEqNwJXnOjoRplibdP9g3p9c2wIjD2YbYGkKe/vYqGZpCDyq6C15lDxVs Ju350Qm5qIIg3LgKPGz5yw+XX3Q58E/3T1iT4JATWu6Qz8E2me9UlTz/tUb14nD/U+mhehMXEHQ6d QwnNL76gRj7/IBrHUq63AQKZigmJi+RtE8uGAqB5FXylHRtp3RSAKAALUTFTJ/pd6+iOJunRxs+XE Ic12UAhTQ==; Received: from shell.armlinux.org.uk ([2002:4e20:1eda:1:5054:ff:fe00:4ec]:37712) by pandora.armlinux.org.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1hEbpU-0003iE-F9; Thu, 11 Apr 2019 16:41:32 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.89) (envelope-from ) id 1hEbpR-00045i-Ja; Thu, 11 Apr 2019 16:41:29 +0100 Date: Thu, 11 Apr 2019 16:41:29 +0100 From: Russell King - ARM Linux admin To: Ilias Apalodimas Subject: Re: Memory size and section boundary on armv7 Message-ID: <20190411154129.xh5eoicmjkpt6ceb@shell.armlinux.org.uk> References: <20190411151320.GA23031@apalos> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20190411151320.GA23031@apalos> User-Agent: NeoMutt/20170113 (1.7.2) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190411_084138_017542_8685B208 X-CRM114-Status: GOOD ( 23.61 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: catalin.marinas@arm.com, labbott@redhat.com, mrutland@arm.com, linux-arm-kernel@lists.infradead.org, ard.biesheuvel@linaro.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Apr 11, 2019 at 06:13:20PM +0300, Ilias Apalodimas wrote: > Hello, > > While experimenting with u-boot and booting the kernel as an EFI stub i seem to > hit an issue with memory mapping (map_lowmem). > > I can only reproduce the crash when using u-boot's dtb (specified in > fdtcontroladdr) and pass that to the kernel, instead of loading an external one > with 'dtb=' on it's command line. > > If CONFIG_ARM_LPAE=y, everything works fine. If the latter is not selected > though the kernel seems to crash only if dtb is placed on a section boundary. > The reason is crashes is the BUG_ON() on arm_pte_alloc() triggers. > > fdt size is 0xc00 in both scenarios. > So something like this works fine: > In this case ff000 + c000 + f5000 = 200000 > [ 0.000000] MAP addr: c7c00000, next c7e00000, phys c7c00000 len 200000 > [ 0.000000] INI addr: c7e00000, next c7eff000, len ff000 > [ 0.000000] INI addr: c7f0b000, next c8000000, len f5000 > [ 0.000000] MAP addr: c8000000, next c8200000, phys c8000000 len 200000 > > In this working case kernel maps sizes ff000 and f5000 alloc_init_pte() and > skips the 0xc000 of the fdt correctly > > The non-working case is: > [ 0.000000] MAP addr: c7e00000, next c7f00000, phys c7e00000 len 100000 > [ 0.000000] INI addr: c7f0c000, next c8000000, len f4000 > > Both entries end up using the same pmd > > I am not sure what's the best way to fix that. > Obviously skipping the alloc_init_pte() once this case is detected fixes things, > but is there a better idea? Well, with the above information, all that I can say is that the mapping code is quite rightfully BUG_ON()ing - it's working as designed. It seems that alloc_init_pte() is finding that a section mapping has already been created for the virtual address range, but it is then being asked to create a page table mapping over the top of it. That is one BIG no no. Replacing the existing section mapping with a page table means that the section mapping is destroyed. If we allowed such replacement, when the section mapping is accessed, we will end up oopsing the kernel. It is also designed to allow hardware-section sized mappings (making it possible to map sections on 1MB granularity) but as a single Linux page table always occupies 2MB, it is not permitted for the unused half of an aligned 2MB slot to be used for a page table mapping - hence this BUG_ON(). The ARM early mapping routines are intentionally designed such that areas of memory that they are asked to map are non-overlapping - it is the caller's responsibility to ensure this. So, this is not a problem with the mapping functions, but the way they are being used. Beyond that, it is impossible to say with the above information since: 1. You've obviously added some additional printk()s, but you haven't said where they are or what they mean. What is the difference between "MAP addr" and "INI addr" ? 2. You haven't included the text of the crash, so there's no way to know the call path to the BUG_ON(), and hence ascertain where the duplicated mapping is coming from. Please always provide the full unaltered text from any kernel oops, bug or warning. Thanks. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel