Re: [PATCH RFC 2/3] genirq: Honor existing IRQ affinities when setting affinity hints

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] irq_set_affinity_and_hint() permanently locks out subsequent affinity updates by the driver itself, breaking dynamic IRQ rebalancing.
- [Medium] __irq_apply_affinity_hint checks IRQD_AFFINITY_SET inside a lock but applies the affinity outside the lock, introducing a TOCTOU race that can overwrite user-defined affinities.
--

--- Patch [2]: [PATCH RFC 2/3] genirq: Honor existing IRQ affinities when setting affinity hints ---
commit c1f8b98c1dbbe4fae2975bbf7872df3c7c3662b6
Author: Florian Bezdeka <florian.bezdeka@siemens.com>

genirq: Honor existing IRQ affinities when setting affinity hints

This commit modifies __irq_apply_affinity_hint to prevent overwriting an
already configured IRQ affinity. It checks if the affinity has been set
previously before allowing the affinity to be updated by a hint.

> diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
> index 7eb07e3bdb4c2..3937ba24df6d6 100644
> --- a/kernel/irq/manage.c
> +++ b/kernel/irq/manage.c
> @@ -503,11 +503,21 @@ EXPORT_SYMBOL_GPL(irq_force_affinity);
>  
>  int __irq_apply_affinity_hint(unsigned int irq, const struct cpumask *m, bool setaffinity)
>  {
> +	struct irq_data *irq_data;
>  	int ret = -EINVAL;
>  
>  	scoped_irqdesc_get_and_lock(irq, IRQ_GET_DESC_CHECK_GLOBAL) {
>  		scoped_irqdesc->affinity_hint = m;
> +		irq_data = irq_desc_get_irq_data(scoped_irqdesc);
>  		ret = 0;
> +
> +		/*
> +		 * Do not overwrite the affinity in case an affinity for this
> +		 * IRQ has already been requested, e.g. by writing to
> +		 * /proc/irq/<n>/smp_affinity
> +		 */
> +		if (irqd_affinity_was_set(irq_data))
> +			setaffinity = false;

[Severity: High]
Will this prevent drivers from dynamically rebalancing their own IRQ
affinities after the initial setup?

If a driver calls irq_set_affinity_and_hint(), it inherently results in the
IRQD_AFFINITY_SET flag being set. On any subsequent call by the same driver
to update the affinity (for example, during CPU hotplug or queue
reconfiguration), the irqd_affinity_was_set() check will evaluate to true
and clear the setaffinity flag.

Does this unintentionally lock out future driver-initiated affinity updates,
leaving interrupts routed to suboptimal or offline CPUs?

>  	}
>  
>  	if (!ret && m && setaffinity)

[Severity: Medium]
Could this introduce a time-of-check to time-of-use race condition?

The irqd_affinity_was_set() check happens inside the scoped block while the
lock is held. However, the lock is dropped when the scoped block ends, right
before the actual affinity update is performed.

If userspace writes to /proc/irq/<n>/smp_affinity exactly after the scoped
block drops the lock but before __irq_set_affinity() runs, won't the driver
blindly overwrite the newly configured user affinity?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260819-flo-net-7-2-make-stmmac-default-affinity-aware-v1-0-3f79a99cadaf@siemens.com?part=2