Re: [PATCH v3 3/5] powerpc/xive: propagate IPI init errors to prevent use-after-free

On 7/28/26 10:47, Srikar Dronamraju wrote:
> * Gou Hao <[email protected]> [2026-07-27 18:42:13]:
> 
>>   
>>   static void __init pnv_smp_probe(void)
>>   {
>> -	if (xive_enabled())
>> -		xive_smp_probe();
>> -	else
>> +	if (xive_enabled()) {
>> +		if (xive_smp_probe() < 0)
>> +			return;
>> +	} else {
> 
> If xive_smp_probe() fails and we return from here, what is the IPI mechanism
> that is going to be used?
> 
> Before the patch, we were not configured for IPI and we would fail.
> Now we have not configured IPI mechanism, so what are the consequences?
> 
Thank you for your review.

current approach: If xive_smp_probe() fails, smp_ops->cause_ipi remains 
NULL (patch 0004 defers the assignment). The IPI path 
(smp_muxed_ipi_message_pass) has a NULL check that silently drops the 
IPI. This means SMP won't function, but that's preferable to the current 
use-after-free crash.

> Should we try disable xive_enabled() and try xics_smp_probe() instead?
> 

When xive_enabled() is true, the entire interrupt subsystem has already 
been committed to XIVE in xive_init_host(). XICS fallback may need more 
than just disabling xive_enabled() and calling xics_smp_probe().

Full XIVE → XICS fallback is theoretically possible — the kexec path 
already demonstrates this (e.g., xive_shutdown() on PowerNV calls 
opal_xive_reset(OPAL_XIVE_MODE_EMU), and pSeries has H_INT_RESET). After 
reverting XIVE, one could call xics_init() + xics_smp_probe() to set up 
XICS completely.

Implementing a safe, complete fallback would require careful sequencing 
and likely an xive_exit() counterpart — this is a significantly larger 
change that is beyond the scope of this series, which focuses on 
removing __GFP_NOFAIL and fixing the use-after-free.

-- 
Thanks,
Gou Hao