public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: anthony.l.nguyen@intel.com
Cc: Jakub Kicinski <kuba@kernel.org>,
	horms@kernel.org, aleksander.lobakin@intel.com,
	edumazet@google.com, sdf@fomichev.me,
	aleksandr.loktionov@intel.com, ast@kernel.org,
	john.fastabend@gmail.com, bpf@vger.kernel.org,
	netdev@vger.kernel.org, davem@davemloft.net,
	andrew+netdev@lunn.ch, hawk@kernel.org,
	nxne.cnse.osdt.itp.upstreaming@intel.com,
	magnus.karlsson@intel.com, pabeni@redhat.com,
	jacob.e.keller@intel.com, daniel@iogearbox.net,
	maciej.fijalkowski@intel.com
Subject: Re: [net-next,3/5] ice: migrate to netdev ops lock
Date: Thu, 12 Mar 2026 18:46:28 -0700	[thread overview]
Message-ID: <20260313014628.1509116-1-kuba@kernel.org> (raw)
In-Reply-To: <20260310220624.537917-4-anthony.l.nguyen@intel.com>

This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.

For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
ice: migrate to netdev ops lock

This commit migrates the ice driver to use netdev ops locking. Queue
management ops unconditionally enable netdev locking, so the driver now
uses _locked counterparts of NAPI configuration functions to avoid
deadlocks.

> diff --git a/drivers/net/ethernet/intel/ice/ice_dcb_lib.c b/drivers/net/ethernet/intel/ice/ice_dcb_lib.c
> index bd77f1c001ee..08157dc04ed6 100644
> --- a/drivers/net/ethernet/intel/ice/ice_dcb_lib.c
> +++ b/drivers/net/ethernet/intel/ice/ice_dcb_lib.c
> @@ -273,14 +273,13 @@ void ice_vsi_cfg_dcb_rings(struct ice_vsi *vsi)
>  /**
>   * ice_dcb_ena_dis_vsi - disable certain VSIs for DCB config/reconfig
>   * @pf: pointer to the PF instance
>   * @ena: true to enable VSIs, false to disable
> - * @locked: true if caller holds RTNL lock, false otherwise
>   *
>   * Before a new DCB configuration can be applied, VSIs of type PF, SWITCHDEV
>   * and CHNL need to be brought down. Following completion of DCB configuration
>   * the VSIs that were downed need to be brought up again. This helper function
>   * does both.
>   */
> -static void ice_dcb_ena_dis_vsi(struct ice_pf *pf, bool ena, bool locked)
> +static void ice_dcb_ena_dis_vsi(struct ice_pf *pf, bool ena)
>  {
>  	int i;
>
> @@ -294,9 +293,9 @@ static void ice_dcb_ena_dis_vsi(struct ice_pf *pf, bool ena, bool locked)
>  		case ICE_VSI_CHNL:
>  		case ICE_VSI_PF:
>  			if (ena)
> -				ice_ena_vsi(vsi, locked);
> +				ice_ena_vsi(vsi, true);
>  			else
> -				ice_dis_vsi(vsi, locked);
> +				ice_dis_vsi_locked(vsi);

Does ice_dcb_ena_dis_vsi() need to acquire the netdev lock before calling
ice_dis_vsi_locked() and ice_ena_vsi()?

Looking at the disable path, ice_dis_vsi_locked() calls ice_vsi_close()
which goes through ice_down() -> ice_napi_disable_all() ->
napi_disable_locked(), and that function has netdev_assert_locked(n->dev) in
net/core/dev.c. Similarly, ice_vsi_close() calls
ice_vsi_clear_napi_queues_locked() -> netif_napi_set_irq_locked() which
checks netdev_assert_locked_or_invisible().

The enable path calls ice_ena_vsi() -> ice_open_internal() ->
ice_vsi_open(), and that now calls ice_vsi_set_napi_queues_locked() ->
netif_napi_set_irq_locked() (requires netdev lock) and ice_up_complete() ->
ice_napi_enable_all() -> napi_enable_locked().

The old code called ice_dis_vsi(vsi, locked) and ice_ena_vsi(vsi, locked)
where the old ice_dis_vsi() only dealt with rtnl_lock. The new code switches
to _locked variants that require the netdev lock but does not acquire it.

Callers ice_pf_dcb_cfg() and ice_dcb_process_lldp_set_mib_change() hold
rtnl_lock but not the netdev lock.

[ ... ]

> diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
> index e7308e381e2f..a8e2db6dc05a 100644
> --- a/drivers/net/ethernet/intel/ice/ice_main.c
> +++ b/drivers/net/ethernet/intel/ice/ice_main.c

[ ... ]

> @@ -7563,7 +7570,7 @@ int ice_vsi_open(struct ice_vsi *vsi)
>  		if (err)
>  			goto err_set_qs;
>
> -		ice_vsi_set_napi_queues(vsi);
> +		ice_vsi_set_napi_queues_locked(vsi);
>  	}
>
>  	err = ice_up_complete(vsi);

