From: Marten Lindahl <martenli@axis.com>
To: Stephen Boyd <swboyd@chromium.org>
Cc: "Mårten Lindahl" <Marten.Lindahl@axis.com>,
"Rob Herring" <robh+dt@kernel.org>,
"Frank Rowand" <frowand.list@gmail.com>,
"Kees Cook" <keescook@chromium.org>,
"Anton Vorontsov" <anton@enomsg.org>,
"Colin Cross" <ccross@android.com>,
"Tony Luck" <tony.luck@intel.com>, kernel <kernel@axis.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: [PATCH] of: fdt: Check overlap of reserved memory regions
Date: Mon, 17 Jan 2022 17:00:19 +0100 [thread overview]
Message-ID: <YeWSk4KfOE0YEQmY@axis.com> (raw)
In-Reply-To: <CAE-0n51eAN5=pt9RtB6guxmOBy_tGe5mBOpxW6=uKz+=-GUYiQ@mail.gmail.com>
On Thu, Jan 13, 2022 at 11:12:11PM +0100, Stephen Boyd wrote:
> Quoting Marten Lindahl (2022-01-13 07:56:42)
> > On Tue, Jan 11, 2022 at 07:34:00PM +0100, Rob Herring wrote:
> > > On Tue, Jan 11, 2022 at 6:25 AM Mårten Lindahl <marten.lindahl@axis.com> wrote:
> >
> > Hi Rob!
> > Thanks for looking at this.
> > > >
> > > > If a DT specified reserved memory region overlaps an already registered
> > > > reserved region no notification is made. Starting the system with
> > > > overlapped memory regions can make it very hard to debug what is going
> > > > wrong. This is specifically true in case the ramoops console intersects
> > > > with initrd since the console overwrites memory that is used for initrd,
> > > > which leads to memory corruption.
> > > >
> > > > Highlight this by printing a message about overlapping memory regions.
> > >
> > > Won't this be noisy if a region is described in both /memreserve/ and
> > > /reserved-memory node?
> > >
> > Yes, it can potentially be noisy if doing so. But I think notifying this
> > can be useful. Should it perhaps be a notification instead of a warning?
> >
Hi Stephen!
>
> Please don't print any message for /memreserve/ and /reserved-memory nodes
> overlapping. On the chromebook at my desk we have overlapping
> /memreserve/ and /reserved-memory. My understanding is that it's
> redundant to have both, especially when a reserved-memory node has
> 'no-map', but it isn't forbidden. The /memreserve/ is like a no-map
> /resreved-memory node without the phandle.
>
> Given that initrd is special cased in drivers/of/fdt.c can the reserved
> memory handling code look to see if it overlaps with the initrd region
> and skip that /reserved-memory carveout? A warning could probably be
> printed and ramoops should fail to probe.
I understand if the check would spam on some system setups. So yes, I should
make the check less generic. The case which I describe with initrd and ramoops
is something that I think should be warned about.
But this would result in a very specific check for these two regions. So I'm
thinking, since the ramoops region is the one that will cause overwrites of
any other intersecting region, not necessarily just initrd, would it maybe
make sense to just add an extra check for ramoops and then print the warning?
And then still let ramoops run, as it depends on what memory part is
conflicting, and may not necessarily break the system.
Something like this?
if (!fdt_node_check_compatible(initial_boot_params,
node, "ramoops") &&
size && memblock_is_reserved(base)) {
pr_warn("WARNING: %s [0x%08llx+0x%08llx] overlaps reserved memory region\n",
uname, (u64)base, (u64)size);
}
Any more thoughts?
Kind regards
Mårten
prev parent reply other threads:[~2022-01-17 16:00 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-11 12:21 [PATCH] of: fdt: Check overlap of reserved memory regions Mårten Lindahl
2022-01-11 18:34 ` Rob Herring
2022-01-13 15:56 ` Marten Lindahl
2022-01-13 22:12 ` Stephen Boyd
2022-01-17 16:00 ` Marten Lindahl [this message]
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=YeWSk4KfOE0YEQmY@axis.com \
--to=martenli@axis.com \
--cc=Marten.Lindahl@axis.com \
--cc=anton@enomsg.org \
--cc=ccross@android.com \
--cc=devicetree@vger.kernel.org \
--cc=frowand.list@gmail.com \
--cc=keescook@chromium.org \
--cc=kernel@axis.com \
--cc=robh+dt@kernel.org \
--cc=swboyd@chromium.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.