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  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 12 May 2017 10:40:53 +0200 (CEST)
From:   Thomas Gleixner <>
To:     Gregory Fong <>
cc:     "" <>,, Florian Fainelli <>
Subject: Re: 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


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



Powered by blists - more mailing lists