All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leon Romanovsky <leon@kernel.org>
To: Tony Nguyen <anthony.l.nguyen@intel.com>
Cc: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com,
	edumazet@google.com, netdev@vger.kernel.org,
	Dawid Wesierski <dawidx.wesierski@intel.com>,
	Kamil Maziarz <kamil.maziarz@intel.com>,
	Jacob Keller <Jacob.e.keller@intel.com>,
	Rafal Romanowski <rafal.romanowski@intel.com>
Subject: Re: [PATCH net 2/3] ice: Fix ice VF reset during iavf initialization
Date: Wed, 26 Apr 2023 09:49:41 +0300	[thread overview]
Message-ID: <20230426064941.GF27649@unreal> (raw)
In-Reply-To: <20230425170127.2522312-3-anthony.l.nguyen@intel.com>

On Tue, Apr 25, 2023 at 10:01:26AM -0700, Tony Nguyen wrote:
> From: Dawid Wesierski <dawidx.wesierski@intel.com>
> 
> Fix the current implementation that causes ice_trigger_vf_reset()
> to start resetting the VF even when the VF is still resetting itself
> and initializing adminq. This leads to a series of -53 errors
> (failed to init adminq) from the IAVF.
> 
> Change the state of the vf_state field to be not active when the IAVF
> asks for a reset. To avoid issues caused by the VF being reset too
> early, make sure to wait until receiving the message on the message
> box to know the exact state of the IAVF driver.
> 
> Fixes: c54d209c78b8 ("ice: Wait for VF to be reset/ready before configuration")
> Signed-off-by: Dawid Wesierski <dawidx.wesierski@intel.com>
> Signed-off-by: Kamil Maziarz <kamil.maziarz@intel.com>
> Acked-by: Jacob Keller <Jacob.e.keller@intel.com>
> Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
> ---
>  drivers/net/ethernet/intel/ice/ice_sriov.c    |  8 ++++----
>  drivers/net/ethernet/intel/ice/ice_vf_lib.c   | 19 +++++++++++++++++++
>  drivers/net/ethernet/intel/ice/ice_vf_lib.h   |  1 +
>  drivers/net/ethernet/intel/ice/ice_virtchnl.c |  1 +
>  4 files changed, 25 insertions(+), 4 deletions(-)

<...>

> -	ret = ice_check_vf_ready_for_cfg(vf);
> +	ret = ice_check_vf_ready_for_reset(vf);
>  	if (ret)
>  		goto out_put_vf;

<...>

> +/**
> + * ice_check_vf_ready_for_reset - check if VF is ready to be reset
> + * @vf: VF to check if it's ready to be reset
> + *
> + * The purpose of this function is to ensure that the VF is not in reset,
> + * disabled, and is both initialized and active, thus enabling us to safely
> + * initialize another reset.
> + */
> +int ice_check_vf_ready_for_reset(struct ice_vf *vf)
> +{
> +	int ret;
> +
> +	ret = ice_check_vf_ready_for_cfg(vf);
> +	if (!ret && !test_bit(ICE_VF_STATE_ACTIVE, vf->vf_states))
> +		ret = -EAGAIN;

I don't know your driver enough to say how it is it possible to find VF
"resetting itself" and PF trying to reset VF at the same time.

But what I see is that ICE_VF_STATE_ACTIVE bit check is racy and you
don't really fix the root cause of calling to reset without proper locking.

Thanks

> +
> +	return ret;
> +}

<...>

>  	case VIRTCHNL_OP_RESET_VF:
> +		clear_bit(ICE_VF_STATE_ACTIVE, vf->vf_states);
>  		ops->reset_vf(vf);
>  		break;
>  	case VIRTCHNL_OP_ADD_ETH_ADDR:
> -- 
> 2.38.1
> 

  reply	other threads:[~2023-04-26  6:49 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-25 17:01 [PATCH net 0/3][pull request] Intel Wired LAN Driver Updates 2023-04-25 (ice, iavf) Tony Nguyen
2023-04-25 17:01 ` [PATCH net 1/3] ice: Fix stats after PF reset Tony Nguyen
2023-04-26  6:50   ` Leon Romanovsky
2023-04-25 17:01 ` [PATCH net 2/3] ice: Fix ice VF reset during iavf initialization Tony Nguyen
2023-04-26  6:49   ` Leon Romanovsky [this message]
2023-04-26 16:22     ` Keller, Jacob E
2023-04-27  9:24       ` Paolo Abeni
2023-04-28  9:12         ` Maziarz, Kamil
2023-04-25 17:01 ` [PATCH net 3/3] iavf: send VLAN offloading caps once after VFR Tony Nguyen
2023-04-26  6:50   ` Leon Romanovsky

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=20230426064941.GF27649@unreal \
    --to=leon@kernel.org \
    --cc=Jacob.e.keller@intel.com \
    --cc=anthony.l.nguyen@intel.com \
    --cc=davem@davemloft.net \
    --cc=dawidx.wesierski@intel.com \
    --cc=edumazet@google.com \
    --cc=kamil.maziarz@intel.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=rafal.romanowski@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.