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=-2.2 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 B1440C433B4 for ; Tue, 20 Apr 2021 16:36:08 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 18147613CE for ; Tue, 20 Apr 2021 16:36:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 18147613CE Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com 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=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:Cc:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=vk4pQYyKl38ceHwSuGSoRKXdEgB15ar+XkmsjOKE1DM=; b=abrI5SClVEWdsMd4yx8n3ipbF mCNPI4llkDp+WbCv8j4Iufys+l8dnouAPOLcA1MlnKn0MRxVKvu3iLzb8ErzXvHpk2mc2xQ8J6Cld g437XngIyA95RwFLggLTRNWZO1VIuadRJ7mMtDXd8nVsD8ENusveiZdw9nO0QL+cMUmyLDp7mrASp IzfqnVnJIvODlHsatqsTiRRCZ4r1+NWzXmOKvzsjVAdyXD94CS8o+RRSDlWqAwMcWDnDRiUmwOqgV fEfZLFlO9iv/rq5RAEQFb4C4xL9F4Q48yeytoav6qT3Um4DThEiy55utbgvOWUXLh9ORZfmhf/Bu1 dz7sOQhLw==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lYtKB-00Caa4-CH; Tue, 20 Apr 2021 16:34:07 +0000 Received: from bombadil.infradead.org ([2607:7c80:54:e::133]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lYtK8-00CaZz-Od for linux-arm-kernel@desiato.infradead.org; Tue, 20 Apr 2021 16:34:04 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Content-Transfer-Encoding: Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To: Subject:Sender:Reply-To:Content-ID:Content-Description; bh=UM+dMdbVQhF6/wEeJythbf1GXG4179triuvsT1MCp7k=; b=V4xs9f4FURTVfxA79FUvjS5IQa L5CnqYdQJ66RI555QTd1cOzh8FaFn0d6wTUMzTNTHqw4LL1/P3yOTe0rPhw6deY06Q3hIPKcBStG4 2CeODOKGx3jepPAZLRZRgDZTxJlITgkrp/pGS8I572PtYIlPNmNYnlf6sJHoyZWHTEMw8Qx6fBUrb CAMTlhtEL7oYeyDUI6A2MPCngZ+gHo1fOJfFX9fs+dk4oyrN8oEpGlU1vDpkOV+fQIV5vwB7iLI66 GFkGsUp1hoO95t6919wyQxBjoyljBOcW4mGrmoqLzpmxEWv24++016SSKTJjdpWRbh8GTBA7INj96 40gT5JJQ==; Received: from mail-pj1-x1030.google.com ([2607:f8b0:4864:20::1030]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lYtK5-00CHFc-Op for linux-arm-kernel@lists.infradead.org; Tue, 20 Apr 2021 16:34:03 +0000 Received: by mail-pj1-x1030.google.com with SMTP id e8-20020a17090a7288b029014e51f5a6baso15640455pjg.2 for ; Tue, 20 Apr 2021 09:34:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=UM+dMdbVQhF6/wEeJythbf1GXG4179triuvsT1MCp7k=; b=HHguGrca/YnX5zvrg/zyA5ib8dorH+vbiVydZIBGnOTrZDVSPKkxGmn/2Zh0ViYJPP vaH5/rVI//OExvBd/zrIjnsC5yHCVHTPY58I3hvbiL4gGqO/dz5QL8NdFeSlbMS9/UN4 VOR5cWvlhiIOZaM8LvUJpfQTCVEeWBRN5TMJI0eUc1icTDGvxUNdYQfoUAz4odTFhH/M ACybpRbRYKvlOi/FzRdRjTl0bykJZodO4cytfZ3Vbq81uVwODLMhNgy5egt9MP4zPxru 2fTlS+3jdOLqUwBPXtAWYPbwB5dkZncYozBR69l+mhGlPlV75eotHGeHTMhpFYDTInDs UGwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=UM+dMdbVQhF6/wEeJythbf1GXG4179triuvsT1MCp7k=; b=p81I0mfIE7aRhppPAN6uQoFq9q99NYja1dF5HWVEy2AIO5Bb30To5OmYltXIOEEiKG soBVOPQtpgWSVlgH8IXuhMYF21rYBf3EAdXkqTzkBHbOCAweIv7sBvmI8nRn6eqnf81O d/OHK7kjdbfSUgWeh/uJUlD+FbBD/BSCXBghrQbMeGT4Y8Zeo98xU18gl+xDIZJv9+qo 8yqZywmGxRK0+0VvcJqeJxINXwsDoPiadwdgXcHL5nqGHSdtg7NK/tpgfpo4K+0Hyfez WZQBQ8Bwc47rN/xNJ3yBGCI8VxXC1cFC76E+iAceD8SFi6HClHo0qpLxyNbhYjOVX59h PnOQ== X-Gm-Message-State: AOAM532z2CqXWmiM0XgCOlVMIljTa6JMfnlUZYVn80hFkIDY2bA4ear2 GXWn7bQo/pVSYX+j0j+EOwL2aRECB9Q= X-Google-Smtp-Source: ABdhPJzrGgZJ0j6PBXGMdQjic3VH9EIjR5N/4AUT0Jz4ZB0LyvB+65+ONhP5bpiPere+pwlvYQzI/Q== X-Received: by 2002:a17:902:d506:b029:eb:27ef:3eb5 with SMTP id b6-20020a170902d506b02900eb27ef3eb5mr30070214plg.8.1618936439944; Tue, 20 Apr 2021 09:33:59 -0700 (PDT) Received: from [10.230.29.202] ([192.19.223.252]) by smtp.gmail.com with ESMTPSA id j8sm16509941pgn.55.2021.04.20.09.33.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 20 Apr 2021 09:33:59 -0700 (PDT) Subject: Re: [v5.4 stable] arm: stm32: Regression observed on "no-map" reserved memory region To: Ard Biesheuvel , Rob Herring Cc: Alexandre TORGUE , Quentin Perret , Greg Kroah-Hartman , Sasha Levin , stable , Arnd Bergmann , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , "linux-kernel@vger.kernel.org" , Nicolas Boichat , Stephen Boyd , KarimAllah Ahmed , Android Kernel Team , Architecture Mailman List , Frank Rowand , linux-arm-kernel References: <4a4734d6-49df-677b-71d3-b926c44d89a9@foss.st.com> <001f8550-b625-17d2-85a6-98a483557c70@foss.st.com> From: Florian Fainelli Message-ID: Date: Tue, 20 Apr 2021 09:33:56 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210420_093401_857268_77F3849C X-CRM114-Status: GOOD ( 31.97 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 4/20/2021 9:10 AM, Ard Biesheuvel wrote: > On Tue, 20 Apr 2021 at 17:54, Rob Herring wrote: >> >> On Tue, Apr 20, 2021 at 10:12 AM Alexandre TORGUE >> wrote: >>> >>> >>> >>> On 4/20/21 4:45 PM, Rob Herring wrote: >>>> On Tue, Apr 20, 2021 at 9:03 AM Alexandre TORGUE >>>> wrote: >>>>> >>>>> Hi, >>>> >>>> Greg or Sasha won't know what to do with this. Not sure who follows >>>> the stable list either. Quentin sent the patch, but is not the author. >>>> Given the patch in question is about consistency between EFI memory >>>> map boot and DT memory map boot, copying EFI knowledgeable folks would >>>> help (Ard B for starters). >>> >>> Ok thanks for the tips. I add Ard in the loop. >> >> Sigh. If it was only Ard I was suggesting I would have done that >> myself. Now everyone on the patch in question and relevant lists are >> Cc'ed. >> > > Thanks for the cc. > >>> >>> Ard, let me know if other people have to be directly added or if I have >>> to resend to another mailing list. >>> >>> thanks >>> alex >>> >>>> >>>>> >>>>> Since v5.4.102 I observe a regression on stm32mp1 platform: "no-map" >>>>> reserved-memory regions are no more "reserved" and make part of the >>>>> kernel System RAM. This causes allocation failure for devices which try >>>>> to take a reserved-memory region. >>>>> >>>>> It has been introduced by the following path: >>>>> >>>>> "fdt: Properly handle "no-map" field in the memory region >>>>> [ Upstream commit 86588296acbfb1591e92ba60221e95677ecadb43 ]" >>>>> which replace memblock_remove by memblock_mark_nomap in no-map case. >>>>> > > Why was this backported? It doesn't look like a bugfix to me. > >>>>> Reverting this patch it's fine. >>>>> >>>>> I add part of my DT (something is maybe wrong inside): >>>>> >>>>> memory@c0000000 { >>>>> reg = <0xc0000000 0x20000000>; >>>>> }; >>>>> >>>>> reserved-memory { >>>>> #address-cells = <1>; >>>>> #size-cells = <1>; >>>>> ranges; >>>>> >>>>> gpu_reserved: gpu@d4000000 { >>>>> reg = <0xd4000000 0x4000000>; >>>>> no-map; >>>>> }; >>>>> }; >>>>> >>>>> Sorry if this issue has already been raised and discussed. >>>>> > > Could you explain why it fails? The region is clearly part of system > memory, and tagged as no-map, so the patch in itself is not > unreasonable. However, we obviously have code that relies on how the > region is represented in /proc/iomem, so it would be helpful to get > some insight into why this is the case. I do wonder as well, we have a 32MB "no-map" reserved memory region on our platforms located at 0xfe000000. Without the offending commit, /proc/iomem looks like this: 40000000-fdffefff : System RAM 40008000-40ffffff : Kernel code 41e00000-41ef1d77 : Kernel data 100000000-13fffffff : System RAM and with the patch applied, we have this: 40000000-fdffefff : System RAM 40008000-40ffffff : Kernel code 41e00000-41ef3db7 : Kernel data fdfff000-ffffffff : System RAM 100000000-13fffffff : System RAM so we can now see that the region 0xfe000000 - 0xfffffff is also cobbled up with the preceding region which is a mailbox between Linux and the secure monitor at 0xfdfff000 and of size 4KB. It seems like there is The memblock=debug outputs is also different: [ 0.000000] MEMBLOCK configuration: [ 0.000000] memory size = 0xfdfff000 reserved size = 0x7ce4d20d [ 0.000000] memory.cnt = 0x2 [ 0.000000] memory[0x0] [0x00000040000000-0x000000fdffefff], 0xbdfff000 bytes flags: 0x0 [ 0.000000] memory[0x1] [0x00000100000000-0x0000013fffffff], 0x40000000 bytes flags: 0x0 [ 0.000000] reserved.cnt = 0x6 [ 0.000000] reserved[0x0] [0x00000040003000-0x0000004000e494], 0xb495 bytes flags: 0x0 [ 0.000000] reserved[0x1] [0x00000040200000-0x00000041ef1d77], 0x1cf1d78 bytes flags: 0x0 [ 0.000000] reserved[0x2] [0x00000045000000-0x000000450fffff], 0x100000 bytes flags: 0x0 [ 0.000000] reserved[0x3] [0x00000047000000-0x0000004704ffff], 0x50000 bytes flags: 0x0 [ 0.000000] reserved[0x4] [0x000000c2c00000-0x000000fdbfffff], 0x3b000000 bytes flags: 0x0 [ 0.000000] reserved[0x5] [0x00000100000000-0x0000013fffffff], 0x40000000 bytes flags: 0x0 [ 0.000000] MEMBLOCK configuration: [ 0.000000] memory size = 0x100000000 reserved size = 0x7ca4f24d [ 0.000000] memory.cnt = 0x3 [ 0.000000] memory[0x0] [0x00000040000000-0x000000fdffefff], 0xbdfff000 bytes flags: 0x0 [ 0.000000] memory[0x1] [0x000000fdfff000-0x000000ffffffff], 0x2001000 bytes flags: 0x4 [ 0.000000] memory[0x2] [0x00000100000000-0x0000013fffffff], 0x40000000 bytes flags: 0x0 [ 0.000000] reserved.cnt = 0x6 [ 0.000000] reserved[0x0] [0x00000040003000-0x0000004000e494], 0xb495 bytes flags: 0x0 [ 0.000000] reserved[0x1] [0x00000040200000-0x00000041ef3db7], 0x1cf3db8 bytes flags: 0x0 [ 0.000000] reserved[0x2] [0x00000045000000-0x000000450fffff], 0x100000 bytes flags: 0x0 [ 0.000000] reserved[0x3] [0x00000047000000-0x0000004704ffff], 0x50000 bytes flags: 0x0 [ 0.000000] reserved[0x4] [0x000000c3000000-0x000000fdbfffff], 0x3ac00000 bytes flags: 0x0 [ 0.000000] reserved[0x5] [0x00000100000000-0x0000013fffffff], 0x40000000 bytes flags: 0x0 in the second case we can clearly see that the 32MB no-map region is now considered as usable RAM. Hope this helps. > > In any case, the mere fact that this causes a regression should be > sufficient justification to revert/withdraw it from v5.4, as I don't > see a reason why it was merged there in the first place. (It has no > fixes tag or cc:stable) Agreed, however that means we still need to find out whether a more recent kernel is also broken, I should be able to tell you that a little later. -- Florian _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel