linux-hardening.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Isaac J. Manjarres" <isaacmanjarres@google.com>
To: Kees Cook <keescook@chromium.org>,
	Tony Luck <tony.luck@intel.com>,
	"Guilherme G. Piccoli" <gpiccoli@igalia.com>
Cc: "Isaac J. Manjarres" <isaacm@codeaurora.org>,
	Mukesh Ojha <mojha@codeaurora.org>,
	Prasad Sodagudi <psodagud@codeaurora.org>,
	"Isaac J . Manjarres" <isaacmanjarres@google.com>,
	kernel-team@android.com, linux-hardening@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: [PATCH] pstore/ram: Add support for dynamically allocated ramoops memory regions
Date: Wed, 21 Jun 2023 17:52:13 -0700	[thread overview]
Message-ID: <20230622005213.458236-1-isaacmanjarres@google.com> (raw)

From: "Isaac J. Manjarres" <isaacm@codeaurora.org>

The reserved memory region for ramoops is assumed to be at a fixed
and known location when read from the devicetree. This is not desirable
in environments where it is preferred for the region to be dynamically
allocated early during boot (i.e. the memory region is defined with
the "alloc-ranges" property instead of the "reg" property).

If the location of the ramoops region is not fixed via the "reg"
devicetree property, the call to platform_get_resource() will fail
because resources of type IORESOURCE_MEM must be described with the
"reg" property.

Since ramoops regions are part of the reserved-memory devicetree
node, they exist in the reserved_mem array. This means that the
of_reserved_mem_lookup() function can be used to retrieve the
reserved_mem structure for the ramoops region, and that structure
contains the base and size of the region, even if it has been
dynamically allocated.

Thus invoke of_reserved_mem_lookup() in case the call to
platform_get_resource() fails in order to support dynamically
allocated ramoops memory regions.

Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org>
Signed-off-by: Mukesh Ojha <mojha@codeaurora.org>
Signed-off-by: Prasad Sodagudi <psodagud@codeaurora.org>
Signed-off-by: Isaac J. Manjarres <isaacmanjarres@google.com>
---
 fs/pstore/ram.c | 19 ++++++++++++++-----
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
index ade66dbe5f39..e4bbba187011 100644
--- a/fs/pstore/ram.c
+++ b/fs/pstore/ram.c
@@ -20,6 +20,7 @@
 #include <linux/compiler.h>
 #include <linux/of.h>
 #include <linux/of_address.h>
+#include <linux/of_reserved_mem.h>
 
 #include "internal.h"
 #include "ram_internal.h"
@@ -643,6 +644,7 @@ static int ramoops_parse_dt(struct platform_device *pdev,
 {
 	struct device_node *of_node = pdev->dev.of_node;
 	struct device_node *parent_node;
+	struct reserved_mem *rmem;
 	struct resource *res;
 	u32 value;
 	int ret;
@@ -651,13 +653,20 @@ static int ramoops_parse_dt(struct platform_device *pdev,
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	if (!res) {
-		dev_err(&pdev->dev,
-			"failed to locate DT /reserved-memory resource\n");
-		return -EINVAL;
+		rmem = of_reserved_mem_lookup(of_node);
+		if (rmem) {
+			pdata->mem_size = rmem->size;
+			pdata->mem_address = rmem->base;
+		} else {
+			dev_err(&pdev->dev,
+				"failed to locate DT /reserved-memory resource\n");
+			return -EINVAL;
+		}
+	} else {
+		pdata->mem_size = resource_size(res);
+		pdata->mem_address = res->start;
 	}
 
-	pdata->mem_size = resource_size(res);
-	pdata->mem_address = res->start;
 	/*
 	 * Setting "unbuffered" is deprecated and will be ignored if
 	 * "mem_type" is also specified.
-- 
2.41.0.178.g377b9f9a00-goog


             reply	other threads:[~2023-06-22  0:52 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-22  0:52 Isaac J. Manjarres [this message]
2023-06-22  4:47 ` [PATCH] pstore/ram: Add support for dynamically allocated ramoops memory regions John Stultz
2023-06-22  5:15   ` Kees Cook
2023-06-22 17:26     ` Isaac Manjarres
2023-06-22 17:58       ` Kees Cook
2023-06-22 19:51         ` Elliot Berman
2023-06-26 17:34           ` Mukesh Ojha
2023-07-04  6:07             ` Krzysztof Kozlowski
2023-07-05 22:21               ` Kees Cook
2023-07-06 16:00                 ` Mukesh Ojha
2023-07-04  6:05           ` Krzysztof Kozlowski
2023-06-22 17:19   ` Isaac Manjarres
2023-07-04  6:05 ` Krzysztof Kozlowski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230622005213.458236-1-isaacmanjarres@google.com \
    --to=isaacmanjarres@google.com \
    --cc=gpiccoli@igalia.com \
    --cc=isaacm@codeaurora.org \
    --cc=keescook@chromium.org \
    --cc=kernel-team@android.com \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mojha@codeaurora.org \
    --cc=psodagud@codeaurora.org \
    --cc=tony.luck@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).