Does ice_ena_vsi() need to take the netdev lock before calling
ice_open_internal()?

ice_vsi_open() now calls ice_vsi_set_napi_queues_locked() which requires the
netdev lock via netif_napi_set_irq_locked() -> netdev_assert_locked_or_
invisible(). It also calls ice_up_complete() -> ice_napi_enable_all() ->
napi_enable_locked().

However, ice_ena_vsi() in ice_lib.c calls ice_open_internal() ->
ice_vsi_open() while holding only rtnl_lock, not the netdev lock. This path
is reached during PF reset rebuild:

ice_rebuild()
    ice_vsi_rebuild_by_type()
        ice_ena_vsi(vsi, false)
            ice_open_internal()
                ice_vsi_open()

The netdev lock is NOT held at this point. ice_vsi_rebuild() took and
released it earlier in ice_vsi_rebuild_by_type().

Additionally, if ice_up_complete() fails, the error path goes through
ice_down() -> ice_napi_disable_all() -> napi_disable_locked(), which has an
explicit netdev_assert_locked(n->dev) check.
-- 
pw-bot: cr

  reply	other threads:[~2026-03-13  1:46 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-10 22:06 [PATCH net-next 0/5][pull request] ice: add support for devmem/io_uring Rx and Tx Tony Nguyen
2026-03-10 22:06 ` [PATCH net-next 1/5] libeth: pass Rx queue index to PP when creating a fill queue Tony Nguyen
2026-03-10 22:06 ` [PATCH net-next 2/5] libeth: handle creating pools with unreadable buffers Tony Nguyen
2026-03-10 22:06 ` [PATCH net-next 3/5] ice: migrate to netdev ops lock Tony Nguyen
2026-03-13  1:46   ` Jakub Kicinski [this message]
2026-03-16 15:10     ` [net-next,3/5] " Alexander Lobakin
2026-03-16 23:16       ` Jakub Kicinski
2026-03-17 15:30         ` Alexander Lobakin
2026-03-17 15:50           ` Jakub Kicinski
2026-03-17 16:15             ` Tony Nguyen
2026-03-17 17:29               ` Jakub Kicinski
2026-03-17 17:57                 ` Tony Nguyen
2026-03-10 22:06 ` [PATCH net-next 4/5] ice: implement Rx queue management ops Tony Nguyen
2026-03-10 22:06 ` [PATCH net-next 5/5] ice: add support for transmitting unreadable frags Tony Nguyen

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=20260313014628.1509116-1-kuba@kernel.org \
    --to=kuba@kernel.org \
    --cc=aleksander.lobakin@intel.com \
    --cc=aleksandr.loktionov@intel.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=anthony.l.nguyen@intel.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=hawk@kernel.org \
    --cc=horms@kernel.org \
    --cc=jacob.e.keller@intel.com \
    --cc=john.fastabend@gmail.com \
    --cc=maciej.fijalkowski@intel.com \
    --cc=magnus.karlsson@intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=nxne.cnse.osdt.itp.upstreaming@intel.com \
    --cc=pabeni@redhat.com \
    --cc=sdf@fomichev.me \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox