Re: [PATCH net 4/4] eth: bnxt: avoid deadlock when canceling IRQ affinity notifier

Test summary: on an AMD EPYC 9335 CPU.
- Instrumented driver to see relevant debug logs - init/notify/update/teardown
- smp_affinity_list of irqs modified under active iperf3 traffic
(irqbalance also active)
- Affinity modify with concurrent 'ip link down' (~20 iterations): no
hang/deadlock
- aRFS/TPH coexistence: verified packets are correctly steered to the
relevant queues.

Tested-by: Vishvambar Panth S <[email protected]>

On Wed, Aug 5, 2026 at 11:32 AM Michael Chan <[email protected]> wrote:
>
> On Mon, Aug 3, 2026 at 12:31 PM Jakub Kicinski <[email protected]> wrote:
> >
> > Unregistering IRQ affinity notifiers waits for the callback synchronously.
> > bnxt takes the netdev instance lock in the notifier (to restart the queue)
> > and cancels the work under the same lock. This may obviously deadlock.
> >
> > Move the restart to the async service task. The queue restart isn't
> > super time sensitive. Store the new TPH tag, schedule the task.
> > Safely canceling the service task is already ironed out.
> >
> > In bnxt_request_irq() the order of registering notifier, affinity and
> > initial TPH programming has to be inverted. I think it was racy
> > previously since user may trigger an update as soon as notifier
> > is installed.
> >
> > There's a small known gap - if pcie_tph_get_cpu_st() fails at init
> > and the target tag is 0 we may miss programming the entry.
> > This does not seem worth fixing, the code has skip-on-failure
> > all over the place, anyway.
> >
> > Fixes: c214410c47d6 ("bnxt_en: Add TPH support in BNXT driver")
> > Signed-off-by: Jakub Kicinski <[email protected]>
>
> Thanks for the patches.  We'll get the patches tested in our lab.