From: Vladimir Oltean <olteanv@xxxxxxxxx> Date: Mon, 3 Aug 2020 23:10:08 +0300 > From: Jiafei Pan <Jiafei.Pan@xxxxxxx> > > The driver calls napi_schedule_irqoff() from a context where, in RT, > hardirqs are not disabled, since the IRQ handler is force-threaded. > > In the call path of this function, __raise_softirq_irqoff() is modifying > its per-CPU mask of pending softirqs that must be processed, using > or_softirq_pending(). The or_softirq_pending() function is not atomic, > but since interrupts are supposed to be disabled, nobody should be > preempting it, and the operation should be safe. > > Nonetheless, when running with hardirqs on, as in the PREEMPT_RT case, > it isn't safe, and the pending softirqs mask can get corrupted, > resulting in softirqs being lost and never processed. > > To have common code that works with PREEMPT_RT and with mainline Linux, > we can use plain napi_schedule() instead. The difference is that > napi_schedule() (via __napi_schedule) also calls local_irq_save, which > disables hardirqs if they aren't already. But, since they already are > disabled in non-RT, this means that in practice we don't see any > measurable difference in throughput or latency with this patch. > > Signed-off-by: Jiafei Pan <Jiafei.Pan@xxxxxxx> > Signed-off-by: Vladimir Oltean <vladimir.oltean@xxxxxxx> Applied.
