Question about the "Dynamic reserved memory" patch

[Valdis Kl=?utf-8?Q?=c4=93?=tnieks]

On Fri, 13 Mar 2020 12:06:37 +0900, <kjhg4321 at naver.com> said:

> In the __reserved_mem_reserve_reg() function, I found something that
> I couldn't easily understand.
>
> To get help, I sent an e-mail to this mailing list.

>                 if (first) {
>                         fdt_reserved_mem_save_node(node, uname, base, size);
>                         first = 0;
>                 }

> I found that fdt_reserved_mem_save_node() is called the regardless of
> memblock remove/reserve success.
>
> I think early_init_dt_reserve_memory_arch() can fail.(ex. for the lack
> of memblock's region)
>
> So I wonder there will be a situation where reserved_mem
> initialization will be executed without memory reservation.

What you probably missed is that function is wrapped in a #ifdef
CONFIG_OF_EARLY_FLATTREE - and is called to read in the OF devicetree data and
save it in a form the kernel can use.

So there usually shouldn't be a problem in reserving memory early in boot,
unless of course somebody bollixed up a devicetree entry and put in bad values
for base, size, and nomap.   If that happens, the pr_info() call will fire and
hopefully notify somebody there's a problem.

However, fdt_reserved_mem_save_node() needs to happen anyhow, because that's
not initialiing the memory that wasn't actually reserved, it's recording the
fact that the devicetree had a reserved memory request in it, and that needs to
be remembered because there's a second pass over the devicetree data later on
(or so the comments in drivers/of/of_reserved_mem.c tell me).

Having said that, it *may* make sense to elevate the pr_info() call to a
pr_err(), to make it *obvious* that something went pear-shaped in the
devicetree. But that's a decision for the devicetree/OF maintainers.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20200312/d3ff4843/attachment.sig>