[PATCH v7 7/9] of: reserved_mem: mark /reserved-memory entries with MEMBLOCK_NODUMP

[sashiko-bot at kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] of: reserved_mem: unconditional MEMBLOCK_NODUMP breaks firmware debugging
--

commit 70f4cbca539766519d8967f7e857d2db27db4c13
Author: Wandun Chen <chenwandun at lixiang.com>

of: reserved_mem: mark /reserved-memory entries with MEMBLOCK_NODUMP

This commit marks non-dumpable reserved-memory regions with MEMBLOCK_NODUMP
so kdump can omit them from the vmcore. The marking is guarded by
CONFIG_CRASH_DUMP to avoid splitting memblock.memory entries unnecessarily
on non-kdump kernels.

> diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
> --- a/drivers/of/of_reserved_mem.c
> +++ b/drivers/of/of_reserved_mem.c

[ ... ]

> @@ -677,6 +677,21 @@ static void __init fdt_init_reserved_mem_node(...)
>  	reserved_mem_count++;
>  }
>  
> +void __init fdt_mark_reserve_mem_nodump(void)
> +{
> +	struct reserved_mem *rmem;
> +	int i;
> +
> +	if (!IS_ENABLED(CONFIG_CRASH_DUMP))
> +		return;
> +
> +	for (i = 0; i < reserved_mem_count; i++) {
> +		rmem = &reserved_mem[i];
> +		if (rmem->size && !rmem->dumpable)
> +			memblock_mark_nodump(rmem->base, rmem->size);

[Severity: High]
Does this unconditional masking prevent debugging of coprocessor memory and
firmware state in vmcores?

Since only the CMA driver sets dumpable to true, it appears all other
generic /reserved-memory regions (such as DSP logs or ramoops) default
to false.

Because fdt_mark_reserve_mem_nodump() unconditionally applies
MEMBLOCK_NODUMP to these regions, and there is no Device Tree property
provided to opt them back in, is there a risk that system administrators
will lose the ability to inspect these regions after a crash?

> +	}
> +}
> +
>  struct rmem_assigned_device {
>  	struct device *dev;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260922084256.1515554-1-chenwandun1@gmail.com?part=7