When __napi_schedule_irqoff was added with bc9ad166e38a
("net: introduce napi_schedule_irqoff()") the commit message stated:
"Many NIC drivers can use it from their hard IRQ handler instead of
generic variant."
It turned out that this most of the time isn't safe in certain
configurations:
- if CONFIG_PREEMPT_RT is set
- if command line parameter threadirqs is setHaving said that drivers are being switched back to __napi_schedule(), see e.g. patch in [0] and related discussion. I thought about a __napi_schedule version checking dynamically whether interrupts are disabled. But checking e.g. variable force_irqthreads also comes at a cost, so that we may not see a benefit compared to calling local_irq_save/local_irq_restore. If more or less all users have to switch back, then the question is whether we should remove __napi_schedule_irqoff. Instead of touching all users we could make __napi_schedule_irqoff an alias for __napi_schedule for now. [0] https://lkml.org/lkml/2020/10/8/706
