DPDK patches and discussions
 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>,
	"Zhou, YidingX" <yidingx.zhou@intel.com>,
	"stable@dpdk.org" <stable@dpdk.org>
Subject: RE: [PATCH v2] net/ice: fix crash on closing representor ports
Date: Wed, 1 Nov 2023 01:11:33 +0000	[thread overview]
Message-ID: <DM4PR11MB5994E195FF4FDE8658E9A36AD7A7A@DM4PR11MB5994.namprd11.prod.outlook.com> (raw)
In-Reply-To: <20231030084459.3470038-1-mingjinx.ye@intel.com>



> -----Original Message-----
> From: Ye, MingjinX <mingjinx.ye@intel.com>
> Sent: Monday, October 30, 2023 4:45 PM
> To: dev@dpdk.org
> Cc: Yang, Qiming <qiming.yang@intel.com>; Zhou, YidingX
> <yidingx.zhou@intel.com>; Ye, MingjinX <mingjinx.ye@intel.com>;
> stable@dpdk.org; Zhang, Qi Z <qi.z.zhang@intel.com>
> Subject: [PATCH v2] net/ice: fix crash on closing representor ports
> 
> Since the representor port needs to access the resources of the associated
> DCF when it is closed. Therefore, the correct close port operation is to close
> all the representor ports first, and then close the associated DCF port.
> 
> If the DCF port is closed before the representor port on pmd exit.
> This will result in accessing freed resources and eventually a core dump will
> occur.
> 
> This patch fixes this issue by notifying all presentor ports that DCF is not
> accessible when the DCF port is closed.
> And when the presentor port is closed, it determines if the DCF resources are
> accessible. If it can't be accessed, it will report an error and return.
> 
> Fixes: 5674465a32c8 ("net/ice: add DCF VLAN handling")
> Fixes: da9cdcd1f372 ("net/ice: fix crash on representor port closing")
> Cc: stable@dpdk.org
> 
> Signed-off-by: Mingjin Ye <mingjinx.ye@intel.com>
> ---
> v2: Reformat code to remove unneeded fixlines.
> ---
>  drivers/net/ice/ice_dcf_ethdev.h         |  1 +
>  drivers/net/ice/ice_dcf_vf_representor.c | 11 ++++++++---
>  2 files changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/ice/ice_dcf_ethdev.h
> b/drivers/net/ice/ice_dcf_ethdev.h
> index 4baaec4b8b..d94ef10244 100644
> --- a/drivers/net/ice/ice_dcf_ethdev.h
> +++ b/drivers/net/ice/ice_dcf_ethdev.h
> @@ -60,6 +60,7 @@ struct ice_dcf_vf_repr {
>  	struct rte_ether_addr mac_addr;
>  	uint16_t switch_domain_id;
>  	uint16_t vf_id;
> +	bool dcf_valid;
> 
>  	struct ice_dcf_vlan outer_vlan_info; /* DCF always handle outer VLAN
> */  }; diff --git a/drivers/net/ice/ice_dcf_vf_representor.c
> b/drivers/net/ice/ice_dcf_vf_representor.c
> index b9fcfc80ad..eb49eae4e4 100644
> --- a/drivers/net/ice/ice_dcf_vf_representor.c
> +++ b/drivers/net/ice/ice_dcf_vf_representor.c
> @@ -45,6 +45,9 @@ ice_dcf_vf_repr_dev_start(struct rte_eth_dev *dev)
> static int  ice_dcf_vf_repr_dev_stop(struct rte_eth_dev *dev)  {
> +	struct ice_dcf_vf_repr *repr = dev->data->dev_private;
> +
> +	repr->dcf_valid = false;

The fix assume the ice_dcf_vf_repr_dev_stop will be invoked during ice_dcf_dev_stop.
But what if DCF port is not closed, while only the port representor port is stopped, should we still reset the flag?
Based your description of the issue, is it better to check on a per DCF port flag, but not a per representer flag?



  reply	other threads:[~2023-11-01  1:11 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-26  9:51 [PATCH] net/iavf: " Mingjin Ye
2023-10-27  7:17 ` David Marchand
2023-10-30  2:35 ` [PATCH v2] " Mingjin Ye
2023-10-30  8:44 ` [PATCH v2] net/ice: " Mingjin Ye
2023-11-01  1:11   ` Zhang, Qi Z [this message]
2023-11-01 10:13   ` [PATCH v3] " Mingjin Ye
2023-11-01 10:48     ` Zhang, Qi Z
2023-11-02  2:38       ` Ye, MingjinX
2023-11-02  3:59         ` Zhang, Qi Z
2023-11-02 10:11     ` [PATCH v4] " Mingjin Ye
2023-11-06  1:23       ` Zhang, Qi Z
2023-11-06 10:00       ` [PATCH v5] " Mingjin Ye
2023-11-06 12:05         ` Zhang, Qi Z
2023-11-07 10:12         ` [PATCH v6] " Mingjin Ye
2023-11-07 12:18           ` Zhang, Qi Z
2023-11-08 11:39           ` [PATCH v7] " Mingjin Ye
2023-11-09  0:26             ` 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=DM4PR11MB5994E195FF4FDE8658E9A36AD7A7A@DM4PR11MB5994.namprd11.prod.outlook.com \
    --to=qi.z.zhang@intel.com \
    --cc=dev@dpdk.org \
    --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).