On Fri, 13 Mar 2020 12:06:37 +0900, <kjhg4321@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.