From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 02291A00C2; Thu, 3 Feb 2022 05:41:09 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8C3C641199; Thu, 3 Feb 2022 05:41:09 +0100 (CET) Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32]) by mails.dpdk.org (Postfix) with ESMTP id DAD4040151; Thu, 3 Feb 2022 05:41:07 +0100 (CET) Received: from pps.filterd (m0246627.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 2131J73Y024816; Thu, 3 Feb 2022 04:41:07 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=corp-2021-07-09; bh=gBmKC5HTK8Aw+jS+lGwzSk+1wAnpsH8Wengimk92ACM=; b=AD/O+Wfqhf7IQEur+JcAf0BSabD+xC/fwQD553GHVjL53f1of/59D5tjtjr6uck8PFm+ JopcBOw9FiJDbL7etoOhzfFNPHNw7Xkeyr3k8ikt5r0KAFslYSxSDHDebqGe4sdcvmiM pm4xtCIit2jNZxMyjUFQdijwFbd/e6fktvTp59CHQCG8erIYF0RZQm++5+mfwDgwdl3Q 04sH4Lg3KRUutyS28U34MM6sOeiIoh+yEdkYeZ1b+xD04bZjBGhBykLv29XapVgCBFNO srxCp/jEXt67EIiCu6zc2zIAyX3S8VKtkEQrnPQB9oWE4ngJkBVk6NExkRREhoqdyi3J VA== Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by mx0b-00069f02.pphosted.com with ESMTP id 3dxjau07sv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 03 Feb 2022 04:41:06 +0000 Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.1.2/8.16.1.2) with SMTP id 2134a3wQ188876; Thu, 3 Feb 2022 04:41:05 GMT Received: from nam11-dm6-obe.outbound.protection.outlook.com (mail-dm6nam11lp2170.outbound.protection.outlook.com [104.47.57.170]) by aserp3030.oracle.com with ESMTP id 3dvumjpdqy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 03 Feb 2022 04:41:05 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gXnotLn9T3WJ1iLXYWo/z6FDin59BPH8kPGdO71TQaEdfNbfoIfOkz8s/wnsjlWUQ/MR3UkBDRX1QZ3EppxTTvLzwHevxiE9kypkjp5KUWdtrgeKhyIETdrJUl+EK35DPLj1WPPG1zbN/FGPUGPCbsVQHLXqqkrfEj3zz5pya1lzNpEJxDQIUxxeyWTlN3BlWtewLBnGxL0osS/aOTTKSzvHsg2zvVwaWekKpJ9ihxuzwLZTW0EGnDYj9B/2kARuhOlt5H5v59oOF2JYi/kcKY3o4AauSDi63/PLM83tJan7sjvNQto9Nr/wPbp57T2picnT1phMVP9TW+roR0mOOw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=gBmKC5HTK8Aw+jS+lGwzSk+1wAnpsH8Wengimk92ACM=; b=iq6cBtzxryvl5LZfBlaiLyUV/lgT4Hc3jqMf4Elmn4uZ8NzY2xmqbaS3tMJy9TYa3nZvKGwye8m18S4W7oaYyIhK+/BATYmP8CSTDNk90HJdV1iJ/nDGiCWXmpiOtFwPtD1gZMrb9a8i/YT9jOojJtCJsveXwTB2qW874qUdxYPY0g0qfp3IndMX3FxfslSDJqqko3NkPC99zHTdptqIPyTQfBcGeUtryFujF++kVbINCDyMLCmsXZcB1NyzlG1o/RT2PXu9dZNf4uuTSGGpmgZJYmbiZoePTTAddlRiHCj9kno0eR1vGz+bxO9No6HlGGQnQ5jwOqbSSFId0GB3Rw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gBmKC5HTK8Aw+jS+lGwzSk+1wAnpsH8Wengimk92ACM=; b=Ux3LGRmYRkkSxRyQDOhaEwHkbcHPBUaHAhDJAOQL0X0wZJYo4A3gLC4wTDQaxWZ4FSnfU3szS1OxQAeHALaMTXSOe5NKMmV7yGkp37nRxZQJ3K/976vqVEwuJOgkO8L6dztgZI+7X8Y+7xkqcCrpV1st280POUkI4XLz4QZaz6M= Received: from CO1PR10MB4756.namprd10.prod.outlook.com (2603:10b6:303:9b::17) by CH2PR10MB3750.namprd10.prod.outlook.com (2603:10b6:610:b::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4930.19; Thu, 3 Feb 2022 04:41:03 +0000 Received: from CO1PR10MB4756.namprd10.prod.outlook.com ([fe80::c934:3558:9e27:c2b7]) by CO1PR10MB4756.namprd10.prod.outlook.com ([fe80::c934:3558:9e27:c2b7%7]) with mapi id 15.20.4951.012; Thu, 3 Feb 2022 04:41:03 +0000 From: Changchun Zhang To: "users@dpdk.org" , "dev@dpdk.org" Subject: RE: cryto_aesni_mb device data contaminated and causing crash when supporting vdev_scan/vdev_action Thread-Topic: cryto_aesni_mb device data contaminated and causing crash when supporting vdev_scan/vdev_action Thread-Index: AQHYGE0D5LwqliNd2kOkHNsup/cQXqyBPjLA Date: Thu, 3 Feb 2022 04:41:03 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d0e27d48-1934-4fff-020b-08d9e6cf625c x-ms-traffictypediagnostic: CH2PR10MB3750:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 1ixM5oy3qSSPc71zwYpvJWgy7Dsq8ByLAOQyjBViI782B772UwQtEytB1OautU0oAFfLVBHIVXZyPYgbr2ngN9ViHZ3MnlBs/TWYtLzkV6XV8owhO5GuxtYfWUAX+rcWfWRJtoxYyJPmCgiecy2WxBs6+Kr/PWKFEP7/MkZJCeXhCih93el/vYgJi3DlW1NR2hankVP5SV2g9zSZ4rCkY55CCtpuK1HeBg3i8Q9H38rGpJWQzOAx3AKtiPRUUa+4Mf1SRgfv/zYC8KzuaKFe8W148bBvvP3q8/wXTkW4RF/fIKsbtRl0cws2Iuf9d4aOVX2Z/O2d60/YHa3hOjaY6CYJDKvErmEi7y7DNxkooMLcFO/Z/QUB8ZTmP31v/TpiCTpFWhT/X446y0Tq/NfEms0gd017KLyOcIU1be4vHztmJQwBdWHr7TPOiDcR+fjE0NTnmeONoiLHBzn0qoVt08OWdARg2cDcicppdXCNUkxmesRvie68ZAmwBBFInRZ0NOqiRUpeMznCCo9z+PiHEwUrL5RS9ER44NKwiRtPdnSzpedbujEVRvlnhcHXP16sTzS/rqwX33NZ2dap30wfcz45DwQ1dQva9/Bbp9OvwNjBSns73LM7r/CuGNE6BHrNEeaZj1HV7UazAy9jJJCoPppVJXSJfhBfo0OE0ET99vjI7EMKu/JjRBMqoPQI5ejhRKU+WovwCxXHaDcvBL9pOmDCRiKAGmsb+3X53Cwf1cUwmBJ4SBsx/h+9GL2FLAgnu+ZiNBHry0DB4mpdKJ638Xk20J7ozLqFVNribPbEy5mOti5tJ25DJ8+lG/oSFuGw x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR10MB4756.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(26005)(44832011)(316002)(110136005)(7696005)(2906002)(508600001)(186003)(966005)(4743002)(76116006)(450100002)(52536014)(8676002)(86362001)(71200400001)(5660300002)(6506007)(66946007)(55016003)(53546011)(9686003)(64756008)(66446008)(33656002)(66476007)(38100700002)(8936002)(122000001)(38070700005)(83380400001)(166002)(66556008)(290074003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?5h+FfuDw5D24wZAgHt5on5df1HA0joijFKCF6dHx8qlGX4QIHo3dIepU6fJY?= =?us-ascii?Q?cUSThCRMaDFxePCXR4grD/2532XRh2dBTljDDIRXaB5afjQ1wy9P/5ZFNckZ?= =?us-ascii?Q?G+4Esn+ohkqsP8m/ID32gPXKHE9+8IVWjjaRJTiRvnIeR0pJ85SaM/yQJEA7?= =?us-ascii?Q?cRdIJsKxwpSnJmRk5569EWISTmH9jI0LGWTyb9JTS5qz6Amw31314H+ebGSy?= =?us-ascii?Q?pWyDwqYgvtJOKC9Z9cTqEmt+BInjytWzbJdtmTw6XHAhAAS2IO6biuTRGovM?= =?us-ascii?Q?FUWe2ZzuZ9iFlu/ZPNWZ5wjjr2Pujce/UHUyV5OfzBZ0H+IqixLakZIVQA4Q?= =?us-ascii?Q?U5mu/0+bmtM21dWTtuwbCyONDknIJjrvFV+Sg309QXLmZ80Qgc7/0FPk/SVe?= =?us-ascii?Q?8gVtckh+ILfNlPm5FrsIyzTU5+f6+zunAaepnMjw5fBExq8YqUNSzTwlgl6L?= =?us-ascii?Q?JM4FzTdE+l4isRqUKhUauuvlIT/SmGQoYuwXNw7Go5nkFnrMCd3pq8OUdumH?= =?us-ascii?Q?6AIccN+Ilz5BwbwtmsqFY8M5HkSaj3d4sjKYsrsufbVbqkLiEoPaTqNKqg8u?= =?us-ascii?Q?wEoZSXRS2LQdC8cWS6FOj6sKKE4EDCllYlCmFI8HzYWIj+X+a3ts05DhU2QH?= =?us-ascii?Q?s5lzW4yjBu4v+/8R+6YKVtW+uIXDutUXBLAWzUBcZwHd8nTIzg5AeQUL9Tii?= =?us-ascii?Q?GbZfe5fh0U7YGJXtgdCXMbgSQqI+8irctDbgQof91A5w27NT3EBOU37KtlY4?= =?us-ascii?Q?M7qwJjf7fb2wwW5ZUy/1mtwWZFRLxy4RTzrYzOMhm3g7ZApKxlzLxl41MiVI?= =?us-ascii?Q?D+kfBAfnfqhDQ11wG8Al2SWgE2R6v4ZaSP6I7sPo3whs0UTE+ixC4ob8sAJi?= =?us-ascii?Q?Y+TVKBOfT0kiBxL+6OBoYLOgqb7weQLGIQeiVJqS2FVD9dS43MRCjjBtbDuQ?= =?us-ascii?Q?hpCMWYNH51LKPdwuk3pfKhZKYt+GtNMA+jhufzZ4xYMPOd7bOHicOSP47BrZ?= =?us-ascii?Q?sTCuPEnzIF1u5NW9uJ+ypKsrSdc0lAPHtXVxnvoIn/fSn3FsqEI92G0DFx7h?= =?us-ascii?Q?QAVHy1rmHQsOEsVwQWRgS56Iw/sAW5o5gazT7lrF35K8GNyfNDkbATxouHjm?= =?us-ascii?Q?GKiZMoMtbjmvdi2PQbzqad3u+u7gu37zWUG2VIkoXynlmIcsdtY3V9WDIPd7?= =?us-ascii?Q?KxN1ritkgH0yZWQL/see4RP7Bo+qVspBNji3NECkYqyfesqs/EYtH2ynL25Z?= =?us-ascii?Q?UfTQcIppB8l4yn/4S5w7nV5FZZwIdlJ2xrk2pOQlAQ3qxWwagqE87nRJZzAR?= =?us-ascii?Q?vFdPw3+ZSTKTrZvzmASCXA/bLW4eHQJUic/VZ6QujFnFr8XJCyGMdC9LujyP?= =?us-ascii?Q?/JrWyKVUeYSnPiKvvvO2A6FmbMYLkghsFXxW/JILSg1lBmjEQ7QmpFXKpnll?= =?us-ascii?Q?rFD2nTQXLWBuvLrXVNTlPPeVGoTF2cbHIcgFTI7xJDBFyqNBO8YRE2CtRf99?= =?us-ascii?Q?aCxZ0LY0Ns6l02CL9iL0OvrmQ7ESY3bPbwZWPwGdpXf3ZDveOObA0w50ZG/9?= =?us-ascii?Q?mZ8FmyI9XMr2Nk35mgrlDVk8Zae1I72i2ctlEtx6RFHZCWXROqrjI914AMl9?= =?us-ascii?Q?iC7kfP8Bt6WHzhw/ZP1cBXPT4VPqw5TFAlsWd19+jotFDobLYnA5PA53CMk0?= =?us-ascii?Q?FriS0g=3D=3D?= Content-Type: multipart/alternative; boundary="_000_CO1PR10MB4756268C96E9C658BDA01BFF84289CO1PR10MB4756namp_" MIME-Version: 1.0 X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CO1PR10MB4756.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d0e27d48-1934-4fff-020b-08d9e6cf625c X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Feb 2022 04:41:03.1358 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: NjDBwnc5QpkdKfmv+YqLzPxFK+7KA2yROobqJiJMg7E6gwF9fRPYsn63nuSoJbP/dUQYNB/I/ddqvjaByhmAjFulWnbufNlAw5eHkpbl8Is= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR10MB3750 X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10246 signatures=673430 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 malwarescore=0 phishscore=0 mlxscore=0 adultscore=0 suspectscore=0 mlxlogscore=999 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2201110000 definitions=main-2202030023 X-Proofpoint-GUID: Tmkwvh88dptKyl-koZOSg8M8TwMKEqGG X-Proofpoint-ORIG-GUID: Tmkwvh88dptKyl-koZOSg8M8TwMKEqGG X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org --_000_CO1PR10MB4756268C96E9C658BDA01BFF84289CO1PR10MB4756namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The issue can be resolved by allocating the mb_mgr only for the primary pro= cess in the PMD probe/create function of the aesni_mb_pmd. Disabling the scanning/probe is just a work around, I guess that is the rea= son why the fix in this https://review.spdk.io/gerrit/c/spdk/dpdk/+/1056 is canceled as the latest DPDK of 21.11 redesigned this PM= D. The mb_mgr is removed from the device data and put to the each creation = of the crypto session (wondering it has performance degradation). Thanks, Changchun (Alex) From: Changchun Zhang [mailto:changchun.zhang@oracle.com] Sent: Wednesday, February 2, 2022 11:08 AM To: users@dpdk.org; dev@dpdk.org Subject: [External] : cryto_aesni_mb device data contaminated and causing c= rash when supporting vdev_scan/vdev_action Hi, Has anyone noticed that crypto_aesni_mb virtual crypto device has issue of = memory crash caused by the scanning and probe on secondary process. Can any= one cast any lights on it. What I encountered is: On the primary process, the crypto_aesni_mb device is probed and created su= ccessfully and I got the mb_mgr set in the device private data. But during = the packet process, the application crashes on accessing the mb_mgr. The de= ugging shows this mb_mgr address has been changed to an invalid address (no= n-NULL). Further digging shows this memory contamination occurs after the v= dev_action replies the scan request. In below code, the crash is gone by either disable sending message on VDEV_= SCAN_REQ or skip processing the VDEV_SCAN_ONE. It seems the insert_vdev() o= n secondary process triggers another probe and break the existing device da= ta? It is also noticed there was an issue which was fixed by this patch https:/= /review.spdk.io/gerrit/c/spdk/dpdk/+/1056 but this patch= is cancelled. This patch was complaining the similar memory issue found du= ring scanning and probing on the secondary process. static int vdev_action(const struct rte_mp_msg *mp_msg, const void *peer) { struct rte_vdev_device *dev; struct rte_mp_msg mp_resp; struct vdev_param *ou =3D (struct vdev_param *)&mp_resp.param; const struct vdev_param *in =3D (const struct vdev_param *)mp_msg->par= am; const char *devname; int num; int ret; strlcpy(mp_resp.name, VDEV_MP_KEY, sizeof(mp_resp.name)); mp_resp.len_param =3D sizeof(*ou); mp_resp.num_fds =3D 0; switch (in->type) { case VDEV_SCAN_REQ: VDEV_LOG(INFO, "changczh skip vdev, %s", devname); ou->type =3D VDEV_SCAN_ONE; ou->num =3D 1; num =3D 0; rte_spinlock_recursive_lock(&vdev_device_list_lock); TAILQ_FOREACH(dev, &vdev_device_list, next) { devname =3D rte_vdev_device_name(dev); if (strlen(devname) =3D=3D 0) { VDEV_LOG(INFO, "vdev with no name is not sent"); continue; } VDEV_LOG(INFO, "send vdev, %s", devname); strlcpy(ou->name, devname, RTE_DEV_NAME_MAX_LEN); if (rte_mp_sendmsg(&mp_resp) < 0) VDEV_LOG(ERR, "send vdev, %s, failed, %s", devname, strerror(rte_errno)); num++; } rte_spinlock_recursive_unlock(&vdev_device_list_lock); ou->type =3D VDEV_SCAN_REP; ou->num =3D num; if (rte_mp_reply(&mp_resp, peer) < 0) VDEV_LOG(ERR, "Failed to reply a scan request"); break; case VDEV_SCAN_ONE: VDEV_LOG(INFO, "receive vdev, %s", in->name); ret =3D insert_vdev(in->name, NULL, NULL, false); if (ret =3D=3D -EEXIST) VDEV_LOG(DEBUG, "device already exist, %s", in->name); else if (ret < 0) VDEV_LOG(ERR, "failed to add vdev, %s", in->name); break; default: VDEV_LOG(ERR, "vdev cannot recognize this message"); } return 0; } Thanks, Alex --_000_CO1PR10MB4756268C96E9C658BDA01BFF84289CO1PR10MB4756namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The issue can be resolved by allocating the mb_mgr o= nly for the primary process in the PMD probe/create function of the aesni_m= b_pmd.

Disab= ling the scanning/probe is just a work around, I guess that is the reason w= hy the fix in this https= ://review.spdk.io/gerrit/c/spdk/dpdk/+/1056 is canceled as the latest DPDK of 21.11 redesigned this PMD. The mb_mgr is= removed from the device data and put to the each creation of the crypto se= ssion (wondering it has performance degradation).

=  

 

Thanks,<= /span>

Changchun (Alex)<= /o:p>

=  

From: Changchun Zhang [mailto:changchun.zhang= @oracle.com]
Sent: Wednesday, February 2, 2022 11:08 AM
To: users@dpdk.org; dev@dpdk.org
Subject: [External] : cryto_aesni_mb device data contaminated and ca= using crash when supporting vdev_scan/vdev_action

 

Hi,

 

Has anyone noticed that crypto_aesni_mb virtual crypto de= vice has issue of memory crash caused by the scanning and probe on secondar= y process. Can anyone cast any lights on it.

What I encountered is:

On the primary process, the crypto_aesni_mb device is pro= bed and created successfully and I got the mb_mgr set in the device private= data. But during the packet process, the application crashes on accessing the mb_mgr. The deugging shows this mb_mgr address ha= s been changed to an invalid address (non-NULL). Further digging shows this= memory contamination occurs after the vdev_action replies the scan request= .

In below code, the crash is gone by either disable sendin= g message on VDEV_SCAN_REQ or skip processing the VDEV_SCAN_ONE. It seems t= he insert_vdev() on secondary process triggers another probe and break the existing device data?

It is also noticed there was an issue which was fixed by = this patch https://review.spdk.io/gerrit/c/spdk/dpdk/+/1056 but this patch is canc= elled. This patch was complaining the similar memory issue found during sca= nning and probing on the secondary process.

 

static int

vdev_action(const struct rte_mp_msg *mp_msg, const void *p= eer)

{

     struct rte_vdev_device *dev;=

     struct rte_mp_msg mp_resp;

     struct vdev_param *ou =3D (struct= vdev_param *)&mp_resp.param;

     const struct vdev_param *in =3D (= const struct vdev_param *)mp_msg->param;

     const char *devname;

     int num;

     int ret;

 

     strlcpy(mp_resp.name, VDEV_MP_KEY= , sizeof(mp_resp.name));

     mp_resp.len_param =3D sizeof(*ou)= ;

     mp_resp.num_fds =3D 0;=

 

     switch (in->type) {=

     case VDEV_SCAN_REQ:

          VDE= V_LOG(INFO, "changczh skip vdev, %s", devname);=

          ou-= >type =3D VDEV_SCAN_ONE;

          ou-= >num =3D 1;

          num= =3D 0;

 

          rte= _spinlock_recursive_lock(&vdev_device_list_lock);

          TAI= LQ_FOREACH(dev, &vdev_device_list, next) {

         &nbs= p;    devname =3D rte_vdev_device_name(dev);

         &nbs= p;    if (strlen(devname) =3D=3D 0) {

         &nbs= p;         VDEV_LOG(INFO, "vde= v with no name is not sent");

         &nbs= p;         continue;

         &nbs= p;    }

         &nbs= p;    VDEV_LOG(INFO, "send vdev, %s", devname);

         &nbs= p;    strlcpy(ou->name, devname, RTE_DEV_NAME_MAX_LEN);

         &nbs= p;    if (rte_mp_sendmsg(&mp_resp) < 0)

         &nbs= p;         VDEV_LOG(ERR, "send= vdev, %s, failed, %s",

         &nbs= p;            &= nbsp; devname, strerror(rte_errno));

         &nbs= p;    num++;

          }

          rte= _spinlock_recursive_unlock(&vdev_device_list_lock);

          ou-= >type =3D VDEV_SCAN_REP;

          ou-= >num =3D num;

          if = (rte_mp_reply(&mp_resp, peer) < 0)

         &nbs= p;    VDEV_LOG(ERR, "Failed to reply a scan request&quo= t;);

          bre= ak;

     case VDEV_SCAN_ONE:

          VDE= V_LOG(INFO, "receive vdev, %s", in->name);

          = ret =3D insert_vdev(in->name, NULL, NULL, false);    = ;            &n= bsp;            = ;         

          if = (ret =3D=3D -EEXIST)

         &nbs= p;    VDEV_LOG(DEBUG, "device already exist, %s", = in->name);

          els= e if (ret < 0)

         &nbs= p;    VDEV_LOG(ERR, "failed to add vdev, %s", in-&= gt;name);

          bre= ak;

     default:

          VDE= V_LOG(ERR, "vdev cannot recognize this message");

     }

 

     return 0;

}

 

 

Thanks,

Alex

--_000_CO1PR10MB4756268C96E9C658BDA01BFF84289CO1PR10MB4756namp_--