On 12/16/22 09:00, Sebastian Andrzej Siewior wrote:
On 2022-12-16 03:15:04 [+0100], Marek Vasut wrote:
Avoid locking in hard interrupt context, move the entirety of hard IRQ
context code into single IRQ handler, preempt-rt would move the handler
into thread. This fixes the following splat with preempt-rt enabled:
BUG: scheduling while atomic: (mount)/1289/0x00010001
Modules linked in:
Preemption disabled at:
[<c0119127>] irq_enter_rcu+0xb/0x42
CPU: 0 PID: 1289 Comm: (mount) Not tainted 6.1.0-rc7-rt5-stable-standard-00006-gd70aeccb9f0f #17
Hardware name: STM32 (Device Tree Support)
unwind_backtrace from show_stack+0xb/0xc
show_stack from dump_stack_lvl+0x2b/0x34
dump_stack_lvl from __schedule_bug+0x53/0x80
__schedule_bug from __schedule+0x47/0x404
__schedule from schedule_rtlock+0x15/0x34
schedule_rtlock from rtlock_slowlock_locked+0x1d7/0x57e
rtlock_slowlock_locked from rt_spin_lock+0x29/0x3c
rt_spin_lock from stm32_usart_interrupt+0xa9/0x110
stm32_usart_interrupt from __handle_irq_event_percpu+0x73/0x14e
__handle_irq_event_percpu from handle_irq_event_percpu+0x9/0x22
handle_irq_event_percpu from handle_irq_event+0x53/0x76
handle_irq_event from handle_fasteoi_irq+0x65/0xa8
handle_fasteoi_irq from handle_irq_desc+0xf/0x18
handle_irq_desc from gic_handle_irq+0x45/0x54
gic_handle_irq from generic_handle_arch_irq+0x19/0x2c
generic_handle_arch_irq from call_with_stack+0xd/0x10
Could this be replaced maybe with a proper description instead of
slapping the backtrace into the patch description?
Sure, I'm not confident in the preempt-rt parts, thanks for the commit
message update, I'll include it in V3.
Requesting an interrupt with IRQF_ONESHOT will run the primary handler
in the hard-IRQ context even in the force-threaded mode. The
force-threaded mode is used by PREEMPT_RT in order to avoid acquiring
sleeping locks (spinlock_t) in hard-IRQ context. This combination
makes it impossible and leads to "sleeping while atomic" warnings.
Use one interrupt handler for both handlers (primary and secondary)
and drop the IRQF_ONESHOT flag which is not needed.
Fixes: e359b4411c283 ("serial: stm32: fix threaded interrupt handling")
As for your change, this should work.
Reviewed-by: Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx>
Thanks for all the help with this.
Should this DMA-mode need to be outsourced (due to $REASON) you can
request two handlers but then you need to avoid IRQF_ONESHOT and the
primary handler needs to disable the interrupt source in the UART
hardware.
Also it might be worth checking if the DMA mode makes any sense if the
FIFO is so small.
If you want to push a lot of data through the UART without refilling the
small FIFO all the time and getting a lot of IRQs, that's where the DMA
comes in. Maybe I misunderstood this comment ?
