Message ID | 20230410120017.41664-2-tanure@linux.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp1856678vqo; Mon, 10 Apr 2023 05:21:32 -0700 (PDT) X-Google-Smtp-Source: AKy350bK65dY/dKtdezThVeDZB4/+DPZcdImn9Y6D41ghwwkXoKEQxAlcbsl84kU69DgQvxKGn8d X-Received: by 2002:a17:906:524f:b0:947:a6d7:e2b4 with SMTP id y15-20020a170906524f00b00947a6d7e2b4mr7330893ejm.8.1681129292156; Mon, 10 Apr 2023 05:21:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1681129292; cv=none; d=google.com; s=arc-20160816; b=TYThGsBeT+r2xHB+hheJGMq86bUhgK4f1rZi+WuV6FXxvfvojF3UbALHAn7BcVuKrq wWKRSTCcxQkOlAngljARLzNEUvbhZvvdDZxE1X5LPEH8fu2o3Ty7HO28h2svupJWBp2P avpXWqzG7aYU67H/906BprjhYDvoyCVdjFB7DLKKOcO8t3vd/4RToETEoZOOY24SbVjt wxsNu4VC9BdHawkgSZE+CCZl2gxAvExIxXA8slNGoIhRL6QkJLcVr2FTRbG/aDf/XSFW UdAXfHPR0SBwLaOqZKGRn5QNZGEP3K4HA0gTDO5ua37r73I+vwpyZv1ygT4al1KvZ0p7 XVfw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=Hdg6OnGdhnbQDxiR6CHlfN0w6V2p30dC7To9wkPjF7U=; b=qQaEXMB7bFbUCPjCHieCtrk0hf3370SRDc7sY3aML3u4zSA/B1NchVWWxSgNwutW96 Wo9KUFRN7wLQ12M+HQCiztdT+lDk46cT5DHfNsIIsiZM9QVrou/bgZoZgF/SKiJjJedL jsgJ52pP9NbI4tYVOxvaAi9uoH2r/hfcGVKnS8+ExOYFxVdxwOmhxXER+XoNi3Rsv49D GMZnu6GHxC9tGp7hzzATdIx873u8UpgCtk/ZYr/amB4fNja2x8FcjIQchTwOYIMrQSJL umK7jCf8wkGatxquL1Oym8KdX1kV1jgTG5d/FUuT6fuJGvnDYqoVTpGNsTlwmdm1KcGz kKiQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id sy23-20020a1709076f1700b0094a82b2fb70si2358669ejc.567.2023.04.10.05.21.08; Mon, 10 Apr 2023 05:21:32 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229794AbjDJMAc (ORCPT <rfc822;yuanzuo1009@gmail.com> + 99 others); Mon, 10 Apr 2023 08:00:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55844 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229485AbjDJMA3 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 10 Apr 2023 08:00:29 -0400 Received: from mail-oa1-f49.google.com (mail-oa1-f49.google.com [209.85.160.49]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F208A5591; Mon, 10 Apr 2023 05:00:28 -0700 (PDT) Received: by mail-oa1-f49.google.com with SMTP id 586e51a60fabf-184518754bfso2013030fac.5; Mon, 10 Apr 2023 05:00:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1681128028; x=1683720028; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Hdg6OnGdhnbQDxiR6CHlfN0w6V2p30dC7To9wkPjF7U=; b=x/+d+Pa5raAbMOCjUJ418G45tcEHXQtCCUhIFIU/+iz9nQHdNHTKWmhGNbZ9m+Lays 9aWtQh+57LPzNpgSsX3H7p83lKNYmEl6ZWVoa7N53fV8vYYtmEgt6MbcpMKgrcUU7z4z Y4nxQbXtHhsO7i3kr34SSeEhLgzHw1o00J45wMlFF6EVqBMnGNf6apFVCEH0mTn54/bi f6IFoLPJQtqBTHLp2s+neFPvWjXPxJ0yDe0m+4vlqgRqJgwK/YEI4nRR01hNu/VeVZC/ Ts+ygdQEq6VwIwChnEW/3EvfJ0B0j3FkAYUFAHyE10jiGebwRFmUkNuu1FAJBx0yfEoV 3yng== X-Gm-Message-State: AAQBX9cPLSr8JclXo6JX7lM1bRutgP4OFGSAEdmdzHZgpCvt/7DuJqIr Gp7l9/tbcCFHYW8fkKxUb8c= X-Received: by 2002:a05:6870:c155:b0:180:2a5e:7f8f with SMTP id g21-20020a056870c15500b001802a5e7f8fmr6126629oad.22.1681128028235; Mon, 10 Apr 2023 05:00:28 -0700 (PDT) Received: from archfamilia.lan ([181.219.149.7]) by smtp.gmail.com with ESMTPSA id j4-20020a9d7384000000b0069f9203967bsm4141884otk.76.2023.04.10.05.00.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 10 Apr 2023 05:00:27 -0700 (PDT) From: Lucas Tanure <tanure@linux.com> To: Rob Herring <robh+dt@kernel.org>, Frank Rowand <frowand.list@gmail.com>, Mike Rapoport <rppt@kernel.org>, Andrew Morton <akpm@linux-foundation.org> Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, jbrunet@baylibre.com, linux-amlogic@lists.infradead.org, linux-arm-kernel@lists.infradead.org, martin.blumenstingl@googlemail.com, narmstrong@baylibre.com, stefan@agner.ch, Lucas Tanure <tanure@linux.com> Subject: [PATCH v2 1/1] of: fdt: Scan /memreserve/ last Date: Mon, 10 Apr 2023 08:00:17 -0400 Message-Id: <20230410120017.41664-2-tanure@linux.com> X-Mailer: git-send-email 2.40.0 In-Reply-To: <20230410120017.41664-1-tanure@linux.com> References: <20230410120017.41664-1-tanure@linux.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.5 required=5.0 tests=FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1762791828341298895?= X-GMAIL-MSGID: =?utf-8?q?1762791828341298895?= |
Series |
Fix Random Kernel panic from when fail to reserve memory
|
|
Commit Message
Lucas Tanure
April 10, 2023, noon UTC
Change the order of scanning /memreserve/ and /reserved-memory node.
/reserved-memory node should go first, as it has a more updated
description of the memory regions and it can apply flags, like nomap.
Also, /memreserve/ should avoid reserving regions described in
/reserved-memory node.
Signed-off-by: Lucas Tanure <tanure@linux.com>
---
drivers/of/fdt.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
Comments
On Mon, Apr 10, 2023 at 7:00 AM Lucas Tanure <tanure@linux.com> wrote: > > Change the order of scanning /memreserve/ and /reserved-memory node. > /reserved-memory node should go first, as it has a more updated > description of the memory regions and it can apply flags, like nomap. > Also, /memreserve/ should avoid reserving regions described in > /reserved-memory node. Like I said on v1, I think doing this has a high chance of causing regressions on other platforms. It should probably not go to stable for some time after a kernel release. > Signed-off-by: Lucas Tanure <tanure@linux.com> > --- > drivers/of/fdt.c | 9 +++++++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > > diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c > index d1a68b6d03b3..26e608d8025d 100644 > --- a/drivers/of/fdt.c > +++ b/drivers/of/fdt.c > @@ -635,16 +635,21 @@ void __init early_init_fdt_scan_reserved_mem(void) > if (!initial_boot_params) > return; > > + fdt_scan_reserved_mem(); > + fdt_reserve_elfcorehdr(); > + > /* Process header /memreserve/ fields */ > for (n = 0; ; n++) { > fdt_get_mem_rsv(initial_boot_params, n, &base, &size); > if (!size) > break; > + if (memblock_overlaps_region(&memblock.memory, base, size) && > + memblock_is_region_reserved(base, size)) Just to make sure, a partial overlap will still get reserved? > + break; Shouldn't we continue to the next entry rather than stopping. > + > memblock_reserve(base, size); > } > > - fdt_scan_reserved_mem(); > - fdt_reserve_elfcorehdr(); > fdt_init_reserved_mem(); > } > > -- > 2.40.0 >
On Mon, Apr 10, 2023 at 8:52 AM Rob Herring <robh+dt@kernel.org> wrote: > > On Mon, Apr 10, 2023 at 7:00 AM Lucas Tanure <tanure@linux.com> wrote: > > > > Change the order of scanning /memreserve/ and /reserved-memory node. > > /reserved-memory node should go first, as it has a more updated > > description of the memory regions and it can apply flags, like nomap. > > Also, /memreserve/ should avoid reserving regions described in > > /reserved-memory node. > > Like I said on v1, I think doing this has a high chance of causing > regressions on other platforms. It should probably not go to stable > for some time after a kernel release. > > > Signed-off-by: Lucas Tanure <tanure@linux.com> > > --- > > drivers/of/fdt.c | 9 +++++++-- > > 1 file changed, 7 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c > > index d1a68b6d03b3..26e608d8025d 100644 > > --- a/drivers/of/fdt.c > > +++ b/drivers/of/fdt.c > > @@ -635,16 +635,21 @@ void __init early_init_fdt_scan_reserved_mem(void) > > if (!initial_boot_params) > > return; > > > > + fdt_scan_reserved_mem(); > > + fdt_reserve_elfcorehdr(); > > + > > /* Process header /memreserve/ fields */ > > for (n = 0; ; n++) { > > fdt_get_mem_rsv(initial_boot_params, n, &base, &size); > > if (!size) > > break; > > + if (memblock_overlaps_region(&memblock.memory, base, size) && > > + memblock_is_region_reserved(base, size)) > > Just to make sure, a partial overlap will still get reserved? A partial overlap will get reserved if not already reserved by the /reserved-memory node. > > > + break; > > Shouldn't we continue to the next entry rather than stopping. Yes, my mistake; I will send v3. > > > + > > memblock_reserve(base, size); > > } > > > > - fdt_scan_reserved_mem(); > > - fdt_reserve_elfcorehdr(); > > fdt_init_reserved_mem(); > > } > > > > -- > > 2.40.0 > >
On Mon, Apr 10, 2023 at 08:00:17AM -0400, Lucas Tanure wrote: > Change the order of scanning /memreserve/ and /reserved-memory node. > /reserved-memory node should go first, as it has a more updated > description of the memory regions and it can apply flags, like nomap. > Also, /memreserve/ should avoid reserving regions described in > /reserved-memory node. > > Signed-off-by: Lucas Tanure <tanure@linux.com> > --- > drivers/of/fdt.c | 9 +++++++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > > diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c > index d1a68b6d03b3..26e608d8025d 100644 > --- a/drivers/of/fdt.c > +++ b/drivers/of/fdt.c > @@ -635,16 +635,21 @@ void __init early_init_fdt_scan_reserved_mem(void) > if (!initial_boot_params) > return; > > + fdt_scan_reserved_mem(); > + fdt_reserve_elfcorehdr(); > + > /* Process header /memreserve/ fields */ > for (n = 0; ; n++) { > fdt_get_mem_rsv(initial_boot_params, n, &base, &size); > if (!size) > break; > + if (memblock_overlaps_region(&memblock.memory, base, size) && > + memblock_is_region_reserved(base, size)) > + break; I don't think this is really needed, it's ok to reserve the same ranges multiple times. Both checks are not cheap, so it'll be better to just reserve everything both from performance and simplicity points of view. > + > memblock_reserve(base, size); > } > > - fdt_scan_reserved_mem(); > - fdt_reserve_elfcorehdr(); > fdt_init_reserved_mem(); > } > > -- > 2.40.0 >
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c index d1a68b6d03b3..26e608d8025d 100644 --- a/drivers/of/fdt.c +++ b/drivers/of/fdt.c @@ -635,16 +635,21 @@ void __init early_init_fdt_scan_reserved_mem(void) if (!initial_boot_params) return; + fdt_scan_reserved_mem(); + fdt_reserve_elfcorehdr(); + /* Process header /memreserve/ fields */ for (n = 0; ; n++) { fdt_get_mem_rsv(initial_boot_params, n, &base, &size); if (!size) break; + if (memblock_overlaps_region(&memblock.memory, base, size) && + memblock_is_region_reserved(base, size)) + break; + memblock_reserve(base, size); } - fdt_scan_reserved_mem(); - fdt_reserve_elfcorehdr(); fdt_init_reserved_mem(); }