On Mon, May 9, 2016 at 11:26 PM, Jonathan Cameron <jic23@xxxxxxxxxxxxxxxxxxxxx> wrote: >>An infinite loop in the threaded interrupt handler looks odd. Are you >>sure this is allowed? I do my tests in qemu with an usb adapter and if >>I >>run with -smp 1 it seems to be impossible to stop the irq thread. > > Definitely not allowed.... > > Long term we need a way to throttle or fault out after first few loops. > > Right now this improves situation even if we just let it happen say 10 times to ride > our slight delays... OK I'm putting in a hard limit to 10 loops. > I ideally want to fire up my board and hammer this as well, plus read it very > carefully to see if this really closes all potential races... I'm doing my best, as far as I can tell this is how threaded interrupts solve thing, normally. As long as no hardirqs get masked, it should work. That would only happen if a new IRQ happens while we're inside the hard IRQ handler, so as long as this is fast enough (which I guess is the assumption we make on all top halves) we should be safe. As the driver currently has a limitation and does not allow to connect the sensor to an interrupt controller which itself is threaded (such as a GPIO expander on an I2C bus) we should be safe for the time being. If we want to support the latter usecase at some point, we may have problems: the I2C traffic to the expander itself will maybe lead us to miss IRQs. But then it is really the latency of the whole system causing things to break, not this driver: the components used simply aren't fast enough. I think in such cases the only safe way to read values is to give up due to bad system architecture and to fall back to using an HRTimer to poll the sensor. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
