* [PATCH net 7/9] ipvs: fix PMTU for GUE/GRE tunnel ICMP errors
From: Florian Westphal @ 2026-07-03 12:57 UTC (permalink / raw)
To: netdev
Cc: Paolo Abeni, David S. Miller, Eric Dumazet, Jakub Kicinski,
netfilter-devel, pablo
In-Reply-To: <20260703125709.16493-1-fw@strlen.de>
From: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
When an ICMP Fragmentation Needed error is received for a tunneled IPVS
connection, ip_vs_in_icmp() recomputes the MTU that the original packet
can use by subtracting the tunnel overhead from the reported next-hop
MTU.
The current code always subtracts sizeof(struct iphdr), which is only
the IPIP overhead. For GUE and GRE tunnels, ipvs_udp_decap() and
ipvs_gre_decap() already compute the additional tunnel header length,
but that value is scoped to the decapsulation block and is lost before
the ICMP_FRAG_NEEDED handling. As a result, the ICMP error sent back to
the client advertises an MTU that is too large, so PMTUD can fail to
converge for GUE/GRE-tunneled real servers.
With a reported next-hop MTU of 1400, a GUE tunnel currently returns
1380 to the client. The correct value is 1368:
1400 - sizeof(struct iphdr) - sizeof(struct udphdr) -
sizeof(struct guehdr)
Hoist the tunnel header length into the main ip_vs_in_icmp() scope and
subtract sizeof(struct iphdr) + ulen in the Fragmentation Needed path.
The IPIP path keeps ulen as 0, so its existing 1400 - 20 = 1380 result
is unchanged.
Fixes: 508f744c0de3 ("ipvs: strip udp tunnel headers from icmp errors")
Cc: stable@vger.kernel.org
Reported-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
Reported-by: Yuxiang Yang <yangyx22@mails.tsinghua.edu.cn>
Reported-by: Ao Wang <wangao@seu.edu.cn>
Reported-by: Xuewei Feng <fengxw06@126.com>
Reported-by: Qi Li <qli01@tsinghua.edu.cn>
Reported-by: Ke Xu <xuke@tsinghua.edu.cn>
Assisted-by: Claude-Code:GLM-5.2
Signed-off-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
Acked-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Florian Westphal <fw@strlen.de>
---
net/netfilter/ipvs/ip_vs_core.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c
index d40b404c1bf6..906f2c361676 100644
--- a/net/netfilter/ipvs/ip_vs_core.c
+++ b/net/netfilter/ipvs/ip_vs_core.c
@@ -1767,6 +1767,7 @@ ip_vs_in_icmp(struct netns_ipvs *ipvs, struct sk_buff *skb, int *related,
bool tunnel, new_cp = false;
union nf_inet_addr *raddr;
char *outer_proto = "IPIP";
+ int ulen = 0;
*related = 1;
@@ -1831,7 +1832,6 @@ ip_vs_in_icmp(struct netns_ipvs *ipvs, struct sk_buff *skb, int *related,
/* Error for our tunnel must arrive at LOCAL_IN */
(skb_rtable(skb)->rt_flags & RTCF_LOCAL)) {
__u8 iproto;
- int ulen;
/* Non-first fragment has no UDP/GRE header */
if (unlikely(cih->frag_off & htons(IP_OFFSET)))
@@ -1936,8 +1936,8 @@ ip_vs_in_icmp(struct netns_ipvs *ipvs, struct sk_buff *skb, int *related,
if (dest_dst)
mtu = dst_mtu(dest_dst->dst_cache);
}
- if (mtu > 68 + sizeof(struct iphdr))
- mtu -= sizeof(struct iphdr);
+ if (mtu > 68 + sizeof(struct iphdr) + ulen)
+ mtu -= sizeof(struct iphdr) + ulen;
info = htonl(mtu);
}
/* Strip outer IP, ICMP and IPIP/UDP/GRE, go to IP header of
--
2.54.0
^ permalink raw reply related
* [PATCH net 6/9] netfilter: nft_set_rbtree: get command skips end element with open interval
From: Florian Westphal @ 2026-07-03 12:57 UTC (permalink / raw)
To: netdev
Cc: Paolo Abeni, David S. Miller, Eric Dumazet, Jakub Kicinski,
netfilter-devel, pablo
In-Reply-To: <20260703125709.16493-1-fw@strlen.de>
From: Pablo Neira Ayuso <pablo@netfilter.org>
The get command on intervals provide partial matches such as subranges
for usability reasons. However, an open interval has no closing end
element. If the closing element matches within the range of the open
internal, ie. its closest match is the start element of the open range,
then, return 0 but offer no matching element to userspace through
netlink as a special case. Userspace provides at least a matching start
element in this case and the closing end element matching the open
interal is ignored.
Another possibility is to report the matching start element of the open
interval for this end interval. However, this results in duplicated
matching being listed in userspace because userspace does not expect a
start element as response to a end element.
Fixes: 2aa34191f06f ("netfilter: nft_set_rbtree: use binary search array in get command")
Reported-by: Melbin K Mathew <mlbnkm1@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Florian Westphal <fw@strlen.de>
---
net/netfilter/nf_tables_api.c | 3 +++
net/netfilter/nft_set_rbtree.c | 8 ++++++--
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c
index 4884f7f7aaee..a9eaf9455c77 100644
--- a/net/netfilter/nf_tables_api.c
+++ b/net/netfilter/nf_tables_api.c
@@ -6563,6 +6563,9 @@ static int nft_get_set_elem(struct nft_ctx *ctx, const struct nft_set *set,
if (err < 0)
return err;
+ if (!elem.priv)
+ return 0;
+
err = -ENOMEM;
skb = nlmsg_new(NLMSG_GOODSIZE, GFP_ATOMIC);
if (skb == NULL)
diff --git a/net/netfilter/nft_set_rbtree.c b/net/netfilter/nft_set_rbtree.c
index 018bbb6df4ce..6222e9bb57bc 100644
--- a/net/netfilter/nft_set_rbtree.c
+++ b/net/netfilter/nft_set_rbtree.c
@@ -184,10 +184,14 @@ nft_rbtree_get(const struct net *net, const struct nft_set *set,
if (!interval || nft_set_elem_expired(interval->from))
return ERR_PTR(-ENOENT);
- if (flags & NFT_SET_ELEM_INTERVAL_END)
+ if (flags & NFT_SET_ELEM_INTERVAL_END) {
+ if (!interval->to)
+ return NULL;
+
rbe = container_of(interval->to, struct nft_rbtree_elem, ext);
- else
+ } else {
rbe = container_of(interval->from, struct nft_rbtree_elem, ext);
+ }
return &rbe->priv;
}
--
2.54.0
^ permalink raw reply related
* [PATCH net 5/9] netfilter: ip6tables: mark malformed IPv6 extension headers for hotdrop
From: Florian Westphal @ 2026-07-03 12:57 UTC (permalink / raw)
To: netdev
Cc: Paolo Abeni, David S. Miller, Eric Dumazet, Jakub Kicinski,
netfilter-devel, pablo
In-Reply-To: <20260703125709.16493-1-fw@strlen.de>
From: Zhixing Chen <running910@gmail.com>
The ah, hbh and rt matches check that the fixed extension header is
present, then use the header length field to derive the advertised
extension header length for matching.
For the ah match, add the missing advertised-length check. For hbh
and rt, update the existing advertised-length checks. In all three
cases, set hotdrop to true before returning false when the advertised
extension header length exceeds the available skb data.
Returning false treats the packet as a rule mismatch. Set hotdrop to
true and drop malformed packets so they cannot bypass rules intended
to drop packets with these IPv6 extension headers.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Zhixing Chen <running910@gmail.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
---
net/ipv6/netfilter/ip6t_ah.c | 5 +++++
net/ipv6/netfilter/ip6t_hbh.c | 1 +
net/ipv6/netfilter/ip6t_rt.c | 3 ++-
3 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/netfilter/ip6t_ah.c b/net/ipv6/netfilter/ip6t_ah.c
index 70da2f2ce064..1258783ed876 100644
--- a/net/ipv6/netfilter/ip6t_ah.c
+++ b/net/ipv6/netfilter/ip6t_ah.c
@@ -56,6 +56,11 @@ static bool ah_mt6(const struct sk_buff *skb, struct xt_action_param *par)
}
hdrlen = ipv6_authlen(ah);
+ if (skb->len - ptr < hdrlen) {
+ /* Packet smaller than its length field */
+ par->hotdrop = true;
+ return false;
+ }
pr_debug("IPv6 AH LEN %u %u ", hdrlen, ah->hdrlen);
pr_debug("RES %04X ", ah->reserved);
diff --git a/net/ipv6/netfilter/ip6t_hbh.c b/net/ipv6/netfilter/ip6t_hbh.c
index 450dd53846a2..6d1a5d2026a6 100644
--- a/net/ipv6/netfilter/ip6t_hbh.c
+++ b/net/ipv6/netfilter/ip6t_hbh.c
@@ -75,6 +75,7 @@ hbh_mt6(const struct sk_buff *skb, struct xt_action_param *par)
hdrlen = ipv6_optlen(oh);
if (skb->len - ptr < hdrlen) {
/* Packet smaller than it's length field */
+ par->hotdrop = true;
return false;
}
diff --git a/net/ipv6/netfilter/ip6t_rt.c b/net/ipv6/netfilter/ip6t_rt.c
index 5561bd9cea81..278b52752f36 100644
--- a/net/ipv6/netfilter/ip6t_rt.c
+++ b/net/ipv6/netfilter/ip6t_rt.c
@@ -56,7 +56,8 @@ static bool rt_mt6(const struct sk_buff *skb, struct xt_action_param *par)
hdrlen = ipv6_optlen(rh);
if (skb->len - ptr < hdrlen) {
- /* Pcket smaller than its length field */
+ /* Packet smaller than its length field */
+ par->hotdrop = true;
return false;
}
--
2.54.0
^ permalink raw reply related
* [PATCH net 4/9] netfilter: nfnetlink_cthelper: cap to maximum number of expectation per master on updates
From: Florian Westphal @ 2026-07-03 12:57 UTC (permalink / raw)
To: netdev
Cc: Paolo Abeni, David S. Miller, Eric Dumazet, Jakub Kicinski,
netfilter-devel, pablo
In-Reply-To: <20260703125709.16493-1-fw@strlen.de>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Really cap it to NF_CT_EXPECT_MAX_CNT (255) on updates.
The commit ("netfilter: nfnetlink_cthelper: cap to maximum number of
expectation per master") only covers creation of helpers, not updates.
Fixes: 397c8300972f ("netfilter: nf_conntrack_helper: cap maximum number of expectation at helper registration")
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Florian Westphal <fw@strlen.de>
---
net/netfilter/nfnetlink_cthelper.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/netfilter/nfnetlink_cthelper.c b/net/netfilter/nfnetlink_cthelper.c
index 2cbcca9110db..f062ac210343 100644
--- a/net/netfilter/nfnetlink_cthelper.c
+++ b/net/netfilter/nfnetlink_cthelper.c
@@ -316,6 +316,8 @@ nfnl_cthelper_update_policy_one(const struct nf_conntrack_expect_policy *policy,
new_policy->max_expected =
ntohl(nla_get_be32(tb[NFCTH_POLICY_EXPECT_MAX]));
+ if (!new_policy->max_expected)
+ new_policy->max_expected = NF_CT_EXPECT_MAX_CNT;
if (new_policy->max_expected > NF_CT_EXPECT_MAX_CNT)
return -EINVAL;
--
2.54.0
^ permalink raw reply related
* [PATCH net 3/9] netfilter: xt_rateest: fix u64 truncation in xt_rateest_mt()
From: Florian Westphal @ 2026-07-03 12:57 UTC (permalink / raw)
To: netdev
Cc: Paolo Abeni, David S. Miller, Eric Dumazet, Jakub Kicinski,
netfilter-devel, pablo
In-Reply-To: <20260703125709.16493-1-fw@strlen.de>
From: Feng Wu <wufengwufengwufeng@gmail.com>
On links faster than ~34 Gbps, where byte rate may exceed 2^32-1
(~ 4.3 GBps), the comparison result becomes incorrect because the
truncated value no longer reflects the actual estimator rate.
Fix by changing the local variables to u64.
Fixes: 1c0d32fde5bd ("net_sched: gen_estimator: complete rewrite of rate estimators")
Signed-off-by: Feng Wu <wufengwufengwufeng@gmail.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
---
net/netfilter/xt_rateest.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/netfilter/xt_rateest.c b/net/netfilter/xt_rateest.c
index b1d736c15fcb..7c05b6342578 100644
--- a/net/netfilter/xt_rateest.c
+++ b/net/netfilter/xt_rateest.c
@@ -16,7 +16,7 @@ xt_rateest_mt(const struct sk_buff *skb, struct xt_action_param *par)
{
const struct xt_rateest_match_info *info = par->matchinfo;
struct gnet_stats_rate_est64 sample = {0};
- u_int32_t bps1, bps2, pps1, pps2;
+ u64 bps1, bps2, pps1, pps2;
bool ret = true;
gen_estimator_read(&info->est1->rate_est, &sample);
--
2.54.0
^ permalink raw reply related
* [PATCH net 2/9] netfilter: xt_u32: reject invalid shift counts
From: Florian Westphal @ 2026-07-03 12:57 UTC (permalink / raw)
To: netdev
Cc: Paolo Abeni, David S. Miller, Eric Dumazet, Jakub Kicinski,
netfilter-devel, pablo
In-Reply-To: <20260703125709.16493-1-fw@strlen.de>
From: Wyatt Feng <bronzed_45_vested@icloud.com>
u32_match_it() executes rule-supplied shift operands on a 32-bit
value. A malformed u32 rule can provide a shift count of 32 or more,
triggering an undefined shift out-of-bounds during packet evaluation.
Validate XT_U32_LEFTSH and XT_U32_RIGHTSH operands in
u32_mt_checkentry() and reject malformed rules before they reach the
packet path.
Fixes: 1b50b8a371e9 ("[NETFILTER]: Add u32 match")
Reported-by: Yuan Tan <yuantan098@gmail.com>
Reported-by: Yifan Wu <yifanwucs@gmail.com>
Reported-by: Juefei Pu <tomapufckgml@gmail.com>
Reported-by: Zhengchuan Liang <zcliangcn@gmail.com>
Reported-by: Xin Liu <bird@lzu.edu.cn>
Assisted-by: Codex:GPT-5.4
Signed-off-by: Wyatt Feng <bronzed_45_vested@icloud.com>
Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
Signed-off-by: Florian Westphal <fw@strlen.de>
---
net/netfilter/xt_u32.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/net/netfilter/xt_u32.c b/net/netfilter/xt_u32.c
index 117d4615d668..ec1a21e3b6e2 100644
--- a/net/netfilter/xt_u32.c
+++ b/net/netfilter/xt_u32.c
@@ -100,7 +100,7 @@ static int u32_mt_checkentry(const struct xt_mtchk_param *par)
{
const struct xt_u32 *data = par->matchinfo;
const struct xt_u32_test *ct;
- unsigned int i;
+ unsigned int i, j;
if (data->ntests > ARRAY_SIZE(data->tests))
return -EINVAL;
@@ -111,6 +111,16 @@ static int u32_mt_checkentry(const struct xt_mtchk_param *par)
if (ct->nnums > ARRAY_SIZE(ct->location) ||
ct->nvalues > ARRAY_SIZE(ct->value))
return -EINVAL;
+
+ for (j = 1; j < ct->nnums; ++j) {
+ switch (ct->location[j].nextop) {
+ case XT_U32_LEFTSH:
+ case XT_U32_RIGHTSH:
+ if (ct->location[j].number >= 32)
+ return -EINVAL;
+ break;
+ }
+ }
}
return 0;
--
2.54.0
^ permalink raw reply related
* [PATCH net 1/9] netfilter: nf_nat_sip: reload possible stale data pointer
From: Florian Westphal @ 2026-07-03 12:57 UTC (permalink / raw)
To: netdev
Cc: Paolo Abeni, David S. Miller, Eric Dumazet, Jakub Kicinski,
netfilter-devel, pablo
In-Reply-To: <20260703125709.16493-1-fw@strlen.de>
quoting sashiko:
------------------------------------------------------------------------
[..] noticed a potential memory bug and header corruption involving the
SIP NAT helper.
In net/netfilter/nf_nat_sip.c:nf_nat_sip():
if (skb_ensure_writable(skb, skb->len)) {
nf_ct_helper_log(skb, ct, "cannot mangle packet");
return NF_DROP;
}
uh = (void *)skb->data + protoff;
uh->dest = ct_sip_info->forced_dport;
if (!nf_nat_mangle_udp_packet(skb, ct, ctinfo, protoff,
0, 0, NULL, 0)) {
If a cloned or fragmented SKB is reallocated by skb_ensure_writable(), the
old data buffer is freed. However, nf_nat_sip() fails to update *dptr to
point to the new buffer.
It also appears to use nf_nat_mangle_udp_packet() on what could be a TCP
packet, which would overwrite the sequence number with a checksum update.
------------------------------------------------------------------------
nf_conntrack_sip linerizes skbs, hence no fragmented skb can be seen.
But clones are possible, so rebuild dptr.
Disable nf_nat_mangle_udp_packet() branch for TCP streams.
It doesn't look like this can ever happen, else we should have received
bug reports about this, so just check the conntrack is UDP and drop
otherwise.
The calling conntrack_sip set ->forced_dport for SIP_HDR_VIA_UDP messages,
so I don't think this is ever expected to be true for a TCP stream.
Fixes: 7266507d8999 ("netfilter: nf_ct_sip: support Cisco 7941/7945 IP phones")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-sonnet-4-6
Signed-off-by: Florian Westphal <fw@strlen.de>
---
net/netfilter/nf_nat_sip.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/net/netfilter/nf_nat_sip.c b/net/netfilter/nf_nat_sip.c
index 67c04d8143ab..aea02f6aff09 100644
--- a/net/netfilter/nf_nat_sip.c
+++ b/net/netfilter/nf_nat_sip.c
@@ -289,13 +289,24 @@ static unsigned int nf_nat_sip(struct sk_buff *skb, unsigned int protoff,
/* Mangle destination port for Cisco phones, then fix up checksums */
if (dir == IP_CT_DIR_REPLY && ct_sip_info->forced_dport) {
+ int doff = *dptr - (const char *)skb->data;
struct udphdr *uh;
+ if (doff <= 0) {
+ DEBUG_NET_WARN_ON_ONCE(1);
+ return NF_DROP;
+ }
+
+ /* ct_sip_info->forced_dport only expected with UDP */
+ if (nf_ct_protonum(ct) != IPPROTO_UDP)
+ return NF_DROP;
+
if (skb_ensure_writable(skb, skb->len)) {
nf_ct_helper_log(skb, ct, "cannot mangle packet");
return NF_DROP;
}
+ *dptr = skb->data + doff;
uh = (void *)skb->data + protoff;
uh->dest = ct_sip_info->forced_dport;
--
2.54.0
^ permalink raw reply related
* [PATCH net 0/9] netfilter: updates for net
From: Florian Westphal @ 2026-07-03 12:57 UTC (permalink / raw)
To: netdev
Cc: Paolo Abeni, David S. Miller, Eric Dumazet, Jakub Kicinski,
netfilter-devel, pablo
Hi,
The following patchset contains Netfilter fixes for *net*, all
for ancient problems. Patch 7 raised drive-by sashiko findings,
but those are not related to the change itself.
1) Rebuild the nf_nat_sip data pointer to prevent stale access after SKB
reallocation. Restrict UDP mangling to UDP streams to avoid TCP packet
corruption.
2) Prevent undefined behavior in xt_u32 caused by invalid shift counts.
From Wyatt Feng.
3) Use u64 variables to prevent incorrect comparisons on links exceeding
34 Gbps in xt_rateest. From Feng Wu.
4) Cap the number of expectations per master during nfnetlink_cthelper
updates. From Pablo Neira Ayuso.
5) Mark malformed IPv6 extension headers for hotdrop in ip6tables.
From Zhixing Chen.
6) Skip the end element of an open interval during the get command when its
closest match is the interval's start element. Also from Pablo Neira Ayuso.
7) Fix PMTU calculation for GUE/GRE tunnels in IPVS during ICMP fragmentation
error handling. Include additional tunnel header length when computing the
new MTU. From Yizhou Zhao.
8) Reset full ip_vs_seq structures in ip_vs_conn_new. Also from Yizhou Zhao.
9) Reject invalid shift parameters in xt_connmark. Also from Wyatt Feng.
Please, pull these changes from:
The following changes since commit d335dcc6f521571d57117b8deeebc940836e5450:
gue: validate REMCSUM private option length (2026-07-03 09:34:53 +0100)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf.git tags/nf-26-07-03
for you to fetch changes up to 1b47026fb4b35bac850ad6e8a4ad7fc018e09ebc:
netfilter: xt_connmark: reject invalid shift parameters (2026-07-03 14:45:21 +0200)
----------------------------------------------------------------
netfilter pull request nf-26-07-03
----------------------------------------------------------------
Feng Wu (1):
netfilter: xt_rateest: fix u64 truncation in xt_rateest_mt()
Florian Westphal (1):
netfilter: nf_nat_sip: reload possible stale data pointer
Pablo Neira Ayuso (2):
netfilter: nfnetlink_cthelper: cap to maximum number of expectation
per master on updates
netfilter: nft_set_rbtree: get command skips end element with open
interval
Wyatt Feng (2):
netfilter: xt_u32: reject invalid shift counts
netfilter: xt_connmark: reject invalid shift parameters
Yizhou Zhao (2):
ipvs: fix PMTU for GUE/GRE tunnel ICMP errors
ipvs: reset full ip_vs_seq structs in ip_vs_conn_new
Zhixing Chen (1):
netfilter: ip6tables: mark malformed IPv6 extension headers for hotdrop
net/ipv6/netfilter/ip6t_ah.c | 5 +++++
net/ipv6/netfilter/ip6t_hbh.c | 1 +
net/ipv6/netfilter/ip6t_rt.c | 3 ++-
net/netfilter/ipvs/ip_vs_conn.c | 4 ++--
net/netfilter/ipvs/ip_vs_core.c | 6 +++---
net/netfilter/nf_nat_sip.c | 11 +++++++++++
net/netfilter/nf_tables_api.c | 3 +++
net/netfilter/nfnetlink_cthelper.c | 2 ++
net/netfilter/nft_set_rbtree.c | 8 ++++++--
net/netfilter/xt_connmark.c | 14 ++++++++++++--
net/netfilter/xt_rateest.c | 2 +-
net/netfilter/xt_u32.c | 12 +++++++++++-
12 files changed, 59 insertions(+), 12 deletions(-)
--
2.54.0
^ permalink raw reply
* [PATCH] net : bonding : Remove TODO comment about retrying setting the MAC
From: Paritosh Potukuchi @ 2026-07-03 12:55 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, jv, paritosh.potukuchi, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni
As correctly pointed out by Jay Vosburgh,
"This comment dates to sometime before git, when it was common for
network device drivers to lack the ability to change the MAC while the
interface is up. To the best of my knowledge, that isn't a issue
today."
Based on the discussion in the RFC linked below, I am removing the
TODO.
Link to the RFC:
https://lore.kernel.org/netdev/2001256.1782860341@famine/T/#t
Signed-off-by: Paritosh Potukuchi <paritosh.potukuchi@amd.com>
---
drivers/net/bonding/bond_main.c | 6 ------
1 file changed, 6 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index d2e4dae4e97c..d5c19dc4bc07 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -4865,12 +4865,6 @@ static int bond_set_mac_address(struct net_device *bond_dev, void *addr)
__func__, slave);
res = dev_set_mac_address(slave->dev, addr, NULL);
if (res) {
- /* TODO: consider downing the slave
- * and retry ?
- * User should expect communications
- * breakage anyway until ARP finish
- * updating, so...
- */
slave_dbg(bond_dev, slave->dev, "%s: err %d\n",
__func__, res);
goto unwind;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 net-next] ethtool: link 10000baseCR to SFF-8431, Appendix-E SFP+ DA
From: Maxime Chevallier @ 2026-07-03 12:53 UTC (permalink / raw)
To: Siddaraju DH, Michal Kubecek, Andrew Lunn, kuba, netdev
Cc: Shubham Das, Balaji Chintalapalle, Vijay Srinivasan,
Magnus Lindberg, Niklas Damberg, Jonas Wirandi, Siddaraju DH
In-Reply-To: <20260703100537.1109838-1-siddaraju.dh@intel.com>
Hi
On 7/3/26 12:05, Siddaraju DH wrote:
> Add comment to clarify the physical media 10000baseCR follows.
>
> 10000baseCR does not correspond to any IEEE 802.3 *base-CR PMD.
> It has no autonegotiation, no link training, and no mandatory FEC.
> The industry standard for this media type is SFF-8431 Appendix-E
> Direct Attach cable, also known as 10G_SFI_DA.
>
> Link: https://lore.kernel.org/r/SN7PR11MB69003D33489DB1D6B17EF72A9AF52@SN7PR11MB6900.namprd11.prod.outlook.com
>
> Signed-off-by: Siddaraju DH <siddaraju.dh@intel.com>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Maxime
^ permalink raw reply
* Re: [PATCH] net: phy: marvell: Add soft reset for 88E1510
From: Andrew Lunn @ 2026-07-03 12:53 UTC (permalink / raw)
To: Ben Brown
Cc: hkallweit1@gmail.com, linux@armlinux.org.uk, davem@davemloft.net,
edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
Chris Packham
In-Reply-To: <c0d760ff-fe66-48df-bd9f-3226dfdc97fc@alliedtelesis.co.nz>
On Fri, Jul 03, 2026 at 12:14:26AM +0000, Ben Brown wrote:
>
>
> On 7/3/26 11:04, Andrew Lunn wrote:
> > On Fri, Jul 03, 2026 at 10:50:34AM +1200, Ben Brown wrote:
> >> When bringing down then up the link on a 88e1512 phy a link is not
> >> getting established. This is because the phy is coming out of reset then
> >> immediately getting configured. During configuration the page is
> >> unsuccessfully updated causing writes to the wrong registers.
> >>
> >> Add the soft reset function that does a reset then polling read waiting
> >> for the phy to come back online, at which stage the page register can be
> >> updated successfully.
> >>
> >> This was tested on a 88E1512 phy, using ip link to bring up/down the
> >> link.
> >
> > What makes the 88E1512 special that it needs this, but no other
> > Marvell PHY does?
> >
> > Andrew
>
> This may be needed on the other marvell phys, but I only have access to
> a 88E1512 phy so I am only updating what I have seen this on.
The Marvell driver is used a lot, so i would of expected somebody else
to of noticed.
Lets take a step back.
What sort of reset are we talking about? Software or hardware?
Andrew
^ permalink raw reply
* Re: Question: bridge: clarify MST VLAN list RCU traversal contract
From: Runyu Xiao @ 2026-07-03 4:24 UTC (permalink / raw)
To: Ido Schimmel
Cc: Nikolay Aleksandrov, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, bridge, netdev,
linux-kernel, jianhao.xu
In-Reply-To: <20260628174900.GA400397@shredder>
Hi Ido,
On Sun, 28 Jun 2026 20:49:00 +0300, Ido Schimmel wrote:
> I don't think anything needs to change. AFAICT, br_mst_info_size() is
> only reachable via the get_link_af_size() callback and
> rtnl_link_get_af_size() always invokes it from an RCU read-side critical
> section.
>
> Did you see a splat with CONFIG_PROVE_RCU_LIST?
Thanks for the clarification.
No, I did not see an in-kernel splat from the actual rtnetlink path.
The warning I had was from the reviewed out-of-tree reproducer used for
our CONFIG_PROVE_RCU_LIST triage, not from a real bridge netlink call
path.
Given your explanation that rtnl_link_get_af_size() already invokes
this from an RCU read-side critical section, I will treat this as an
intended contract and I will not pursue a patch for it based on the
current evidence.
Thanks,
Runyu
^ permalink raw reply
* Re: [PATCH net v2 2/2] octeon_ep_vf: fix skb frags overflow in the RX path
From: Maciej Fijalkowski @ 2026-07-03 12:11 UTC (permalink / raw)
To: Maoyi Xie
Cc: Veerasenareddy Burru, Sathesh Edara, Andrew Lunn,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
netdev, linux-kernel
In-Reply-To: <20260702180518.2013324-3-maoyixie.tju@gmail.com>
On Fri, Jul 03, 2026 at 02:05:18AM +0800, Maoyi Xie wrote:
> __octep_vf_oq_process_rx() has the same unbounded fragment loop as the PF
> driver. buff_info->len comes from the device response header, and one
> fragment is added per buffer_size chunk with no check against
> MAX_SKB_FRAGS. A long packet yields about 18 fragments, one past the
> default MAX_SKB_FRAGS of 17, so skb_add_rx_frag() writes past
> shinfo->frags[].
>
> The fragment count is now checked before napi_build_skb(). A packet that
> needs more fragments than the skb can hold is dropped. Its descriptors are
> drained the same way the build_skb failure path does.
>
> Fixes: 1cd3b407977c ("octeon_ep_vf: add Tx/Rx processing and interrupt support")
> Co-developed-by: Kaixuan Li <kaixuan.li@ntu.edu.sg>
> Signed-off-by: Kaixuan Li <kaixuan.li@ntu.edu.sg>
> Signed-off-by: Maoyi Xie <maoyixie.tju@gmail.com>
> ---
> .../marvell/octeon_ep_vf/octep_vf_rx.c | 20 +++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/drivers/net/ethernet/marvell/octeon_ep_vf/octep_vf_rx.c b/drivers/net/ethernet/marvell/octeon_ep_vf/octep_vf_rx.c
> index d982474082..7af6a80671 100644
> --- a/drivers/net/ethernet/marvell/octeon_ep_vf/octep_vf_rx.c
> +++ b/drivers/net/ethernet/marvell/octeon_ep_vf/octep_vf_rx.c
> @@ -431,6 +431,26 @@ static int __octep_vf_oq_process_rx(struct octep_vf_device *oct,
> struct skb_shared_info *shinfo;
> u16 data_len;
>
> + data_len = buff_info->len - oq->max_single_buffer_size;
> + if (DIV_ROUND_UP(data_len, oq->buffer_size) > MAX_SKB_FRAGS) {
> + desc_used++;
> + read_idx = octep_vf_oq_next_idx(oq, read_idx);
> + while (data_len) {
> + dma_unmap_page(oq->dev, oq->desc_ring[read_idx].buffer_ptr,
> + PAGE_SIZE, DMA_FROM_DEVICE);
> + buff_info = (struct octep_vf_rx_buffer *)
> + &oq->buff_info[read_idx];
> + buff_info->page = NULL;
> + if (data_len < oq->buffer_size)
> + data_len = 0;
> + else
> + data_len -= oq->buffer_size;
> + desc_used++;
> + read_idx = octep_vf_oq_next_idx(oq, read_idx);
> + }
> + continue;
> + }
This is exactly repeated code for !skb case below, right? Please pull it
out to helper function then.
> +
> skb = napi_build_skb((void *)resp_hw, PAGE_SIZE);
> if (!skb) {
> oq->stats->alloc_failures++;
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH net-next v3 13/15] net: macb: re-read ISR inside IRQ handler locked section
From: Conor Dooley @ 2026-07-03 12:09 UTC (permalink / raw)
To: Théo Lebrun
Cc: Conor Dooley, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Richard Cochran, Russell King,
netdev, linux-kernel, Nicolas Ferre, Claudiu Beznea,
Paolo Valerio, Nicolai Buchwitz, Vladimir Kondratiev,
Gregory CLEMENT, Benoît Monin, Tawfik Bayouk,
Thomas Petazzoni, Maxime Chevallier
In-Reply-To: <20260701-macb-context-v3-13-00268d5b1502@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 2844 bytes --]
Hey,
I'll admit to being a bit confused by this patch..
On Wed, Jul 01, 2026 at 05:59:16PM +0200, Théo Lebrun wrote:
> The IRQ handler reads ISR register into the `status` stack variable.
> If empty, it early returns. Else, it grabs bp->lock and iterates on
> the status bits.
>
> If we tried grabbing bp->lock while already acquired, we might have
> slept and the status might have been updated. Our most likely
This mention of sleeping I think should be removed, it implies sleeping
is required for the status to be updated.
> competitor in this race (condition) is a swap operation, used in
> change_mtu and set_ringparam. It is the only MACB codepath that resets
> interrupts and HW inside a bp->lock critical section. Other codepaths
> that clear HW IRQ status do so outside the bp->lock critical section.
Where do change_mtu and set_ringparam take the bp lock?
As far as I can see, they don't. The commit message should reflect how
the code behaves at the time of the patch, not at some point in the
future after it.
> We can only detect spurious interrupts before grabbing bp->lock if
> MACB_CAPS_ISR_CLEAR_ON_WRITE. If we don't, then we only read ISR once.
>
> Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
> ---
> drivers/net/ethernet/cadence/macb_main.c | 16 ++++++++++++----
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
> index 7245c345c78f..5a32d5cb759e 100644
> --- a/drivers/net/ethernet/cadence/macb_main.c
> +++ b/drivers/net/ethernet/cadence/macb_main.c
> @@ -2184,13 +2184,21 @@ static irqreturn_t macb_interrupt(int irq, void *dev_id)
> struct net_device *netdev = bp->netdev;
> u32 status;
>
> - status = queue_readl(queue, ISR);
> -
> - if (unlikely(!status))
> - return IRQ_NONE;
> + /* detect spurious interrupts without grabbing bp->lock */
> + if (bp->caps & MACB_CAPS_ISR_CLEAR_ON_WRITE) {
> + status = queue_readl(queue, ISR);
> + if (unlikely(!status))
> + return IRQ_NONE;
> + }
To be honest, this check feels like penalising the likely^2 case* with an
extra read favour of the unlikely case where there's contention on the
lock and the contending function is capable of affecting the status
register. Could we get away with just the single check of the register
with the lock taken?
* although I don't know what percentage of hardware supports this cap,
so maybe most devices will never run this code
>
> spin_lock(&bp->lock);
>
> + status = queue_readl(queue, ISR);
> + if (unlikely(!status)) {
> + spin_unlock(&bp->lock);
> + return IRQ_NONE;
> + }
> +
> while (status) {
> /* close possible race with dev_close */
> if (unlikely(!netif_running(netdev))) {
>
> --
> 2.55.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net v2 1/2] octeon_ep: fix skb frags overflow in the RX path
From: Maciej Fijalkowski @ 2026-07-03 12:01 UTC (permalink / raw)
To: Maoyi Xie
Cc: Veerasenareddy Burru, Sathesh Edara, Andrew Lunn,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
netdev, linux-kernel
In-Reply-To: <20260702180518.2013324-2-maoyixie.tju@gmail.com>
On Fri, Jul 03, 2026 at 02:05:17AM +0800, Maoyi Xie wrote:
> __octep_oq_process_rx() builds an skb for a multi-buffer packet by adding
> one fragment per buffer_size chunk:
>
> data_len = buff_info->len - oq->max_single_buffer_size;
> while (data_len) {
> ...
> skb_add_rx_frag(skb, shinfo->nr_frags, buff_info->page, 0,
> buff_info->len, buff_info->len);
> ...
> }
>
> buff_info->len comes from the device response header
> (be64_to_cpu(resp_hw->length)). Nothing bounds the fragment count against
> MAX_SKB_FRAGS. data_len can be close to 65535. buffer_size defaults to
> about 3776 on 4K pages, so a full packet yields about 18 fragments. That
> is one more than the default MAX_SKB_FRAGS of 17, so skb_add_rx_frag()
> writes past shinfo->frags[].
>
> The fragment count is now checked before build_skb(). A packet that needs
> more fragments than the skb can hold is dropped. octep_oq_drop_rx()
> consumes its descriptors like the build_skb failure path. The same class
> was fixed in other RX paths, including commit 5ffcb7b890f6 ("net: atlantic:
> fix fragment overflow handling in RX path") and commit f0813bcd2d9d ("net:
> wwan: t7xx: fix potential skb->frags overflow in RX path").
>
> Fixes: 37d79d059606 ("octeon_ep: add Tx/Rx processing and interrupt support")
> Co-developed-by: Kaixuan Li <kaixuan.li@ntu.edu.sg>
> Signed-off-by: Kaixuan Li <kaixuan.li@ntu.edu.sg>
> Signed-off-by: Maoyi Xie <maoyixie.tju@gmail.com>
Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
> ---
> drivers/net/ethernet/marvell/octeon_ep/octep_rx.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/net/ethernet/marvell/octeon_ep/octep_rx.c b/drivers/net/ethernet/marvell/octeon_ep/octep_rx.c
> index e6ebc7e44a..bdbed58c7b 100644
> --- a/drivers/net/ethernet/marvell/octeon_ep/octep_rx.c
> +++ b/drivers/net/ethernet/marvell/octeon_ep/octep_rx.c
> @@ -453,6 +453,15 @@ static int __octep_oq_process_rx(struct octep_device *oct,
>
> octep_oq_next_pkt(oq, buff_info, &read_idx, &desc_used);
>
> + if (buff_info->len > oq->max_single_buffer_size) {
> + u16 data_len = buff_info->len - oq->max_single_buffer_size;
> +
> + if (DIV_ROUND_UP(data_len, oq->buffer_size) > MAX_SKB_FRAGS) {
> + octep_oq_drop_rx(oq, buff_info, &read_idx, &desc_used);
> + continue;
> + }
> + }
> +
> skb = build_skb((void *)resp_hw, PAGE_SIZE);
> if (!skb) {
> octep_oq_drop_rx(oq, buff_info,
> --
> 2.34.1
>
^ permalink raw reply
* Re: [REGRESSION][BISECTED] tun/tap & vhost-net: multi-threaded network performance
From: Michael S. Tsirkin @ 2026-07-03 11:55 UTC (permalink / raw)
To: Simon Schippers
Cc: Jakub Kicinski, Tim Gebauer, Willem de Bruijn, Jason Wang,
Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
linux-kernel, Brett Sheffield, regressions, netdev
In-Reply-To: <a1bae349-61a1-4c65-a531-179850576642@tu-dortmund.de>
On Fri, Jul 03, 2026 at 12:41:19PM +0200, Simon Schippers wrote:
> On 7/1/26 21:16, Brett Sheffield wrote:
> > TL;DR - Commit 1d6e569b7d0c0b2736636749e4be0a27f3cefcb3 causes
> > significant performance regressions with TAP interfaces and multithreaded
> > network code. Please revert.
>
> Micheal, I am convinced that netdev_tx_stop_queue() and
> netdev_tx_wake_queue() are too slow. The communication between the CPUs
> is just too slow. We already spent *a lot* of time speeding it up, the
> patchset was only merged at v12...
>
> Yes, I would *love* to have qdisc backpressure on by default but I do
> not see how anything could speed it up.
>
>
> *Is there any issue if we introduce IFF_BACKPRESSURE?*
> I implemented it and it is a simple patch that only executes the
> stopping / waking if ((tun->flags & IFF_BACKPRESSURE)).
> I could submit that to [net] very soon.
>
> Thank you,
> Simon
Pls go ahead.
--
MST
^ permalink raw reply
* Re: [PATCH net-next v3 11/15] net: macb: change function signatures to take contexts
From: Conor Dooley @ 2026-07-03 11:45 UTC (permalink / raw)
To: Théo Lebrun
Cc: Conor Dooley, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Richard Cochran, Russell King,
netdev, linux-kernel, Nicolas Ferre, Claudiu Beznea,
Paolo Valerio, Nicolai Buchwitz, Vladimir Kondratiev,
Gregory CLEMENT, Benoît Monin, Tawfik Bayouk,
Thomas Petazzoni, Maxime Chevallier
In-Reply-To: <20260701-macb-context-v3-11-00268d5b1502@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 52 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v3 10/15] net: macb: change caps helpers signatures
From: Conor Dooley @ 2026-07-03 11:43 UTC (permalink / raw)
To: Théo Lebrun
Cc: Conor Dooley, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Richard Cochran, Russell King,
netdev, linux-kernel, Nicolas Ferre, Claudiu Beznea,
Paolo Valerio, Nicolai Buchwitz, Vladimir Kondratiev,
Gregory CLEMENT, Benoît Monin, Tawfik Bayouk,
Thomas Petazzoni, Maxime Chevallier
In-Reply-To: <20260701-macb-context-v3-10-00268d5b1502@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 52 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v3 07/15] net: macb: introduce macb_context struct for buffer management
From: Conor Dooley @ 2026-07-03 11:39 UTC (permalink / raw)
To: Théo Lebrun
Cc: Conor Dooley, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Richard Cochran, Russell King,
netdev, linux-kernel, Nicolas Ferre, Claudiu Beznea,
Paolo Valerio, Nicolai Buchwitz, Vladimir Kondratiev,
Gregory CLEMENT, Benoît Monin, Tawfik Bayouk,
Thomas Petazzoni, Maxime Chevallier
In-Reply-To: <20260701-macb-context-v3-7-00268d5b1502@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 52 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net v2] gtp: parse extension headers before reading inner protocol
From: Pablo Neira Ayuso @ 2026-07-03 11:38 UTC (permalink / raw)
To: Zhixing Chen
Cc: Harald Welte, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, osmocom-net-gprs, netdev
In-Reply-To: <20260703093708.18141-1-running910@gmail.com>
On Fri, Jul 03, 2026 at 05:37:08PM +0800, Zhixing Chen wrote:
> GTPv1-U packets may carry a chain of extension headers before the inner
> IP packet. The receive path already parses and skips these extension
> headers, but it currently reads the inner protocol before doing so.
>
> As a result, the first extension header byte is interpreted as the inner
> IP version. Packets with extension headers are then dropped before PDP
> lookup.
>
> Parse the extension header chain before calling gtp_inner_proto(), so the
> inner protocol is read from the actual inner IP header.
>
> Fixes: c75fc0b9e5be ("gtp: identify tunnel via GTP device + GTP version + TEID + family")
> Signed-off-by: Zhixing Chen <running910@gmail.com>
Reviewed-by: Pablo Neira Ayuso <pablo@netfilter.org>
^ permalink raw reply
* Re: [PATCH net-next v3 05/15] net: macb: enforce reverse christmas tree (RCT) convention
From: Conor Dooley @ 2026-07-03 11:35 UTC (permalink / raw)
To: Théo Lebrun
Cc: Conor Dooley, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Richard Cochran, Russell King,
netdev, linux-kernel, Nicolas Ferre, Claudiu Beznea,
Paolo Valerio, Nicolai Buchwitz, Vladimir Kondratiev,
Gregory CLEMENT, Benoît Monin, Tawfik Bayouk,
Thomas Petazzoni, Maxime Chevallier
In-Reply-To: <20260701-macb-context-v3-5-00268d5b1502@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 52 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v3 04/15] net: macb: unify queue index variable naming convention and types
From: Conor Dooley @ 2026-07-03 11:34 UTC (permalink / raw)
To: Théo Lebrun
Cc: Conor Dooley, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Richard Cochran, Russell King,
netdev, linux-kernel, Nicolas Ferre, Claudiu Beznea,
Paolo Valerio, Nicolai Buchwitz, Vladimir Kondratiev,
Gregory CLEMENT, Benoît Monin, Tawfik Bayouk,
Thomas Petazzoni, Maxime Chevallier
In-Reply-To: <20260701-macb-context-v3-4-00268d5b1502@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 5903 bytes --]
On Wed, Jul 01, 2026 at 05:59:07PM +0200, Théo Lebrun wrote:
> Variables are named q or queue_index. Types are int, unsigned int, u32
> and u16. Use `unsigned int q` everywhere.
>
> Skip over taprio functions. They use `u8 queue_id` which fits with the
> `struct macb_queue_enst_config` field. Using `queue_id` everywhere
> would be too verbose.
I'm not sure that I agree about the verbosity, and "q" isn't a letter I
would naturally associate with indexing, in the way ijk etc are. Perhaps
in netdev it is a natural choice however?
Conor.
>
> Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
> ---
> drivers/net/ethernet/cadence/macb_main.c | 32 ++++++++++++++++----------------
> 1 file changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
> index 86c0e9ccbfce..3b75797381b6 100644
> --- a/drivers/net/ethernet/cadence/macb_main.c
> +++ b/drivers/net/ethernet/cadence/macb_main.c
> @@ -877,7 +877,7 @@ static void gem_shuffle_tx_one_ring(struct macb_queue *queue)
> static void gem_shuffle_tx_rings(struct macb *bp)
> {
> struct macb_queue *queue;
> - int q;
> + unsigned int q;
>
> for (q = 0, queue = bp->queues; q < bp->num_queues; q++, queue++)
> gem_shuffle_tx_one_ring(queue);
> @@ -1258,7 +1258,7 @@ static void macb_tx_error_task(struct work_struct *work)
> tx_error_task);
> bool halt_timeout = false;
> struct macb *bp = queue->bp;
> - u32 queue_index;
> + unsigned int q;
> u32 packets = 0;
> u32 bytes = 0;
> struct macb_tx_skb *tx_skb;
> @@ -1267,9 +1267,9 @@ static void macb_tx_error_task(struct work_struct *work)
> unsigned int tail;
> unsigned long flags;
>
> - queue_index = queue - bp->queues;
> + q = queue - bp->queues;
> netdev_vdbg(bp->netdev, "macb_tx_error_task: q = %u, t = %u, h = %u\n",
> - queue_index, queue->tx_tail, queue->tx_head);
> + q, queue->tx_tail, queue->tx_head);
>
> /* Prevent the queue NAPI TX poll from running, as it calls
> * macb_tx_complete(), which in turn may call netif_wake_subqueue().
> @@ -1342,7 +1342,7 @@ static void macb_tx_error_task(struct work_struct *work)
> macb_tx_unmap(bp, tx_skb, 0);
> }
>
> - netdev_tx_completed_queue(netdev_get_tx_queue(bp->netdev, queue_index),
> + netdev_tx_completed_queue(netdev_get_tx_queue(bp->netdev, q),
> packets, bytes);
>
> /* Set end of TX queue */
> @@ -1407,7 +1407,7 @@ static bool ptp_one_step_sync(struct sk_buff *skb)
> static int macb_tx_complete(struct macb_queue *queue, int budget)
> {
> struct macb *bp = queue->bp;
> - u16 queue_index = queue - bp->queues;
> + unsigned int q = queue - bp->queues;
> unsigned long flags;
> unsigned int tail;
> unsigned int head;
> @@ -1469,14 +1469,14 @@ static int macb_tx_complete(struct macb_queue *queue, int budget)
> }
> }
>
> - netdev_tx_completed_queue(netdev_get_tx_queue(bp->netdev, queue_index),
> + netdev_tx_completed_queue(netdev_get_tx_queue(bp->netdev, q),
> packets, bytes);
>
> queue->tx_tail = tail;
> - if (__netif_subqueue_stopped(bp->netdev, queue_index) &&
> + if (__netif_subqueue_stopped(bp->netdev, q) &&
> CIRC_CNT(queue->tx_head, queue->tx_tail,
> bp->tx_ring_size) <= MACB_TX_WAKEUP_THRESH(bp))
> - netif_wake_subqueue(bp->netdev, queue_index);
> + netif_wake_subqueue(bp->netdev, q);
> spin_unlock_irqrestore(&queue->tx_ptr_lock, flags);
>
> if (packets)
> @@ -2470,10 +2470,10 @@ static int macb_pad_and_fcs(struct sk_buff **skb, struct net_device *netdev)
> static netdev_tx_t macb_start_xmit(struct sk_buff *skb,
> struct net_device *netdev)
> {
> - u16 queue_index = skb_get_queue_mapping(skb);
> struct macb *bp = netdev_priv(netdev);
> - struct macb_queue *queue = &bp->queues[queue_index];
> + unsigned int q = skb_get_queue_mapping(skb);
> unsigned int desc_cnt, nr_frags, frag_size, f;
> + struct macb_queue *queue = &bp->queues[q];
> unsigned int hdrlen;
> unsigned long flags;
> bool is_lso;
> @@ -2512,8 +2512,8 @@ static netdev_tx_t macb_start_xmit(struct sk_buff *skb,
>
> #if defined(DEBUG) && defined(VERBOSE_DEBUG)
> netdev_vdbg(bp->netdev,
> - "start_xmit: queue %hu len %u head %p data %p tail %p end %p\n",
> - queue_index, skb->len, skb->head, skb->data,
> + "start_xmit: queue %u len %u head %p data %p tail %p end %p\n",
> + q, skb->len, skb->head, skb->data,
> skb_tail_pointer(skb), skb_end_pointer(skb));
> print_hex_dump(KERN_DEBUG, "data: ", DUMP_PREFIX_OFFSET, 16, 1,
> skb->data, 16, true);
> @@ -2539,7 +2539,7 @@ static netdev_tx_t macb_start_xmit(struct sk_buff *skb,
> /* This is a hard error, log it. */
> if (CIRC_SPACE(queue->tx_head, queue->tx_tail,
> bp->tx_ring_size) < desc_cnt) {
> - netif_stop_subqueue(netdev, queue_index);
> + netif_stop_subqueue(netdev, q);
> netdev_dbg(netdev, "tx_head = %u, tx_tail = %u\n",
> queue->tx_head, queue->tx_tail);
> ret = NETDEV_TX_BUSY;
> @@ -2555,7 +2555,7 @@ static netdev_tx_t macb_start_xmit(struct sk_buff *skb,
> /* Make newly initialized descriptor visible to hardware */
> wmb();
> skb_tx_timestamp(skb);
> - netdev_tx_sent_queue(netdev_get_tx_queue(bp->netdev, queue_index),
> + netdev_tx_sent_queue(netdev_get_tx_queue(bp->netdev, q),
> skb->len);
>
> spin_lock(&bp->lock);
> @@ -2564,7 +2564,7 @@ static netdev_tx_t macb_start_xmit(struct sk_buff *skb,
> spin_unlock(&bp->lock);
>
> if (CIRC_SPACE(queue->tx_head, queue->tx_tail, bp->tx_ring_size) < 1)
> - netif_stop_subqueue(netdev, queue_index);
> + netif_stop_subqueue(netdev, q);
>
> unlock:
> spin_unlock_irqrestore(&queue->tx_ptr_lock, flags);
>
> --
> 2.55.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v3 03/15] net: macb: unify variable naming convention in at91ether functions
From: Conor Dooley @ 2026-07-03 11:30 UTC (permalink / raw)
To: Théo Lebrun
Cc: Conor Dooley, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Richard Cochran, Russell King,
netdev, linux-kernel, Nicolas Ferre, Claudiu Beznea,
Paolo Valerio, Nicolai Buchwitz, Vladimir Kondratiev,
Gregory CLEMENT, Benoît Monin, Tawfik Bayouk,
Thomas Petazzoni, Maxime Chevallier
In-Reply-To: <20260701-macb-context-v3-3-00268d5b1502@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 52 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v3 02/15] net: macb: unify device pointer naming convention
From: Conor Dooley @ 2026-07-03 11:29 UTC (permalink / raw)
To: Théo Lebrun
Cc: Conor Dooley, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Richard Cochran, Russell King,
netdev, linux-kernel, Nicolas Ferre, Claudiu Beznea,
Paolo Valerio, Nicolai Buchwitz, Vladimir Kondratiev,
Gregory CLEMENT, Benoît Monin, Tawfik Bayouk,
Thomas Petazzoni, Maxime Chevallier
In-Reply-To: <20260701-macb-context-v3-2-00268d5b1502@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 751 bytes --]
On Wed, Jul 01, 2026 at 05:59:05PM +0200, Théo Lebrun wrote:
> Here are all device pointer variable permutations inside MACB:
>
> struct device *dev;
> struct net_device *dev;
> struct net_device *ndev;
> struct net_device *netdev;
> struct pci_dev *pdev; // inside macb_pci.c
> struct phy_device *phy;
> struct phy_device *phydev;
> struct platform_device *pdev;
> struct platform_device *plat_dev; // inside macb_pci.c
>
> Unify to this convention:
>
> struct device *dev;
> struct net_device *netdev;
> struct pci_dev *pci;
> struct phy_device *phydev;
> struct platform_device *pdev;
Oh lovely, OCD approved.
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v3 01/15] net: macb: drop "consistent" from alloc/free function names
From: Conor Dooley @ 2026-07-03 11:28 UTC (permalink / raw)
To: Théo Lebrun
Cc: Conor Dooley, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Richard Cochran, Russell King,
netdev, linux-kernel, Nicolas Ferre, Claudiu Beznea,
Paolo Valerio, Nicolai Buchwitz, Vladimir Kondratiev,
Gregory CLEMENT, Benoît Monin, Tawfik Bayouk,
Thomas Petazzoni, Maxime Chevallier
In-Reply-To: <20260701-macb-context-v3-1-00268d5b1502@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 419 bytes --]
On Wed, Jul 01, 2026 at 05:59:04PM +0200, Théo Lebrun wrote:
> Since commit 4df95131ea80 ("net/macb: change RX path for GEM") those
> functions have not been only allocating or freeing consistent memory
> mappings.
>
> Rename from macb_alloc_consistent() to macb_alloc() and
> from macb_free_consistent() to macb_free().
What does "consistent" even mean? Is it intended to be analogous to
coherent?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ 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