patches for DPDK stable branches
 help / color / mirror / Atom feed
From: "Zhang, Qi Z" <qi.z.zhang@intel.com>
To: "Ye, MingjinX" <mingjinx.ye@intel.com>, "dev@dpdk.org" <dev@dpdk.org>
Cc: "Yang, Qiming" <qiming.yang@intel.com>,
	"stable@dpdk.org" <stable@dpdk.org>,
	"Zhou, YidingX" <yidingx.zhou@intel.com>,
	"Zhang, Ke1X" <ke1x.zhang@intel.com>
Subject: RE: [PATCH v6] net/ice: fix ice dcf control thread crash
Date: Mon, 3 Apr 2023 06:54:57 +0000	[thread overview]
Message-ID: <DM4PR11MB59940B9400220C967A388655D7929@DM4PR11MB5994.namprd11.prod.outlook.com> (raw)
In-Reply-To: <20230322055606.84874-1-mingjinx.ye@intel.com>



> -----Original Message-----
> From: Ye, MingjinX <mingjinx.ye@intel.com>
> Sent: Wednesday, March 22, 2023 1:56 PM
> To: dev@dpdk.org
> Cc: Yang, Qiming <qiming.yang@intel.com>; stable@dpdk.org; Zhou, YidingX
> <yidingx.zhou@intel.com>; Ye, MingjinX <mingjinx.ye@intel.com>; Zhang,
> Ke1X <ke1x.zhang@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>
> Subject: [PATCH v6] net/ice: fix ice dcf control thread crash
> 
> The control thread accesses the hardware resources after the resources were
> released, which results in a segment error.
> 
> The 'ice-reset' threads are detached, so thread resources cannot be
> reclaimed by `pthread_join` calls.
> 
> This commit synchronizes the number of "ice-reset" threads by adding a
> variable ("vsi_update_thread_num") to the "struct ice_dcf_hw" and
> performing an atomic operation on this variable. When releasing HW
> resources, we wait for the number of "ice-reset" threads to be reduced to 0
> before releasing the resources.
> 
> Fixes: c7e1a1a3bfeb ("net/ice: refactor DCF VLAN handling")
> Fixes: 7564d5509611 ("net/ice: add DCF hardware initialization")
> Fixes: 0b02c9519432 ("net/ice: handle PF initialization by DCF")
> Cc: stable@dpdk.org
> 
> Signed-off-by: Ke Zhang <ke1x.zhang@intel.com>
> Signed-off-by: Mingjin Ye <mingjinx.ye@intel.com>
> ---
> v2: add pthread_exit() for windows
> ---
> v3: Optimization. It is unsafe for a thread to forcibly exit, which will cause the
> spin lock to not be released correctly
> ---
> v4: Safely wait for all event threads to end
> ---
> v5: Spinlock moved to struct ice_dcf_hw
> ---
> v6: Spinlock changed to atomic
> ---
>  drivers/net/ice/ice_dcf.c        | 9 +++++++++
>  drivers/net/ice/ice_dcf.h        | 2 ++
>  drivers/net/ice/ice_dcf_parent.c | 6 ++++++
>  3 files changed, 17 insertions(+)
> 
> diff --git a/drivers/net/ice/ice_dcf.c b/drivers/net/ice/ice_dcf.c index
> 1c3d22ae0f..adf2cf2cb6 100644
> --- a/drivers/net/ice/ice_dcf.c
> +++ b/drivers/net/ice/ice_dcf.c
> @@ -32,6 +32,8 @@
>  #define ICE_DCF_ARQ_MAX_RETRIES 200
>  #define ICE_DCF_ARQ_CHECK_TIME  2   /* msecs */
> 
> +#define ICE_DCF_CHECK_INTERVAL  100   /* 100ms */
> +
>  #define ICE_DCF_VF_RES_BUF_SZ	\
>  	(sizeof(struct virtchnl_vf_resource) +	\
>  		IAVF_MAX_VF_VSI * sizeof(struct virtchnl_vsi_resource)) @@
> -639,6 +641,8 @@ ice_dcf_init_hw(struct rte_eth_dev *eth_dev, struct
> ice_dcf_hw *hw)
>  	rte_spinlock_init(&hw->vc_cmd_queue_lock);
>  	TAILQ_INIT(&hw->vc_cmd_queue);
> 
> +	__atomic_store_n(&hw->vsi_update_thread_num, 0,
> __ATOMIC_RELAXED);
> +
>  	hw->arq_buf = rte_zmalloc("arq_buf", ICE_DCF_AQ_BUF_SZ, 0);
>  	if (hw->arq_buf == NULL) {
>  		PMD_INIT_LOG(ERR, "unable to allocate AdminQ buffer
> memory"); @@ -760,6 +764,11 @@ ice_dcf_uninit_hw(struct rte_eth_dev
> *eth_dev, struct ice_dcf_hw *hw)
>  	rte_intr_callback_unregister(intr_handle,
>  				     ice_dcf_dev_interrupt_handler, hw);
> 
> +	/* Wait for all `ice-thread` threads to exit. */
> +	while (__atomic_load_n(&hw->vsi_update_thread_num,
> +		__ATOMIC_ACQUIRE) != 0)
> +		rte_delay_ms(ICE_DCF_CHECK_INTERVAL);
> +
>  	ice_dcf_mode_disable(hw);
>  	iavf_shutdown_adminq(&hw->avf);
> 
> diff --git a/drivers/net/ice/ice_dcf.h b/drivers/net/ice/ice_dcf.h index
> 7f42ebabe9..7becf6d187 100644
> --- a/drivers/net/ice/ice_dcf.h
> +++ b/drivers/net/ice/ice_dcf.h
> @@ -105,6 +105,8 @@ struct ice_dcf_hw {
>  	void (*vc_event_msg_cb)(struct ice_dcf_hw *dcf_hw,
>  				uint8_t *msg, uint16_t msglen);
> 
> +	int vsi_update_thread_num;
> +
>  	uint8_t *arq_buf;
> 
>  	uint16_t num_vfs;
> diff --git a/drivers/net/ice/ice_dcf_parent.c
> b/drivers/net/ice/ice_dcf_parent.c
> index 01e390ddda..6ee0fbcd2b 100644
> --- a/drivers/net/ice/ice_dcf_parent.c
> +++ b/drivers/net/ice/ice_dcf_parent.c
> @@ -154,6 +154,9 @@ ice_dcf_vsi_update_service_handler(void *param)
> 
>  	free(param);
> 
> +	__atomic_fetch_sub(&hw->vsi_update_thread_num, 1,
> +		__ATOMIC_RELEASE);
> +
>  	return NULL;
>  }
> 
> @@ -183,6 +186,9 @@ start_vsi_reset_thread(struct ice_dcf_hw *dcf_hw,
> bool vfr, uint16_t vf_id)
>  		PMD_DRV_LOG(ERR, "Failed to start the thread for reset
> handling");
>  		free(param);
>  	}
> +
> +	__atomic_fetch_add(&dcf_hw->vsi_update_thread_num, 1,
> +		__ATOMIC_RELAXED);

Is this correct? you increment the counter after you start the new thread with rte_ctrl_thread_create, 
It is possible, __atomic_fetch_sub in ice_dcf_vsi_update_service_handler will be executed before __atomic_fetch_add?

Why not moving __atomic_fetch_add to the service_handler thread? So the order of "add" and "sub" can be guaranteed ?

>  }
> 
>  static uint32_t
> --
> 2.25.1


  reply	other threads:[~2023-04-03  6:55 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20230213071648.326123-1-ke1x.zhang@intel.com>
2023-03-15  8:20 ` [PATCH v3] " Mingjin Ye
2023-03-15 13:06   ` Zhang, Qi Z
2023-03-17  5:09   ` [PATCH v4] " Mingjin Ye
2023-03-17 10:15     ` Zhang, Qi Z
2023-03-20  9:40     ` [PATCH v5] " Mingjin Ye
2023-03-20 12:52       ` Zhang, Qi Z
2023-03-21  2:08         ` Ye, MingjinX
2023-03-21 11:55           ` Zhang, Qi Z
2023-03-21 16:24             ` Tyler Retzlaff
2023-03-22  5:56       ` [PATCH v6] " Mingjin Ye
2023-04-03  6:54         ` Zhang, Qi Z [this message]
2023-04-11  2:08         ` [PATCH v7] " Mingjin Ye
2023-05-15  6:28           ` Zhang, Qi Z

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=DM4PR11MB59940B9400220C967A388655D7929@DM4PR11MB5994.namprd11.prod.outlook.com \
    --to=qi.z.zhang@intel.com \
    --cc=dev@dpdk.org \
    --cc=ke1x.zhang@intel.com \
    --cc=mingjinx.ye@intel.com \
    --cc=qiming.yang@intel.com \
    --cc=stable@dpdk.org \
    --cc=yidingx.zhou@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).