From: "Szapar-Mudlaw, Martyna" <martyna.szapar-mudlaw@linux.intel.com>
To: Paul Menzel <pmenzel@molgen.mpg.de>, Jan Glaza <jan.glaza@intel.com>
Cc: intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
Jedrzej Jagielski <jedrzej.jagielski@intel.com>,
Simon Horman <horms@kernel.org>,
Alexander Lobakin <aleksander.lobakin@intel.com>
Subject: Re: [Intel-wired-lan] [iwl-net v3 1/5] virtchnl: make proto and filter action count unsigned
Date: Tue, 4 Mar 2025 14:11:42 +0100 [thread overview]
Message-ID: <e384e61a-4ccd-4ae7-8ddd-66259769f6dd@linux.intel.com> (raw)
In-Reply-To: <832cc2a5-0c15-42d1-924b-a14674db6391@molgen.mpg.de>
On 3/4/2025 12:51 PM, Paul Menzel wrote:
> Dear Martyna,
>
>
> Thank you for your quick reply.
>
> Am 04.03.25 um 12:45 schrieb Szapar-Mudlaw, Martyna:
>
>> On 3/4/2025 12:15 PM, Paul Menzel wrote:
>
>>> Am 04.03.25 um 12:08 schrieb Martyna Szapar-Mudlaw:
>>>> From: Jan Glaza <jan.glaza@intel.com>
>>>>
>>>> The count field in virtchnl_proto_hdrs and virtchnl_filter_action_set
>>>> should never be negative while still being valid. Changing it from
>>>> int to u32 ensures proper handling of values in virtchnl messages in
>>>> driverrs and prevents unintended behavior.
>>>> In its current signed form, a negative count does not trigger
>>>> an error in ice driver but instead results in it being treated as 0.
>>>> This can lead to unexpected outcomes when processing messages.
>>>> By using u32, any invalid values will correctly trigger -EINVAL,
>>>> making error detection more robust.
>>>>
>>>> Fixes: 1f7ea1cd6a374 ("ice: Enable FDIR Configure for AVF")
>>>> Reviewed-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com>
>>>> Reviewed-by: Simon Horman <horms@kernel.org>
>>>> Signed-off-by: Jan Glaza <jan.glaza@intel.com>
>>>> Signed-off-by: Martyna Szapar-Mudlaw <martyna.szapar-
>>>> mudlaw@linux.intel.com>
>>>> ---
>>>> include/linux/avf/virtchnl.h | 4 ++--
>>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/include/linux/avf/virtchnl.h b/include/linux/avf/
>>>> virtchnl.h
>>>> index 4811b9a14604..cf0afa60e4a7 100644
>>>> --- a/include/linux/avf/virtchnl.h
>>>> +++ b/include/linux/avf/virtchnl.h
>>>> @@ -1343,7 +1343,7 @@ struct virtchnl_proto_hdrs {
>>>> * 2 - from the second inner layer
>>>> * ....
>>>> **/
>>>> - int count; /* the proto layers must <
>>>> VIRTCHNL_MAX_NUM_PROTO_HDRS */
>>>> + u32 count; /* the proto layers must <
>>>> VIRTCHNL_MAX_NUM_PROTO_HDRS */
>>>
>>> Why limit the length, and not use unsigned int?
>>
>> u32 range is completely sufficient for number of proto hdrs (as said:
>> "the proto layers must < VIRTCHNL_MAX_NUM_PROTO_HDRS") and I believe
>> it is recommended to use fixed sized variables where possible
>
> Do you have a pointer to the recommendation? I heard the opposite, that
> fixed length is only useful for register writes. Otherwise, you should
> use the “generic” types [1].
Thanks for sharing the source and your perspective, you are right, as a
general rule, using generic types is preferred - I actually learned
something new from this.
That said, I still believe there are exceptions, and in this case, using
u32 is the right choice. When dealing with protocols or data formats
using a fixed-width type makes sense.
Additionally, throughout this file, we consistently use u32/u16 for
similar cases, so also here we're keeping it aligned with the existing
codebase.
Thank you for your review and appreciate the discussion on best practices.
Regards,
Martyna
>
>>>> union {
>>>> struct virtchnl_proto_hdr
>>>> proto_hdr[VIRTCHNL_MAX_NUM_PROTO_HDRS];
>>>> @@ -1395,7 +1395,7 @@ VIRTCHNL_CHECK_STRUCT_LEN(36,
>>>> virtchnl_filter_action);
>>>> struct virtchnl_filter_action_set {
>>>> /* action number must be less then VIRTCHNL_MAX_NUM_ACTIONS */
>>>> - int count;
>>>> + u32 count;
>>>> struct virtchnl_filter_action actions[VIRTCHNL_MAX_NUM_ACTIONS];
>>>> };
>
> Kind regards,
>
> Paul
>
>
> [1]: https://notabs.org/coding/smallIntsBigPenalty.htm
>
next prev parent reply other threads:[~2025-03-04 13:11 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-04 11:08 [Intel-wired-lan] [iwl-net v3 0/5] ice: fix validation issues in virtchnl parameters Martyna Szapar-Mudlaw
2025-03-04 11:08 ` Martyna Szapar-Mudlaw
2025-03-04 11:08 ` [Intel-wired-lan] [iwl-net v3 1/5] virtchnl: make proto and filter action count unsigned Martyna Szapar-Mudlaw
2025-03-04 11:08 ` Martyna Szapar-Mudlaw
2025-03-04 11:15 ` [Intel-wired-lan] " Paul Menzel
2025-03-04 11:45 ` Szapar-Mudlaw, Martyna
2025-03-04 11:51 ` Paul Menzel
2025-03-04 13:11 ` Szapar-Mudlaw, Martyna [this message]
2025-03-17 13:29 ` Romanowski, Rafal
2025-03-17 13:29 ` Romanowski, Rafal
2025-03-04 11:08 ` [Intel-wired-lan] [iwl-net v3 2/5] ice: stop truncating queue ids when checking Martyna Szapar-Mudlaw
2025-03-04 11:08 ` Martyna Szapar-Mudlaw
2025-03-17 13:28 ` [Intel-wired-lan] " Romanowski, Rafal
2025-03-17 13:28 ` Romanowski, Rafal
2025-03-04 11:08 ` [Intel-wired-lan] [iwl-net v3 3/5] ice: validate queue quanta parameters to prevent OOB access Martyna Szapar-Mudlaw
2025-03-04 11:08 ` Martyna Szapar-Mudlaw
2025-03-17 13:28 ` [Intel-wired-lan] " Romanowski, Rafal
2025-03-17 13:28 ` Romanowski, Rafal
2025-03-04 11:08 ` [Intel-wired-lan] [iwl-net v3 4/5] ice: fix input validation for virtchnl BW Martyna Szapar-Mudlaw
2025-03-04 11:08 ` Martyna Szapar-Mudlaw
2025-03-17 13:27 ` [Intel-wired-lan] " Romanowski, Rafal
2025-03-17 13:27 ` Romanowski, Rafal
2025-03-04 11:08 ` [Intel-wired-lan] [iwl-net v3 5/5] ice: fix using untrusted value of pkt_len in ice_vc_fdir_parse_raw() Martyna Szapar-Mudlaw
2025-03-04 11:08 ` Martyna Szapar-Mudlaw
2025-03-17 13:27 ` [Intel-wired-lan] " Romanowski, Rafal
2025-03-17 13:27 ` Romanowski, Rafal
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=e384e61a-4ccd-4ae7-8ddd-66259769f6dd@linux.intel.com \
--to=martyna.szapar-mudlaw@linux.intel.com \
--cc=aleksander.lobakin@intel.com \
--cc=horms@kernel.org \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jan.glaza@intel.com \
--cc=jedrzej.jagielski@intel.com \
--cc=netdev@vger.kernel.org \
--cc=pmenzel@molgen.mpg.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.