2013/6/27 Daniel Vetter <daniel.vetter at ffwll.ch>: > 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. Ok then. Looks like I forgot the stamp: Reviewed-by: Paulo Zanoni <paulo.r.zanoni at intel.com> > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Paulo Zanoni
