* [PATCH net 2/2] net: ipa: Fix decoding EV_PER_EE for IPA v5.0+
From: Luca Weiss @ 2026-04-09 8:13 UTC (permalink / raw)
To: Alex Elder, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni
Cc: ~postmarketos/upstreaming, phone-devel, netdev, linux-arm-msm,
linux-kernel, Luca Weiss
In-Reply-To: <20260409-ipa-fixes-v1-0-a817c30678ac@fairphone.com>
Initially 'reg' and 'val' are assigned from HW_PARAM_2.
But since IPA v5.0+ takes EV_PER_EE from HW_PARAM_4 (instead of
NUM_EV_PER_EE from HW_PARAM_2), we not only need to re-assign 'reg' but
also read the register value of that register into 'val' so that
reg_decode() works on the correct value.
Fixes: f651334e1ef5 ("net: ipa: add HW_PARAM_4 GSI register")
Link: https://sashiko.dev/#/patchset/20260403-milos-ipa-v1-0-01e9e4e03d3e%40fairphone.com?part=2
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
drivers/net/ipa/gsi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ipa/gsi.c b/drivers/net/ipa/gsi.c
index 4c3227e77898..624649484d62 100644
--- a/drivers/net/ipa/gsi.c
+++ b/drivers/net/ipa/gsi.c
@@ -2044,6 +2044,7 @@ static int gsi_ring_setup(struct gsi *gsi)
count = reg_decode(reg, NUM_EV_PER_EE, val);
} else {
reg = gsi_reg(gsi, HW_PARAM_4);
+ val = ioread32(gsi->virt + reg_offset(reg));
count = reg_decode(reg, EV_PER_EE, val);
}
if (!count) {
--
2.53.0
^ permalink raw reply related
* Re: [PATCH net-next] l2tp: Drop large packets with UDP encap
From: Paolo Abeni @ 2026-04-09 8:15 UTC (permalink / raw)
To: Alice Mikityanska, Simon Horman
Cc: Alice Mikityanska, David S. Miller, Eric Dumazet, Jakub Kicinski,
James Chapman, netdev, syzbot+ci3edea60a44225dec
In-Reply-To: <CAD0BsJU8-NBeAGn_rPD-woZARNZ8vb6uJGMDNf70syRkzKiL4A@mail.gmail.com>
On 4/8/26 7:11 PM, Alice Mikityanska wrote:
> On Wed, 8 Apr 2026 at 19:48, Simon Horman <horms@kernel.org> wrote:
>> On Fri, Apr 03, 2026 at 08:49:49PM +0300, Alice Mikityanska wrote:
>>> From: Alice Mikityanska <alice@isovalent.com>
>>>
>>> syzbot reported a WARN on my patch series [1]. The actual issue is an
>>> overflow of 16-bit UDP length field, and it exists in the upstream code.
>>> My series added a debug WARN with an overflow check that exposed the
>>> issue, that's why syzbot tripped on my patches, rather than on upstream
>>> code.
>>>
>>> syzbot's repro:
>>>
>>> # {"procs":1,"slowdown":1,"sandbox":"","sandbox_arg":0,"close_fds":false,"callcomments":true}
>>> r0 = socket$pppl2tp(0x18, 0x1, 0x1)
>>> r1 = socket$inet6_udp(0xa, 0x2, 0x0)
>>> connect$inet6(r1, &(0x7f00000000c0)={0xa, 0x0, 0x0, @loopback, 0xfffffffc}, 0x1c)
>>> connect$pppl2tp(r0, &(0x7f0000000240)=@pppol2tpin6={0x18, 0x1, {0x0, r1, 0x4, 0x0, 0x0, 0x0, {0xa, 0x4e22, 0xffff, @ipv4={'\x00', '\xff\xff', @empty}}}}, 0x32)
>>> writev(r0, &(0x7f0000000080)=[{&(0x7f0000000000)="ee", 0x34000}], 0x1)
>>>
>>> It basically sends an oversized (0x34000 bytes) PPPoL2TP packet with UDP
>>> encapsulation, and l2tp_xmit_core doesn't check for overflows when it
>>> assigns the UDP length field. The value gets trimmed to 16 bites.
>>>
>>> Add an overflow check that drops oversized packets and avoids sending
>>> packets with trimmed UDP length to the wire.
>>>
>>> syzbot's stack trace (with my patch applied):
>>>
>>> len >= 65536u
>>> WARNING: ./include/linux/udp.h:38 at udp_set_len_short include/linux/udp.h:38 [inline], CPU#1: syz.0.17/5957
>>> WARNING: ./include/linux/udp.h:38 at l2tp_xmit_core net/l2tp/l2tp_core.c:1293 [inline], CPU#1: syz.0.17/5957
>>> WARNING: ./include/linux/udp.h:38 at l2tp_xmit_skb+0x1204/0x18d0 net/l2tp/l2tp_core.c:1327, CPU#1: syz.0.17/5957
>>> Modules linked in:
>>> CPU: 1 UID: 0 PID: 5957 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)
>>> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
>>> RIP: 0010:udp_set_len_short include/linux/udp.h:38 [inline]
>>> RIP: 0010:l2tp_xmit_core net/l2tp/l2tp_core.c:1293 [inline]
>>> RIP: 0010:l2tp_xmit_skb+0x1204/0x18d0 net/l2tp/l2tp_core.c:1327
>>> Code: 0f 0b 90 e9 21 f9 ff ff e8 e9 05 ec f6 90 0f 0b 90 e9 8d f9 ff ff e8 db 05 ec f6 90 0f 0b 90 e9 cc f9 ff ff e8 cd 05 ec f6 90 <0f> 0b 90 e9 de fa ff ff 44 89 f1 80 e1 07 80 c1 03 38 c1 0f 8c 4f
>>> RSP: 0018:ffffc90003d67878 EFLAGS: 00010293
>>> RAX: ffffffff8ad985e3 RBX: ffff8881a6400090 RCX: ffff8881697f0000
>>> RDX: 0000000000000000 RSI: 0000000000034010 RDI: 000000000000ffff
>>> RBP: dffffc0000000000 R08: 0000000000000003 R09: 0000000000000004
>>> R10: dffffc0000000000 R11: fffff520007acf00 R12: ffff8881baf20900
>>> R13: 0000000000034010 R14: ffff8881a640008e R15: ffff8881760f7000
>>> FS: 000055557e81f500(0000) GS:ffff8882a9467000(0000) knlGS:0000000000000000
>>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>> CR2: 0000200000033000 CR3: 00000001612f4000 CR4: 00000000000006f0
>>> Call Trace:
>>> <TASK>
>>> pppol2tp_sendmsg+0x40a/0x5f0 net/l2tp/l2tp_ppp.c:302
>>> sock_sendmsg_nosec net/socket.c:727 [inline]
>>> __sock_sendmsg net/socket.c:742 [inline]
>>> sock_write_iter+0x503/0x550 net/socket.c:1195
>>> do_iter_readv_writev+0x619/0x8c0 fs/read_write.c:-1
>>> vfs_writev+0x33c/0x990 fs/read_write.c:1059
>>> do_writev+0x154/0x2e0 fs/read_write.c:1105
>>> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
>>> do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
>>> entry_SYSCALL_64_after_hwframe+0x77/0x7f
>>> RIP: 0033:0x7f636479c629
>>> Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
>>> RSP: 002b:00007ffffd4241c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000014
>>> RAX: ffffffffffffffda RBX: 00007f6364a15fa0 RCX: 00007f636479c629
>>> RDX: 0000000000000001 RSI: 0000200000000080 RDI: 0000000000000003
>>> RBP: 00007f6364832b39 R08: 0000000000000000 R09: 0000000000000000
>>> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
>>> R13: 00007f6364a15fac R14: 00007f6364a15fa0 R15: 00007f6364a15fa0
>>> </TASK>
>>>
>>> [1]: https://lore.kernel.org/all/20260226201600.222044-1-alice.kernel@fastmail.im/
>>>
>>> Reported-by: syzbot+ci3edea60a44225dec@syzkaller.appspotmail.com
>>> Closes: https://lore.kernel.org/netdev/69a1dfba.050a0220.3a55be.0026.GAE@google.com/
>>
>> Hi Alice,
>>
>> A Fixes tag needs to go here.
>> And if it's fixing code present in net - that is, the bug can manifest
>> there - then it should be targeted at net rather than net-next.
>
> Thanks for the review! I submitted to net-next, because I wanted to
> piggy-back my net-next series on top of this fix without making a
> merge conflict, and the bug didn't look that critical to go to net
> (sometimes I received feedback that my bugfixes should have been
> submitted to -next).
The expected workflow in this case is: submit the fix(es) to net, wait
for the following net -> net-next cross merge (happens on Thursday),
submit the dependent net-next patch(es).
> I can resubmit to net, if it's something that
> deserves backporting, or the maintainers can apply it to net instead.
> For the Fixes tag, I can take the closest commit:
>
> Fixes: 0d76751fad77 ("l2tp: Add L2TPv3 IP encapsulation (no UDP) support")
>
> It's old enough (2010) to cover all supported LTS kernels. Or I can go
> as deep as:
>
> Fixes: 3557baabf280 ("[L2TP]: PPP over L2TP driver core")
It looks like the correct fix tag is the latter. The patch LGTM and
given the current PW status, I'm applying it to net without a repost.
Thanks,
Paolo
^ permalink raw reply
* Re: [PATCH net 1/2] net: ipa: Fix programming of QTIME_TIMESTAMP_CFG
From: Konrad Dybcio @ 2026-04-09 8:17 UTC (permalink / raw)
To: Luca Weiss, Alex Elder, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni
Cc: ~postmarketos/upstreaming, phone-devel, netdev, linux-arm-msm,
linux-kernel
In-Reply-To: <20260409-ipa-fixes-v1-1-a817c30678ac@fairphone.com>
On 4/9/26 10:13 AM, Luca Weiss wrote:
> The 'val' variable gets overwritten multiple times, discarding previous
> values. Looking at the git log shows these should be combined with |=
> instead.
>
> Fixes: 9265a4f0f0b4 ("net: ipa: define even more IPA register fields")
> Link: https://sashiko.dev/#/patchset/20260403-milos-ipa-v1-0-01e9e4e03d3e%40fairphone.com?part=4
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> ---
Ha, nice!
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH net 2/2] net: ipa: Fix decoding EV_PER_EE for IPA v5.0+
From: Konrad Dybcio @ 2026-04-09 8:18 UTC (permalink / raw)
To: Luca Weiss, Alex Elder, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni
Cc: ~postmarketos/upstreaming, phone-devel, netdev, linux-arm-msm,
linux-kernel
In-Reply-To: <20260409-ipa-fixes-v1-2-a817c30678ac@fairphone.com>
On 4/9/26 10:13 AM, Luca Weiss wrote:
> Initially 'reg' and 'val' are assigned from HW_PARAM_2.
>
> But since IPA v5.0+ takes EV_PER_EE from HW_PARAM_4 (instead of
> NUM_EV_PER_EE from HW_PARAM_2), we not only need to re-assign 'reg' but
> also read the register value of that register into 'val' so that
> reg_decode() works on the correct value.
>
> Fixes: f651334e1ef5 ("net: ipa: add HW_PARAM_4 GSI register")
> Link: https://sashiko.dev/#/patchset/20260403-milos-ipa-v1-0-01e9e4e03d3e%40fairphone.com?part=2
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH net-next v1 2/2] ice: add 0x88E7 handling to SW validation paths
From: Romanowski, Rafal @ 2026-04-09 8:21 UTC (permalink / raw)
To: Loktionov, Aleksandr, intel-wired-lan@lists.osuosl.org,
Nguyen, Anthony L, Loktionov, Aleksandr
Cc: netdev@vger.kernel.org
In-Reply-To: <20260318080737.3012293-3-aleksandr.loktionov@intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Aleksandr Loktionov
> Sent: Wednesday, March 18, 2026 9:08 AM
> To: intel-wired-lan@lists.osuosl.org; Nguyen, Anthony L
> <anthony.l.nguyen@intel.com>; Loktionov, Aleksandr
> <aleksandr.loktionov@intel.com>
> Cc: netdev@vger.kernel.org
> Subject: [Intel-wired-lan] [PATCH net-next v1 2/2] ice: add 0x88E7 handling to
> SW validation paths
>
> The virtchnl v2 VLAN capability handshake now includes the new
> VIRTCHNL_VLAN_ETHERTYPE_88E7 flag for IEEE 802.1ah B-TAG support.
> Wire up the corresponding software-path handling in ice so the PF correctly
> accepts and translates 0x88E7 (ETH_P_8021AH) VLAN filters requested by VFs.
>
> Three software-only changes, no hardware offload path affected:
>
> - ice_check_supported_vlan_tpid() (ice_tc_lib.c): accept ETH_P_8021AH
> in the TC VLAN TPID validation switch so 0x88E7-tagged flower filters
> are not rejected early.
>
> - validate_vlan() (ice_vsi_vlan_lib.c): allow ETH_P_8021AH as a valid
> TPID when adding VLAN filters to a VSI, consistent with the other
> accepted dot1q/dot1ad/QinQ1 TPIDs.
>
> - ice_vc_validate_vlan_tpid() / ice_vc_get_tpid() (virt/virtchnl.c):
> bidirectional translation between ETH_P_8021AH and
> VIRTCHNL_VLAN_ETHERTYPE_88E7 in the virtchnl VLAN v2 filter path.
>
> This does not add 0x88E7 hardware offload capability, does not change outer-tag
> programming, and does not alter any datapath.
>
> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> ---
> drivers/net/ethernet/intel/ice/ice_tc_lib.c | 1 +
> drivers/net/ethernet/intel/ice/ice_vsi_vlan_lib.c | 3 ++-
> drivers/net/ethernet/intel/ice/virt/virtchnl.c | 6 ++++++
> 3 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/intel/ice/ice_tc_lib.c
> b/drivers/net/ethernet/intel/ice/ice_tc_lib.c
> index d20357c..4560e55 100644
> --- a/drivers/net/ethernet/intel/ice/ice_tc_lib.c
> +++ b/drivers/net/ethernet/intel/ice/ice_tc_lib.c
> @@ -174,6 +174,7 @@ static u16 ice_check_supported_vlan_tpid(u16 vlan_tpid)
Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
^ permalink raw reply
* Re: [PATCH 6/6] arm64: dts: qcom: milos-fairphone-fp6: Enable IPA
From: Luca Weiss @ 2026-04-09 8:26 UTC (permalink / raw)
To: Dmitry Baryshkov, Luca Weiss
Cc: Alex Elder, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Alexander Koskovich,
~postmarketos/upstreaming, phone-devel, netdev, linux-kernel,
linux-arm-msm, devicetree
In-Reply-To: <ku4w5dbfk4ihxfslyf7lcxtxnbzabim5mmtm7xlhqbnmav36iv@zt3dky3vbfbo>
Hi Dmitry,
On Fri Apr 3, 2026 at 9:27 PM CEST, Dmitry Baryshkov wrote:
> On Fri, Apr 03, 2026 at 06:43:52PM +0200, Luca Weiss wrote:
>> Configure and enable the node for IPA which enables mobile data on this
>> device.
>>
>> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
>> ---
>> arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts | 9 +++++++++
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts b/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts
>> index c1899db46e71..31c6d6627619 100644
>> --- a/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts
>> +++ b/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts
>> @@ -690,6 +690,15 @@ vreg_l7p: ldo7 {
>> /* AW86938FCR vibrator @ 0x5a */
>> };
>>
>> +&ipa {
>> + firmware-name = "qcom/milos/fairphone/fp6/ipa_fws.mbn";
>> + memory-region = <&ipa_fw_mem>;
>> +
>> + qcom,gsi-loader = "self";
>
> Are these two common to all Milos devices? Should they be a part of the
> milos.dtsi?
All qcom,gsi-loader properties are in device .dts (or device-common
.dtsi) files, never in SoC .dtsi files. Based on this, I guess it would
mostly differ based on the boot firmware used. If Linux is booted in
EL2, then probably it needs to be changed?
Regards
Luca
^ permalink raw reply
* Re: [PATCH net-next] l2tp: Drop large packets with UDP encap
From: patchwork-bot+netdevbpf @ 2026-04-09 8:30 UTC (permalink / raw)
To: Alice Mikityanska
Cc: davem, edumazet, kuba, pabeni, horms, jchapman, netdev, alice,
syzbot+ci3edea60a44225dec
In-Reply-To: <20260403174949.843941-1-alice.kernel@fastmail.im>
Hello:
This patch was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Fri, 3 Apr 2026 20:49:49 +0300 you wrote:
> From: Alice Mikityanska <alice@isovalent.com>
>
> syzbot reported a WARN on my patch series [1]. The actual issue is an
> overflow of 16-bit UDP length field, and it exists in the upstream code.
> My series added a debug WARN with an overflow check that exposed the
> issue, that's why syzbot tripped on my patches, rather than on upstream
> code.
>
> [...]
Here is the summary with links:
- [net-next] l2tp: Drop large packets with UDP encap
https://git.kernel.org/netdev/net/c/ebe560ea5f54
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next v3 0/4] net: move .getsockopt away from __user buffers
From: Stefan Metzmacher @ 2026-04-09 8:39 UTC (permalink / raw)
To: David Laight, Breno Leitao
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Kuniyuki Iwashima, Willem de Bruijn, axboe,
Stanislav Fomichev, io-uring, bpf, netdev, Linus Torvalds,
linux-kernel, kernel-team
In-Reply-To: <3fd4bf27-344f-45fc-bca3-9e9676522972@samba.org>
Am 08.04.26 um 15:56 schrieb Stefan Metzmacher:
> Am 08.04.26 um 13:26 schrieb David Laight:
>> On Wed, 08 Apr 2026 03:30:28 -0700
>> Breno Leitao <leitao@debian.org> wrote:
>>
>>> Currently, the .getsockopt callback requires __user pointers:
>>>
>>> int (*getsockopt)(struct socket *sock, int level,
>>> int optname, char __user *optval, int __user *optlen);
>>>
>>> This prevents kernel callers (io_uring, BPF) from using getsockopt on
>>> levels other than SOL_SOCKET, since they pass kernel pointers.
>>>
>>> Following Linus' suggestion [0], this series introduces sockopt_t, a
>>> type-safe wrapper around iov_iter, and a getsockopt_iter callback that
>>> works with both user and kernel buffers. AF_PACKET and CAN raw are
>>> converted as initial users, with selftests covering the trickiest
>>> conversion patterns.
>>
>> What are you doing about the cases where 'optlen' is a complete lie?
>> IIRC there is one related to some form of async io where it is just
>> the length of the header, the actual buffer length depends on
>> data in the header.
>> This doesn't matter with the existing code for applications, when they
>> get it wrong they just crash.
>> But kernel users will need to pass the actual buffer length separately
>> from optlen.
>> It also affects any code that tries to cache the actual data and copy
>> it back to userspace in the syscall wrapper - which makes sense for
>> most short getsockopt.
>>
>> (This is different from historic code where the length might be
>> assumed to be 4 regardless of what was passed.)
>
> As the insane legacy cases can only happen for keeping
> compatibility with existing userspace applications,
> we could get the original optval and optlen __user pointers
> out of sockopt_t again via something like:
>
> char __user * __must_check sockopt_get_insame_legacy_optval(sockopt_t *sopt);
> int __user * __must_check sockopt_get_insame_legacy_optlen(sockopt_t *sopt);
>
> And for kernel callers they return NULL and the code should
> turn that into -EINVAL or something similar.
Or better helper macros/inline functions to call the legacy implementations.
something like this:
int sockopt_call_legacy_sock_fn(struct socket *sock, int level, int optname, sockopt_t *sopt,
int kernel_errno,
int (*legacy_fn)(struct socket *sock, int level,
int optname, char __user *optval, int __user *optlen))
{
if (!sopt->legacy.optlen)
return kernel_errno;
return legacy_fn(sock, level, optname, sopt->legacy.optval, sopt->legacy.optlen);
}
And a similar sockopt_call_legacy_sk_fn() that takes struct sock instead of struct socket.
That way it would be relatively easy to move the calls of sockopt_call_legacy_{sock,sk}_fn
down the stack to the places where it's really needed in incremental steps.
^ permalink raw reply
* Re: [PATCH net-next v9 00/10] net: phy_port: SFP modules representation and phy_port listing
From: Maxime Chevallier @ 2026-04-09 8:40 UTC (permalink / raw)
To: Paolo Abeni, davem, Andrew Lunn, Jakub Kicinski, Eric Dumazet,
Russell King, Heiner Kallweit
Cc: netdev, linux-kernel, thomas.petazzoni, Christophe Leroy,
Herve Codina, Florian Fainelli, Vladimir Oltean,
Köry Maincent, Marek Behún, Oleksij Rempel,
Nicolò Veronese, Simon Horman, mwojtas, Romain Gantois,
Daniel Golle, Dimitri Fedrau
In-Reply-To: <76e290cd-22bd-4ed3-b2b3-036e1edff140@redhat.com>
On 09/04/2026 09:35, Paolo Abeni wrote:
> @Maxime: I went over sashiko feedback and I *think* it ranges from
> orthogonal to wrong, but it would be useful if you could go over it.
Yeah I've looked at its feedback, and indeed most of it is incorrect or
irrelevant :(
Let's see if the PHY crew have things to say on the overall approach :)
Thanks for pinging on this,
Maxime
>
> Thanks,
>
> Paolo
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH net] ice: Fix missing 1's complement negation in GCS raw checksum
From: Loktionov, Aleksandr @ 2026-04-09 8:45 UTC (permalink / raw)
To: Matt Fleming, Nguyen, Anthony L, Kitszel, Przemyslaw
Cc: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, intel-wired-lan@lists.osuosl.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel-team@cloudflare.com, Matt Fleming
In-Reply-To: <20260408190214.1287708-1-matt@readmodwrite.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Matt Fleming
> Sent: Wednesday, April 8, 2026 9:02 PM
> To: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Kitszel,
> Przemyslaw <przemyslaw.kitszel@intel.com>
> Cc: Andrew Lunn <andrew+netdev@lunn.ch>; David S . Miller
> <davem@davemloft.net>; Eric Dumazet <edumazet@google.com>; Jakub
> Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>; intel-
> wired-lan@lists.osuosl.org; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; kernel-team@cloudflare.com; Matt Fleming
> <mfleming@cloudflare.com>
> Subject: [Intel-wired-lan] [PATCH net] ice: Fix missing 1's complement
> negation in GCS raw checksum
>
> From: Matt Fleming <mfleming@cloudflare.com>
>
> Commit 905d1a220e8d ("ice: Add E830 checksum offload support") added
> Generic Checksum (GCS) support for E830 NICs but omitted the 1's
> complement negation (~) when converting the hardware raw_csum to
> skb->csum for CHECKSUM_COMPLETE.
>
> Without the negation, every CHECKSUM_COMPLETE packet fails the fast-
> path validation in nf_ip_checksum() and falls through to software
> checksumming via __skb_checksum_complete(), which triggers the rate-
> limited "hw csum failure" warning. Packets are still accepted (the
> software recheck passes) but hardware checksum offload is effectively
> disabled and the warning floods dmesg on systems running nf_conntrack
> on VLAN sub-interfaces.
>
> Multiple other drivers (idpf, ehea, iwlwifi, cassini, sunhme, enetc)
> also apply ~ for CHECKSUM_COMPLETE. The ice driver was the only in-
> tree user of csum_unfold() for CHECKSUM_COMPLETE that omitted it.
>
> Fixes: 905d1a220e8d ("ice: Add E830 checksum offload support")
> Signed-off-by: Matt Fleming <mfleming@cloudflare.com>
> ---
> drivers/net/ethernet/intel/ice/ice_txrx_lib.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/intel/ice/ice_txrx_lib.c
> b/drivers/net/ethernet/intel/ice/ice_txrx_lib.c
> index e695a664e53d..c177579e0114 100644
> --- a/drivers/net/ethernet/intel/ice/ice_txrx_lib.c
> +++ b/drivers/net/ethernet/intel/ice/ice_txrx_lib.c
> @@ -92,7 +92,7 @@ static void ice_rx_gcs(struct sk_buff *skb,
> desc = (struct ice_32b_rx_flex_desc_nic *)rx_desc;
> skb->ip_summed = CHECKSUM_COMPLETE;
> csum = (__force u16)desc->raw_csum;
> - skb->csum = csum_unfold((__force __sum16)swab16(csum));
> + skb->csum = csum_unfold((__force __sum16)~swab16(csum));
> }
>
> /**
> --
> 2.43.0
I'd recommend adding Cc: stable@vger.kernel.org
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* Re: [PATCH 3/5] uaccess: add copy_struct_{from,to}_bounce_buffer() helpers
From: Stefan Metzmacher @ 2026-04-09 8:47 UTC (permalink / raw)
To: David Laight
Cc: linux-kernel, Dmitry Safonov, Dmitry Safonov, Francesco Ruggeri,
Salam Noureddine, David Ahern, David S . Miller, Michal Luczaj,
David Wei, Luiz Augusto von Dentz, Luiz Augusto von Dentz,
Marcel Holtmann, Xin Long, Eric Dumazet, Kuniyuki Iwashima,
Paolo Abeni, Willem de Bruijn, Neal Cardwell, Jakub Kicinski,
Simon Horman, Aleksa Sarai, Christian Brauner, Kees Cook, netdev,
linux-bluetooth
In-Reply-To: <20260407192540.321f3879@pumpkin>
Hi David,
> On Tue, 7 Apr 2026 18:03:15 +0200
> Stefan Metzmacher <metze@samba.org> wrote:
>
>> These are similar to copy_struct_{from,to}_user() but operate
>> on kernel buffers instead of user buffers.
>>
>> They can be used when there is a temporary bounce buffer used,
>> e.g. in msg_control or similar places.
>>
>> It allows us to have the same logic to handle old vs. current
>> and current vs. new structures in the same compatible way.
>>
>> copy_struct_from_sockptr() will also be able to
>> use copy_struct_from_bounce_buffer() for the kernel
>> case as follow us patch.
>>
>> I'll use this in my IPPROTO_SMBDIRECT work,
>> but maybe it will also be useful for others...
>> IPPROTO_QUIC will likely also use it.
>>
>> Cc: Dmitry Safonov <0x7f454c46@gmail.com>
>> Cc: Dmitry Safonov <dima@arista.com>
>> Cc: Francesco Ruggeri <fruggeri@arista.com>
>> Cc: Salam Noureddine <noureddine@arista.com>
>> Cc: David Ahern <dsahern@kernel.org>
>> Cc: David S. Miller <davem@davemloft.net>
>> Cc: Michal Luczaj <mhal@rbox.co>
>> Cc: David Wei <dw@davidwei.uk>
>> Cc: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
>> Cc: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
>> Cc: Marcel Holtmann <marcel@holtmann.org>
>> Cc: Xin Long <lucien.xin@gmail.com>
>> Cc: Eric Dumazet <edumazet@google.com>
>> Cc: Kuniyuki Iwashima <kuniyu@google.com>
>> Cc: Paolo Abeni <pabeni@redhat.com>
>> Cc: Willem de Bruijn <willemb@google.com>
>> Cc: Neal Cardwell <ncardwell@google.com>
>> Cc: Jakub Kicinski <kuba@kernel.org>
>> Cc: Simon Horman <horms@kernel.org>
>> Cc: Aleksa Sarai <cyphar@cyphar.com>
>> Cc: Christian Brauner <brauner@kernel.org>
>> CC: Kees Cook <keescook@chromium.org>
>> Cc: netdev@vger.kernel.org
>> Cc: linux-bluetooth@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Stefan Metzmacher <metze@samba.org>
>> ---
>> include/linux/uaccess.h | 63 +++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 63 insertions(+)
>>
>> diff --git a/include/linux/uaccess.h b/include/linux/uaccess.h
>> index 1234b5fa4761..a6cd4f48bb99 100644
>> --- a/include/linux/uaccess.h
>> +++ b/include/linux/uaccess.h
>> @@ -513,6 +513,69 @@ copy_struct_to_user(void __user *dst, size_t usize, const void *src,
>> return 0;
>> }
>>
>> +static __always_inline void
>> +__copy_struct_generic_bounce_buffer(void *dst, size_t dstsize,
>> + const void *src, size_t srcsize,
>> + bool *ignored_trailing)
>> +{
>> + size_t size = min(dstsize, srcsize);
>> + size_t rest = max(dstsize, srcsize) - size;
>> +
>> + /* Deal with trailing bytes. */
>> + if (dstsize > srcsize)
>> + memset(dst + size, 0, rest);
>> + if (ignored_trailing)
>> + *ignored_trailing = dstsize < srcsize &&
>> + memchr_inv(src + size, 0, rest) != NULL;
>> + /* Copy the interoperable parts of the struct. */
>> + memcpy(dst, src, size);
>> +}
>
> Return 'ignored_trailing' rather than pass by reference.
I also thought about that but it makes
the copy_struct_to_ case more complex.
I'm not sure but my guess would be that
the compiler would have the chance to skip the
ignore_trailing logic if (as all current callers do)
NULL is passed.
> And this is probably too big to inline.
In the next patch this replace open coded logic in
copy_struct_from_sockptr. So as all of copy_struct_*
consists of inline functions I thought it would be good to
keep it that way.
So unless there a real good reason to change it
I'd like to keep it as is.
Thanks!
metze
^ permalink raw reply
* [PATCH net-next 0/2] ipvlan: multicast delivery changes
From: Eric Dumazet @ 2026-04-09 8:52 UTC (permalink / raw)
To: David S . Miller, Jakub Kicinski, Paolo Abeni
Cc: Simon Horman, netdev, eric.dumazet, Eric Dumazet
As we did recently for macvlan, this series adds some relief
when ipvlan is under multicast storms.
Eric Dumazet (2):
ipvlan: ipvlan_handle_mode_l2() refactoring
ipvlan: avoid spinlock contention in ipvlan_multicast_enqueue()
drivers/net/ipvlan/ipvlan_core.c | 42 +++++++++++++++++---------------
1 file changed, 23 insertions(+), 19 deletions(-)
--
2.53.0.1213.gd9a14994de-goog
^ permalink raw reply
* [PATCH net-next 1/2] ipvlan: ipvlan_handle_mode_l2() refactoring
From: Eric Dumazet @ 2026-04-09 8:52 UTC (permalink / raw)
To: David S . Miller, Jakub Kicinski, Paolo Abeni
Cc: Simon Horman, netdev, eric.dumazet, Eric Dumazet
In-Reply-To: <20260409085238.1122947-1-edumazet@google.com>
Reduce indentation level, and add a likely() clause
as we expect to process more unicast packets than multicast ones.
No functional change, this eases the following patch review.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
drivers/net/ipvlan/ipvlan_core.c | 38 +++++++++++++++-----------------
1 file changed, 18 insertions(+), 20 deletions(-)
diff --git a/drivers/net/ipvlan/ipvlan_core.c b/drivers/net/ipvlan/ipvlan_core.c
index 0b493a8aa33857d531329e8eaef6b25a5c6f572d..214fd299a5aa6e40579aa2dbcb178b5474b561a4 100644
--- a/drivers/net/ipvlan/ipvlan_core.c
+++ b/drivers/net/ipvlan/ipvlan_core.c
@@ -744,34 +744,32 @@ static rx_handler_result_t ipvlan_handle_mode_l3(struct sk_buff **pskb,
static rx_handler_result_t ipvlan_handle_mode_l2(struct sk_buff **pskb,
struct ipvl_port *port)
{
- struct sk_buff *skb = *pskb;
+ struct sk_buff *nskb, *skb = *pskb;
struct ethhdr *eth = eth_hdr(skb);
- rx_handler_result_t ret = RX_HANDLER_PASS;
if (unlikely(skb->pkt_type == PACKET_LOOPBACK))
return RX_HANDLER_PASS;
- if (is_multicast_ether_addr(eth->h_dest)) {
- if (ipvlan_external_frame(skb, port)) {
- struct sk_buff *nskb = skb_clone(skb, GFP_ATOMIC);
+ /* Perform like l3 mode for non-multicast packet */
+ if (likely(!is_multicast_ether_addr(eth->h_dest)))
+ return ipvlan_handle_mode_l3(pskb, port);
- /* External frames are queued for device local
- * distribution, but a copy is given to master
- * straight away to avoid sending duplicates later
- * when work-queue processes this frame. This is
- * achieved by returning RX_HANDLER_PASS.
- */
- if (nskb) {
- ipvlan_skb_crossing_ns(nskb, NULL);
- ipvlan_multicast_enqueue(port, nskb, false);
- }
- }
- } else {
- /* Perform like l3 mode for non-multicast packet */
- ret = ipvlan_handle_mode_l3(pskb, port);
+ /* External frames are queued for device local
+ * distribution, but a copy is given to master
+ * straight away to avoid sending duplicates later
+ * when work-queue processes this frame.
+ * This is achieved by returning RX_HANDLER_PASS.
+ */
+ if (!ipvlan_external_frame(skb, port))
+ return RX_HANDLER_PASS;
+
+ nskb = skb_clone(skb, GFP_ATOMIC);
+ if (nskb) {
+ ipvlan_skb_crossing_ns(nskb, NULL);
+ ipvlan_multicast_enqueue(port, nskb, false);
}
- return ret;
+ return RX_HANDLER_PASS;
}
rx_handler_result_t ipvlan_handle_frame(struct sk_buff **pskb)
--
2.53.0.1213.gd9a14994de-goog
^ permalink raw reply related
* [PATCH net-next 2/2] ipvlan: avoid spinlock contention in ipvlan_multicast_enqueue()
From: Eric Dumazet @ 2026-04-09 8:52 UTC (permalink / raw)
To: David S . Miller, Jakub Kicinski, Paolo Abeni
Cc: Simon Horman, netdev, eric.dumazet, Eric Dumazet
In-Reply-To: <20260409085238.1122947-1-edumazet@google.com>
Under high stress, we spend a lot of time cloning skbs,
then acquiring a spinlock, then freeing the clone because
the queue is full.
Add a shortcut to avoid these costs under pressure, as we did
in macvlan with commit 0d5dc1d7aad1 ("macvlan: avoid spinlock
contention in macvlan_broadcast_enqueue()")
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
drivers/net/ipvlan/ipvlan_core.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ipvlan/ipvlan_core.c b/drivers/net/ipvlan/ipvlan_core.c
index 214fd299a5aa6e40579aa2dbcb178b5474b561a4..1be8620ad3971d281fb36fd0770efd67b566ae60 100644
--- a/drivers/net/ipvlan/ipvlan_core.c
+++ b/drivers/net/ipvlan/ipvlan_core.c
@@ -763,10 +763,16 @@ static rx_handler_result_t ipvlan_handle_mode_l2(struct sk_buff **pskb,
if (!ipvlan_external_frame(skb, port))
return RX_HANDLER_PASS;
- nskb = skb_clone(skb, GFP_ATOMIC);
+ if (skb_queue_len_lockless(&port->backlog) >= IPVLAN_QBACKLOG_LIMIT)
+ nskb = NULL;
+ else
+ nskb = skb_clone(skb, GFP_ATOMIC);
+
if (nskb) {
ipvlan_skb_crossing_ns(nskb, NULL);
ipvlan_multicast_enqueue(port, nskb, false);
+ } else {
+ dev_core_stats_rx_dropped_inc(skb->dev);
}
return RX_HANDLER_PASS;
--
2.53.0.1213.gd9a14994de-goog
^ permalink raw reply related
* Re: [PATCH net-next v2 02/14] libie: add PCI device initialization helpers to libie
From: Paolo Abeni @ 2026-04-09 8:56 UTC (permalink / raw)
To: Tony Nguyen, davem, kuba, edumazet, andrew+netdev, netdev
Cc: Phani R Burra, larysa.zaremba, przemyslaw.kitszel,
aleksander.lobakin, sridhar.samudrala, anjali.singhai,
michal.swiatkowski, maciej.fijalkowski, emil.s.tantilov,
madhu.chittim, joshua.a.hay, jacob.e.keller,
jayaprakash.shanmugam, jiri, horms, corbet, richardcochran,
linux-doc, bhelgaas, linux-pci, Bharath R, Samuel Salin,
Aleksandr Loktionov
In-Reply-To: <20260403194938.3577011-3-anthony.l.nguyen@intel.com>
On 4/3/26 9:49 PM, Tony Nguyen wrote:
> + mr = libie_find_mmio_region(&mmio_info->mmio_list, offset, size,
> + bar_idx);
> + if (mr) {
> + pci_warn(pdev,
> + "Mapping of BAR%u (offset=%llu, size=%llu) intersecting region (offset=%llu, size=%llu) already exists\n",
> + bar_idx, (unsigned long long)mr->offset,
> + (unsigned long long)mr->size,
> + (unsigned long long)offset, (unsigned long long)size);
> + return mr->offset <= offset &&
> + mr->offset + mr->size >= offset + size;
Sashiko says:
---
Does returning true here without creating a new tracking object leave
the new mapping tied to the original mapping's lifetime?
If the driver unmaps the original region, iounmap() is called and the
tracking object is freed. Any cached virtual address pointers to the
sub-region would then become a use-after-free, and subsequent queries
for the sub-region would fail.
---
/P
^ permalink raw reply
* Re: [PATCH 1/5] uaccess: fix ignored_trailing logic in copy_struct_to_user()
From: Stefan Metzmacher @ 2026-04-09 9:01 UTC (permalink / raw)
To: Aleksa Sarai
Cc: linux-kernel, Dmitry Safonov, Dmitry Safonov, Salam Noureddine,
David Ahern, David S . Miller, Michal Luczaj, David Wei,
Luiz Augusto von Dentz, Luiz Augusto von Dentz, Marcel Holtmann,
Xin Long, Eric Dumazet, Kuniyuki Iwashima, Paolo Abeni,
Willem de Bruijn, Neal Cardwell, Jakub Kicinski, Simon Horman,
Christian Brauner, Kees Cook, netdev, linux-bluetooth
In-Reply-To: <2026-04-08-ditzy-organic-yowl-croc-yWsgIE@cyphar.com>
Hi Aleksa,
> On 2026-04-07, Stefan Metzmacher <metze@samba.org> wrote:
>> Currently all callers pass ignored_trailing=NULL, but I have
>> code that will make use of.
>>
>> Now it actually behaves like documented:
>>
>> * If @usize < @ksize, then the kernel is trying to pass userspace a newer
>> struct than it supports. Thus we only copy the interoperable portions
>> (@usize) and ignore the rest (but @ignored_trailing is set to %true if
>> any of the trailing (@ksize - @usize) bytes are non-zero).
>
> Good catch, though I want to mention that the current API design for
> copy_struct_to_user() is a bit of a compromise -- I was trying to think
> of a way of making it generic but what information you need really
> depends on your API.
>
> For request-flag APIs (like statx) then you can just unset the bits in
> the response mask for fields past usize and so it is a non-fatal error,
> but it requires knowing which field offsets map to which flags.
>
> My initial idea for ignored_trailing was for it to return the offset
> memchr_inv() gives you -- but unfortunately, this doesn't help in the
> more generic case where you have multiple non-zero bits that need to
> unset multiple flags.
I guess the caller could use if (ignored_trailing) { ... }
to check more complex stuff and then decide ignore or return an error.
> Out of interest, how did you plan on using it? It might be a good idea
> to rethink this API before it starts getting used "in anger" in a way
> that leaks to uAPIs we can't change.
Currently I only use it with WARN_ON_ONCE(ignored_trailing);
in order to catch internal errors. See
https://git.samba.org/?p=metze/linux/wip.git;a=blob;f=fs/smb/common/smbdirect/smbdirect_proto.c;h=ce7c78eb6795041ba672da434ffb01db73269cb7;hb=37c61ef9758f3e113d4078220d8fc2aee366c955#l1625
But I guess I will at least change it to
if (WARN_ON_ONCE(ignored_trailing))
return...
And in general I thought it would be good practice to
check that case in new code in order to avoid unexpected
behavior.
> In any case, for this patch feel free to take my
>
> Reviewed-by: Aleksa Sarai <aleksa@amutable.com>
Thanks!
metze
^ permalink raw reply
* Re: [PATCH bpf-next v3 5/6] bpf: clear decap tunnel GSO state in skb_adjust_room
From: Hudson, Nick @ 2026-04-09 9:03 UTC (permalink / raw)
To: Willem de Bruijn
Cc: bpf@vger.kernel.org, netdev@vger.kernel.org, Willem de Bruijn,
Martin KaFai Lau, Tottenham, Max, Glasgall, Anna,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Eduard Zingerman, Kumar Kartikeya Dwivedi, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni,
linux-kernel@vger.kernel.org
In-Reply-To: <willemdebruijn.kernel.245c592e6d270@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3944 bytes --]
> On Apr 8, 2026, at 4:10 PM, Willem de Bruijn <willemdebruijn.kernel@gmail.com> wrote:
>
> !-------------------------------------------------------------------|
> This Message Is From an External Sender
> This message came from outside your organization.
> |-------------------------------------------------------------------!
>
> Nick Hudson wrote:
>> On shrink in bpf_skb_adjust_room(), clear tunnel-specific GSO flags
>> according to the decapsulation flags:
>>
>> - BPF_F_ADJ_ROOM_DECAP_L4_UDP clears SKB_GSO_UDP_TUNNEL{,_CSUM}, and
>> SKB_GSO_TUNNEL_REMCSUM
>> - BPF_F_ADJ_ROOM_DECAP_L4_GRE clears SKB_GSO_GRE{,_CSUM}
>> - BPF_F_ADJ_ROOM_DECAP_IPXIP4 clears SKB_GSO_IPXIP4
>> - BPF_F_ADJ_ROOM_DECAP_IPXIP6 clears SKB_GSO_IPXIP6
>>
>> When all tunnel-related GSO bits are cleared, also clear
>> skb->encapsulation.
>>
>> Handle the ESP inside a UDP tunnel case where encapsulation should remain
>> set.
>>
>> If UDP decap is performed and GSO state removed then reset encap_hdr_csum, and
>> remcsum_offload.
>>
>> Co-developed-by: Max Tottenham <mtottenh@akamai.com>
>> Signed-off-by: Max Tottenham <mtottenh@akamai.com>
>> Co-developed-by: Anna Glasgall <aglasgal@akamai.com>
>> Signed-off-by: Anna Glasgall <aglasgal@akamai.com>
>> Signed-off-by: Nick Hudson <nhudson@akamai.com>
>> ---
>> net/core/filter.c | 40 ++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 40 insertions(+)
>>
>> diff --git a/net/core/filter.c b/net/core/filter.c
>> index 7f8d43420afb..04059d07d368 100644
>> --- a/net/core/filter.c
>> +++ b/net/core/filter.c
>> @@ -3667,6 +3667,46 @@ static int bpf_skb_net_shrink(struct sk_buff *skb, u32 off, u32 len_diff,
>> if (!(flags & BPF_F_ADJ_ROOM_FIXED_GSO))
>> skb_increase_gso_size(shinfo, len_diff);
>>
>> + /* Selective GSO flag clearing based on decap type.
>> + * Only clear the flags for the tunnel layer being removed.
>> + */
>> + if ((flags & BPF_F_ADJ_ROOM_DECAP_L4_UDP) &&
>> + (shinfo->gso_type & (SKB_GSO_UDP_TUNNEL |
>> + SKB_GSO_UDP_TUNNEL_CSUM |
>> + SKB_GSO_TUNNEL_REMCSUM)))
>> + shinfo->gso_type &= ~(SKB_GSO_UDP_TUNNEL |
>> + SKB_GSO_UDP_TUNNEL_CSUM |
>> + SKB_GSO_TUNNEL_REMCSUM);
>
> REMCSUM was previously not included in the series.
Yeah, I was trying to address
https://sashiko.dev/#/patchset/20260318134242.2725749-1-nhudson%40akamai.com?part=5
>
> It is a non-obvious and rare enough feature that I would exclude it,
> or move it to a separate patch.
I’m happy to drop it.
>
>> + if ((flags & BPF_F_ADJ_ROOM_DECAP_L4_GRE) &&
>> + (shinfo->gso_type & (SKB_GSO_GRE | SKB_GSO_GRE_CSUM)))
>> + shinfo->gso_type &= ~(SKB_GSO_GRE |
>> + SKB_GSO_GRE_CSUM);
>> + if ((flags & BPF_F_ADJ_ROOM_DECAP_IPXIP4) &&
>> + (shinfo->gso_type & SKB_GSO_IPXIP4))
>> + shinfo->gso_type &= ~SKB_GSO_IPXIP4;
>> + if ((flags & BPF_F_ADJ_ROOM_DECAP_IPXIP6) &&
>> + (shinfo->gso_type & SKB_GSO_IPXIP6))
>> + shinfo->gso_type &= ~SKB_GSO_IPXIP6;
>> +
>> + /* Clear encapsulation flag only when no tunnel GSO flags remain */
>> + if (flags & (BPF_F_ADJ_ROOM_DECAP_L4_MASK |
>> + BPF_F_ADJ_ROOM_DECAP_IPXIP_MASK)) {
>> + if (!(shinfo->gso_type & (SKB_GSO_UDP_TUNNEL |
>> + SKB_GSO_UDP_TUNNEL_CSUM |
>> + SKB_GSO_GRE |
>> + SKB_GSO_GRE_CSUM |
>> + SKB_GSO_IPXIP4 |
>> + SKB_GSO_IPXIP6 |
>> + SKB_GSO_ESP)))
>> + if (skb->encapsulation)
>> + skb->encapsulation = 0;
>> +
>> + if (flags & BPF_F_ADJ_ROOM_DECAP_L4_UDP) {
>> + skb->encap_hdr_csum = !!(shinfo->gso_type & SKB_GSO_UDP_TUNNEL_CSUM);
>
> Since the flag is never set, only possibly cleared: just clear this field when clearing the flag?
>
> It appears that this is only used for deprecated UFO anyway.
>
>> + skb->remcsum_offload = !!(shinfo->gso_type & SKB_GSO_TUNNEL_REMCSUM);
>
> Always zero?
Yeah, I’ll fix these up in v4
Thanks.
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 3066 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v2 05/14] libie: add bookkeeping support for control queue messages
From: Paolo Abeni @ 2026-04-09 9:07 UTC (permalink / raw)
To: Tony Nguyen, davem, kuba, edumazet, andrew+netdev, netdev
Cc: Phani R Burra, larysa.zaremba, przemyslaw.kitszel,
aleksander.lobakin, sridhar.samudrala, anjali.singhai,
michal.swiatkowski, maciej.fijalkowski, emil.s.tantilov,
madhu.chittim, joshua.a.hay, jacob.e.keller,
jayaprakash.shanmugam, jiri, horms, corbet, richardcochran,
linux-doc, Bharath R, Samuel Salin, Aleksandr Loktionov
In-Reply-To: <20260403194938.3577011-6-anthony.l.nguyen@intel.com>
On 4/3/26 9:49 PM, Tony Nguyen wrote:
> +static bool
> +libie_ctlq_xn_process_recv(struct libie_ctlq_xn_recv_params *params,
> + struct libie_ctlq_msg *ctlq_msg)
> +{
> + struct libie_ctlq_xn_manager *xnm = params->xnm;
> + struct libie_ctlq_xn *xn;
> + u16 msg_cookie, xn_index;
> + struct kvec *response;
> + int status;
> + u16 data;
> +
> + data = ctlq_msg->sw_cookie;
> + xn_index = FIELD_GET(LIBIE_CTLQ_XN_INDEX_M, data);
> + msg_cookie = FIELD_GET(LIBIE_CTLQ_XN_COOKIE_M, data);
> + status = ctlq_msg->chnl_retval ? -EFAULT : 0;
> +
> + xn = &xnm->ring[xn_index];
> + if (ctlq_msg->chnl_opcode != xn->virtchnl_opcode ||
> + msg_cookie != xn->cookie)
> + return false;
> +
> + spin_lock(&xn->xn_lock);
Sashiko says:
---
Because the cookie and opcode are checked before acquiring the lock, is
it possible for the transaction to time out, be returned to the free
list, and get reallocated for a new message before the lock is acquired?
If that happens, could the old delayed response falsely complete the
newly allocated transaction since the identifiers are not re-verified
inside the lock?
---
> +/**
> + * libie_xn_check_async_timeout - Check for asynchronous message timeouts
> + * @xnm: Xn transaction manager
> + *
> + * Call the corresponding callback to notify the caller about the timeout.
> + */
> +static void libie_xn_check_async_timeout(struct libie_ctlq_xn_manager *xnm)
> +{
> + u32 idx;
> +
> + for_each_clear_bit(idx, xnm->free_xns_bm, LIBIE_CTLQ_MAX_XN_ENTRIES) {
Sashiko says:
---
This iterates over the bitmap without holding the lock. Concurrently,
other paths modify this bitmap using non-atomic bitwise operations like
__clear_bit() and __set_bit() under the lock. Will this cause torn reads
or data races that might lead the timeout handler to skip valid
transactions or examine invalid ones?
---
> + params->ctlq_msg->sw_cookie = cookie;
> + params->ctlq_msg->send_mem = *dma_mem;
> + params->ctlq_msg->data_len = buf_len;
> + params->ctlq_msg->chnl_opcode = params->chnl_opcode;
> + ret = libie_ctlq_send(params->ctlq, params->ctlq_msg, 1);
> + }
> +
> + if (ret && !libie_cp_can_send_onstack(buf_len))
> + libie_cp_unmap_dma_mem(dev, dma_mem);
Sashiko says:
---
When libie_ctlq_send() fails here, the DMA memory is unmapped and the
buffer is freed by the caller. However, the software tracking ring at
tx_msg[next_to_use] still contains the populated send_mem details and a
non-zero data_len.
During driver teardown, libie_ctlq_xn_send_clean() is invoked with
params->force = true, which processes the ring without checking the
hardware completion bit. Could this cause the cleanup routine to process
the failed slot again, resulting in a double-free and double-unmap?
---
There are more remarks on the following patch, please have a look.
Also, it would be very helpful if you could help triaging such
(overwhelming amount of) feedback on future submissions, explicitly
commenting on the ML. Sashiko tends to be quite noise on device driver code.
Thanks,
Paolo
^ permalink raw reply
* [PATCH net-next] gre: Count GRE packet drops
From: Gal Pressman @ 2026-04-09 9:09 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Andrew Lunn, netdev
Cc: David Ahern, Simon Horman, Gal Pressman, Dragos Tatulea,
Nimrod Oren
GRE is silently dropping packets without updating statistics.
In case of drop, increment rx_dropped counter to provide visibility into
packet loss. For the case where no GRE protocol handler is registered,
use rx_nohandler.
Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com>
Reviewed-by: Nimrod Oren <noren@nvidia.com>
Signed-off-by: Gal Pressman <gal@nvidia.com>
---
net/ipv4/gre_demux.c | 8 ++++++--
net/ipv4/ip_gre.c | 1 +
net/ipv6/ip6_gre.c | 1 +
3 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/gre_demux.c b/net/ipv4/gre_demux.c
index dafd68f3436a..96fd7dc6d82d 100644
--- a/net/ipv4/gre_demux.c
+++ b/net/ipv4/gre_demux.c
@@ -159,14 +159,18 @@ static int gre_rcv(struct sk_buff *skb)
rcu_read_lock();
proto = rcu_dereference(gre_proto[ver]);
if (!proto || !proto->handler)
- goto drop_unlock;
+ goto drop_nohandler;
ret = proto->handler(skb);
rcu_read_unlock();
return ret;
-drop_unlock:
+drop_nohandler:
rcu_read_unlock();
+ dev_core_stats_rx_nohandler_inc(skb->dev);
+ kfree_skb(skb);
+ return NET_RX_DROP;
drop:
+ dev_core_stats_rx_dropped_inc(skb->dev);
kfree_skb(skb);
return NET_RX_DROP;
}
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index 35f0baa99d40..169e2921a851 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -468,6 +468,7 @@ static int gre_rcv(struct sk_buff *skb)
out:
icmp_send(skb, ICMP_DEST_UNREACH, ICMP_PORT_UNREACH, 0);
drop:
+ dev_core_stats_rx_dropped_inc(skb->dev);
kfree_skb(skb);
return 0;
}
diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
index dafcc0dcd77a..63fc8556b475 100644
--- a/net/ipv6/ip6_gre.c
+++ b/net/ipv6/ip6_gre.c
@@ -593,6 +593,7 @@ static int gre_rcv(struct sk_buff *skb)
out:
icmpv6_send(skb, ICMPV6_DEST_UNREACH, ICMPV6_PORT_UNREACH, 0);
drop:
+ dev_core_stats_rx_dropped_inc(skb->dev);
kfree_skb(skb);
return 0;
}
--
2.52.0
^ permalink raw reply related
* Re: [PATCH mlx5-next 0/2] mlx5-next updates 2026-04-03
From: Leon Romanovsky @ 2026-04-09 9:27 UTC (permalink / raw)
To: Jason Gunthorpe, Saeed Mahameed, Tariq Toukan
Cc: Eric Dumazet, Jakub Kicinski, Paolo Abeni, Andrew Lunn,
David S. Miller, Mark Bloch, netdev, linux-rdma, linux-kernel,
Gal Pressman, Dragos Tatulea, Moshe Shemesh
In-Reply-To: <20260403090028.137783-1-tariqt@nvidia.com>
On Fri, 03 Apr 2026 12:00:26 +0300, Tariq Toukan wrote:
> This series contains mlx5 shared updates as preparation for upcoming
> features.
>
> Regards,
> Tariq
>
> Moshe Shemesh (2):
> net/mlx5: Rename MLX5_PF page counter type to MLX5_SELF
> net/mlx5: Add icm_mng_function_id_mode cap bit
>
> [...]
Applied, thanks!
[1/2] net/mlx5: Rename MLX5_PF page counter type to MLX5_SELF
https://git.kernel.org/rdma/rdma/c/f9e3bd43d55f24
[2/2] net/mlx5: Add icm_mng_function_id_mode cap bit
https://git.kernel.org/rdma/rdma/c/a1bac8b70ede33
Best regards,
--
Leon Romanovsky <leon@kernel.org>
^ permalink raw reply
* [PATCH net-next] mlx4: correct error reporting in mlx4_master_process_vhcr()
From: Alok Tiwari @ 2026-04-09 9:27 UTC (permalink / raw)
To: tariqt, andrew+netdev, kuba, davem, edumazet, pabeni, horms,
netdev
Cc: alok.a.tiwarilinux, alok.a.tiwari
mlx4_master_process_vhcr() logs vhcr->errno on failures, but this field
is never populated by the PF path. As a result, all failures are reported
with errno 0 and err print in status case which is misleading.
Use the actual return value (err) instead, translate it to FW status
before logging, and report both values.
Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com>
---
drivers/net/ethernet/mellanox/mlx4/cmd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/cmd.c b/drivers/net/ethernet/mellanox/mlx4/cmd.c
index de0193d82ec1..bdaf152e6712 100644
--- a/drivers/net/ethernet/mellanox/mlx4/cmd.c
+++ b/drivers/net/ethernet/mellanox/mlx4/cmd.c
@@ -1782,6 +1782,7 @@ static int mlx4_master_process_vhcr(struct mlx4_dev *dev, int slave,
}
if (err) {
+ vhcr_cmd->status = mlx4_errno_to_status(err);
if (!(dev->persist->state & MLX4_DEVICE_STATE_INTERNAL_ERROR)) {
if (vhcr->op == MLX4_CMD_ALLOC_RES &&
(vhcr->in_modifier & 0xff) == RES_COUNTER &&
@@ -1791,9 +1792,8 @@ static int mlx4_master_process_vhcr(struct mlx4_dev *dev, int slave,
slave, err);
else
mlx4_warn(dev, "vhcr command:0x%x slave:%d failed with error:%d, status %d\n",
- vhcr->op, slave, vhcr->errno, err);
+ vhcr->op, slave, err, vhcr_cmd->status);
}
- vhcr_cmd->status = mlx4_errno_to_status(err);
goto out_status;
}
--
2.50.1
^ permalink raw reply related
* Re: [PATCH net-next 4/5] net/sched: netem: add per-impairment extended statistics
From: Paolo Abeni @ 2026-04-09 9:30 UTC (permalink / raw)
To: Stephen Hemminger, netdev
Cc: Jamal Hadi Salim, Jiri Pirko, David S. Miller, Eric Dumazet,
Jakub Kicinski, Simon Horman, open list
In-Reply-To: <20260403225324.476787-5-stephen@networkplumber.org>
On 4/4/26 12:52 AM, Stephen Hemminger wrote:
> diff --git a/include/uapi/linux/pkt_sched.h b/include/uapi/linux/pkt_sched.h
> index 66e8072f44df..fada10cb9b7b 100644
> --- a/include/uapi/linux/pkt_sched.h
> +++ b/include/uapi/linux/pkt_sched.h
> @@ -569,6 +569,15 @@ struct tc_netem_gemodel {
> #define NETEM_DIST_SCALE 8192
> #define NETEM_DIST_MAX 16384
>
> +struct tc_netem_xstats {
> + __u32 delayed; /* packets delayed */
> + __u32 dropped; /* packets dropped by loss model */
> + __u32 corrupted; /* packets with bit errors injected */
> + __u32 duplicated; /* duplicate packets generated */
> + __u32 reordered; /* packets sent out of order */
> + __u32 ecn_marked; /* packets ECN CE-marked (not dropped)*/
> +};
Sashiko notes that the counters size will be set in stone by the uAPI,
and u32 can wraparound very quickly (especially for unconditional delay).
I see other qdiscs generally use __u32, but some have __u64 too, so I
assume there are no architectural blocker to larger counter.
Could you please move use __u64 above?
Thanks,
Paolo
^ permalink raw reply
* [PATCH net-next v2] iavf: fix kernel-doc comment style in iavf_ethtool.c
From: Aleksandr Loktionov @ 2026-04-09 9:30 UTC (permalink / raw)
To: intel-wired-lan, anthony.l.nguyen, aleksandr.loktionov
Cc: netdev, Leszek Pepiak
iavf_ethtool.c contains 31 kernel-doc comment blocks using the legacy
`**/` terminator instead of the correct single `*/`. Two function
headers also use a colon separator (`iavf_get_channels:`,
`iavf_set_channels:`) instead of the ` - ` dash required by kernel-doc.
Additionally several comments embed their return-value descriptions in
the body paragraph, producing `scripts/kernel-doc -Wreturn` warnings.
Void functions that incorrectly say "Returns ..." are also rephrased.
Fix all issues across the full file:
- Replace every `**/` terminator with `*/`.
- Change `function_name:` doc headers to `function_name -`.
- Move inline "Returns ..." sentences into dedicated `Return:` sections
for non-void functions (iavf_get_msglevel, iavf_get_rxnfc,
iavf_set_channels, iavf_get_rxfh_key_size, iavf_get_rxfh_indir_size,
iavf_get_rxfh, iavf_set_rxfh).
- Rephrase body descriptions in void functions that incorrectly said
"Returns ..." (iavf_get_drvinfo, iavf_get_ringparam, iavf_get_coalesce).
- Remove boilerplate body text for iavf_get_rxfh_key_size and
iavf_get_rxfh_indir_size; the `Return:` line now conveys the same
information without the vague "Returns the table size." sentence.
Suggested-by: Anthony L. Nguyen <anthony.l.nguyen@intel.com>
Suggested-by: Leszek Pepiak <leszek.pepiak@intel.com>
Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
---
v1 -> v2 extending the scope of the changes to whole iavf_ethtool.c file
---
drivers/net/ethernet/intel/iavf/iavf_ethtool.c | 103 ++++++++++++------------
1 file changed, 53 insertions(+), 50 deletions(-)
diff --git a/drivers/net/ethernet/intel/iavf/iavf_ethtool.c b/drivers/net/ethernet/intel/iavf/iavf_ethtool.c
index 1cd1f3f..a615d59 100644
--- a/drivers/net/ethernet/intel/iavf/iavf_ethtool.c
+++ b/drivers/net/ethernet/intel/iavf/iavf_ethtool.c
@@ -32,7 +32,7 @@
* statistics array. Thus, every statistic string in an array should have the
* same type and number of format specifiers, to be formatted by variadic
* arguments to the iavf_add_stat_string() helper function.
- **/
+ */
struct iavf_stats {
char stat_string[ETH_GSTRING_LEN];
int sizeof_stat;
@@ -116,7 +116,7 @@ iavf_add_one_ethtool_stat(u64 *data, void *pointer,
* the next empty location for successive calls to __iavf_add_ethtool_stats.
* If pointer is null, set the data values to zero and update the pointer to
* skip these stats.
- **/
+ */
static void
__iavf_add_ethtool_stats(u64 **data, void *pointer,
const struct iavf_stats stats[],
@@ -140,7 +140,7 @@ __iavf_add_ethtool_stats(u64 **data, void *pointer,
*
* The parameter @stats is evaluated twice, so parameters with side effects
* should be avoided.
- **/
+ */
#define iavf_add_ethtool_stats(data, pointer, stats) \
__iavf_add_ethtool_stats(data, pointer, stats, ARRAY_SIZE(stats))
@@ -157,7 +157,7 @@ __iavf_add_ethtool_stats(u64 **data, void *pointer,
* buffer and update the data pointer when finished.
*
* This function expects to be called while under rcu_read_lock().
- **/
+ */
static void
iavf_add_queue_stats(u64 **data, struct iavf_ring *ring)
{
@@ -189,7 +189,7 @@ iavf_add_queue_stats(u64 **data, struct iavf_ring *ring)
*
* Format and copy the strings described by stats into the buffer pointed at
* by p.
- **/
+ */
static void __iavf_add_stat_strings(u8 **p, const struct iavf_stats stats[],
const unsigned int size, ...)
{
@@ -216,7 +216,7 @@ static void __iavf_add_stat_strings(u8 **p, const struct iavf_stats stats[],
* The parameter @stats is evaluated twice, so parameters with side effects
* should be avoided. Additionally, stats must be an array such that
* ARRAY_SIZE can be called on it.
- **/
+ */
#define iavf_add_stat_strings(p, stats, ...) \
__iavf_add_stat_strings(p, stats, ARRAY_SIZE(stats), ## __VA_ARGS__)
@@ -249,7 +249,7 @@ static const struct iavf_stats iavf_gstrings_stats[] = {
*
* Reports speed/duplex settings. Because this is a VF, we don't know what
* kind of link we really have, so we fake it.
- **/
+ */
static int iavf_get_link_ksettings(struct net_device *netdev,
struct ethtool_link_ksettings *cmd)
{
@@ -308,7 +308,7 @@ static int iavf_get_link_ksettings(struct net_device *netdev,
* @sset: id of string set
*
* Reports size of various string tables.
- **/
+ */
static int iavf_get_sset_count(struct net_device *netdev, int sset)
{
/* Report the maximum number queues, even if not every queue is
@@ -331,7 +331,7 @@ static int iavf_get_sset_count(struct net_device *netdev, int sset)
* @data: pointer to data buffer
*
* All statistics are added to the data buffer as an array of u64.
- **/
+ */
static void iavf_get_ethtool_stats(struct net_device *netdev,
struct ethtool_stats *stats, u64 *data)
{
@@ -367,7 +367,7 @@ static void iavf_get_ethtool_stats(struct net_device *netdev,
* @data: buffer for string data
*
* Builds the statistics string table
- **/
+ */
static void iavf_get_stat_strings(struct net_device *netdev, u8 *data)
{
unsigned int i;
@@ -392,7 +392,7 @@ static void iavf_get_stat_strings(struct net_device *netdev, u8 *data)
* @data: buffer for string data
*
* Builds string tables for various string sets
- **/
+ */
static void iavf_get_strings(struct net_device *netdev, u32 sset, u8 *data)
{
switch (sset) {
@@ -408,8 +408,8 @@ static void iavf_get_strings(struct net_device *netdev, u32 sset, u8 *data)
* iavf_get_msglevel - Get debug message level
* @netdev: network interface device structure
*
- * Returns current debug message level.
- **/
+ * Return: current debug message level.
+ */
static u32 iavf_get_msglevel(struct net_device *netdev)
{
struct iavf_adapter *adapter = netdev_priv(netdev);
@@ -424,7 +424,7 @@ static u32 iavf_get_msglevel(struct net_device *netdev)
*
* Set current debug message level. Higher values cause the driver to
* be noisier.
- **/
+ */
static void iavf_set_msglevel(struct net_device *netdev, u32 data)
{
struct iavf_adapter *adapter = netdev_priv(netdev);
@@ -439,8 +439,8 @@ static void iavf_set_msglevel(struct net_device *netdev, u32 data)
* @netdev: network interface device structure
* @drvinfo: ethool driver info structure
*
- * Returns information about the driver and device for display to the user.
- **/
+ * Fills @drvinfo with information about the driver and device.
+ */
static void iavf_get_drvinfo(struct net_device *netdev,
struct ethtool_drvinfo *drvinfo)
{
@@ -458,9 +458,9 @@ static void iavf_get_drvinfo(struct net_device *netdev,
* @kernel_ring: ethtool extenal ringparam structure
* @extack: netlink extended ACK report struct
*
- * Returns current ring parameters. TX and RX rings are reported separately,
- * but the number of rings is not reported.
- **/
+ * Fills @ring with current ring parameters. TX and RX rings are reported
+ * separately, but the number of rings is not reported.
+ */
static void iavf_get_ringparam(struct net_device *netdev,
struct ethtool_ringparam *ring,
struct kernel_ethtool_ringparam *kernel_ring,
@@ -483,7 +483,7 @@ static void iavf_get_ringparam(struct net_device *netdev,
*
* Sets ring parameters. TX and RX rings are controlled separately, but the
* number of rings is not specified, so all rings get the same settings.
- **/
+ */
static int iavf_set_ringparam(struct net_device *netdev,
struct ethtool_ringparam *ring,
struct kernel_ethtool_ringparam *kernel_ring,
@@ -551,7 +551,7 @@ static int iavf_set_ringparam(struct net_device *netdev,
* Gets the per-queue settings for coalescence. Specifically Rx and Tx usecs
* are per queue. If queue is <0 then we default to queue 0 as the
* representative value.
- **/
+ */
static int __iavf_get_coalesce(struct net_device *netdev,
struct ethtool_coalesce *ec, int queue)
{
@@ -588,11 +588,11 @@ static int __iavf_get_coalesce(struct net_device *netdev,
* @kernel_coal: ethtool CQE mode setting structure
* @extack: extack for reporting error messages
*
- * Returns current coalescing settings. This is referred to elsewhere in the
- * driver as Interrupt Throttle Rate, as this is how the hardware describes
- * this functionality. Note that if per-queue settings have been modified this
- * only represents the settings of queue 0.
- **/
+ * Fills @ec with current coalescing settings. This is referred to elsewhere
+ * in the driver as Interrupt Throttle Rate, as this is how the hardware
+ * describes this functionality. Note that if per-queue settings have been
+ * modified this only represents the settings of queue 0.
+ */
static int iavf_get_coalesce(struct net_device *netdev,
struct ethtool_coalesce *ec,
struct kernel_ethtool_coalesce *kernel_coal,
@@ -608,7 +608,7 @@ static int iavf_get_coalesce(struct net_device *netdev,
* @queue: the queue to read
*
* Read specific queue's coalesce settings.
- **/
+ */
static int iavf_get_per_queue_coalesce(struct net_device *netdev, u32 queue,
struct ethtool_coalesce *ec)
{
@@ -622,7 +622,7 @@ static int iavf_get_per_queue_coalesce(struct net_device *netdev, u32 queue,
* @queue: the queue to modify
*
* Change the ITR settings for a specific queue.
- **/
+ */
static int iavf_set_itr_per_queue(struct iavf_adapter *adapter,
struct ethtool_coalesce *ec, int queue)
{
@@ -680,7 +680,7 @@ static int iavf_set_itr_per_queue(struct iavf_adapter *adapter,
* @queue: the queue to change
*
* Sets the coalesce settings for a particular queue.
- **/
+ */
static int __iavf_set_coalesce(struct net_device *netdev,
struct ethtool_coalesce *ec, int queue)
{
@@ -722,7 +722,7 @@ static int __iavf_set_coalesce(struct net_device *netdev,
* @extack: extack for reporting error messages
*
* Change current coalescing settings for every queue.
- **/
+ */
static int iavf_set_coalesce(struct net_device *netdev,
struct ethtool_coalesce *ec,
struct kernel_ethtool_coalesce *kernel_coal,
@@ -1639,7 +1639,7 @@ static int iavf_set_rxnfc(struct net_device *netdev, struct ethtool_rxnfc *cmd)
* @netdev: network interface device structure
*
* Return: number of RX rings.
- **/
+ */
static u32 iavf_get_rx_ring_count(struct net_device *netdev)
{
struct iavf_adapter *adapter = netdev_priv(netdev);
@@ -1653,8 +1653,8 @@ static u32 iavf_get_rx_ring_count(struct net_device *netdev)
* @cmd: ethtool rxnfc command
* @rule_locs: pointer to store rule locations
*
- * Returns Success if the command is supported.
- **/
+ * Return: 0 on success, -EOPNOTSUPP if the command is not supported.
+ */
static int iavf_get_rxnfc(struct net_device *netdev, struct ethtool_rxnfc *cmd,
u32 *rule_locs)
{
@@ -1684,13 +1684,13 @@ static int iavf_get_rxnfc(struct net_device *netdev, struct ethtool_rxnfc *cmd,
return ret;
}
/**
- * iavf_get_channels: get the number of channels supported by the device
+ * iavf_get_channels - get the number of channels supported by the device
* @netdev: network interface device structure
* @ch: channel information structure
*
* For the purposes of our device, we only use combined channels, i.e. a tx/rx
* queue pair. Report one extra channel to match our "other" MSI-X vector.
- **/
+ */
static void iavf_get_channels(struct net_device *netdev,
struct ethtool_channels *ch)
{
@@ -1706,14 +1706,15 @@ static void iavf_get_channels(struct net_device *netdev,
}
/**
- * iavf_set_channels: set the new channel count
+ * iavf_set_channels - set the new channel count
* @netdev: network interface device structure
* @ch: channel information structure
*
- * Negotiate a new number of channels with the PF then do a reset. During
- * reset we'll realloc queues and fix the RSS table. Returns 0 on success,
- * negative on failure.
- **/
+ * Negotiate a new number of channels with the PF then do a reset. During
+ * reset we'll realloc queues and fix the RSS table.
+ *
+ * Return: 0 on success, negative on failure.
+ */
static int iavf_set_channels(struct net_device *netdev,
struct ethtool_channels *ch)
{
@@ -1750,8 +1751,8 @@ static int iavf_set_channels(struct net_device *netdev,
* iavf_get_rxfh_key_size - get the RSS hash key size
* @netdev: network interface device structure
*
- * Returns the table size.
- **/
+ * Return: the RSS hash key size.
+ */
static u32 iavf_get_rxfh_key_size(struct net_device *netdev)
{
struct iavf_adapter *adapter = netdev_priv(netdev);
@@ -1763,8 +1764,8 @@ static u32 iavf_get_rxfh_key_size(struct net_device *netdev)
* iavf_get_rxfh_indir_size - get the rx flow hash indirection table size
* @netdev: network interface device structure
*
- * Returns the table size.
- **/
+ * Return: the indirection table size.
+ */
static u32 iavf_get_rxfh_indir_size(struct net_device *netdev)
{
struct iavf_adapter *adapter = netdev_priv(netdev);
@@ -1777,8 +1778,10 @@ static u32 iavf_get_rxfh_indir_size(struct net_device *netdev)
* @netdev: network interface device structure
* @rxfh: pointer to param struct (indir, key, hfunc)
*
- * Reads the indirection table directly from the hardware. Always returns 0.
- **/
+ * Reads the indirection table directly from the hardware.
+ *
+ * Return: 0 always.
+ */
static int iavf_get_rxfh(struct net_device *netdev,
struct ethtool_rxfh_param *rxfh)
{
@@ -1806,9 +1809,9 @@ static int iavf_get_rxfh(struct net_device *netdev,
* @rxfh: pointer to param struct (indir, key, hfunc)
* @extack: extended ACK from the Netlink message
*
- * Returns -EINVAL if the table specifies an invalid queue id, otherwise
- * returns 0 after programming the table.
- **/
+ * Return: 0 on success, -EOPNOTSUPP if the hash function is not supported,
+ * -EINVAL if the table specifies an invalid queue id.
+ */
static int iavf_set_rxfh(struct net_device *netdev,
struct ethtool_rxfh_param *rxfh,
struct netlink_ext_ack *extack)
@@ -1885,7 +1888,7 @@ static const struct ethtool_ops iavf_ethtool_ops = {
*
* Sets ethtool ops struct in our netdev so that ethtool can call
* our functions.
- **/
+ */
void iavf_set_ethtool_ops(struct net_device *netdev)
{
netdev->ethtool_ops = &iavf_ethtool_ops;
--
2.52.0
^ permalink raw reply related
* Re: [RFC net-next 05/15] ipxlat: add IPv6 packet validation path
From: Ralf Lici @ 2026-04-09 9:44 UTC (permalink / raw)
To: Xavier HSINYUAN
Cc: andrew+netdev, antonio, davem, dxld, edumazet, kuba, linux-kernel,
netdev, pabeni
In-Reply-To: <TYRPR01MB12666C2C108C1D23202C5B79ACA582@TYRPR01MB12666.jpnprd01.prod.outlook.com>
On 4/9/26 04:18, Xavier HSINYUAN wrote:
> Hi Ralf,
>
>> +static int ipxlat_v6_validate_icmp_csum(const struct sk_buff *skb)
>> +{
>> + struct ipv6hdr *iph6;
>> + unsigned int len;
>> + __sum16 csum;
>> +
>> + if (skb->ip_summed != CHECKSUM_NONE)
>> + return 0;
>> +
>> + iph6 = ipv6_hdr(skb);
>> + len = ipxlat_skb_datagram_len(skb);
>> + csum = csum_ipv6_magic(&iph6->saddr, &iph6->daddr, len, NEXTHDR_ICMP,
>> + skb_checksum(skb, skb_transport_offset(skb), len,
>> + 0));
>> +
>> + return unlikely(csum) ? -EINVAL : 0;
>> +}
> We should include net/ip6_checksum.h to make x86_64 with KMSAN/KASAN and
> other architectures with optional _HAVE_ARCH_IPV6_CSUM happy.
Hi Xavier,
Yep, this showed up in patchwork build failures as well.
I'll add the required header where needed (packet.c and icmp_{46,64}.c)
in the next revision.
Thanks!
>
> Best regards,
> Xavier
>
--
Ralf Lici
Mandelbit Srl
^ permalink raw reply
* Re: [PATCH nf] netfilter: nft_fwd_netdev: use recursion counter in neigh egress path
From: Florian Westphal @ 2026-04-09 9:50 UTC (permalink / raw)
To: Weiming Shi
Cc: Pablo Neira Ayuso, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Phil Sutter, Simon Horman, netfilter-devel, coreteam,
netdev, Xiang Mei
In-Reply-To: <20260409053629.698822-2-bestswngs@gmail.com>
Weiming Shi <bestswngs@gmail.com> wrote:
> Fixes: f87b9464d152 ("netfilter: nft_fwd_netdev: Support egress hook")
> Reported-by: Xiang Mei <xmei5@asu.edu>
> Signed-off-by: Weiming Shi <bestswngs@gmail.com>
> ---
> include/net/netfilter/nf_dup_netdev.h | 4 ++++
> net/netfilter/nf_dup_netdev.c | 18 ++++++++++++++++++
> net/netfilter/nft_fwd_netdev.c | 7 +++++++
> 3 files changed, 29 insertions(+)
>
> diff --git a/include/net/netfilter/nf_dup_netdev.h b/include/net/netfilter/nf_dup_netdev.h
> index b175d271aec9..17362f76d1d1 100644
> --- a/include/net/netfilter/nf_dup_netdev.h
> +++ b/include/net/netfilter/nf_dup_netdev.h
> @@ -7,6 +7,10 @@
> void nf_dup_netdev_egress(const struct nft_pktinfo *pkt, int oif);
> void nf_fwd_netdev_egress(const struct nft_pktinfo *pkt, int oif);
>
> +bool nf_dup_netdev_has_recursed(void);
> +void nf_dup_netdev_recursion_inc(void);
> +void nf_dup_netdev_recursion_dec(void);
> +
> struct nft_offload_ctx;
> struct nft_flow_rule;
>
> diff --git a/net/netfilter/nf_dup_netdev.c b/net/netfilter/nf_dup_netdev.c
> index fab8b9011098..e2fe8bb6fe0d 100644
> --- a/net/netfilter/nf_dup_netdev.c
> +++ b/net/netfilter/nf_dup_netdev.c
> @@ -29,6 +29,24 @@ static u8 *nf_get_nf_dup_skb_recursion(void)
>
> #endif
>
> +bool nf_dup_netdev_has_recursed(void)
> +{
> + return *nf_get_nf_dup_skb_recursion() > NF_RECURSION_LIMIT;
> +}
> +EXPORT_SYMBOL_GPL(nf_dup_netdev_has_recursed);
I think thats a bit too heavy-handed.
nf_get_nf_dup_skb_recursion() fetches from pcpu counter or current->.
Can you move nf_get_nf_dup_skb_recursion to a shared header file
and make it inline instead of having a function call?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).