Re: [PATCH 1/2] iio: hrtimer-trigger: Mark hrtimer to expire in hard interrupt context

[Lars-Peter Clausen <lars@metafoo.de>]

On 8/13/20 11:11 AM, Sebastian Andrzej Siewior wrote:
> On 2020-08-13 09:53:57 [+0200], Lars-Peter Clausen wrote:
>> On PREEMPT_RT enabled kernels unmarked hrtimers are moved into soft
>> interrupt expiry mode by default.
>>
>> The IIO hrtimer-trigger needs to run in hard interrupt context since it
>> will end up calling generic_handle_irq() which has the requirement to run
>> in hard interrupt context.
>>
>> Explicitly specify that the timer needs to run in hard interrupt context by
>> using the HRTIMER_MODE_REL_HARD flag.
> No, I don't think that this is good. It basically renders threaded-irqs
> in context of IIO useless. This also requires that the IRQ-handler in
> question runs with IRQs disabled / uses raw_spinlock_t which is in not
> good idea either.

It should not affect the IRQ handlers of individual drivers. The hrtimer 
triggers acts like an IRQ chip and will call generic_handle_irq() to 
multiplex the interrupt handling onto all consumers. As far as I 
understand it there is a requirement that generic_handle_irq() is called 
in hard irq context, even with PREEMT_RT=y.

If you are running with forced IRQ threads the only thing that will then 
happen in the actual hard IRQ context is the launching of the IRQ 
threads. Th e IRQ handler of the device driver will run in a threaded IRQ.

>
> Has this change (including the second patch in thread) been tested on RT
> in terms of locking and latency?

It has not been tested in terms of latency. But like I said if you are 
running with forced IRQ threads the effect should be minimal.

Without this patch there is an correctness issue when PREEMT_RT=y since 
generic_handle_irq() runs with interrupts on which breaks its internal 
assumptions.