LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Vishal Chourasia <vishalc@linux.ibm.com>
To: sashiko-reviews@lists.linux.dev, linuxppc-dev@lists.ozlabs.org,
	linux-kernel@vger.kernel.org, kexec@lists.infradead.org,
	x86@kernel.org
Subject: Re: [PATCH] powerpc/crash: Add only the onlined CPU's node to the crash FDT
Date: Wed, 4 Nov 2026 19:44:48 +0530	[thread overview]
Message-ID: <ac2eaf0b-10bf-4f58-8c9a-fd195ff569ea@linux.ibm.com> (raw)
In-Reply-To: <sashiko-outbox-196696@kernel.org>


On 04/11/26 11:22, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] powerpc/crash: detached DLPAR CPU nodes accumulate in crash FDT in update_crash_fdt()
> - [High] powerpc/crash: incomplete CPU subnode left in FDT on fdt_setprop() failure in update_crash_fdt()
> --
>
> commit f91f7035e04400925af984e21ed910579118bae0
> Author: Vishal Chourasia <vishalc@linux.ibm.com>
>
> powerpc/crash: Add only the onlined CPU's node to the crash FDT
>
> This patch updates crash FDT handling on CPU online events to pass the onlined
> CPU number to arch_crash_handle_hotplug_event() and insert only that CPU's
> device node into the crash FDT if it is not already present, rather than
> rebuilding all CPU nodes via update_cpus_node().
>
>> diff --git a/arch/powerpc/kexec/crash.c b/arch/powerpc/kexec/crash.c
>> index 775895f310379..ca37006bddeae 100644
>> --- a/arch/powerpc/kexec/crash.c
>> +++ b/arch/powerpc/kexec/crash.c
> [ ... ]
>> @@ -584,32 +585,71 @@ static int get_fdt_index(struct kimage *image)
>>   }
>>   
>>   /**
>> - * update_crash_fdt - updates the cpus node of the crash FDT.
>> + * update_crash_fdt - add the node of the onlined CPU to the crash FDT.
>>    *
>>    * @image: a pointer to kexec_crash_image
>> + * @cpu: the CPU that was onlined
>> + *
>> + * The node is added as the first child of /cpus, the same position a node
>> + * attached to the live device tree takes. Nothing is done if the FDT already
>> + * has the node, for example when an offlined CPU comes back.
>>    */
>> -static void update_crash_fdt(struct kimage *image)
>> +static void update_crash_fdt(struct kimage *image, unsigned int cpu)
>>   {
>> +	struct device_node *dn;
>> +	struct property *pp;
>>   	void *fdt;
>> -	int fdt_index;
>> +	int fdt_index, cpus_offset, node_offset;
>> +
>> +	dn = of_get_cpu_node(cpu, NULL);
>> +	if (!dn) {
>> +		pr_err("No device node found for CPU %u\n", cpu);
>> +		return;
>> +	}
>>   
>>   	fdt_index = get_fdt_index(image);
>>   	if (fdt_index < 0) {
>>   		pr_err("Unable to locate FDT segment.\n");
>> -		return;
>> +		goto put;
>>   	}
>>   
>>   	fdt = __va((void *)image->segment[fdt_index].mem);
>>   
>> -	/* Temporarily invalidate the crash image while it is replaced */
>> +	cpus_offset = fdt_path_offset(fdt, "/cpus");
>> +	if (cpus_offset < 0) {
>> +		pr_err("Malformed device tree: error reading /cpus node: %s\n",
>> +		       fdt_strerror(cpus_offset));
>> +		goto put;
>> +	}
>> +
>> +	/* Node already present, e.g. an offlined CPU came back online */
>> +	if (fdt_subnode_offset(fdt, cpus_offset, dn->full_name) >= 0)
>> +		goto put;
>> +
>> +	/* Temporarily invalidate the crash image while it is updated */
>>   	xchg(&kexec_crash_image, NULL);
>>   
>> -	/* update FDT to reflect changes in CPU resources */
>> -	if (update_cpus_node(fdt))
>> -		pr_err("Failed to update crash FDT");
>> +	node_offset = fdt_add_subnode(fdt, cpus_offset, dn->full_name);
> [Severity: High]
> What happens across DLPAR CPU removal and addition when update_crash_fdt()
> only appends missing CPU nodes and never removes detached ones?
>
> On pSeries, dlpar_cpu_remove() offlines the CPU threads (where
> KEXEC_CRASH_HP_REMOVE_CPU is a no-op in arch_crash_handle_hotplug_event()),
> pseries_cpuhp_detach_nodes() detaches the CPU device_node from /cpus in the
> live device tree, and pseries_remove_processor() clears its bits in
> cpu_present_mask so those logical CPU IDs can be reused.
>
> Previously, update_cpus_node() deleted all existing cpu subnodes under /cpus
> in the crash FDT and rebuilt them from the live /cpus tree, purging any
> detached DLPAR CPU nodes. With this change, detached CPU subnodes remain in
> the crash FDT indefinitely:

As mentioned in the previous paragraph, during the CPU offline path,
crash handler doesn't update the crash image and returns early.
update_cpus_node() is not invoked.

>
> 1. kdump_extra_fdt_size_ppc64() in arch/powerpc/kexec/file_load_64.c only
>     budgets extra FDT space for possible_cpu_nodes concurrent CPU nodes:
>
> 	if (image->type == KEXEC_TYPE_CRASH) {
> 		possible_cpu_nodes = num_possible_cpus() / threads_per_core;
> 		if (possible_cpu_nodes > cpu_nodes)
> 			extra_size += (possible_cpu_nodes - cpu_nodes) * cpu_node_size();
> 	}
>
>     When a CPU is DLPAR-removed and a CPU with a different DRC index is
>     DLPAR-added, retaining the detached node alongside the newly added node
>     exceeds possible_cpu_nodes and causes fdt_add_subnode() or fdt_setprop() to
>     fail with -FDT_ERR_NOSPACE.
Behaviour is same as before.
>
> 2. Because detached nodes remain under /cpus in the crash FDT,
>     smp_setup_cpu_maps() in the kdump kernel still iterates over them and
>     assigns logical CPU IDs up to nr_cpu_ids, which can push valid present
>     CPUs past nr_cpu_ids.
>
> 3. If the same DRC index is later DLPAR-added again via
>     dlpar_configure_connector() with updated properties (such as
>     ibm,associativity), fdt_subnode_offset(fdt, cpus_offset, dn->full_name) >= 0
>     matches the stale node and skips updating its properties.
>
>> +	if (node_offset < 0) {
>> +		pr_err("Unable to add %s subnode: %s\n", dn->full_name,
>> +		       fdt_strerror(node_offset));
>> +		goto out;
>> +	}
>>   
>> +	for_each_property_of_node(dn, pp) {
>> +		int ret = fdt_setprop(fdt, node_offset, pp->name, pp->value, pp->length);
>> +
>> +		if (ret < 0) {
>> +			pr_err("Unable to add %s property: %s\n", pp->name,
>> +			       fdt_strerror(ret));
>> +			break;
>> +		}
>> +	}
> [Severity: High]
> If fdt_setprop() fails partway through copying the properties in
> update_crash_fdt(), should node_offset be removed with fdt_del_node(fdt,
> node_offset) before breaking out?
>
> Leaving the partially populated subnode under /cpus has two consequences:
>
> 1. Any subsequent update_crash_fdt() call for sibling SMT threads of the same
>     core (or a later re-online of the CPU) sees
>     fdt_subnode_offset(fdt, cpus_offset, dn->full_name) >= 0 and returns early
>     without populating the missing properties.
>
> 2. If the device_type = "cpu" property was written before fdt_setprop() failed
>     on ibm,ppc-interrupt-server#s and reg, early_init_dt_scan_cpus() in
>     arch/powerpc/kernel/prom.c will match the partial CPU node during kdump
>     boot, get NULL for intserv with len left uninitialized, and dereference
>     intserv[i]:
>
> 	intserv = of_get_flat_dt_prop(node, "ibm,ppc-interrupt-server#s", &len);
> 	if (!intserv)
> 		intserv = of_get_flat_dt_prop(node, "reg", &len);
>
> 	nthreads = len / sizeof(int);
>
> 	for (i = 0; i < nthreads; i++) {
> 		if (be32_to_cpu(intserv[i]) ==
> 			fdt_boot_cpuid_phys(initial_boot_params)) {

Similar errors on update_cpus_node() can live the crash fdt
inconsistent and result in crash kernel boot hangs.

>


      parent reply	other threads:[~2026-11-04 14:15 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-04  5:38 [PATCH] powerpc/crash: Add only the onlined CPU's node to the crash FDT Vishal Chourasia
2026-11-04  8:13 ` Mukesh Pilaniya
     [not found] ` <sashiko-outbox-196696@kernel.org>
2026-11-04 14:14   ` Vishal Chourasia [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=ac2eaf0b-10bf-4f58-8c9a-fd195ff569ea@linux.ibm.com \
    --to=vishalc@linux.ibm.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=x86@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox