On Thu, Jun 27, 2013 at 11:14 PM, Paulo Zanoni <przanoni at gmail.com> wrote: > 2013/6/25 Daniel Vetter <daniel.vetter at ffwll.ch>: >> Since we only have one interrupt handler and interrupt handlers are >> non-reentrant. >> >> To drive the point really home give them all an _irq_handler suffix. > > Could we also add WARN(!in_irq()) or something equivalent for better > protection? Big backtraces are a nice way to discover we did something > wrong. Lockdep checks hard/soft irq context constraints and will scream horribly into dmesg if we get it wrong. So I don't think a in_irq warning will add any value. Aside: hard/softirq isn't the only special context lockdep checks for, it also checks for memory allocations, e.g. if you hold a lock while calling kmalloc and your shrinker needs the same locks it'll scream. That's why we have all the GFP_NORETRY stuff when allocating memory and the trylock in the shrinker. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
