[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240429125742.GX516117@kernel.org>
Date: Mon, 29 Apr 2024 13:57:42 +0100
From: Simon Horman <horms@...nel.org>
To: Alexander Lobakin <aleksander.lobakin@...el.com>
Cc: intel-wired-lan@...ts.osuosl.org,
Michal Kubiak <michal.kubiak@...el.com>,
Wojciech Drewek <wojciech.drewek@...el.com>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
nex.sw.ncis.osdt.itp.upstreaming@...el.com, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [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@...el.com>
> Reviewed-by: Wojciech Drewek <wojciech.drewek@...el.com>
> Signed-off-by: Alexander Lobakin <aleksander.lobakin@...el.com>
Reviewed-by: Simon Horman <horms@...nel.org>
Powered by blists - more mailing lists