linux-kernel - Re: [PATCH net-next 06/14] ice: Extend PTYPE bitmap coverage for GTP encapsulated flows

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <902dab41-51f0-4e01-8149-921fb80db23d@intel.com>
Date: Thu, 16 Oct 2025 14:37:53 -0700
From: Jacob Keller <jacob.e.keller@...el.com>
To: Simon Horman <horms@...nel.org>
CC: Jakub Kicinski <kuba@...nel.org>, Jiri Pirko <jiri@...nulli.us>, "David S.
 Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, "Paolo
 Abeni" <pabeni@...hat.com>, Jonathan Corbet <corbet@....net>, Tony Nguyen
	<anthony.l.nguyen@...el.com>, Przemek Kitszel <przemyslaw.kitszel@...el.com>,
	Andrew Lunn <andrew+netdev@...n.ch>, Alexander Lobakin
	<aleksander.lobakin@...el.com>, <netdev@...r.kernel.org>,
	<linux-doc@...r.kernel.org>, <linux-kernel@...r.kernel.org>, Dan Nowlin
	<dan.nowlin@...el.com>, Qi Zhang <qi.z.zhang@...el.com>, Jie Wang
	<jie1x.wang@...el.com>, Junfeng Guo <junfeng.guo@...el.com>, "Jedrzej
 Jagielski" <jedrzej.jagielski@...el.com>, Aleksandr Loktionov
	<aleksandr.loktionov@...el.com>, Rafal Romanowski
	<rafal.romanowski@...el.com>
Subject: Re: [PATCH net-next 06/14] ice: Extend PTYPE bitmap coverage for GTP
 encapsulated flows



On 10/16/2025 12:03 PM, Simon Horman wrote:
> On Thu, Oct 16, 2025 at 10:20:25AM -0700, Jacob Keller wrote:
>>
>>
>> On 10/16/2025 5:21 AM, Simon Horman wrote:
>>> On Wed, Oct 15, 2025 at 12:32:02PM -0700, Jacob Keller wrote:
>>>> From: Przemek Kitszel <przemyslaw.kitszel@...el.com>
>>>>
>>>> Consolidate updates to the Protocol Type (PTYPE) bitmap definitions
>>>> across multiple flow types in the Intel ICE driver to support GTP
>>>> (GPRS Tunneling Protocol) encapsulated traffic.
>>>>
>>>> Enable improved Receive Side Scaling (RSS) configuration for both user
>>>> and control plane GTP flows.
>>>>
>>>> Cover a wide range of protocol and encapsulation scenarios, including:
>>>>  - MAC OFOS and IL
>>>>  - IPv4 and IPv6 (OFOS, IL, ALL, no-L4)
>>>>  - TCP, SCTP, ICMP
>>>>  - GRE OF
>>>>  - GTPC (control plane)
>>>>
>>>> Expand the PTYPE bitmap entries to improve classification and
>>>> distribution of GTP traffic across multiple queues, enhancing
>>>> performance and scalability in mobile network environments.
>>>>
>>>> --
>>>
>>> Hi Jacob,
>>>
>>> Perhaps surprisingly, git truncates the commit message at
>>> the ('--') line above. So, importantly, the tags below are absent.
>>>
>>
>> Its somewhat surprising, since I thought you had to use '---' for that.
>> Regardless, this shouldn't be in the commit message at all.
>>> Also, the two lines below seem out of place.
>>>
>>>>  ice_flow.c |   54 +++++++++++++++++++++++++++---------------------------
>>>>  1 file changed, 26 insertions(+), 26 deletions(-)
>>>>
>>
>> Yep these shouldn't have been here at all. I checked, and for some
>> reason it was included in the original message id of the patch. b4
>> happily picked it up when using b4 shazam.
>>
>> See:
>> https://lore.kernel.org/intel-wired-lan/20250915133928.3308335-5-aleksandr.loktionov@intel.com/
>>
>> I am not sure if this is the fault of b4, though it has different
>> behavior than other git tooling here.
> 
> TBH, I am also surprised that git truncates at '--'. I also thought
> '---'. And as this is the second time it's come up recently,
> while I don't recall seeing it before, perhaps due to some tooling change
> somewhere: e.g. interaction between git and b4.
> 

Hm. Looking into this more, since I wanted to figure out how *I* got
those in my commit.

I checked the original message posted to Intel Wired LAN, and the
contents are there.

Git says:

>        The patch is expected to be inline, directly following the message. Any line that is of the form:
> 
>        •   three-dashes and end-of-line, or
> 
>        •   a line that begins with "diff -", or
> 
>        •   a line that begins with "Index: "
> 
>        is taken as the beginning of a patch, and the commit log message is terminated before the first occurrence of such a line.

This is only 2 dashes, so it shouldn't trigger the 3-dash rule. Indeed,
if I use b4 shazam, I get these lines in the commit message. (That
explains how it ended up on my tree when I submitted).

If I use git format-patch on this commit, I get the lines in the file.
If I then use git am to apply the formatted patch file, I indeed still
keep these lines in the commit message.

What version of git are you using? I'm using git v2.51.0 Perhaps this
isn't a b4 or git issue but some other tooling that is causing an issue
(patchwork?).

At least on my system I do actually preserve the lines below '--', and
it is not until '---' which it will start stripping data.
>> I fixed this on my end, and can resubmit after the 24hr period if needed.
> 
> FWIIW, I'd lean towards reposting after 24h if you don't hear from one of
> the maintainers.
> 
> 

Obviously, we shouldn't need these lines in the commit message, so I
will still send a v2 and drop the cruft.


Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (237 bytes)