From: Kohei Enju <kohei@enjuk.jp>
To: Alexander Lobakin <aleksander.lobakin@intel.com>
Cc: Tony Nguyen <anthony.l.nguyen@intel.com>,
intel-wired-lan@lists.osuosl.org,
Przemek Kitszel <przemyslaw.kitszel@intel.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
Jacob Keller <jacob.e.keller@intel.com>,
Aleksandr Loktionov <aleksandr.loktionov@intel.com>,
nxne.cnse.osdt.itp.upstreaming@intel.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [Intel-wired-lan] [PATCH iwl-next v4 3/5] ice: migrate to netdev ops lock
Date: Wed, 25 Mar 2026 02:08:28 +0900 [thread overview]
Message-ID: <acLExfyijq7HCEc4@x1> (raw)
In-Reply-To: <1ec79e7b-50e8-4c64-9e79-fc377a505cfa@intel.com>
On 03/24 17:56, Alexander Lobakin wrote:
> From: Kohei Enju <kohei@enjuk.jp>
> Date: Thu, 19 Mar 2026 03:56:19 +0900
>
> > On 03/19 02:55, Kohei Enju wrote:
> >> On 03/18 17:35, Alexander Lobakin wrote:
> >>> Queue management ops unconditionally enable netdev locking. The same
> >>> lock is taken by default by several NAPI configuration functions,
> >>> such as napi_enable() and netif_napi_set_irq().
> >>> Request ops locking in advance and make sure we use the _locked
> >>> counterparts of those functions to avoid deadlocks, taking the lock
> >>> manually where needed (suspend/resume, queue rebuild and resets).
> >>
> >> Hi Alexander,
>
>
> Uff, sorry, I didn't notice this thread for some reason. Maybe it landed
> into the IWL folder in my mail client and I haven't checked it for some
> time... But I read LKML online on a daily basis and missed this reports =\
NP, thanks for taking a look!
Regards,
Kohei
>
> >> After applying this patch (3/5) along with the preceding ones on top of
> >> net-next, I got some WARNING splats when changing the admin state
> >> (up/down) using the ip link command. [1, 2]
> >>
> >> Since I haven't looked into this series in detail, I'm reporting the
> >> splats anyway.
> >> I'm wondering why I haven't seen anyone report this type of issue up to
> >> v3. Maybe there is something wrong with my setup or devices?
> >>
> >> Device: Intel Corporation Ethernet Controller E810-XXV for SFP (rev 02)
> >
> > Ah, I think I figured out the reason. My adapter accidentally fell into
> > safe mode. When the adapter is in the safe mode, netdev->queue_mgmt_ops
> > == NULL and netdev->request_ops_lock == false, so
> > netdev_assert_locked_or_invisible() complains about not holding the
> > netdev lock.
> >
> > Setting netdev->request_ops_lock = true in the safe mode path also
> > worked fine for me.
> >
> > ---
> > diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
> > index 9ef258d5ab48..3477c53316ba 100644
> > --- a/drivers/net/ethernet/intel/ice/ice_main.c
> > +++ b/drivers/net/ethernet/intel/ice/ice_main.c
> > @@ -3519,6 +3519,7 @@ static void ice_set_ops(struct ice_vsi *vsi)
> >
> > if (ice_is_safe_mode(pf)) {
> > netdev->netdev_ops = &ice_netdev_safe_mode_ops;
> > + netdev->request_ops_lock = true;
>
> This fix looks good to me, thanks!
>
> > ice_set_ethtool_safe_mode_ops(netdev);
> > return;
> > }
>
> Tony, could you please pick it up to patch 3/5 when sending a new PR?
>
> Thanks,
> Olek
next prev parent reply other threads:[~2026-03-24 17:09 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-18 16:35 [Intel-wired-lan] [PATCH iwl-next v4 0/5] ice: add support for devmem/io_uring Rx and Tx Alexander Lobakin
2026-03-18 16:35 ` Alexander Lobakin
2026-03-18 16:35 ` [Intel-wired-lan] [PATCH iwl-next v4 1/5] libeth: pass Rx queue index to PP when creating a fill queue Alexander Lobakin
2026-03-18 16:35 ` Alexander Lobakin
2026-03-18 16:35 ` [Intel-wired-lan] [PATCH iwl-next v4 2/5] libeth: handle creating pools with unreadable buffers Alexander Lobakin
2026-03-18 16:35 ` Alexander Lobakin
2026-03-18 16:35 ` [Intel-wired-lan] [PATCH iwl-next v4 3/5] ice: migrate to netdev ops lock Alexander Lobakin
2026-03-18 16:35 ` Alexander Lobakin
2026-03-18 17:55 ` [Intel-wired-lan] " Kohei Enju
2026-03-18 18:56 ` Kohei Enju
2026-03-24 16:56 ` Alexander Lobakin
2026-03-24 17:08 ` Kohei Enju [this message]
2026-03-24 17:20 ` Tony Nguyen
2026-03-18 16:35 ` [Intel-wired-lan] [PATCH iwl-next v4 4/5] ice: implement Rx queue management ops Alexander Lobakin
2026-03-18 16:35 ` Alexander Lobakin
2026-03-18 16:35 ` [Intel-wired-lan] [PATCH iwl-next v4 5/5] ice: add support for transmitting unreadable frags Alexander Lobakin
2026-03-18 16:35 ` Alexander Lobakin
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=acLExfyijq7HCEc4@x1 \
--to=kohei@enjuk.jp \
--cc=aleksander.lobakin@intel.com \
--cc=aleksandr.loktionov@intel.com \
--cc=andrew+netdev@lunn.ch \
--cc=anthony.l.nguyen@intel.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jacob.e.keller@intel.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=nxne.cnse.osdt.itp.upstreaming@intel.com \
--cc=pabeni@redhat.com \
--cc=przemyslaw.kitszel@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.