Re: [net PATCH v2 4/6] eth: fbnic: reset num_napi when the napi vectors are freed

[Simon Horman <horms@kernel.org>]

On Mon, Sep 14, 2026 at 02:10:18PM -0700, Alexander Duyck wrote:
> From: Alexander Duyck <alexanderduyck@fb.com>
> 
> fbn->num_napi is the count of live napi vectors, each of which owns an
> IRQ.  The PM path had freed them without clearing the count.
> fbnic_pm_suspend() tears the datapath down via ndo_stop() and frees the
> IRQs, but leaves netif_running() true so resume knows to re-open.  Resume
> rebuilds the datapath in __fbnic_pm_resume() and fbnic_reset_queues() sets
> num_napi and __fbnic_open() re-allocates the vectors.
> 
> When the datapath is torn down but never rebuilt, num_napi is left
> pointing at freed vectors under 2 different scenarios:
>  - a PCIe error recovery that fails (fbnic_err_slot_reset() ->
>    __fbnic_pm_resume() returns an error -> PCI_ERS_RESULT_DISCONNECT), so
>    .resume never runs; or
>  - an __fbnic_open() that fails partway on resume and unwinds, freeing
>    the vectors after fbnic_reset_queues() has already set num_napi.
> 
> The netdev is then running with num_napi > 0 but napi[] freed, and the
> eventual remove/unbind close re-enters fbnic_down() -> fbnic_dbg_down()
> and dereferences the freed vectors:
>   BUG: kernel NULL pointer dereference, address: 0000000000000210
>   RIP: fbnic_dbg_down+0x28
> 
> Clear num_napi when the vectors are freed: in the suspend teardown (a
> good resume re-establishes it before __fbnic_open()) and on the resume
> open failure.  A redundant ndo_stop() then walks an empty napi[].  The
> normal ndo_stop() down/up cycle is untouched and keeps num_napi for the
> next ndo_open().
> 
> Fixes: bc6107771bb4 ("eth: fbnic: Allocate a netdevice and napi vectors with queues")
> Signed-off-by: Alexander Duyck <alexanderduyck@fb.com>

Reviewed-by: Simon Horman <horms@kernel.org>