Patch "x86/irq: Remove the cpumask allocation from send_cleanup_vector()" has been added to the 4.4-stable tree

This is a note to let you know that I've just added the patch titled

x86/irq: Remove the cpumask allocation from send_cleanup_vector()

to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
x86-irq-remove-the-cpumask-allocation-from-send_cleanup_vector.patch
and it can be found in the queue-4.4 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.

From: Thomas Gleixner <[email protected]>
Date: Thu, 31 Dec 2015 16:30:52 +0000
Subject: x86/irq: Remove the cpumask allocation from send_cleanup_vector()

From: Thomas Gleixner <[email protected]>

commit 5da0c1217f05d2ccc9a8ed6e6e5c23a8a1d24dd6 upstream.

There is no need to allocate a new cpumask for sending the cleanup vector. The old_domain mask is now protected by the vector_lock, so we can safely remove the offline cpus from it and send the IPI with the resulting mask.

---
 arch/x86/kernel/apic/vector.c |   16 +++-------------
 1 file changed, 3 insertions(+), 13 deletions(-)

@@ -528,21 +528,11 @@ static struct irq_chip lapic_controller
 #ifdef CONFIG_SMP
 static void __send_cleanup_vector(struct apic_chip_data *data)
 {
-	cpumask_var_t cleanup_mask;
-
 	raw_spin_lock(&vector_lock);
+	cpumask_and(data->old_domain, data->old_domain, cpu_online_mask);
 	data->move_in_progress = 0;
-	if (unlikely(!alloc_cpumask_var(&cleanup_mask, GFP_ATOMIC))) {
-		unsigned int i;
-
-		for_each_cpu_and(i, data->old_domain, cpu_online_mask)
-			apic->send_IPI_mask(cpumask_of(i),
-					    IRQ_MOVE_CLEANUP_VECTOR);
-	} else {
-		cpumask_and(cleanup_mask, data->old_domain, cpu_online_mask);
-		apic->send_IPI_mask(cleanup_mask, IRQ_MOVE_CLEANUP_VECTOR);
-		free_cpumask_var(cleanup_mask);
-	}
+	if (!cpumask_empty(data->old_domain))
+		apic->send_IPI_mask(data->old_domain, IRQ_MOVE_CLEANUP_VECTOR);
 	raw_spin_unlock(&vector_lock);
 }
 

Patches currently in stable-queue which might be from [email protected] are

queue-4.4/x86-irq-validate-that-irq-descriptor-is-still-active.patch queue-4.4/x86-irq-remove-outgoing-cpu-from-vector-cleanup-mask.patch queue-4.4/x86-irq-get-rid-of-code-duplication.patch queue-4.4/x86-entry-compat-add-missing-clac-to-entry_int80_32.patch queue-4.4/tick-nohz-set-the-correct-expiry-when-switching-to-nohz-lowres-mode.patch queue-4.4/irqchip-mxs-add-missing-set_handle_irq.patch queue-4.4/genirq-validate-action-before-dereferencing-it-in-handle_irq_event_percpu.patch queue-4.4/x86-irq-remove-offline-cpus-from-vector-cleanup.patch queue-4.4/posix-clock-fix-return-code-on-the-poll-method-s-error-path.patch queue-4.4/x86-irq-reorganize-the-return-path-in-assign_irq_vector.patch queue-4.4/cputime-prevent-32bit-overflow-in-time_to_cputime.patch queue-4.4/x86-irq-copy-vectormask-instead-of-an-and-operation.patch queue-4.4/x86-irq-call-irq_force_move_complete-with-irq-descriptor.patch queue-4.4/x86-irq-call-chip-irq_set_affinity-in-proper-context.patch queue-4.4/x86-irq-plug-vector-cleanup-race.patch queue-4.4/x86-irq-do-not-use-apic_chip_data.old_domain-as-temporary-buffer.patch queue-4.4/clockevents-tcb_clksrc-prevent-disabling-an-already-disabled-clock.patch queue-4.4/x86-irq-reorganize-the-search-in-assign_irq_vector.patch queue-4.4/x86-irq-remove-the-cpumask-allocation-from-send_cleanup_vector.patch queue-4.4/x86-irq-fix-a-race-in-x86_vector_free_irqs.patch queue-4.4/x86-irq-check-vector-allocation-early.patch queue-4.4/irqchip-omap-intc-add-support-for-spurious-irq-handling.patch queue-4.4/x86-irq-clear-move_in_progress-before-sending-cleanup-ipi.patch queue-4.4/x86-mpx-fix-off-by-one-comparison-with-nr_registers.patch queue-4.4/irqchip-atmel-aic-fix-wrong-bit-operation-for-irq-priority.patch queue-4.4/revert-workqueue-make-sure-delayed-work-run-in-local-cpu.patch