Re: [v5.4 stable] arm: stm32: Regression observed on "no-map" reserved memory region

On Tue, Apr 20, 2021 at 11:10 AM Ard Biesheuvel [off-list ref] wrote:

On Tue, 20 Apr 2021 at 17:54, Rob Herring [off-list ref] wrote:

quoted

On Tue, Apr 20, 2021 at 10:12 AM Alexandre TORGUE
[off-list ref] wrote:

quoted

On 4/20/21 4:45 PM, Rob Herring wrote:

quoted

On Tue, Apr 20, 2021 at 9:03 AM Alexandre TORGUE
[off-list ref] wrote:

quoted

Hi,

Greg or Sasha won't know what to do with this. Not sure who follows
the stable list either. Quentin sent the patch, but is not the author.
Given the patch in question is about consistency between EFI memory
map boot and DT memory map boot, copying EFI knowledgeable folks would
help (Ard B for starters).

Ok thanks for the tips. I add Ard in the loop.

Sigh. If it was only Ard I was suggesting I would have done that
myself. Now everyone on the patch in question and relevant lists are
Cc'ed.

Thanks for the cc.

quoted

quoted

Ard, let me know if other people have to be directly added or if I have
to resend to another mailing list.

thanks
alex

quoted

quoted

Since v5.4.102 I observe a regression on stm32mp1 platform: "no-map"
reserved-memory regions are no more "reserved" and make part of the
kernel System RAM. This causes allocation failure for devices which try
to take a reserved-memory region.

It has been introduced by the following path:

"fdt: Properly handle "no-map" field in the memory region
[ Upstream commit 86588296acbfb1591e92ba60221e95677ecadb43 ]"
which replace memblock_remove by memblock_mark_nomap in no-map case.

Why was this backported? It doesn't look like a bugfix to me.

Probably because of commit 8a5a75e5e9e5 ("of/fdt: Make sure no-map
does not remove already reserved regions") which was in the same
series.

'Properly handle' implies before it was 'improperly handled', so
sounds like a fix.

Rob