From: Simon Horman <horms@kernel.org>
To: Alexander Lobakin <aleksander.lobakin@intel.com>
Cc: Wojciech Drewek <wojciech.drewek@intel.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Eric Dumazet <edumazet@google.com>,
Michal Kubiak <michal.kubiak@intel.com>,
intel-wired-lan@lists.osuosl.org,
nex.sw.ncis.osdt.itp.upstreaming@intel.com,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [Intel-wired-lan] [PATCH iwl] idpf: don't enable NAPI and interrupts prior to allocating Rx buffers
Date: Mon, 29 Apr 2024 13:57:42 +0100 [thread overview]
Message-ID: <20240429125742.GX516117@kernel.org> (raw)
In-Reply-To: <20240426144408.1353962-1-aleksander.lobakin@intel.com>
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@intel.com>
> Reviewed-by: Wojciech Drewek <wojciech.drewek@intel.com>
> Signed-off-by: Alexander Lobakin <aleksander.lobakin@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
WARNING: multiple messages have this Message-ID (diff)
From: Simon Horman <horms@kernel.org>
To: Alexander Lobakin <aleksander.lobakin@intel.com>
Cc: intel-wired-lan@lists.osuosl.org,
Michal Kubiak <michal.kubiak@intel.com>,
Wojciech Drewek <wojciech.drewek@intel.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
nex.sw.ncis.osdt.itp.upstreaming@intel.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH iwl] idpf: don't enable NAPI and interrupts prior to allocating Rx buffers
Date: Mon, 29 Apr 2024 13:57:42 +0100 [thread overview]
Message-ID: <20240429125742.GX516117@kernel.org> (raw)
In-Reply-To: <20240426144408.1353962-1-aleksander.lobakin@intel.com>
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@intel.com>
> Reviewed-by: Wojciech Drewek <wojciech.drewek@intel.com>
> Signed-off-by: Alexander Lobakin <aleksander.lobakin@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
next prev parent reply other threads:[~2024-04-29 12:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-26 14:44 [Intel-wired-lan] [PATCH iwl] idpf: don't enable NAPI and interrupts prior to allocating Rx buffers Alexander Lobakin
2024-04-26 14:44 ` Alexander Lobakin
2024-04-29 12:57 ` Simon Horman [this message]
2024-04-29 12:57 ` Simon Horman
2024-05-09 23:03 ` [Intel-wired-lan] " Singh, Krishneil K
2024-05-09 23:03 ` Singh, Krishneil K
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240429125742.GX516117@kernel.org \
--to=horms@kernel.org \
--cc=aleksander.lobakin@intel.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michal.kubiak@intel.com \
--cc=netdev@vger.kernel.org \
--cc=nex.sw.ncis.osdt.itp.upstreaming@intel.com \
--cc=pabeni@redhat.com \
--cc=wojciech.drewek@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.