On 1/23/2024 2:59 PM, Ferruh Yigit wrote: > On 1/23/2024 12:07 PM, Power, Ciara wrote: >> Hi Ferruh, >> >>> -----Original Message----- >>> From: Ferruh Yigit <ferruh.yi...@amd.com> >>> Sent: Friday, January 19, 2024 2:51 PM >>> To: Sivaramakrishnan, VenkatX <venkatx.sivaramakrish...@intel.com>; Igor >>> Russkikh <irussk...@marvell.com>; Selwin Sebastian >>> <selwin.sebast...@amd.com>; Ajit Khaparde >>> <ajit.khapa...@broadcom.com>; Somnath Kotur >>> <somnath.ko...@broadcom.com>; Nithin Dabilpuram >>> <ndabilpu...@marvell.com>; Kiran Kumar K <kirankum...@marvell.com>; >>> Sunil Kumar Kori <sk...@marvell.com>; Satha Rao >>> <skotesh...@marvell.com>; Zhang, Yuying <yuying.zh...@intel.com>; Xing, >>> Beilei <beilei.x...@intel.com>; Rahul Lakkireddy >>> <rahul.lakkire...@chelsio.com>; Hemant Agrawal >>> <hemant.agra...@nxp.com>; Sachin Saxena <sachin.sax...@nxp.com>; Su, >>> Simei <simei...@intel.com>; Wu, Wenjun1 <wenjun1...@intel.com>; >>> Gagandeep Singh <g.si...@nxp.com>; John Daley <johnd...@cisco.com>; >>> Hyong Youb Kim <hyon...@cisco.com>; Gaetan Rivet <gr...@u256.net>; >>> Zhang, Qi Z <qi.z.zh...@intel.com>; Wang, Xiao W <xiao.w.w...@intel.com>; >>> Jie Hai <haij...@huawei.com>; Yisen Zhuang <yisen.zhu...@huawei.com>; >>> Wu, Jingjing <jingjing...@intel.com>; Yang, Qiming >>> <qiming.y...@intel.com>; Guo, Junfeng <junfeng....@intel.com>; Andrew >>> Boyer <andrew.bo...@amd.com>; Long Li <lon...@microsoft.com>; Matan >>> Azrad <ma...@nvidia.com>; Viacheslav Ovsiienko <viachesl...@nvidia.com>; >>> Dariusz Sosnowski <dsosnow...@nvidia.com>; Ori Kam <or...@nvidia.com>; >>> Suanming Mou <suanmi...@nvidia.com>; Chaoyong He >>> <chaoyong...@corigine.com>; Jiawen Wu <jiawe...@trustnetic.com>; >>> Harman Kalra <hka...@marvell.com>; Devendra Singh Rawat >>> <dsinghra...@marvell.com>; Alok Prasad <pa...@marvell.com>; Andrew >>> Rybchenko <andrew.rybche...@oktetlabs.ru>; Jerin Jacob >>> <jer...@marvell.com>; Maciej Czekaj <mcze...@marvell.com>; Jian Wang >>> <jianw...@trustnetic.com>; Behrens, Jochen <jbehr...@vmware.com>; >>> Thomas Monjalon <tho...@monjalon.net> >>> Cc: dev@dpdk.org; Power, Ciara <ciara.po...@intel.com> >>> Subject: Re: [PATCH v5 2/2] drivers/net: return number of types in get >>> supported types >>> >>> On 1/18/2024 12:07 PM, Sivaramakrishnan Venkat wrote: >>>> Missing "RTE_PTYPE_UNKNOWN" ptype causes buffer overflow. >>>> Enhance code such that the dev_supported_ptypes_get() function pointer >>>> now returns the number of elements to eliminate the need for >>>> "RTE_PTYPE_UNKNOWN" as the last item. >>>> >>>> Signed-off-by: Sivaramakrishnan Venkat >>>> <venkatx.sivaramakrish...@intel.com> >>>> >>>> -- >>>> v5: >>>> - modified commit message. >>>> - tidied formatting of code. >>>> - added doxygen comment. >>>> v4: >>>> - split into two patches, one for backporting and another one for >>>> upstream rework. >>>> v3: >>>> - reworked the function to return number of elements and remove the >>>> need for RTE_PTYPE_UNKNOWN in list. >>>> v2: >>>> - extended fix for multiple drivers. >>>> --- >>> >>> <...> >>> >>>> 59 files changed, 188 insertions(+), 141 deletions(-) >>>> >>> >>> Some driver still have the flag: >>> - drivers/net/mvneta/mvneta_ethdev.c >>> - drivers/net/mvpp2/mrvl_ethdev.c >>> - pfe >>> - dpaa >>> - drivers/net/thunderx/nicvf_ethdev.c >>> - drivers/net/nfp/nfp_net_common.c >>> >>> Above seems the ones updated in previous patch, flags added in previous >>> patch should be removed in this one. >>> >>> >>> And following seems missed and still has the flag: >>> >>> - drivers/net/ngbe/ngbe_ptypes.c >>> >>> <...> >>> >>>> @@ -3971,9 +3975,6 @@ rte_eth_dev_set_ptypes(uint16_t port_id, >>> uint32_t ptype_mask, >>>> } >>>> } >>>> >>>> - if (set_ptypes != NULL && j < num) >>>> - set_ptypes[j] = RTE_PTYPE_UNKNOWN; >>>> - >>>> >>> >>> This change is new in this version and not mentioned in the changelog. >>> >>> 'rte_eth_dev_set_ptypes()' returns 'set_ptypes' that terminated with >>> 'RTE_PTYPE_UNKNOWN', this is how that API works. >>> Why changing it in this patch? >> >> Apologies, yes, we missed this in the changelog. >> >> For the change itself, if we are removing the need for RTE_PTYPE_UNKNOWN in >> the supported ptypes lists to mark the last element, do we still need to add >> it here when setting ptypes list? >> Maybe a misunderstanding on my part - I thought it would be the same for >> both cases. >> >> > > They are two different APIs, and 'rte_eth_dev_set_ptypes()' returns > ptypes to user that will be terminated by RTE_PTYPE_UNKNOWN, so to not > break the user code we can't change it. >
A little more details if helps: 'rte_eth_dev_get_supported_ptypes()', fills the '*ptypes' and function return value is number of elements in the '*ptypes' array. There is no requirement that last element of '*ptypes' will be 'RTE_PTYPE_UNKNOWN', and if you check the current implementation, it is not. 'rte_eth_dev_set_ptypes()', fills the '*set_ptypes' array and function return value is function success status. User can deduce the size of '*set_ptypes' by 'RTE_PTYPE_UNKNOWN' marker at the end of the array. Requirement is last element should be 'RTE_PTYPE_UNKNOWN', and this documented in API. We are preserving above API behavior and only changing ethdev - driver interface.
