From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 8EA31A00C4; Thu, 23 Apr 2020 15:30:56 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 9C1381C1F7; Thu, 23 Apr 2020 15:30:55 +0200 (CEST) Received: from mailout2.w1.samsung.com (mailout2.w1.samsung.com [210.118.77.12]) by dpdk.org (Postfix) with ESMTP id 022EF1B6B4 for ; Thu, 23 Apr 2020 15:30:53 +0200 (CEST) Received: from eucas1p1.samsung.com (unknown [182.198.249.206]) by mailout2.w1.samsung.com (KnoxPortal) with ESMTP id 20200423133052euoutp022587b23fa663120adcd3b01a77054951~Idgm7FtCA0829508295euoutp029 for ; Thu, 23 Apr 2020 13:30:52 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout2.w1.samsung.com 20200423133052euoutp022587b23fa663120adcd3b01a77054951~Idgm7FtCA0829508295euoutp029 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1587648652; bh=dCECE8uhuTBDq5SlCUssduGct5DFxcoDPBqYXzyJ4MQ=; h=Subject:To:Cc:From:Date:In-Reply-To:References:From; b=puU0Du4YAgsWP6GSBC6DL1cqJeloo5qJJ+ea5gF8DdkIDzr2FMx6tfhAja89l3Wnv fjY6hNJN6b2Q25ZQfWLhIRvOhm/+ZgCUKgWQeLzHfpG1WbmLmDde20MH40IfoO8Aiu QZGF/NoDH0DaIdZYr35fJlPdQq8zSmNofVjhF0no= Received: from eusmges2new.samsung.com (unknown [203.254.199.244]) by eucas1p2.samsung.com (KnoxPortal) with ESMTP id 20200423133052eucas1p2514a715e0756001caac4347416591be7~Idgm0xTlk0867108671eucas1p21; Thu, 23 Apr 2020 13:30:52 +0000 (GMT) Received: from eucas1p1.samsung.com ( [182.198.249.206]) by eusmges2new.samsung.com (EUCPMTA) with SMTP id 93.27.60679.C8891AE5; Thu, 23 Apr 2020 14:30:52 +0100 (BST) Received: from eusmtrp2.samsung.com (unknown [182.198.249.139]) by eucas1p1.samsung.com (KnoxPortal) with ESMTPA id 20200423133052eucas1p1012daf769904d4b41f1e3d34261361e6~Idgmf9jQ_2676126761eucas1p1B; Thu, 23 Apr 2020 13:30:52 +0000 (GMT) Received: from eusmgms1.samsung.com (unknown [182.198.249.179]) by eusmtrp2.samsung.com (KnoxPortal) with ESMTP id 20200423133052eusmtrp26125ba32a5d35738eeecf2f6935b2212~IdgmfZfHd0347803478eusmtrp2i; Thu, 23 Apr 2020 13:30:52 +0000 (GMT) X-AuditID: cbfec7f4-0e5ff7000001ed07-65-5ea1988c58ad Received: from eusmtip1.samsung.com ( [203.254.199.221]) by eusmgms1.samsung.com (EUCPMTA) with SMTP id 30.2F.08375.C8891AE5; Thu, 23 Apr 2020 14:30:52 +0100 (BST) Received: from [106.210.88.70] (unknown [106.210.88.70]) by eusmtip1.samsung.com (KnoxPortal) with ESMTPA id 20200423133051eusmtip1ca411d746594006c622785a1d934d3d7~IdgmBRe5B2092820928eusmtip1P; Thu, 23 Apr 2020 13:30:51 +0000 (GMT) To: Akhil Goyal , Anoob Joseph , "Ananyev, Konstantin" , "dev@dpdk.org" Cc: "Doherty, Declan" From: Lukasz Wojciechowski Message-ID: <9be859c5-9904-ea51-2e32-4b0775f233a0@partner.samsung.com> Date: Thu, 23 Apr 2020 15:30:50 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Transfer-Encoding: 8bit Content-Language: pl X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFKsWRmVeSWpSXmKPExsWy7djPc7o9MxbGGXyar26x/sw8RotlW7Yy Wbx50MRi8e7TdiaL938WsTiwevxasJTVY/Gel0wekxdeZPbY+G4HUwBLFJdNSmpOZllqkb5d AlfG3rcT2QqW81RMa8psYGzg6mLk5JAQMJHY+2UtcxcjF4eQwApGifX/HkM5XxglFp85CuV8 ZpT4NXcOE0zL7PULWCASyxklNm29xwThvGWUuLrhEyNIlbBAmMTZ+a2MIAkRgYWMEgdvrGIF STALGEh0tDewg9hsArYSR2Z+BYpzcPAKuEnsfe4DYrIIqEos288CYooKxEpMvxYCUswrIChx cuYTsDAnUPjgTEGIefISzVtnM0PYIhI3HrWALZUQmMcu8XniPRaIm10kbmxvY4awhSVeHd/C DmHLSPzfOZ8JomEb0Pm/f0J172eUuN67AqrKWuLwv99sIJuZBTQl1u/Shwg7Sqx79AvsegkB Pokbb6EO4pOYtG06M0SYV6KjTQiiWk/iac9URpi1f9Y+YZnAqDQLyWezkLwzC8k7sxD2LmBk WcUonlpanJueWmyUl1quV5yYW1yal66XnJ+7iRGYYk7/O/5lB+OuP0mHGAU4GJV4eG8ULYwT Yk0sK67MPcQowcGsJMK74eG8OCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8xotexgoJpCeWpGan phakFsFkmTg4pRoY51mzqGRZPNH7lX1rnUN1K0M62wPD8KZZCn/f7t98rLl5yT3HlQd7dSf4 Td0v/+uQn3nk2flqXItfXpgdnifqwqMlf9OS74e645lXJcxFF8Nlw/8FdU5h2TX948kly412 HE+ZO38nu+ubP3OZ3p3esDz1m9yPwqbj2d5TLI7NVVxzfdXsqeXSN5RYijMSDbWYi4oTAaLO xNQtAwAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJIsWRmVeSWpSXmKPExsVy+t/xu7o9MxbGGTRsELZYf2Yeo8WyLVuZ LN48aGKxePdpO5PF+z+LWBxYPX4tWMrqsXjPSyaPyQsvMntsfLeDKYAlSs+mKL+0JFUhI7+4 xFYp2tDCSM/Q0kLPyMRSz9DYPNbKyFRJ384mJTUnsyy1SN8uQS9j79uJbAXLeSqmNWU2MDZw dTFyckgImEjMXr+ABcQWEljKKLFkZ1wXIwdQXEbiwyUBiBJhiT/Xuti6GLmASl4zSsx7eIcZ JCEsECZxdn4rI4gtIrCQUWLmNC8Qm1nAQKKjvYEdoqGdVeL3nq1MIAk2AVuJIzO/soIs4BVw k9j73AfEZBFQlVi2nwXEFBWIlWi5qAlSzCsgKHFy5hOwMCdQ+OBMQYjhZhLzNj9khrDlJZq3 zoayRSRuPGphnMAoNAtJ9ywkLbOQtMxC0rKAkWUVo0hqaXFuem6xoV5xYm5xaV66XnJ+7iZG YDRtO/Zz8w7GSxuDDzEKcDAq8fDeKFoYJ8SaWFZcmXuIUYKDWUmEd8PDeXFCvCmJlVWpRfnx RaU5qcWHGE2BPpvILCWanA+M9LySeENTQ3MLS0NzY3NjMwslcd4OgYMxQgLpiSWp2ampBalF MH1MHJxSDYwT/ZvibKTSk+rvnNv1dP+DXfusw9Zon/6WxtJ29YjaVJetZ1rDt2St05+j8EXE TEw9Idl+aZLX9k+WTyOuupTZzOz9YPciv/qtleHJTRkztzGt/fTy0IxFDzQZ3JyveG472t11 dDvPgQ+fI6oWHXknlXF7fSFb4C67e4d0N72bZxN3zCbUcfN6JZbijERDLeai4kQAii5xDrwC AAA= X-CMS-MailID: 20200423133052eucas1p1012daf769904d4b41f1e3d34261361e6 X-Msg-Generator: CA Content-Type: text/plain; charset="utf-8" X-RootMTR: 20200423125533eucas1p1f7e5fca1540327c8b1dd6a93e068f4d0 X-EPHeader: CA CMS-TYPE: 201P X-CMS-RootMailID: 20200423125533eucas1p1f7e5fca1540327c8b1dd6a93e068f4d0 References: <20200422235158.24497-1-konstantin.ananyev@intel.com> Subject: Re: [dpdk-dev] [PATCH] security: fix crash at accessing non-implemented ops X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" W dniu 23.04.2020 o 14:55, Akhil Goyal pisze: > Hi Anoob/Konstantin, >>> Check that ops->get_userdata is a valid function pointer will be compiled out. >>> So PMDs that don't implement this function will crash in >>> rte_security_get_userdata(). >>> In our particular case - ixgbe. >>> Same story with rte_security_set_pkt_metadata() - see the patch. >> [Anoob] But ixgbe doesn't implement inline protocol which is the primary >> consumer of this API (rte_security_get_userdata()). So what is the trouble? >> >> Also, application is expected to call rte_security_set_pkt_metadata() only on >> devices with offload flag RTE_SECURITY_TX_OLOAD_NEED_MDATA. If a PMD >> states it needs MDATA but fails to register a function pointer for doing the same, >> it is a control path problem. Checking for that in the datapath is an overkill. >> > Whatever your concern is, we can resolve it later, but for now we should have the same > Unconditional checks that were there earlier. We need to make RC1 today/tomorrow. > And this cannot go as an issue. > > These are optional APIs and every PMD may not have supported that. > > Konstantin, > Please send an update to your patch reverting the original patch for these 2 functions. > Currently it is adding 2 extra checks. > > Regards, > Akhil > Please remember also about updating app/test. I will be glad to help with this matter. -- Lukasz Wojciechowski Principal Software Engineer Samsung R&D Institute Poland Samsung Electronics Office +48 22 377 88 25 l.wojciechow@partner.samsung.com