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 <[email protected]> >>> Sent: Friday, January 19, 2024 2:51 PM >>> To: Sivaramakrishnan, VenkatX <[email protected]>; Igor >>> Russkikh <[email protected]>; Selwin Sebastian >>> <[email protected]>; Ajit Khaparde >>> <[email protected]>; Somnath Kotur >>> <[email protected]>; Nithin Dabilpuram >>> <[email protected]>; Kiran Kumar K <[email protected]>; >>> Sunil Kumar Kori <[email protected]>; Satha Rao >>> <[email protected]>; Zhang, Yuying <[email protected]>; Xing, >>> Beilei <[email protected]>; Rahul Lakkireddy >>> <[email protected]>; Hemant Agrawal >>> <[email protected]>; Sachin Saxena <[email protected]>; Su, >>> Simei <[email protected]>; Wu, Wenjun1 <[email protected]>; >>> Gagandeep Singh <[email protected]>; John Daley <[email protected]>; >>> Hyong Youb Kim <[email protected]>; Gaetan Rivet <[email protected]>; >>> Zhang, Qi Z <[email protected]>; Wang, Xiao W <[email protected]>; >>> Jie Hai <[email protected]>; Yisen Zhuang <[email protected]>; >>> Wu, Jingjing <[email protected]>; Yang, Qiming >>> <[email protected]>; Guo, Junfeng <[email protected]>; Andrew >>> Boyer <[email protected]>; Long Li <[email protected]>; Matan >>> Azrad <[email protected]>; Viacheslav Ovsiienko <[email protected]>; >>> Dariusz Sosnowski <[email protected]>; Ori Kam <[email protected]>; >>> Suanming Mou <[email protected]>; Chaoyong He >>> <[email protected]>; Jiawen Wu <[email protected]>; >>> Harman Kalra <[email protected]>; Devendra Singh Rawat >>> <[email protected]>; Alok Prasad <[email protected]>; Andrew >>> Rybchenko <[email protected]>; Jerin Jacob >>> <[email protected]>; Maciej Czekaj <[email protected]>; Jian Wang >>> <[email protected]>; Behrens, Jochen <[email protected]>; >>> Thomas Monjalon <[email protected]> >>> Cc: [email protected]; Power, Ciara <[email protected]> >>> 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 >>>> <[email protected]> >>>> >>>> -- >>>> 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.
