RE: [Intel-wired-lan] [PATCH iwl] idpf: don't enable NAPI and interrupts prior to allocating Rx buffers

[Singh, Krishneil K]

> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@xxxxxxxxxx> On Behalf Of
> Simon Horman
> Sent: Monday, April 29, 2024 5:58 AM
> To: Lobakin, Aleksander <aleksander.lobakin@xxxxxxxxx>
> Cc: Drewek, Wojciech <wojciech.drewek@xxxxxxxxx>;
> netdev@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Eric Dumazet
> <edumazet@xxxxxxxxxx>; Kubiak, Michal <michal.kubiak@xxxxxxxxx>; intel-
> wired-lan@xxxxxxxxxxxxxxxx; NEX SW NCIS OSDT ITP Upstreaming
> <nex.sw.ncis.osdt.itp.upstreaming@xxxxxxxxx>; Jakub Kicinski
> <kuba@xxxxxxxxxx>; Paolo Abeni <pabeni@xxxxxxxxxx>; David S. Miller
> <davem@xxxxxxxxxxxxx>
> Subject: Re: [Intel-wired-lan] [PATCH iwl] idpf: don't enable NAPI and
> interrupts prior to allocating Rx buffers
> 
> On Fri, Apr 26, 2024 at 04:44:08PM +0200, Alexander Lobakin wrote:
> > Currently, idpf enables NAPI and interrupts prior to allocating Rx
> > buffers.
> > This may lead to frame loss (there are no buffers to place incoming
> > frames) and even crashes on quick ifup-ifdown. Interrupts must be
> > enabled only after all the resources are here and available.
> > Split interrupt init into two phases: initialization and enabling,
> > and perform the second only after the queues are fully initialized.
> > Note that we can't just move interrupt initialization down the init
> > process, as the queues must have correct a ::q_vector pointer set
> > and NAPI already added in order to allocate buffers correctly.
> > Also, during the deinit process, disable HW interrupts first and
> > only then disable NAPI. Otherwise, there can be a HW event leading
> > to napi_schedule(), but the NAPI will already be unavailable.
> >
> > Fixes: d4d558718266 ("idpf: initialize interrupts and enable vport")
> > Reported-by: Michal Kubiak <michal.kubiak@xxxxxxxxx>
> > Reviewed-by: Wojciech Drewek <wojciech.drewek@xxxxxxxxx>
> > Signed-off-by: Alexander Lobakin <aleksander.lobakin@xxxxxxxxx>
> 
> Reviewed-by: Simon Horman <horms@xxxxxxxxxx>

Tested-by: Krishneil Singh <krishneil.k.singh@xxxxxxxxx>