lkml.org 
[lkml]   [2017]   [May]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: handle_bad_irq and locking
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

\
 
 \ /
  Last update: 2017-05-12 10:42    [W:0.046 / U:0.952 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site