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 781A1A00BE; Thu, 10 Feb 2022 17:08:57 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 693334117D; Thu, 10 Feb 2022 17:08:57 +0100 (CET) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by mails.dpdk.org (Postfix) with ESMTP id D16DE41176 for ; Thu, 10 Feb 2022 17:08:56 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 851065C01EE; Thu, 10 Feb 2022 11:08:56 -0500 (EST) Received: from imap48 ([10.202.2.98]) by compute2.internal (MEProxy); Thu, 10 Feb 2022 11:08:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=u256.net; h=cc :cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm1; bh=qyf8+FOICxzkqJxkaYTnviTldKCOg5hIn3NwuV yL4Oo=; b=DjICXWl3uoObs9sGbwKZKnHynWsIUCLTlhbymWbti2knSfzXZZn2kn tvVLHAt3uy/RI/DnwOkf4yr+OcrFAqLDEksxIbWYhF2rA9A9t14rV05Q2e+NyF2g qEnMtiXHDVjfftnZGHXsKfbtAhqoBXjPCoM8bXLJTG7EA974u5voxCM1FynSENnt Beo1rtND17YOulFifhmken46WY+QBRi2u7fOVsEXcY4A8R8CFah14k+KxMtl/U2r VMdStroX2G8xMRuapOKJAT9XdXKGTboP43U4ALAV+zRfZHf/LhRnZIGjI7MY1Jlz gXpiLEh+agb9aSxrO43c6Wi+j/axmynA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=qyf8+FOICxzkqJxka YTnviTldKCOg5hIn3NwuVyL4Oo=; b=Xd36QX98hf6ZrdUHIrv2jnlU5cMabldeH GHCIv1cR0i6NJ2FXreAc8CQQxVORtMeiIpYVgXanrpZu/0KHf/kdTsy9zSTudqy+ 0uWSOy0a0qsHn3dxO9Cq20It0zHPZhy8ZfD55EQQF8Jdf1dvKaVIglezpK/F+fwb ZHLXIUiaMAXY9oqUEJIjiHpxy/rmNwrN2bVNr+jc4hBTCd6wKfcKXKFq2lor09uQ ByjX/Vjb6A0QGfUjVFTgehWgEt2K4oDdyNsiS3jrGJkN5r9568uS3sb3y2bMj3Zt JYqusS1t2bck1XDYkpThIGkwYVeBsBYureqxqaOpSXIJQ9IXeEljw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddriedugdekfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderreejnecuhfhrohhmpefirgotthgr nhgptfhivhgvthcuoehgrhhivhgvsehuvdehiedrnhgvtheqnecuggftrfgrthhtvghrnh epgfeuhfffleeludeuheeuteeufeegtdeiveduudfhgeevteeutdelueffueehkeefnecu vehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepghhrihhvvg esuhdvheeirdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2A83A21E006E; Thu, 10 Feb 2022 11:08:56 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-4748-g31a5b5f50e-fm-cal2020-20220204.001-g31a5b5f5 Mime-Version: 1.0 Message-Id: <9dc29099-0c73-4070-b017-69de6fc0e687@www.fastmail.com> In-Reply-To: <0a3f6aa6-2499-ce40-6dd0-721f70017003@intel.com> References: <20220210071052.527-1-madhuker.mythri@oracle.com> <0a3f6aa6-2499-ce40-6dd0-721f70017003@intel.com> Date: Thu, 10 Feb 2022 17:08:34 +0100 From: =?UTF-8?Q?Ga=C3=ABtan_Rivet?= To: "Ferruh Yigit" , madhuker.mythri@oracle.com Cc: dev@dpdk.org Subject: Re: Content-Type: text/plain 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 On Thu, Feb 10, 2022, at 16:00, Ferruh Yigit wrote: > On 2/10/2022 7:10 AM, madhuker.mythri@oracle.com wrote: >> From: Madhuker Mythri >> >> Failsafe pmd started crashing with global devargs syntax as devargs is >> not memset to zero. Access it to in rte_devargs_parse resulted in a >> crash when called from secondary process. >> >> Bugzilla Id: 933 >> >> Signed-off-by: Madhuker Mythri >> --- >> drivers/net/failsafe/failsafe.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/drivers/net/failsafe/failsafe.c b/drivers/net/failsafe/failsafe.c >> index 3c754a5f66..aa93cc6000 100644 >> --- a/drivers/net/failsafe/failsafe.c >> +++ b/drivers/net/failsafe/failsafe.c >> @@ -360,6 +360,7 @@ rte_pmd_failsafe_probe(struct rte_vdev_device *vdev) >> if (sdev->devargs.name[0] == '\0') >> continue; >> >> + memset(&devargs, 0, sizeof(devargs)); >> /* rebuild devargs to be able to get the bus name. */ >> ret = rte_devargs_parse(&devargs, >> sdev->devargs.name); > > if 'rte_devargs_parse()' requires 'devargs' parameter to be memset, > what do you think memset it in the API? > This prevents forgotten cases like this. Hi, I was looking at it this morning. Before the last release, rte_devargs_parse() was only supporting legacy syntax. It never read from the devargs structure, only wrote to it. So it was safe to use with a non-memset devargs. The rte_devargs_layer_parse() however is more complex. To allow rte_dev_iterator_init() to call it without doing memory allocation, it reads parts of the devargs to make decisions. Doing a first call to rte_devargs_layer_parse() as part of rte_devargs_parse() thus modified the contract it had with the users, that it would never read from devargs. It is not possible to completely avoid reading from devargs in rte_devargs_layer_parse(). It is necessary for RTE_DEV_FOREACH() to be safe to interrupt without having to do iterator cleanup. This is my current understanding. In that context, yes I think it is preferrable to do memset() within rte_devargs_parse(). It will restore the previous part of the API saying that calling it with non-memset devargs was safe to do. Thanks, -- Gaetan Rivet