* [PATCH] ice: propagate ETH56G deskew read errors
From: Pengpeng Hou @ 2026-06-25 3:03 UTC (permalink / raw)
To: Tony Nguyen, Przemek Kitszel
Cc: Andrew Lunn, davem, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Richard Cochran, intel-wired-lan, netdev, linux-kernel, pengpeng
ice_ptp_calc_deskew_eth56g() returns a u32 deskew value, but it also
returns the negative read_poll_timeout() error when the DESKEW valid bit
never appears. That converts the negative error into a large unsigned
deskew contribution, which can then be folded into the RX timestamp
offset and programmed into hardware.
Return the deskew value through an output parameter and propagate the
read error from ice_phy_set_offsets_eth56g() instead of using it as
offset data.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 27 +++++++++++++++------
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_ptp_hw.c b/drivers/net/ethernet/intel/ice/ice_ptp_hw.c
index 8e5f97835954..bd2e31b816a8 100644
--- a/drivers/net/ethernet/intel/ice/ice_ptp_hw.c
+++ b/drivers/net/ethernet/intel/ice/ice_ptp_hw.c
@@ -1736,17 +1736,21 @@ static u32 ice_ptp_calc_bitslip_eth56g(struct ice_hw *hw, u8 port, u32 bs,
* @ds: deskew multiplier
* @rs: RS-FEC enabled
* @spd: link speed
+ * @deskew: calculated deskew value
*
- * Return: calculated deskew value
+ * Return: 0 on success, negative error code otherwise
*/
-static u32 ice_ptp_calc_deskew_eth56g(struct ice_hw *hw, u8 port, u32 ds,
- bool rs, enum ice_eth56g_link_spd spd)
+static int ice_ptp_calc_deskew_eth56g(struct ice_hw *hw, u8 port, u32 ds,
+ bool rs, enum ice_eth56g_link_spd spd,
+ u32 *deskew)
{
u32 deskew_i, deskew_f;
int err;
- if (!ds)
+ if (!ds) {
+ *deskew = 0;
return 0;
+ }
read_poll_timeout(ice_read_ptp_reg_eth56g, err,
FIELD_GET(PHY_REG_DESKEW_0_VALID, deskew_i), 500,
@@ -1766,7 +1770,9 @@ static u32 ice_ptp_calc_deskew_eth56g(struct ice_hw *hw, u8 port, u32 ds,
deskew_i = FIELD_PREP(ICE_ETH56G_MAC_CFG_RX_OFFSET_INT, deskew_i);
/* Shift 3 fractional bits to the end of the integer part */
deskew_f <<= ICE_ETH56G_MAC_CFG_FRAC_W - PHY_REG_DESKEW_0_RLEVEL_FRAC_W;
- return mul_u32_u32_fx_q9(deskew_i | deskew_f, ds);
+ *deskew = mul_u32_u32_fx_q9(deskew_i | deskew_f, ds);
+
+ return 0;
}
/**
@@ -1789,6 +1795,7 @@ static int ice_phy_set_offsets_eth56g(struct ice_hw *hw, u8 port,
{
u32 rx_offset, tx_offset, bs_ds;
bool onestep, sfd;
+ int err;
onestep = hw->ptp.phy.eth56g.onestep_ena;
sfd = hw->ptp.phy.eth56g.sfd_ena;
@@ -1805,11 +1812,15 @@ static int ice_phy_set_offsets_eth56g(struct ice_hw *hw, u8 port,
if (sfd)
rx_offset = add_u32_u32_fx(rx_offset, cfg->rx_offset.sfd);
- if (spd < ICE_ETH56G_LNK_SPD_40G)
+ if (spd < ICE_ETH56G_LNK_SPD_40G) {
bs_ds = ice_ptp_calc_bitslip_eth56g(hw, port, bs_ds, fc, rs,
spd);
- else
- bs_ds = ice_ptp_calc_deskew_eth56g(hw, port, bs_ds, rs, spd);
+ } else {
+ err = ice_ptp_calc_deskew_eth56g(hw, port, bs_ds, rs, spd,
+ &bs_ds);
+ if (err)
+ return err;
+ }
rx_offset = add_u32_u32_fx(rx_offset, bs_ds);
rx_offset &= ICE_ETH56G_MAC_CFG_RX_OFFSET_INT |
ICE_ETH56G_MAC_CFG_RX_OFFSET_FRAC;
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* Re: [PATCH v3 1/7] list: Add mutable iterator variants
From: Kaitao Cheng @ 2026-06-25 3:01 UTC (permalink / raw)
To: David Laight, Christian König, Jani Nikula,
David Hildenbrand (Arm), Alexei Starovoitov
Cc: Andrew Morton, David Hildenbrand, Jens Axboe, Tejun Heo,
Alexander Viro, Christian Brauner, Daniel Borkmann,
Andrii Nakryiko, Johannes Weiner, Peter Zijlstra, Ingo Molnar,
Arnaldo Carvalho de Melo, Namhyung Kim, Thomas Gleixner,
Juri Lelli, Vincent Guittot, Paul Moore, Andy Shevchenko,
Paul E. McKenney, Shakeel Butt, David Howells, Simona Vetter,
Randy Dunlap, Luca Ceresoli, Philipp Stanner, linux-block,
linux-kernel, cgroups, linux-ntfs-dev, linux-fsdevel, io-uring,
audit, bpf, netdev, dri-devel, linux-perf-users,
linux-trace-kernel, kexec, live-patching, linux-modules,
linux-crypto, linux-pm, rcu, sched-ext, linux-mm, virtualization,
damon, llvm, Kaitao Cheng, Muchun Song
In-Reply-To: <20260624152324.3def88ce@pumpkin>
在 2026/6/24 22:23, David Laight 写道:
> On Wed, 24 Jun 2026 15:23:47 +0200
> Christian König <christian.koenig@amd.com> wrote:
>> On 6/24/26 15:14, Kaitao Cheng wrote:
>>> 在 2026/6/22 16:42, David Laight 写道:
>>>> On Mon, 22 Jun 2026 12:05:31 +0800
>>>> Kaitao Cheng <kaitao.cheng@linux.dev> wrote:
>>>>
>>>>> From: Kaitao Cheng <chengkaitao@kylinos.cn>
>>>>>
>>>>> The list_for_each*_safe() helpers are used when the loop body may
>>>>> remove the current entry. Their API exposes the temporary cursor at
>>>>> every call site, even though most users only need it for the iterator
>>>>> implementation and never reference it in the loop body.
>>>>>
>>>>> Add *_mutable() variants for list and hlist iteration. The new helpers
>>>>> support both forms: callers may keep passing an explicit temporary cursor
>>>>> when they need to inspect or reset it, or omit it and let the helper use
>>>>> a unique internal cursor.
>>>>
>>>> I'm not really sure 'mutable' means anything either.
>>>> It is possible to make it valid for the loop body (or even other threads)
>>>> to delete arbitrary list items - but that needs significant extra overheads.
>>>>
>>>> It might be worth doing something that doesn't need the extra variable,
>>>> but there is little point doing all the churn just to rename things.
>>>>
>>>>>
>>>>> This makes call sites that only mutate the list through the current entry
>>>>> less noisy, while keeping the existing *_safe() helpers available for
>>>>> compatibility.
>>>>>
>>>>> Signed-off-by: Kaitao Cheng <chengkaitao@kylinos.cn>
>>>>> ---
>>>>> include/linux/list.h | 269 +++++++++++++++++++++++++++++++++++++------
>>>>> 1 file changed, 231 insertions(+), 38 deletions(-)
>>>>>
>>>>> diff --git a/include/linux/list.h b/include/linux/list.h
>>>>> index 09d979976b3b..1081def7cea9 100644
>>>>> --- a/include/linux/list.h
>>>>> +++ b/include/linux/list.h
>>>>> @@ -7,6 +7,7 @@
>>>>> #include <linux/stddef.h>
>>>>> #include <linux/poison.h>
>>>>> #include <linux/const.h>
>>>>> +#include <linux/args.h>
>>>>>
>>>>> #include <asm/barrier.h>
>>>>>
>>>>> @@ -763,28 +764,72 @@ static inline void list_splice_tail_init(struct list_head *list,
>>>>> #define list_for_each_prev(pos, head) \
>>>>> for (pos = (head)->prev; !list_is_head(pos, (head)); pos = pos->prev)
>>>>>
>>>>> -/**
>>>>> - * list_for_each_safe - iterate over a list safe against removal of list entry
>>>>> - * @pos: the &struct list_head to use as a loop cursor.
>>>>> - * @n: another &struct list_head to use as temporary storage
>>>>> - * @head: the head for your list.
>>>>> +/*
>>>>> + * list_for_each_safe is an old interface, use list_for_each_mutable instead.
>>>>> */
>>>>> #define list_for_each_safe(pos, n, head) \
>>>>> for (pos = (head)->next, n = pos->next; \
>>>>> !list_is_head(pos, (head)); \
>>>>> pos = n, n = pos->next)
>>>>>
>>>>> +#define __list_for_each_mutable_internal(pos, tmp, head) \
>>>>> + for (typeof(pos) tmp = (pos = (head)->next)->next; \
>>>>
>>>> Use auto
>>>>
>>>>> + !list_is_head(pos, (head)); \
>>>>> + pos = tmp, tmp = pos->next)
>>>>> +
>>>>> +#define __list_for_each_mutable1(pos, head) \
>>>>> + __list_for_each_mutable_internal(pos, __UNIQUE_ID(next), head)
>>>>> +
>>>>> +#define __list_for_each_mutable2(pos, next, head) \
>>>>> + list_for_each_safe(pos, next, head)
>>>>> +
>>>>> /**
>>>>> - * list_for_each_prev_safe - iterate over a list backwards safe against removal of list entry
>>>>> + * list_for_each_mutable - iterate over a list safe against entry removal
>>>>> * @pos: the &struct list_head to use as a loop cursor.
>>>>> - * @n: another &struct list_head to use as temporary storage
>>>>> - * @head: the head for your list.
>>>>> + * @...: either (head) or (next, head)
>>>>> + *
>>>>> + * next: another &struct list_head to use as optional temporary storage.
>>>>> + * The temporary cursor is internal unless explicitly supplied by
>>>>> + * the caller.
>>>>> + * head: the head for your list.
>>>>> + */
>>>>> +#define list_for_each_mutable(pos, ...) \
>>>>> + CONCATENATE(__list_for_each_mutable, COUNT_ARGS(__VA_ARGS__)) \
>>>>> + (pos, __VA_ARGS__)
>>>>
>>>> The variable argument count logic really just slows down compilation.
>>>> Maybe there aren't enough copies of this code to make that significant.
>>>> But just because you can do it doesn't mean it is a gooD idea.
>>>> I'm also not sure it really adds anything to the readability.
>>>>
>>>> And, it you are going to make the middle argument optional there is
>>>> no need to change the macro name.
>>>
>>> Christian König and Jani Nikula also disagree with the variadic-argument
>>> implementation approach. If we abandon that method, it means we will
>>> inevitably need to add some new macros. If mutable is not a good name,
>>> suggestions for better alternatives would be welcome; coming up with a
>>> suitable name is indeed rather tricky.
>>
>> I don't think you need to add a new macro for the specific use case that people want to modify the next element of the iteration.
>>
>> If I remember your numbers correctly that is a really corner case and keeping using the existing *_safe() macros for that sounds perfectly fine to me.
>
> IIRC currently you have a choice of either:
> define Item that can't be deleted
> list_for_each() The current item.
> list_for_each_safe() The next item.
> There is also likely to be code that updates the variables to allow
> for other scenarios.
>
> Note that if increase a reference count and release a lock then list_for_each()
> is likely safer than list_for_each_safe() :-)
>
> list.h has 9 variants of the 'safe' loop.
> The bloat of another 9 is getting excessive.
>
> It has to be said that this is one of my least favourite type of list...
Hi Christian König, David Laight, Jani Nikula, David Hildenbrand,
Andy Shevchenko, Alexei Starovoitov
For ease of discussion, I need to summarize the currently possible
approaches and briefly describe their respective pros and cons,
using the list_for_each_entry* interfaces as examples.
1. Add list_for_each_entry_mutable, while keeping list_for_each_entry
and list_for_each_entry_safe unchanged. list_for_each_entry_mutable
would be used specifically for safe deletion scenarios that do not
need to expose the temporary cursor externally. The code can refer to
the v1 version.
Pros: Does not depend on immediate per-subsystem adaptation and can be
merged directly.
Cons: Requires adding a whole set of mutable interfaces, which makes the
code somewhat redundant.
2. Directly optimize away the temporary cursor in list_for_each_entry_safe
and define it inside the loop instead, changing the interface from four
arguments to three.
Pros: Does not add redundant interfaces.
Cons: (1) Users need to manually update special cases that use the
traversal variable of list_for_each_entry_safe, the new
list_for_each_entry_safe would no longer apply there and would
need to be open-coded.
(2) Because the macro arguments changes, all list_for_each_entry_safe
callers would need to be modified and merged together, making it
difficult to merge such a large amount of code at once.
3. Use a variadic macro approach to optimize list_for_each_entry_safe,
so that it supports both three and four arguments.
Pros: (1) Does not add redundant interfaces.
(2) Does not depend on immediate per-subsystem adaptation and can
be merged directly.
Cons: (1) Increases compile time.
(2) Makes the interface harder for users to use.
4. Optimize list_for_each_entry by defining the temporary cursor internally,
making it compatible with the functionality of list_for_each_entry_safe.
The code can refer to the v2 version.
Pros: (1) Does not add redundant interfaces.
(2) The number of externally visible arguments of list_for_each_entry
remains unchanged, still three.
Cons: (1) list_for_each_entry and list_for_each_entry_safe would be merged
into one, and list_for_each_entry_safe would gradually be deprecated.
(2) Users need to manually update special cases that use the traversal
variable of list_for_each_entry, the new list_for_each_entry would no
longer apply there and would need to be open-coded. There are 15 such
cases in total.
5. Use a variadic macro approach to optimize list_for_each_entry, so that
it supports both three and four arguments.
Pros: (1) Does not add redundant interfaces.
(2) Does not depend on immediate per-subsystem adaptation and can be
merged directly.
Cons: (1) Increases compile time.
(2) list_for_each_entry and list_for_each_entry_safe would be merged
into one, and list_for_each_entry_safe would gradually be deprecated.
6. Make no changes, keep the current logic unchanged, and close the current
email discussion.
Which of the six solutions above do people prefer?
--
Thanks
Kaitao Cheng
^ permalink raw reply
* Re: [PATCH net 0/8][pull request] Intel Wired LAN Driver Updates 2026-06-22 (ice, i40e, e1000e)
From: patchwork-bot+netdevbpf @ 2026-06-25 3:00 UTC (permalink / raw)
To: Tony Nguyen; +Cc: davem, kuba, pabeni, edumazet, andrew+netdev, netdev
In-Reply-To: <20260622220059.2471844-1-anthony.l.nguyen@intel.com>
Hello:
This series was applied to netdev/net.git (main)
by Tony Nguyen <anthony.l.nguyen@intel.com>:
On Mon, 22 Jun 2026 15:00:47 -0700 you wrote:
> For ice:
> Dawid changes call to release control VSI during reset to prevent
> leaking it.
>
> Lukasz fixes flow control error check to check value rather than treat
> is as bitmap values.
>
> [...]
Here is the summary with links:
- [net,1/8] ice: fix FDIR CTRL VSI resource leak in ice_reset_all_vfs()
https://git.kernel.org/netdev/net/c/ebbe8868cf47
- [net,2/8] ice: fix AQ error code comparison in ice_set_pauseparam()
https://git.kernel.org/netdev/net/c/2bf7744bc322
- [net,3/8] ice: fix ice_init_link() error return preventing probe
https://git.kernel.org/netdev/net/c/eb509638686b
- [net,4/8] ice: call netif_keep_dst() once when entering switchdev mode
https://git.kernel.org/netdev/net/c/c0d00c882bc4
- [net,5/8] ice: dpll: set pointers to NULL after kfree in ice_dpll_deinit_info
https://git.kernel.org/netdev/net/c/a903afff66d7
- [net,6/8] ice: dpll: fix memory leak in ice_dpll_init_info error paths
https://git.kernel.org/netdev/net/c/20da495f2df0
- [net,7/8] i40e: Fix i40e_debug() to use struct i40e_hw argument
https://git.kernel.org/netdev/net/c/798f94603eb0
- [net,8/8] e1000e: Reconfigure PLL clock gate timeout and re-enable K1 on Meteor Lake
https://git.kernel.org/netdev/net/c/578294b8b60d
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 01/14] netfilter: nf_nat: avoid invalid nat_net pointer use on failed nf_nat_init()
From: patchwork-bot+netdevbpf @ 2026-06-25 3:00 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: netfilter-devel, davem, netdev, kuba, pabeni, edumazet, fw, horms
In-Reply-To: <20260623221548.701545-2-pablo@netfilter.org>
Hello:
This series was applied to netdev/net.git (main)
by Pablo Neira Ayuso <pablo@netfilter.org>:
On Wed, 24 Jun 2026 00:15:34 +0200 you wrote:
> From: Mathias Krause <minipli@grsecurity.net>
>
> We ran into below KASAN splat, which is mostly uninteresting, beside
> for having nf_nat_register_fn() in the call chain as a cause for the
> offending access:
>
> ==================================================================
> BUG: KASAN: slab-out-of-bounds in nf_nat_register_fn+0x5f9/0x640
> Read of size 8 at addr ffff890031e54c20 by task iptables/9510
>
> [...]
Here is the summary with links:
- [net,01/14] netfilter: nf_nat: avoid invalid nat_net pointer use on failed nf_nat_init()
https://git.kernel.org/netdev/net/c/069cfe3de2a5
- [net,02/14] netfilter: nf_conncount: prevent connlimit drops for early confirmed ct
https://git.kernel.org/netdev/net/c/c8b6f36f7669
- [net,03/14] netfilter: flowtable: Validate iph->ihl in nf_flow_ip4_tunnel_proto()
https://git.kernel.org/netdev/net/c/84460b644329
- [net,04/14] netfilter: x_tables.h: fix all kernel-doc warnings
https://git.kernel.org/netdev/net/c/22f9dbed18bc
- [net,05/14] netfilter: nft_synproxy: stop bypassing the priv->info snapshot
https://git.kernel.org/netdev/net/c/11d4bc4e26fb
- [net,06/14] selftests: netfilter: conntrack_sctp_collision.sh: Introduce SCTP INIT collision test
https://git.kernel.org/netdev/net/c/a49a8e51eebc
- [net,07/14] netfilter: nft_compat: ebtables emulation must reject non-bridge targets
https://git.kernel.org/netdev/net/c/9dbba7e694ec
- [net,08/14] selftests: nft_queue.sh: add a bridge queue test
https://git.kernel.org/netdev/net/c/8a2cfe7951f6
- [net,09/14] netfilter: ctnetlink: do not allow to reset helper on existing conntrack
https://git.kernel.org/netdev/net/c/aaa0cd698ffa
- [net,10/14] netfilter: conntrack: add deprecation warnings for irc and pptp trackers
https://git.kernel.org/netdev/net/c/57f940017a77
- [net,11/14] netfilter: nf_conntrack_expect: store master_tuple in expectation
https://git.kernel.org/netdev/net/c/979c13114c0b
- [net,12/14] netfilter: nf_conntrack_expect: run expectation eviction with no helper
https://git.kernel.org/netdev/net/c/be57dd9c1c17
- [net,13/14] netfilter: nft_ct: expectation timeouts are passed in milliseconds
https://git.kernel.org/netdev/net/c/6fb421bd07f1
- [net,14/14] netfilter: nf_conntrack_helper: cap maximum number of expectation at helper registration
https://git.kernel.org/netdev/net/c/397c8300972f
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] net: udp_tunnel: fix use-after-free by refcounting udp_tunnel_nic
From: Jakub Kicinski @ 2026-06-25 2:55 UTC (permalink / raw)
To: Jiayuan Chen
Cc: Eric Dumazet, David S . Miller, Paolo Abeni, Simon Horman,
Ido Schimmel, David Ahern, netdev, eric.dumazet, Yue Sun
In-Reply-To: <04d09dea-baa2-4c43-ada1-cd71579aad53@linux.dev>
On Thu, 25 Jun 2026 10:47:09 +0800 Jiayuan Chen wrote:
> On 6/25/26 5:57 AM, Jakub Kicinski wrote:
> > On Wed, 24 Jun 2026 17:10:34 +0000 Eric Dumazet wrote:
> >> Yue Sun reported a use-after-free and debugobjects warning in
> >> udp_tunnel_nic_device_sync_work() during concurrent device operations.
> >>
> >> The state flags of struct udp_tunnel_nic were originally bitfields
> >> sharing a byte, modified concurrently without locking (RCU vs worker).
> > Can you clarify the path where the bits are modified without locks??
> > My mental model is that this is basically all under rtnl_lock, and
> > Stan added _another_ lock so that drivers can call "sync" / reply
> > without needing rtnl lock, but any changes are still under rtnl_lock.
> >
> > The gap seems to be that we don't check pending under Stan's new lock,
> > since commit 1ead7501094c6 ("udp_tunnel: remove rtnl_lock dependency")
> > did:
>
>
> I think the real problem is that a single work_pending flag can't track
> the work being queued twice:
>
> 1. Thread A calls queue_work() -> work_pending = 1.
> 2. The worker gets picked up; workqueue clears the PENDING(internal work
> queue flag) bit before running the work function.
> The worker then blocks on rtnl/utn->lock.
> 3. Thread B calls queue_work() again. Since PENDING was already cleared,
> it enqueues a second
> instance and sets work_pending = 1.
> 4. A's worker finally gets the lock and does work_pending = 0, runs,
> returns.
> 5. Now work_pending == 0 but B's instance is still queued. unregister
> sees 0, frees utn.
Ah, thanks, now I get it. Claude told me the same thing but in 10,000
words and I lost the thread before reading 'til the end...
In that case:
diff --git a/net/ipv4/udp_tunnel_nic.c b/net/ipv4/udp_tunnel_nic.c
index 9944ed923ddf..3b32a0afa979 100644
--- a/net/ipv4/udp_tunnel_nic.c
+++ b/net/ipv4/udp_tunnel_nic.c
@@ -301,7 +301,7 @@ __udp_tunnel_nic_device_sync(struct net_device *dev, struct udp_tunnel_nic *utn)
static void
udp_tunnel_nic_device_sync(struct net_device *dev, struct udp_tunnel_nic *utn)
{
- if (!utn->need_sync)
+ if (!utn->need_sync || utn->work_pending)
return;
queue_work(udp_tunnel_nic_workqueue, &utn->work);
^ permalink raw reply related
* Re: [PATCH net v3] fsl/fman: Free init resources on KeyGen failure in fman_init()
From: Jakub Kicinski @ 2026-06-25 2:48 UTC (permalink / raw)
To: Haoxiang Li
Cc: madalin.bucur, sean.anderson, andrew+netdev, davem, edumazet,
pabeni, florinel.iordache, netdev, linux-kernel, stable,
Pavan Chebbi, Breno Leitao
In-Reply-To: <20260625004834.3394389-1-haoxiang_li2024@163.com>
On Thu, 25 Jun 2026 08:48:34 +0800 Haoxiang Li wrote:
> fman_muram_alloc() allocates initialization resources before
> initializing the KeyGen block. If keygen_init() fails, the
> function returns -EINVAL directly and leaves those resources
> allocated. Free the initialization resources before returning
> from the KeyGen failure path.
Please slow down. You're sending a lot of low value patches.
Please do not have more than 5 outstanding "active" networking
patches under name at any given time:
https://patchwork.kernel.org/project/netdevbpf/list/?submitter=215341
^ permalink raw reply
* Re: [PATCH net] net: udp_tunnel: fix use-after-free by refcounting udp_tunnel_nic
From: Jiayuan Chen @ 2026-06-25 2:47 UTC (permalink / raw)
To: Jakub Kicinski, Eric Dumazet
Cc: David S . Miller, Paolo Abeni, Simon Horman, Ido Schimmel,
David Ahern, netdev, eric.dumazet, Yue Sun
In-Reply-To: <20260624145722.083632b6@kernel.org>
On 6/25/26 5:57 AM, Jakub Kicinski wrote:
> On Wed, 24 Jun 2026 17:10:34 +0000 Eric Dumazet wrote:
>> Yue Sun reported a use-after-free and debugobjects warning in
>> udp_tunnel_nic_device_sync_work() during concurrent device operations.
>>
>> The state flags of struct udp_tunnel_nic were originally bitfields
>> sharing a byte, modified concurrently without locking (RCU vs worker).
> Can you clarify the path where the bits are modified without locks??
> My mental model is that this is basically all under rtnl_lock, and
> Stan added _another_ lock so that drivers can call "sync" / reply
> without needing rtnl lock, but any changes are still under rtnl_lock.
>
> The gap seems to be that we don't check pending under Stan's new lock,
> since commit 1ead7501094c6 ("udp_tunnel: remove rtnl_lock dependency")
> did:
I think the real problem is that a single work_pending flag can't track
the work being queued twice:
1. Thread A calls queue_work() -> work_pending = 1.
2. The worker gets picked up; workqueue clears the PENDING(internal work
queue flag) bit before running the work function.
The worker then blocks on rtnl/utn->lock.
3. Thread B calls queue_work() again. Since PENDING was already cleared,
it enqueues a second
instance and sets work_pending = 1.
4. A's worker finally gets the lock and does work_pending = 0, runs,
returns.
5. Now work_pending == 0 but B's instance is still queued. unregister
sees 0, frees utn.
^ permalink raw reply
* Re: [PATCH net-next] fsl/fman: make enable() return void
From: Jakub Kicinski @ 2026-06-25 2:46 UTC (permalink / raw)
To: Haoxiang Li
Cc: madalin.bucur, sean.anderson, andrew+netdev, davem, edumazet,
pabeni, netdev, linux-kernel
In-Reply-To: <20260625005600.3400023-1-haoxiang_li2024@163.com>
On Thu, 25 Jun 2026 08:56:00 +0800 Haoxiang Li wrote:
> The enable() helper always returns 0 and has no failure path.
> Make it return void and update the only caller accordingly.
## Form letter - net-next-closed
We have already submitted our pull request with net-next material for v7.2,
and therefore net-next is closed for new drivers, features, code refactoring
and optimizations. We are currently accepting bug fixes only.
Please repost when net-next reopens after June 29th.
RFC patches sent for review only are obviously welcome at any time.
See: https://www.kernel.org/doc/html/next/process/maintainer-netdev.html#development-cycle
--
pw-bot: defer
pv-bot: closed
^ permalink raw reply
* Re: [External Mail] Re: [PATCH v3 0/7] net: wwan: t9xx: Add MediaTek T9XX WWAN driver
From: Jakub Kicinski @ 2026-06-25 2:45 UTC (permalink / raw)
To: Wu. JackBB (GSM)
Cc: Loic Poulain, Sergey Ryazanov, Johannes Berg, Andrew Lunn,
David S. Miller, Eric Dumazet, Paolo Abeni, Wen-Zhi Huang,
Shi-Wei Yeh, Minano Tseng, Matthias Brugger,
AngeloGioacchino Del Regno, Simon Horman, Jonathan Corbet,
Shuah Khan, linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, linux-doc@vger.kernel.org
In-Reply-To: <cec5736466864641967b99adcfaf324a@compal.com>
On Thu, 25 Jun 2026 01:55:49 +0000 Wu. JackBB (GSM) wrote:
> I have a question about the preferred workflow: the cover
> letter changelog would get quite long if I include detailed
> explanations for each sashiko comment we chose not to fix.
>
> Was the concern more about timing? Should we have replied
> to the sashiko review promptly when it came in, rather than
> waiting until the full v3 was ready?
Either way works. Either give reviewers 24h to dispute the comments or
add the comments to the repost. You don't have to keep a full detailed
log in the changelog.
> ================================================================================================================================================================
> This message may contain information which is private, privileged or confidential of Compal Electronics, Inc. If you are not the intended recipient of this message, please notify the sender and destroy/delete the message. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information, by persons or entities other than the intended recipient is prohibited.
> ================================================================================================================================================================
Again, please fix this.
^ permalink raw reply
* Re: [PATCH net] tools/ynl: add missing uapi header deps in Makefile.deps
From: patchwork-bot+netdevbpf @ 2026-06-25 2:40 UTC (permalink / raw)
To: Thorsten Leemhuis
Cc: netdev, davem, edumazet, kuba, pabeni, donald.hunter, riana.tauro,
linux-kernel
In-Reply-To: <20260623070818.2161810-1-linux@leemhuis.info>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 23 Jun 2026 09:08:18 +0200 you wrote:
> drm_ras includes drm/drm_ras.h, which is a relatively new header not yet
> shipped in most distro kernel-header packages. Without the explicit
> entry, the build might fail with a message like this:
>
> drm_ras-user.c:19:10: error: ‘DRM_RAS_CMD_CLEAR_ERROR_COUNTER’ \
> undeclared here (not in a function); did you mean \
> ‘DRM_RAS_CMD_GET_ERROR_COUNTER’
>
> [...]
Here is the summary with links:
- [net] tools/ynl: add missing uapi header deps in Makefile.deps
https://git.kernel.org/netdev/net/c/636838ebb74a
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 v3 0/2] net: ethernet: sunplus: spl2sw: fix of_node refcount leaks
From: patchwork-bot+netdevbpf @ 2026-06-25 2:40 UTC (permalink / raw)
To: Shitalkumar Gandhi
Cc: wellslutw, kuba, andrew, davem, edumazet, pabeni, horms, netdev,
linux-kernel, shitalkumar.gandhi
In-Reply-To: <cover.1782195965.git.shitalkumar.gandhi@cambiumnetworks.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 23 Jun 2026 12:11:41 +0530 you wrote:
> This series fixes of_node refcount leaks in the Sunplus SP7021 ethernet
> driver, found by inspection. Compile-tested only; no SP7021 hardware
> available here.
>
> Patch 1/2 fixes the phy_node leak in the remove path.
> Patch 2/2 fixes multiple leaks in the probe path and depends on the
> cleanup contract from patch 1/2.
>
> [...]
Here is the summary with links:
- [net,v3,1/2] net: ethernet: sunplus: spl2sw: fix phy_node refcount leak in remove
https://git.kernel.org/netdev/net/c/a9e29dcd8a84
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 v2 0/2] net: stmmac: dwmac-spacemit: Fix wrong macro definition
From: patchwork-bot+netdevbpf @ 2026-06-25 2:40 UTC (permalink / raw)
To: Inochi Amaoto
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, mcoquelin.stm32,
alexandre.torgue, dlan, rmk+kernel, netdev, linux-stm32,
linux-arm-kernel, linux-riscv, spacemit, linux-kernel, dlan,
looong.bin
In-Reply-To: <20260623074637.503864-1-inochiama@gmail.com>
Hello:
This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 23 Jun 2026 15:46:33 +0800 you wrote:
> Fix Wrong macro definition of the Spacemit K3.
>
> Changed from v1:
> - https://lore.kernel.org/netdev/20260618064143.1102179-1-inochiama@gmail.com
> 1. Separate the patch into two patches
> 2. Use the right macro name for the LPI interrupt.
>
> [...]
Here is the summary with links:
- [net,v2,1/2] net: stmmac: dwmac-spacemit: Fix wrong phy interface definition
https://git.kernel.org/netdev/net/c/d1e3a4c3b24d
- [net,v2,2/2] net: stmmac: dwmac-spacemit: Fix wrong irq definition
https://git.kernel.org/netdev/net/c/bf5cd5d4ca42
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 v3 0/2] net: ethernet: sunplus: spl2sw: fix of_node refcount leaks
From: Jakub Kicinski @ 2026-06-25 2:35 UTC (permalink / raw)
To: Shitalkumar Gandhi
Cc: Wells Lu, Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
Simon Horman, netdev, linux-kernel, Shitalkumar Gandhi
In-Reply-To: <cover.1782195965.git.shitalkumar.gandhi@cambiumnetworks.com>
On Tue, 23 Jun 2026 12:11:41 +0530 Shitalkumar Gandhi wrote:
> Shitalkumar Gandhi (2):
> net: ethernet: sunplus: spl2sw: fix phy_node refcount leak in remove
> net: ethernet: sunplus: spl2sw: fix multiple of_node refcount leaks in
> probe
Only the first patch reached the list
^ permalink raw reply
* Re: [PATCH net-next] selftests/xsk: preserve UMEM view in bidi test
From: Jakub Kicinski @ 2026-06-25 2:33 UTC (permalink / raw)
To: Maciej Fijalkowski
Cc: netdev, bpf, magnus.karlsson, stfomichev, pabeni, horms,
tushar.vyavahare, kerneljasonxing
In-Reply-To: <20260623091008.1046547-1-maciej.fijalkowski@intel.com>
On Tue, 23 Jun 2026 11:10:08 +0200 Maciej Fijalkowski wrote:
> Subject: [PATCH net-next] selftests/xsk: preserve UMEM view in bidi test
Do you want it in net? Either way - we'll need a rebase
> Signed-off-by: Maciej Fijalkowski maciej.fijalkowski@intel.com
missing <> around the email
^ permalink raw reply
* Re: [PATCH net v2] net: sungem: fix probe error cleanup
From: patchwork-bot+netdevbpf @ 2026-06-25 2:30 UTC (permalink / raw)
To: Ruoyu Wang
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, horms, netdev,
linux-kernel
In-Reply-To: <20260623025759.3468566-1-ruoyuw560@gmail.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 23 Jun 2026 10:57:59 +0800 you wrote:
> gem_init_one() calls gem_remove_one() when register_netdev() fails.
> gem_remove_one() unregisters and frees resources owned by the net_device,
> including the DMA block, MMIO mapping, PCI regions, and the net_device
> itself. gem_init_one() then falls through to its own cleanup labels and
> frees the same resources again.
>
> Keep the register_netdev() error path in gem_init_one(): clear drvdata so
> PM/remove paths do not see a half-registered device, remove the NAPI
> instance added during probe, and let the existing cleanup labels release
> the resources once.
>
> [...]
Here is the summary with links:
- [net,v2] net: sungem: fix probe error cleanup
https://git.kernel.org/netdev/net/c/36dea2f63924
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] tools: ynl: build archives with $(AR)
From: patchwork-bot+netdevbpf @ 2026-06-25 2:30 UTC (permalink / raw)
To: Greg Thelen; +Cc: donald.hunter, kuba, davem, netdev, linux-kernel
In-Reply-To: <20260622161659.145047-1-gthelen@google.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 22 Jun 2026 09:16:59 -0700 you wrote:
> Use $(AR) to allow build system to override the archiver tool (e.g.,
> when cross-compiling for a different architecture) by setting the AR
> environment variable.
>
> GNU Make defaults AR to ar, so this change will not break existing build
> environments that do not explicitly set AR.
>
> [...]
Here is the summary with links:
- tools: ynl: build archives with $(AR)
https://git.kernel.org/netdev/net/c/8c37e76f960b
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/tcp-ao: fix use-after-free of key in del_async path
From: patchwork-bot+netdevbpf @ 2026-06-25 2:30 UTC (permalink / raw)
To: HanQuan; +Cc: netdev, edumazet, ncardwell
In-Reply-To: <20260623015208.1191687-1-eilaimemedsnaimel@gmail.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 23 Jun 2026 01:52:08 +0000 you wrote:
> In tcp_ao_delete_key(), the del_async path skips the current_key
> and rnext_key validity checks present in the synchronous path,
> assuming these pointers are always NULL on LISTEN sockets. However,
> if a key was added with set_current=1/set_rnext=1 while the socket
> was in CLOSE state, current_key and rnext_key will be non-NULL
> after listen() transitions the socket to LISTEN.
>
> [...]
Here is the summary with links:
- net/tcp-ao: fix use-after-free of key in del_async path
https://git.kernel.org/netdev/net/c/5ba9950bc907
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] eth: mlx5: fix macsec dependency
From: patchwork-bot+netdevbpf @ 2026-06-25 2:30 UTC (permalink / raw)
To: Arnd Bergmann
Cc: saeedm, leon, tariqt, mbloch, andrew+netdev, davem, edumazet,
kuba, pabeni, sd, arnd, daniel.zahka, rrameshbabu, raeds, netdev,
linux-rdma, linux-kernel
In-Reply-To: <20260622124229.2444502-1-arnd@kernel.org>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 22 Jun 2026 14:41:07 +0200 you wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> Configurations with mlx5 built-in but macsec=m fail to link:
>
> x86_64-linux-ld: drivers/infiniband/hw/mlx5/macsec.o: in function `mlx5r_add_gid_macsec_operations':
> macsec.c:(.text+0x77d): undefined reference to `macsec_netdev_is_offloaded'
> x86_64-linux-ld: drivers/infiniband/hw/mlx5/macsec.o: in function `mlx5r_del_gid_macsec_operations':
> macsec.c:(.text+0xe81): undefined reference to `macsec_netdev_is_offloaded'
>
> [...]
Here is the summary with links:
- [net] eth: mlx5: fix macsec dependency
https://git.kernel.org/netdev/net/c/87ab8276ed24
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] netpoll: fix a use-after-free on shutdown path
From: Jakub Kicinski @ 2026-06-25 2:25 UTC (permalink / raw)
To: Breno Leitao
Cc: David S. Miller, Eric Dumazet, Paolo Abeni, Simon Horman,
Amerigo Wang, netdev, linux-kernel, vlad.wing, asantostc,
kernel-team, stable
In-Reply-To: <20260622-netpoll_rcu_fix-v1-1-15c3285e92e6@debian.org>
On Mon, 22 Jun 2026 08:01:23 -0700 Breno Leitao wrote:
> + * synchronize_net() does not protect the worker
> + * (queue_process() is not an RCU reader). It fences the
> + * senders -- the real RCU readers -- so they cannot re-arm
> + * tx_work after the np->dev->npinfo was set to NULL.
> + */
> + synchronize_net();
> + cancel_delayed_work_sync(&npinfo->tx_work);
Maybe we can avoid the sync_net and the comment by using
disable_delayed_work_sync() ?
^ permalink raw reply
* Re: [PATCH] net: stmmac: fix missed le32_to_cpu()
From: Jakub Kicinski @ 2026-06-25 2:22 UTC (permalink / raw)
To: Maxime Chevallier
Cc: Ben Dooks, Andrew Lunn, David S. Miller, Eric Dumazet,
Paolo Abeni, Maxime Coquelin, Alexandre Torgue,
Russell King (Oracle), netdev, linux-stm32, linux-arm-kernel,
linux-kernel
In-Reply-To: <b375d36c-112e-4662-b538-fd10fa927ecc@bootlin.com>
On Mon, 22 Jun 2026 19:51:39 +0200 Maxime Chevallier wrote:
> Hi Ben,
>
> On 6/22/26 16:37, Ben Dooks wrote:
> > The print in ndesc_display_ring() sends the des2 and des3
> > to the pr_info() without passing them through the relevant
> > conversion to cpu order.
> >
> > Fix the (prototype) sparse warnings by using le32_to_cpu():
> > drivers/net/ethernet/stmicro/stmmac/norm_desc.c:258:17: warning: incorrect type in argument 6 (different base types)
> > drivers/net/ethernet/stmicro/stmmac/norm_desc.c:258:17: expected unsigned int
> > drivers/net/ethernet/stmicro/stmmac/norm_desc.c:258:17: got restricted __le32 [usertype] des2
> > drivers/net/ethernet/stmicro/stmmac/norm_desc.c:258:17: warning: incorrect type in argument 7 (different base types)
> > drivers/net/ethernet/stmicro/stmmac/norm_desc.c:258:17: expected unsigned int
> > drivers/net/ethernet/stmicro/stmmac/norm_desc.c:258:17: got restricted __le32 [usertype] des3
> >
> > Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
>
> I agree on the principle, but this isn't a fix so this'll have to wait
> until net-next re-opens :)
Humpf, why are we not seeing this on x86 allmodconfig ? 🤔️
$ make C=1 W=1 drivers/net/ethernet/stmicro/stmmac/norm_desc.o
DESCEND objtool
CC [M] drivers/net/ethernet/stmicro/stmmac/norm_desc.o
CHECK drivers/net/ethernet/stmicro/stmmac/norm_desc.c
$
^ permalink raw reply
* Re: [PATCH net 2/3] net/mlx5e: Validate bandwidth for non-ETS traffic classes
From: Jakub Kicinski @ 2026-06-25 2:10 UTC (permalink / raw)
To: Tariq Toukan
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, netdev, Paolo Abeni,
Alexei Lazar, Carolina Jubran, Leon Romanovsky, linux-kernel,
linux-rdma, Mark Bloch, Saeed Mahameed, Gal Pressman
In-Reply-To: <20260622112925.624795-3-tariqt@nvidia.com>
On Mon, 22 Jun 2026 14:29:24 +0300 Tariq Toukan wrote:
> From: Alexei Lazar <alazar@nvidia.com>
>
> The IEEE 802.1Qaz standard defines that bandwidth allocation percentages
> only apply to ETS traffic classes.
>
> Reject ETS configurations that specify non-zero bandwidth for traffic
> classes.
>
> Fixes: 08fb1dacdd76 ("net/mlx5e: Support DCBNL IEEE ETS")
> Signed-off-by: Alexei Lazar <alazar@nvidia.com>
> Reviewed-by: Carolina Jubran <cjubran@nvidia.com>
> Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
> ---
> drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c b/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c
> index 762f0a46c120..e4161603cdc0 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c
> @@ -324,6 +324,17 @@ static int mlx5e_dbcnl_validate_ets(struct net_device *netdev,
> }
> }
>
> + /* Validate Non ETS BW */
> + for (i = 0; i < IEEE_8021QAZ_MAX_TCS; i++) {
> + if (ets->tc_tsa[i] != IEEE_8021QAZ_TSA_ETS &&
> + ets->tc_tx_bw[i]) {
> + netdev_err(netdev,
> + "Failed to validate ETS: tc=%d BW is not 0 for non-ETS TC (tsa=%u, bw=%u)\n",
> + i, ets->tc_tsa[i], ets->tc_tx_bw[i]);
> + return -EINVAL;
> + }
> + }
Can we pull this check out into the shared dcbnl handling?
There seems to be zero mlx5 specific logic in this patch,
and the motivation.
> /* Validate Bandwidth Sum */
> for (i = 0; i < IEEE_8021QAZ_MAX_TCS; i++) {
> if (ets->tc_tsa[i] == IEEE_8021QAZ_TSA_ETS) {
^ permalink raw reply
* Re: [PATCH net] net: usb: kalmia: bound RX frame length in kalmia_rx_fixup()
From: patchwork-bot+netdevbpf @ 2026-06-25 2:10 UTC (permalink / raw)
To: Maoyi Xie
Cc: oneukum, andrew+netdev, davem, edumazet, kuba, pabeni, linux-usb,
netdev, linux-kernel, stable
In-Reply-To: <178211531778.2216480.12637613349790980750@maoyixie.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 22 Jun 2026 16:01:57 +0800 you wrote:
> kalmia_rx_fixup() computes usb_packet_length = skb->len - (2 *
> KALMIA_HEADER_LENGTH) as a u16, guarded only by a pre-loop check that
> skb->len is at least KALMIA_HEADER_LENGTH, which is 6. A device can
> deliver a short bulk-IN frame with skb->len in the 6 to 11 range, or
> leave a short trailing remainder on a later loop iteration. Either case
> underflows usb_packet_length to about 65530.
>
> [...]
Here is the summary with links:
- [net] net: usb: kalmia: bound RX frame length in kalmia_rx_fixup()
https://git.kernel.org/netdev/net/c/47b6bcef6e67
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 v4] net: mvneta: re-enable percpu interrupt on resume
From: patchwork-bot+netdevbpf @ 2026-06-25 2:10 UTC (permalink / raw)
To: Yun Zhou
Cc: marcin.s.wojtas, andrew+netdev, davem, edumazet, kuba, pabeni,
bigeasy, clrkwllms, rostedt, netdev, linux-kernel, linux-rt-devel
In-Reply-To: <20260622074350.1666290-1-yun.zhou@windriver.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 22 Jun 2026 15:43:50 +0800 you wrote:
> On Marvell MPIC platforms (Armada 370/XP/38x), mvneta uses a percpu
> IRQ disable/enable scheme for NAPI: the ISR (mvneta_percpu_isr) calls
> disable_percpu_irq() to mask the MPIC per-CPU interrupt and schedules
> NAPI poll, which calls enable_percpu_irq() on completion to unmask.
>
> If suspend occurs while NAPI poll is pending (between
> disable_percpu_irq in the ISR and enable_percpu_irq in poll
> completion), the interrupt is never re-enabled:
>
> [...]
Here is the summary with links:
- [v4] net: mvneta: re-enable percpu interrupt on resume
https://git.kernel.org/netdev/net/c/fd398d648098
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 v3 1/2] geneve: gate GRO hint in geneve_gro_complete() on gs->gro_hint
From: patchwork-bot+netdevbpf @ 2026-06-25 2:10 UTC (permalink / raw)
To: Xiang Mei
Cc: netdev, pabeni, kuba, edumazet, andrew+netdev, davem, bestswngs,
kylebot
In-Reply-To: <20260618032622.484720-1-xmei5@asu.edu>
Hello:
This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 17 Jun 2026 20:26:21 -0700 you wrote:
> geneve_gro_receive() reads the GRO hint through geneve_sk_gro_hint_off(),
> which honours it only when the socket enabled IFLA_GENEVE_GRO_HINT
> (gs->gro_hint). geneve_gro_complete() instead calls the low-level
> geneve_opt_gro_hint_off() and acts on the hint unconditionally.
>
> On a tunnel without the hint, receive aggregates the frames as plain
> ETH_P_TEB while complete still honours an attacker-supplied hint option: it
> inflates gh_len by gro_hint->nested_hdr_len (u8) and redirects the dispatch
> type, so the inner gro_complete handler runs at nhoff + gh_len, an offset
> receive never pulled nor validated, reading out of bounds of the skb head:
>
> [...]
Here is the summary with links:
- [net,v3,1/2] geneve: gate GRO hint in geneve_gro_complete() on gs->gro_hint
https://git.kernel.org/netdev/net/c/2651c1744458
- [net,v3,2/2] geneve: validate inner network offset in geneve_gro_complete()
https://git.kernel.org/netdev/net/c/cbb0d30a1ad6
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 v2 net-next] sctp: use sctp_auth_shkey_release() in error path for consistency
From: Jakub Kicinski @ 2026-06-25 2:01 UTC (permalink / raw)
To: Wentao Liang
Cc: Marcelo Ricardo Leitner, Xin Long, David S . Miller, Eric Dumazet,
Paolo Abeni, Simon Horman, linux-sctp, netdev, linux-kernel
In-Reply-To: <20260622100235.34263-1-vulab@iscas.ac.cn>
On Mon, 22 Jun 2026 18:02:35 +0800 Wentao Liang wrote:
> Use the proper refcount-aware helper sctp_auth_shkey_release() instead
> of kfree() when freeing cur_key in the error path of sctp_auth_set_key().
> While both are equivalent in the current code, using the helper maintains
> abstraction consistency and prevents potential issues if the code is
> reordered in the future.
## Form letter - net-next-closed
We have already submitted our pull request with net-next material for v7.2,
and therefore net-next is closed for new drivers, features, code refactoring
and optimizations. We are currently accepting bug fixes only.
Please repost when net-next reopens after June 29th.
RFC patches sent for review only are obviously welcome at any time.
See: https://www.kernel.org/doc/html/next/process/maintainer-netdev.html#development-cycle
--
pw-bot: defer
pv-bot: closed
^ 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