Re: [PATCH net 0/4][pull request] igb: fix igb_msix_other() handling for PREEMPT_RT
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date: 2025-02-19 16:35:57
Also in:
linux-rt-devel
On 2025-02-18 11:50:55 [-0300], Wander Lairson Costa wrote:
These logs are for the test case of booting the kernel with nr_cpus=1:
kworker/0:0-8 [000] d..2. 2120.708145: process_one_work <-worker_thread
kworker/0:0-8 [000] ...1. 2120.708145: igbvf_reset_task <-process_one_workThis looks like someone broke the function tracer because the preemtion level should be 0 here not 1. So we would have to substract one… This does remind me of something else… …
kworker/0:0-8 [000] b..13 2120.718620: e1000_reset_hw_vf <-igbvf_reset
…
kworker/0:0-8 [000] D.h.3 2120.718626: irq_handler_entry: irq=63 name=ens14f0
^ the interrupt. …
kworker/0:0-8 [000] b..13 2120.719133: e1000_check_for_ack_vf <-e1000_write_posted_mbx irq/63-ens14f0-1112 [000] b..12 2121.730652: igb_msix_other <-irq_thread_fn irq/63-ens14f0-1112 [000] b..12 2121.730652: igb_rd32 <-igb_msix_other irq/63-ens14f0-1112 [000] b..13 2121.730653: igb_check_for_rst <-igb_msix_other irq/63-ens14f0-1112 [000] b..13 2121.730653: igb_check_for_rst_pf <-igb_msix_other
The threaded interrupt is postponed due to the BH-off section. I am working on lifting that restriction. Therefore it gets on CPU right after kworker's bh-enable. …
The threaded interrupt handler is called right after (during?) spin_unlock_bh(). I wonder what the 'f' means in the preempt-count field there.
The hardware interrupt handler gets there while worker is in the wait loop. The threaded interrupt handler gets postponed until after the last spin_unlock_bh(). The BH part is the important part. With that log, I expect the same hold-off part with threaded interrupts and the same BH-off synchronisation.
I am currently working on something else that has a higher priority, so I don't have time right now to go deeper on that. But feel free to ask me for any test or trace you may need.
I would need to check if it is safe to explicitly request the threaded handler but this is what I would suggest. It works around the issue for threaded interrupts and PREEMPT_RT as its user. You confirmed that it works, right? Sebastian