From: Linkui Xiao <xiaolinkui@126.com>
To: "Loktionov, Aleksandr" <aleksandr.loktionov@intel.com>,
"Nguyen, Anthony L" <anthony.l.nguyen@intel.com>,
"Kitszel, Przemyslaw" <przemyslaw.kitszel@intel.com>,
"andrew+netdev@lunn.ch" <andrew+netdev@lunn.ch>,
"davem@davemloft.net" <davem@davemloft.net>,
"edumazet@google.com" <edumazet@google.com>,
"kuba@kernel.org" <kuba@kernel.org>,
"pabeni@redhat.com" <pabeni@redhat.com>
Cc: "intel-wired-lan@lists.osuosl.org"
<intel-wired-lan@lists.osuosl.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Linkui Xiao <xiaolinkui@kylinos.cn>
Subject: Re: [Intel-wired-lan] [PATCH net] i40e: limit the DDP profile count returned by the firmware
Date: Wed, 16 Sep 2026 21:06:07 +0800 [thread overview]
Message-ID: <3ab21824-7863-4fb5-9e13-cf0dfd1aa4df@126.com> (raw)
In-Reply-To: <IA3PR11MB898605544C71BB998C0FA35DE5B92@IA3PR11MB8986.namprd11.prod.outlook.com>
On 2026/9/16 14:03, Loktionov, Aleksandr wrote:
>
>
>> -----Original Message-----
>> From: Linkui Xiao <xiaolinkui@126.com>
>> Sent: Tuesday, September 15, 2026 2:04 PM
>> To: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Kitszel,
>> Przemyslaw <przemyslaw.kitszel@intel.com>; andrew+netdev@lunn.ch;
>> davem@davemloft.net; edumazet@google.com; kuba@kernel.org;
>> pabeni@redhat.com
>> Cc: intel-wired-lan@lists.osuosl.org; netdev@vger.kernel.org; linux-
>> kernel@vger.kernel.org; Linkui Xiao <xiaolinkui@kylinos.cn>
>> Subject: [Intel-wired-lan] [PATCH net] i40e: limit the DDP profile
>> count returned by the firmware
>>
>> From: Linkui Xiao <xiaolinkui@kylinos.cn>
>>
>> i40e_aq_get_ddp_list() writes into a I40E_PROFILE_LIST_SIZE buffer,
>> which is sized for I40E_MAX_PROFILE_NUM (16) i40e_profile_info entries
>> plus the 4 byte p_count header. i40e_ddp_does_profile_exist() and
>> i40e_ddp_does_profile_overlap() then loop over profile_list->p_count
>> without bounding it, so a firmware reporting more than 16 profiles
>> makes both helpers walk past the end of the on-stack buff[] and
>> compare against whatever happens to follow it on the stack.
>>
>> Clamp the count to the number of entries the buffer can actually hold
>> and make the loop counter unsigned to match the field type.
>>
>> Fixes: cdc594e00370 ("i40e: Implement DDP support in i40e driver")
>> Signed-off-by: Linkui Xiao <xiaolinkui@kylinos.cn>
>> ---
>> drivers/net/ethernet/intel/i40e/i40e_ddp.c | 18 ++++++++++++++----
>> 1 file changed, 14 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/intel/i40e/i40e_ddp.c
>> b/drivers/net/ethernet/intel/i40e/i40e_ddp.c
>> index daa9f2c42f70..1d6d8b3835a3 100644
>> --- a/drivers/net/ethernet/intel/i40e/i40e_ddp.c
>> +++ b/drivers/net/ethernet/intel/i40e/i40e_ddp.c
>> @@ -55,7 +55,7 @@ static int i40e_ddp_does_profile_exist(struct
>> i40e_hw *hw,
>> struct i40e_ddp_profile_list *profile_list;
>> u8 buff[I40E_PROFILE_LIST_SIZE];
>> int status;
>> - int i;
>> + u32 i, p_count;
> RCT please
>
>>
>> status = i40e_aq_get_ddp_list(hw, buff, I40E_PROFILE_LIST_SIZE,
>> 0,
>> NULL);
>> @@ -63,7 +63,12 @@ static int i40e_ddp_does_profile_exist(struct
>> i40e_hw *hw,
>> return -1;
>>
>> profile_list = (struct i40e_ddp_profile_list *)buff;
>> - for (i = 0; i < profile_list->p_count; i++) {
>> + /* Never walk past the end of buff[], the profile count
>> reported by
>> + * the firmware is not guaranteed to fit into the buffer we
>> gave it.
>> + */
>> + p_count = min_t(u32, profile_list->p_count,
>> I40E_MAX_PROFILE_NUM);
>> +
>> + for (i = 0; i < p_count; i++) {
>> if (i40e_ddp_profiles_eq(pinfo, &profile_list-
>>> p_info[i]))
>> return 1;
>> }
>> @@ -110,7 +115,7 @@ static int i40e_ddp_does_profile_overlap(struct
>> i40e_hw *hw,
>> struct i40e_ddp_profile_list *profile_list;
>> u8 buff[I40E_PROFILE_LIST_SIZE];
>> int status;
>> - int i;
>> + u32 i, p_count;
> RCT please
>
> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Hi,
Thanks for the review and for the Reviewed-by tag.
Just to make sure I understand the "RCT please" comments correctly: are
they referring to the Reverse Christmas Tree (RCT) variable declaration
ordering convention, i.e. the local variables should be declared in
decreasing order of line length? In both functions I currently have:
struct i40e_ddp_profile_list *profile_list;
u8 buff[I40E_PROFILE_LIST_SIZE];
int status;
u32 i, p_count;
If I understand RCT correctly, the expected order would be something like:
struct i40e_ddp_profile_list *profile_list;
u8 buff[I40E_PROFILE_LIST_SIZE];
u32 i, p_count;
int status;
Could you please confirm whether that is what is being asked for, and
whether there are any other RCT-related issues in this patch?
Also, should I send a v2 with the RCT ordering fixed, or would you
prefer to keep the current version as-is since the change is purely
stylistic? I am happy to send a v2 if that is preferred.
Thanks,
Linkui
>
>>
>> status = i40e_aq_get_ddp_list(hw, buff, I40E_PROFILE_LIST_SIZE,
>> 0,
>> NULL);
>> @@ -118,7 +123,12 @@ static int i40e_ddp_does_profile_overlap(struct
>> i40e_hw *hw,
>> return -EIO;
>>
>> profile_list = (struct i40e_ddp_profile_list *)buff;
>> - for (i = 0; i < profile_list->p_count; i++) {
>> + /* Never walk past the end of buff[], the profile count
>> reported by
>> + * the firmware is not guaranteed to fit into the buffer we
>> gave it.
>> + */
>> + p_count = min_t(u32, profile_list->p_count,
>> I40E_MAX_PROFILE_NUM);
>> +
>> + for (i = 0; i < p_count; i++) {
>> if (i40e_ddp_profiles_overlap(pinfo,
>> &profile_list->p_info[i]))
>> return 1;
>> --
>> 2.25.1
>
prev parent reply other threads:[~2026-09-16 13:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-15 12:03 Linkui Xiao
2026-09-16 6:03 ` Loktionov, Aleksandr
2026-09-16 13:06 ` Linkui Xiao [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3ab21824-7863-4fb5-9e13-cf0dfd1aa4df@126.com \
--to=xiaolinkui@126.com \
--cc=aleksandr.loktionov@intel.com \
--cc=andrew+netdev@lunn.ch \
--cc=anthony.l.nguyen@intel.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=przemyslaw.kitszel@intel.com \
--cc=xiaolinkui@kylinos.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®