All of lore.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 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.