On Thu, Oct 11, 2012 at 05:33:24PM +0900, Mark Brown wrote: > On Thu, Oct 11, 2012 at 01:27:49AM -0700, Dmitry Torokhov wrote: > > On Thu, Oct 11, 2012 at 05:07:24PM +0900, Mark Brown wrote: > > > > > > > What's the error pattern you're seeing? I've not noticed much of an > > > issue here, but if there is one perhaps we can do something to make the > > > error more obvious or harder to introduce. > > > devm_request_irq(); > > > The problem is that input device is freed but interrupts are still fully > > functional. > > Ah, yes - that one I do spot all the time. I agree that devm_request_irq() > is a menace, that error is far too easy to introduce and it always seems > more work to work out if it's safe than the benefit in the cases where > it can be used. Right. Another one (the IRQ again): have IRQ schedule [delayed] work and then use cancel_delayed_work() in ->remove() but rely on devres to free IRQ which is the wrong order. > > The other devm APIs are less problematic, though. I agree, they are indeed safer. I guess if I add devm_input* the some of the devm_request_*irq() will be safe as well, but we are not there yet. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
