linux-kernel - Re: [PATCH v3] genirq/cpuhotplug: notify about irq affinity change for offlined cpus.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87sec9i81t.ffs@tglx>
Date: Tue, 13 Jan 2026 21:14:54 +0100
From: Thomas Gleixner <tglx@...nel.org>
To: Imran Khan <imran.f.khan@...cle.com>
Cc: linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] genirq/cpuhotplug: notify about irq affinity change
 for offlined cpus.

On Tue, Jan 13 2026 at 22:37, Imran Khan wrote:
> During cpu offlining the irqs affined to that cpu are moved

Please use proper words, i.e. interrupts, in change logs. There is no
character limit.

> to other cpu, but this affinity change is not accounted for by
> irq_desc::affinity_notify (if available).
> This can leave users, of irq_set_affinity_notifier, with old
> affinity information.

That's not really correct. _All_ device interrupts (except managed
interrupts which are shut down) are moved away from the outgoing CPU,
but the affinity change notification is only required when the outgoing
CPU was the last online CPU in the affinity mask.

> Avoid this by allowing to schedule affinity change notification

Allowing? This is not what the patch does. It schedules it, no?

> work for irqs that were affined to the cpu being offlined.
>
> Also since irq_set_affinity_locked uses the same logic to

As documented in Documentation/process/.... functions should be denoted
with function_name().

> @@ -383,6 +383,7 @@ irq_create_affinity_masks(unsigned int nvec, struct irq_affinity *affd);
>  unsigned int irq_calc_affinity_vectors(unsigned int minvec, unsigned int maxvec,
>  				       const struct irq_affinity *affd);
>  
> +extern void schedule_affinity_notify_work(struct irq_desc *desc);
>  #else /* CONFIG_SMP */
>  
>  static inline int irq_set_affinity(unsigned int irq, const struct cpumask *m)
> @@ -445,6 +446,7 @@ irq_calc_affinity_vectors(unsigned int minvec, unsigned int maxvec,
>  	return maxvec;
>  }
>  
> +static inline void schedule_affinity_notify_work(struct irq_desc *desc) { }

There is neither a reason for this to be in the global header nor there
is a reason for the !SMP stub. Both call sites are only compiled when
CONFIG_SMP=y.

> +/**
> + * schedule_affinity_notify_work - Schedule work to notify
> + * about irq affinity change.
> + * @desc:  irq descriptor whose affinity changed
> + *
> + * Caller needs to hold desc->lock
> + */
> +void schedule_affinity_notify_work(struct irq_desc *desc)
> +{
> +	kref_get(&desc->affinity_notify->kref);
> +	if (!schedule_work(&desc->affinity_notify->work))
> +		/* Work was already scheduled, drop our extra ref */
> +		kref_put(&desc->affinity_notify->kref,
> +			 desc->affinity_notify->release);

Lacks brackets around the if() (see Documentation) and the line break is pointless.

> +}
> +EXPORT_SYMBOL_GPL(schedule_affinity_notify_work);

Zero reason to export this. It's an internal function of the built-in
interrupt core code and nothing outside of it has any business with it.

No need to resend. I fixed it up on the fly.

Please study and verify the changes I made both in code and change log
once the merge notification hits your inbox.

Thanks,

        tglx