Re: [PATCH 4/7] s390/pci: fix MSI directed-mode teardown IRQ bit count

["Tobias Schumacher" <ts@linux.ibm.com>]

On Wed Aug 19, 2026 at 11:07 AM CEST, sashiko-bot wrote:
> Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
>
> Pre-existing issues:
> - [High] Double-addition logic error in `zpci_msi_clear_airq()` causes out-of-bounds memory writes and leaves dangling pointers.

yes, see below.

> - [High] Directed MSI teardown leaks uncleared hardware vector bits on CPUs > 0, causing spurious interrupts.
> - [Medium] Missing RCU pointer assignment when publishing `zdev->aibv` to `zpci_ibv` array.

The last two findings were already discussed for the previous patches,
won't comment again here.

> --- Patch [4]: [PATCH 4/7] s390/pci: fix MSI directed-mode teardown IRQ bit count ---
> commit 061bcdd7920b9b7d42fc840ba0aa403eaf0255a5
> Author: Tobias Schumacher <ts@linux.ibm.com>
>
> s390/pci: fix MSI directed-mode teardown IRQ bit count
>
> This commit updates zpci_msi_teardown_directed() to free the actual number of
> allocated MSI bits (msi_nr_irqs) instead of the maximum supported by the
> platform (max_msi). This prevents freeing bits that were not actually
> allocated, which would corrupt the shared IRQ bitmap.
>
>> diff --git a/arch/s390/pci/pci_irq.c b/arch/s390/pci/pci_irq.c
>> index 5e934ac990ac1..e9eda846cb2d2 100644
>> --- a/arch/s390/pci/pci_irq.c
>> +++ b/arch/s390/pci/pci_irq.c
>> @@ -349,7 +349,7 @@ static struct airq_struct zpci_airq = {
>>
>>  static void zpci_msi_teardown_directed(struct zpci_dev *zdev)
>>  {
>> -	airq_iv_free(zpci_ibv[0], zdev->msi_first_bit, zdev->max_msi);
>> +	airq_iv_free(zpci_ibv[0], zdev->msi_first_bit, zdev->msi_nr_irqs);
>
> [Severity: High]
> This is a pre-existing issue, but does this leak hardware vector bits on CPUs
> other than 0?
>
> It looks like this only clears the vector bits for zpci_ibv[0]. Since CPUs
> greater than 0 have zpci_ibv[cpu] created without AIRQ_IV_ALLOC, their avail
> mask is NULL, and airq_iv_free() returns immediately without clearing the bits
> in zpci_ibv[cpu]->vector.
>
> If a pending hardware interrupt bit is left set on a CPU greater than 0 after
> device teardown, could reallocating that bit index to a new device trigger a
> spurious interrupt on that CPU?
>
>>  	zdev->msi_first_bit = -1U;
>>  	zdev->msi_nr_irqs = 0;
>>  }

This is correct. The avail mask is NULL on CPUs greater than 0 since all
per-CPU vectors share one bit layout, so a single allocator is
sufficient. To fix this issue, we need to change airq_iv_free() to also
clear leftover interrupts bits if avail is NULL and additionally call
airq_iv_free() for all for each CPU.

Since directed interrupts are currently not used in the field, this
should be analyzed more in-depth sparately and be fixed outside this
series.

Tobias