Re: handle_bad_irq and locking

[Thomas Gleixner]

On Thu, 11 May 2017, Gregory Fong wrote:
> Hi Thomas,
> 
> I noticed that when you changed arm irq handling to use the generic
> implementation back in 2006 that you changed do_bad_IRQ() to the
> following:
> 
> +#define do_bad_IRQ(irq,desc,regs)                      \
> +do {                                                   \
> +       spin_lock(&desc->lock);                         \
> +       handle_bad_irq(irq, desc, regs);                \
> +       spin_unlock(&desc->lock);                       \
> +} while(0)
> 
> and it's mostly stayed the same since then.  As such, there are a few
> examples of this being open-coded in the kernel in various irqchip
> handlers such as that of drivers/irqchip/irq-brcmstb-l2.c, and even
> more cases where the lock isn't being grabbed before calling
> handle_bad_irq().
> 
> Since handle_bad_irq() is sort of a flow handler like
> handle_edge_irq() etc., do you think it would make sense to do the
> same as those and have it do the locking on its own?  A quick look
> through existing users of handle_bad_irq() at [1] suggests that either
> the locking isn't necessary or it's almost always done wrong.

Right. So the proper solution to this is to create a generic function

       handle_bad_irq_desc()

have proper locking in it and move all users (including do_bad_IRQ()) over
to it.

Thanks,

	tglx