Hi,

Generally it's preferable to avoid placing cpumasks on the stack, as
for large values of NR_CPUS these can consume significant amounts of
stack space and make stack overflows more likely.

One may argue that alloc_cpumask_var() and its friends are the formal
way for these cases. But for struct irqchip::irq_set_affinity(), it's
called under atomic context(raw spinlock held), and dynamic memory
allocation in atomic context is less-favorable.

So a new helper is introduced to address all these issues above. It's
free of any context issue and intermediate cpumask variable allocation
issue(no matter it's on stack or heap).

The case with gic-v3-its is special from others since it's not related
to intersections between 3 cpumask.

And yes, the helper naming(maybe the whole idea) is terrible, and I am
all ears for any comments from you :).

Dawei Li (6):
  cpumask: introduce cpumask_first_and_and()
  irqchip/irq-bcm6345-l1: Avoid explicit cpumask allocation on stack
  irqchip/gic-v3-its: Avoid explicit cpumask allocation on stack
  irqchip/loongson-eiointc: Avoid explicit cpumask allocation on stack
  irqchip/riscv-aplic-direct: Avoid explicit cpumask allocation on stack
  irqchip/sifive-plic: Avoid explicit cpumask allocation on stack

 drivers/irqchip/irq-bcm6345-l1.c         |  7 ++----
 drivers/irqchip/irq-gic-v3-its.c         |  9 +++++---
 drivers/irqchip/irq-loongson-eiointc.c   |  9 +++-----
 drivers/irqchip/irq-riscv-aplic-direct.c |  8 +++----
 drivers/irqchip/irq-sifive-plic.c        |  8 +++----
 include/linux/cpumask.h                  | 17 ++++++++++++++
 include/linux/find.h                     | 29 ++++++++++++++++++++++++
 lib/find_bit.c                           | 14 ++++++++++++
 8 files changed, 77 insertions(+), 24 deletions(-)

Thanks,

    Dawei

-- 
2.27.0