* [PATCH 09/10] xfrm6: clear dst.dev on error to avoid double netdev_put in xfrm6_fill_dst()
From: Steffen Klassert @ 2026-07-10 9:03 UTC (permalink / raw)
To: David Miller, Jakub Kicinski; +Cc: Herbert Xu, Steffen Klassert, netdev
In-Reply-To: <20260710090349.343389-1-steffen.klassert@secunet.com>
From: "Xiang Mei (Microsoft)" <xmei5@asu.edu>
On the error path where in6_dev_get(dev) returns NULL, xfrm6_fill_dst()
releases the device reference with netdev_put() but leaves
xdst->u.dst.dev set. dst_destroy() later calls netdev_put(dst->dev)
again, so the same net_device reference is released twice, underflowing
its refcount (ref_tracker WARNING + "unregister_netdevice: waiting for
<dev> to become free").
Clear xdst->u.dst.dev after the netdev_put(), the same way the XFRM
device-offload paths xfrm_dev_state_add() and xfrm_dev_policy_add() in
net/xfrm/xfrm_device.c NULL ->dev when releasing the reference on error.
ref_tracker: reference already released.
ref_tracker: allocated in:
xfrm6_fill_dst (net/ipv6/xfrm6_policy.c:86)
...
udpv6_sendmsg (net/ipv6/udp.c:1696)
...
ref_tracker: freed in:
xfrm6_fill_dst (net/ipv6/xfrm6_policy.c:90)
...
WARNING: lib/ref_tracker.c:322 at ref_tracker_free+0x58b/0x780
dst_destroy (net/core/dst.c:115)
rcu_core
handle_softirqs
...
Fixes: 84c4a9dfbf43 ("xfrm6: release dev before returning error")
Reported-by: AutonomousCodeSecurity@microsoft.com
Signed-off-by: Xiang Mei (Microsoft) <xmei5@asu.edu>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/ipv6/xfrm6_policy.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv6/xfrm6_policy.c b/net/ipv6/xfrm6_policy.c
index 125ea9a5b8a0..3b749475f6ed 100644
--- a/net/ipv6/xfrm6_policy.c
+++ b/net/ipv6/xfrm6_policy.c
@@ -88,6 +88,7 @@ static int xfrm6_fill_dst(struct xfrm_dst *xdst, struct net_device *dev,
xdst->u.rt6.rt6i_idev = in6_dev_get(dev);
if (!xdst->u.rt6.rt6i_idev) {
netdev_put(dev, &xdst->u.dst.dev_tracker);
+ xdst->u.dst.dev = NULL;
return -ENODEV;
}
--
2.43.0
^ permalink raw reply related
* [PATCH net v1 1/3] bna: fix use-after-free on DMA mapping failure
From: xuanqiang.luo @ 2026-07-10 9:05 UTC (permalink / raw)
To: netdev
Cc: Xuanqiang Luo, Rasesh Mody, Sudarsana Kalluru, GR-Linux-NIC-Dev,
Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Ivan Vecera, linux-kernel, stable
In-Reply-To: <20260710090527.58354-1-xuanqiang.luo@linux.dev>
From: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
If dma_map_single() fails in bnad_start_xmit(), the skb is freed, but
head_unmap->skb was set before the mapping attempt and is not cleared. The
producer index is not advanced, so later transmissions normally overwrite
the entry.
However, if the interface is brought down first, bnad_txq_cleanup() scans
the entire unmap queue, finds the stale pointer, and calls
bnad_tx_buff_unmap() on it. That function dereferences the freed skb in
skb_headlen(). Its zero nvecs count is decremented to -1, causing its
while (nvecs) loop to repeatedly unmap entries around the TX ring and
potentially hang cleanup.
Set head_unmap->skb after the first DMA mapping succeeds. This prevents the
stale entry from reaching bnad_tx_buff_unmap().
Fixes: ba5ca7848be0 ("bna: check for dma mapping errors")
Cc: stable@vger.kernel.org
Assisted-by: Opencode:deepseek-v4-pro[1m]
Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
---
drivers/net/ethernet/brocade/bna/bnad.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/brocade/bna/bnad.c b/drivers/net/ethernet/brocade/bna/bnad.c
index 8e19add764db2..8b75004ba7c9d 100644
--- a/drivers/net/ethernet/brocade/bna/bnad.c
+++ b/drivers/net/ethernet/brocade/bna/bnad.c
@@ -3006,7 +3006,6 @@ bnad_start_xmit(struct sk_buff *skb, struct net_device *netdev)
txqent->hdr.wi.reserved = 0;
txqent->hdr.wi.num_vectors = vectors;
- head_unmap->skb = skb;
head_unmap->nvecs = 0;
/* Program the vectors */
@@ -3018,6 +3017,7 @@ bnad_start_xmit(struct sk_buff *skb, struct net_device *netdev)
BNAD_UPDATE_CTR(bnad, tx_skb_map_failed);
return NETDEV_TX_OK;
}
+ head_unmap->skb = skb;
BNA_SET_DMA_ADDR(dma_addr, &txqent->vector[0].host_addr);
txqent->vector[0].length = htons(len);
dma_unmap_addr_set(&unmap->vectors[0], dma_addr, dma_addr);
--
2.43.0
^ permalink raw reply related
* [PATCH net v1 0/3] net: fix stale TX skb pointers on DMA map failure
From: xuanqiang.luo @ 2026-07-10 9:05 UTC (permalink / raw)
To: netdev
Cc: Xuanqiang Luo, Rasesh Mody, Sudarsana Kalluru, GR-Linux-NIC-Dev,
Fan Gong, Xin Guo, Gur Stavi, Jijie Shao, Jian Shen, Andrew Lunn,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Ivan Vecera, linux-kernel
From: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
While I was backporting commit 1a303baa715e6 ("ice: fix double-free of
tx_buf skb"), an AI-assisted scan identified several suspected TX error
paths. I reviewed the results and found this issue in the three drivers
fixed here.
The drivers differ, but the bug is the same. On a DMA mapping failure, the
TX path frees an skb while its ring entry still points to it. A later
transmission normally overwrites the entry. If the interface is stopped
first, teardown can instead access or free the skb again.
I do not have these adapters, so I have not tested the drivers on hardware.
I checked the error and teardown paths by inspection. Still, these small
fixes seem worth posting for review. They are independent, but are sent as
one series because they address the same issue.
Xuanqiang Luo (3):
bna: fix use-after-free on DMA mapping failure
hinic3: fix use-after-free on DMA mapping failure
net: hibmcge: fix double-free of tx skb on DMA mapping failure
drivers/net/ethernet/brocade/bna/bnad.c | 2 +-
drivers/net/ethernet/hisilicon/hibmcge/hbg_txrx.c | 1 +
drivers/net/ethernet/huawei/hinic3/hinic3_tx.c | 5 +++--
3 files changed, 5 insertions(+), 3 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH net v1 2/3] hinic3: fix use-after-free on DMA mapping failure
From: xuanqiang.luo @ 2026-07-10 9:05 UTC (permalink / raw)
To: netdev
Cc: Xuanqiang Luo, Fan Gong, Xin Guo, Gur Stavi, Andrew Lunn,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
linux-kernel, stable
In-Reply-To: <20260710090527.58354-1-xuanqiang.luo@linux.dev>
From: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
If hinic3_tx_map_skb() fails in hinic3_send_one_skb(), the skb is freed,
but tx_info->skb was set before the mapping attempt and is not cleared. The
SQ producer index is rolled back, so later transmissions normally overwrite
the entry.
If the interface is brought down first, hinic3_free_txqs_res() calls
free_all_tx_skbs(). It scans the entire tx_info array and finds the stale
pointer. hinic3_tx_unmap_skb() then dereferences the freed skb in
skb_shinfo(), before it is freed again.
Set tx_info->skb and its WQEBB count only after DMA mapping succeeds,
preventing the stale pointer from reaching free_all_tx_skbs().
Fixes: 17fcb3dc12bb ("hinic3: module initialization and tx/rx logic")
Cc: stable@vger.kernel.org
Assisted-by: Opencode:deepseek-v4-pro[1m]
Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
---
drivers/net/ethernet/huawei/hinic3/hinic3_tx.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/huawei/hinic3/hinic3_tx.c b/drivers/net/ethernet/huawei/hinic3/hinic3_tx.c
index 9306bf0020caf..5739ecb08d0d3 100644
--- a/drivers/net/ethernet/huawei/hinic3/hinic3_tx.c
+++ b/drivers/net/ethernet/huawei/hinic3/hinic3_tx.c
@@ -578,8 +578,6 @@ static netdev_tx_t hinic3_send_one_skb(struct sk_buff *skb,
*wqe_combo.task = task;
tx_info = &txq->tx_info[pi];
- tx_info->skb = skb;
- tx_info->wqebb_cnt = wqebb_cnt;
err = hinic3_tx_map_skb(netdev, skb, txq, tx_info, &wqe_combo);
if (err) {
@@ -589,6 +587,9 @@ static netdev_tx_t hinic3_send_one_skb(struct sk_buff *skb,
goto err_drop_pkt;
}
+ tx_info->skb = skb;
+ tx_info->wqebb_cnt = wqebb_cnt;
+
netif_subqueue_sent(netdev, txq->sq->q_id, skb->len);
netif_subqueue_maybe_stop(netdev, txq->sq->q_id,
hinic3_wq_free_wqebbs(&txq->sq->wq),
--
2.43.0
^ permalink raw reply related
* [PATCH net v1 3/3] net: hibmcge: fix double-free of tx skb on DMA mapping failure
From: xuanqiang.luo @ 2026-07-10 9:05 UTC (permalink / raw)
To: netdev
Cc: Xuanqiang Luo, Jijie Shao, Jian Shen, Andrew Lunn,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
linux-kernel, stable
In-Reply-To: <20260710090527.58354-1-xuanqiang.luo@linux.dev>
From: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
If hbg_dma_map() fails, hbg_net_start_xmit() frees the skb, but buffer->skb
is left pointing to it. ring->ntu is not advanced, so the buffer is not
visible to the TX cleanup path.
A subsequent transmit normally overwrites the buffer. However, if the
interface is brought down first, hbg_ring_uninit() calls hbg_buffer_free().
It sees the stale pointer, attempts to unmap the failed mapping, and frees
the skb again.
Clear buffer->skb before freeing the skb in the error path, preventing
hbg_buffer_free() from treating it as an outstanding TX buffer.
Fixes: 40735e7543f9 ("net: hibmcge: Implement .ndo_start_xmit function")
Cc: stable@vger.kernel.org
Assisted-by: Opencode:deepseek-v4-pro[1m]
Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
---
drivers/net/ethernet/hisilicon/hibmcge/hbg_txrx.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/hisilicon/hibmcge/hbg_txrx.c b/drivers/net/ethernet/hisilicon/hibmcge/hbg_txrx.c
index 0ae3149946769..4382af937e2e7 100644
--- a/drivers/net/ethernet/hisilicon/hibmcge/hbg_txrx.c
+++ b/drivers/net/ethernet/hisilicon/hibmcge/hbg_txrx.c
@@ -155,6 +155,7 @@ netdev_tx_t hbg_net_start_xmit(struct sk_buff *skb, struct net_device *netdev)
buffer->skb = skb;
buffer->skb_len = skb->len;
if (unlikely(hbg_dma_map(buffer))) {
+ buffer->skb = NULL;
dev_kfree_skb_any(skb);
return NETDEV_TX_OK;
}
--
2.43.0
^ permalink raw reply related
* Re: Please backport bridge multicast exponential field encoding fix series to 6.1.y/6.6.y/6.12.y/6.18.y/7.0.y
From: Ujjal Roy @ 2026-07-10 9:10 UTC (permalink / raw)
To: Andrew Lunn
Cc: Greg KH, Linux Stable, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Nikolay Aleksandrov,
Ido Schimmel, David Ahern, Shuah Khan, Andy Roulin, Yong Wang,
Petr Machata, Ujjal Roy, bridge, netdev, linux-kernel,
linux-kselftest
In-Reply-To: <14350a31-ffc7-41fd-84d3-6cfb2cb96841@lunn.ch>
On Fri, Jul 10, 2026 at 1:31 AM Andrew Lunn <andrew@lunn.ch> wrote:
>
> > > > History: The multicast stack currently supports decoding of IGMPv3 and
> > > > MLDv2 exponential timer field encodings, but lacks the corresponding
> > > > encoding logic when generating multicast query packets.
>
> RFC 3376 says:
>
> 4.1.1. Max Resp Code
>
> The Max Resp Code field specifies the maximum time allowed before
> sending a responding report. The actual time allowed, called the Max
> Resp Time, is represented in units of 1/10 second and is derived from
> the Max Resp Code as follows:
Here I can give you some input. Default value is 10 seconds for which
the protocol value sent on the wire will be 100. This means 100 *
(1/10 second) = 10s. Similarly, setting just 14 seconds will cause
issues. The protocol value transmitted on the wire is 140, which, when
decoded as a linear value, results in 224. Similarly, values greater
than 25.5 seconds cannot be represented directly in the 8-bit field.
>
> Let me check i understand the issue. If the user configures a value >
> 127, linux continues to use the linear encoding, but a peer decodes it
> as a floating value.
Yes, you are right and that is what it does till now. And the Kernel
applies same to the QQIC field as well.
>
> 128 linear is 0 | 0x10) << (0 + 3) = 0x40 = 64. So the peer sends the
> reports earlier than required?
No, it is not 64. This becomes (0x10 << 3) = 0x80 = 128 again.
>
> 255 linear is (0xf | 0x10) << (7 + 3) = 0x1F0000 = 2031616. So the
> peer can send the reports much later than the 255 1/10 of a second
> than userspace expected.
Yes, you are right. But the calculation is incorrect; it becomes
0x7C00, which is 31744.
>
> What is useful here is, 'maximum time allowed'. The RFC does not
> appear to say how to pick a value between 0 and the maximum time
> allowed. Which gives us some flexibility.
Yes. However, this can lead to excessively slow membership
convergence, increased leave latency, and in some scenarios may cause
multicast membership state to expire before reports are received.
>
> I think a much simpler fix for stable is to clamp the user space
> request for setting the max response time to 127. That seems like a
> one line patch.
In mainline I encoded the value according to the RFC. We can clamp to
127 in stables, if we are not willing to take the entire series. This
will force user to use value < 128. Also, please consider QQIC; a
similar encoding issue persists.
>
> Andrew
>
On Fri, Jul 10, 2026 at 1:31 AM Andrew Lunn <andrew@lunn.ch> wrote:
>
> > > > History: The multicast stack currently supports decoding of IGMPv3 and
> > > > MLDv2 exponential timer field encodings, but lacks the corresponding
> > > > encoding logic when generating multicast query packets.
>
> RFC 3376 says:
>
> 4.1.1. Max Resp Code
>
> The Max Resp Code field specifies the maximum time allowed before
> sending a responding report. The actual time allowed, called the Max
> Resp Time, is represented in units of 1/10 second and is derived from
> the Max Resp Code as follows:
>
> If Max Resp Code < 128, Max Resp Time = Max Resp Code
>
> If Max Resp Code >= 128, Max Resp Code represents a floating-point
> value as follows:
>
> 0 1 2 3 4 5 6 7
> +-+-+-+-+-+-+-+-+
> |1| exp | mant |
> +-+-+-+-+-+-+-+-+
>
> Max Resp Time = (mant | 0x10) << (exp + 3)
>
> Small values of Max Resp Time allow IGMPv3 routers to tune the "leave
> latency" (the time between the moment the last host leaves a group
> and the moment the routing protocol is notified that there are no
> more members). Larger values, especially in the exponential range,
> allow tuning of the burstiness of IGMP traffic on a network.
>
> Let me check i understand the issue. If the user configures a value >
> 127, linux continues to use the linear encoding, but a peer decodes it
> as a floating value.
>
> 128 linear is 0 | 0x10) << (0 + 3) = 0x40 = 64. So the peer sends the
> reports earlier than required?
>
> 255 linear is (0xf | 0x10) << (7 + 3) = 0x1F0000 = 2031616. So the
> peer can send the reports much later than the 255 1/10 of a second
> than userspace expected.
>
> What is useful here is, 'maximum time allowed'. The RFC does not
> appear to say how to pick a value between 0 and the maximum time
> allowed. Which gives us some flexibility.
>
> I think a much simpler fix for stable is to clamp the user space
> request for setting the max response time to 127. That seems like a
> one line patch.
>
> Andrew
>
^ permalink raw reply
* Re: [PATCH v12 nf-next 3/7] netfilter: nf_flow_table_offload: Add nf_flow_rule_bridge()
From: Pablo Neira Ayuso @ 2026-07-10 9:26 UTC (permalink / raw)
To: Eric Woudstra
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Florian Westphal, Phil Sutter,
Nikolay Aleksandrov, Ido Schimmel, Kuniyuki Iwashima,
Stanislav Fomichev, Samiullah Khawaja, Hangbin Liu, Krishna Kumar,
Martin Karsten, netdev, netfilter-devel, bridge
In-Reply-To: <81c3bf65-b19b-4f80-aa8e-c0c4b3f5d6a7@gmail.com>
Hi Eric,
On Wed, Jul 08, 2026 at 08:36:11PM +0200, Eric Woudstra wrote:
> On 7/8/26 11:48 AM, Pablo Neira Ayuso wrote:
> > On Tue, Jul 07, 2026 at 11:10:41AM +0200, Eric Woudstra wrote:
> >> Add nf_flow_rule_bridge().
> >>
> >> It only calls the common rule and adds the redirect.
> >
> > I decided to use the new _unsupp() function, so we don't pretend
> > bridge hw offload is already supported. We will need a driver before
> > we can add this, this stub does not provide much. I guess your goal
> > was just to avoid a crash here.
>
> No, I am already using hw_offload between bridged interfaces
> on the mt7986 succesfully for almost 2 years.
> It works dsa-port to direct interface (lan1 to eth1 on Bananapi R3) and
> between direct interfaces (eth0 to eth1 on Bananapi-R3-mini)
Do you utilize the existing mt7986 driver in-tree without changes to
achive this hardware offload? Or you have still have out-of-tree
patches that need to be merged to achive this?
> It can also be tested with my bridge_fastpath.sh selftest script.
> This script uses veth-device pairs to test the software fastpath.
> It can also use 2 real interfaces interconnected in a loop of copper,
> when chosen with commandline arguments. Then it tests software- and
> hardware-fastpath. It also tests many different scenarios.
>
> So this is why I've added it, as it is already functional. If a software
> fastpath is setup correctly, the hardware fastpath is also functional.
Thanks for explaining.
I am targetting at a minimal subset of the flowtable bridge support at
this stage. There is a need to make progress with the
nf_conntrack_bridge counterpart before the flowtable bridge can get
more features (namely, bridge vlan filtering support).
^ permalink raw reply
* RE: [PATCH net] net/af_iucv: fix NULL deref in afiucv_hs_callback_syn()
From: Jagielski, Jedrzej @ 2026-07-10 9:34 UTC (permalink / raw)
To: Hidayath Khan, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com
Cc: horms@kernel.org, linux-s390@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
wintera@linux.ibm.com, twinkler@linux.ibm.com,
heiko.carstens@de.ibm.com, gor@linux.ibm.com,
agordeev@linux.ibm.com, borntraeger@linux.ibm.com,
svens@linux.ibm.com
In-Reply-To: <20260709191732.124092-1-hidayath@linux.ibm.com>
From: Hidayath Khan <hidayath@linux.ibm.com>
Sent: Thursday, July 9, 2026 9:18 PM
>afiucv_hs_callback_syn() allocates the child socket with GFP_ATOMIC.
>If the allocation fails, nsk is NULL.
>
>The connection-refused path is entered when the listen state check
>fails, the accept backlog is full, or nsk is NULL. The code
>unconditionally calls iucv_sock_kill(nsk) in that path.
>
>iucv_sock_kill() does not accept a NULL socket pointer and immediately
>dereferences sk via sock_flag(sk, SOCK_ZAPPED). When nsk is NULL,
>calling iucv_sock_kill(nsk) results in a NULL pointer dereference.
>
>Only call iucv_sock_kill() when a child socket was successfully
>allocated.
>
>Fixes: 3881ac441f64 ("af_iucv: add HiperSockets transport")
>Cc: stable@vger.kernel.org
>Reviewed-by: Alexandra Winter <wintera@linux.ibm.com>
>Signed-off-by: Hidayath Khan <hidayath@linux.ibm.com>
>---
> net/iucv/af_iucv.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
>diff --git a/net/iucv/af_iucv.c b/net/iucv/af_iucv.c
>index fed240b453bd..f5b1ec44b6ae 100644
>--- a/net/iucv/af_iucv.c
>+++ b/net/iucv/af_iucv.c
>@@ -1872,7 +1872,8 @@ static int afiucv_hs_callback_syn(struct sock *sk, struct sk_buff *skb)
> afiucv_swap_src_dest(skb);
> trans_hdr->flags = AF_IUCV_FLAG_SYN | AF_IUCV_FLAG_FIN;
> err = dev_queue_xmit(skb);
>- iucv_sock_kill(nsk);
>+ if (nsk)
Hi Hidayath
why not to move this check into iucv_sock_kill()?
would prevent from potential similar issues in the future
>+ iucv_sock_kill(nsk);
> bh_unlock_sock(sk);
> goto out;
> }
>
>base-commit: 262b2eac463d880a664cf92af1107b4f9d84ad37
>--
>2.52.0
^ permalink raw reply
* Re: [PATCH net 4/4] rxrpc: Fix CHALLENGE packet overqueuing and simplify RESPONSE generation
From: Paolo Abeni @ 2026-07-10 9:39 UTC (permalink / raw)
To: David Howells, netdev
Cc: Marc Dionne, Jakub Kicinski, David S. Miller, Eric Dumazet,
Simon Horman, linux-afs, linux-kernel, Jeffrey Altman,
Jarkko Sakkinen, keyrings, stable
In-Reply-To: <20260702144919.172295-5-dhowells@redhat.com>
On 7/2/26 4:49 PM, David Howells wrote:
> Currently, when a CHALLENGE packet comes in, it's queued in an OOB queue on
> the AF_RXRPC socket that generated one of the calls on that connection for
> the application (which might be in userspace) to service. The application
> then picks up the CHALLENGE and requests a RESPONSE packet be generated,
> allowing the app to include app-specific data in it if appropriate. There
> is, however, no actual limit on the capacity of the CHALLENGE queue, and
> this could be abused remotely - and also getting the OOB mechanism right
> has proven tricky.
>
> Further, by analogy with other AFS codebases, it's not actually necessary
> to generate the application data in response to the CHALLENGE. The reason
> I did this was to set the encryption on the app-data to be the same as that
> specified in the CHALLENGE as the server must be able to handle that.
> However, it's sufficient to use the encoding type set in the token that is
> going to be sent to the server; presumably the kerberos server knows that
> the fileserver can handle that type - otherwise why tell the client to use
> it?
>
> With this in mind, make the following changes to the rxrpc server:
>
> (1) Remove the OOB queuing stuff and retire the related CMSG values and
> sockopt.
>
> (2) Revert to making the connection event processor work item parse the
> CHALLENGE and generate the RESPONSE directly.
>
> (3) Add another (optional) parameter that is passed in when an rxrpc
> client call is created and ends up attached to the connection bundle
> and is a user-type key containing the application data.
>
> (4) RESPONSE generation looks at the bundle and if the app-data is there,
> it will include it (if the security class is YFS-RxGK; RxKAD ignores
> it).
>
> (5) The AFS filesystem driver will create an app-data key when it probes a
> fileserver and will attach it to the afs_server struct. This is then
> picked up when a call is made to that server and passed to rxrpc.
>
> (6) Direct userspace users of AF_RXRPC can partake by creating a user-type
> key containing the app-data they want to use and passing its serial ID
> in a CMSG of type RXRPC_RESPONSE_APPDATA in the initial sendmsg() of a
> call.
>
> To support this, I've made a change outside of afs and rxrc:
>
> (7) Add a refcount to the user-type key payload. The problem is that the
> RESPONSE packet generator needs to look at the length of the app-data,
> allocate a buffer for the packet and then copy the app-data in - but
> the RCU read lock cannot be held across the allocation and the key
> might get updated. To get around this, a ref is taken on the payload
> before the allocation and then put afterwards.
>
> (8) Since the DNS resolver makes use of the user-defined type's code, but
> allocates the payload itself, make it initialise the refcount.
>
> Fixes: 5800b1cf3fd8 ("rxrpc: Allow CHALLENGEs to the passed to the app for a RESPONSE")
> Link: https://sashiko.dev/#/patchset/20260624163819.3017002-1-dhowells%40redhat.com
> Signed-off-by: David Howells <dhowells@redhat.com>
> cc: Marc Dionne <marc.dionne@auristor.com>
> cc: Jeffrey Altman <jaltman@auristor.com>
> cc: Eric Dumazet <edumazet@google.com>
> cc: "David S. Miller" <davem@davemloft.net>
> cc: Jakub Kicinski <kuba@kernel.org>
> cc: Paolo Abeni <pabeni@redhat.com>
> cc: Simon Horman <horms@kernel.org>
> cc: Jarkko Sakkinen <jarkko@kernel.org>
> cc: linux-afs@lists.infradead.org
> cc: keyrings@vger.kernel.org
> cc: stable@kernel.org
> ---
> fs/afs/cm_security.c | 151 ++++++--------
> fs/afs/fs_probe.c | 5 +
> fs/afs/internal.h | 37 ++--
> fs/afs/main.c | 1 -
> fs/afs/rxrpc.c | 39 ++--
> fs/afs/server.c | 2 +-
> include/keys/user-type.h | 2 +
> include/net/af_rxrpc.h | 20 +-
> include/trace/events/afs.h | 1 +
> include/trace/events/rxrpc.h | 2 -
> include/uapi/linux/rxrpc.h | 6 +-
> net/dns_resolver/dns_key.c | 1 +
> net/rxrpc/Makefile | 1 -
> net/rxrpc/af_rxrpc.c | 49 +----
> net/rxrpc/ar-internal.h | 22 +-
> net/rxrpc/call_object.c | 4 +-
> net/rxrpc/conn_client.c | 2 +
> net/rxrpc/conn_event.c | 68 +-----
> net/rxrpc/key.c | 36 ++++
> net/rxrpc/oob.c | 387 -----------------------------------
> net/rxrpc/recvmsg.c | 84 +-------
> net/rxrpc/rxgk.c | 128 +++---------
> net/rxrpc/rxkad.c | 27 ---
> net/rxrpc/sendmsg.c | 15 ++
> net/rxrpc/server_key.c | 40 ----
> security/keys/user_defined.c | 23 ++-
> 26 files changed, 238 insertions(+), 915 deletions(-)
> delete mode 100644 net/rxrpc/oob.c
This is quite big and difficult to review, could you please someout
break it in smaller chunk?
/P
^ permalink raw reply
* Re: [PATCH net] net: dpaa: always set a valid mode I/F mode
From: Michael Walle @ 2026-07-10 9:39 UTC (permalink / raw)
To: Sean Anderson, Madalin Bucur, Andrew Lunn, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni
Cc: netdev, linux-kernel
In-Reply-To: <cbfa2b2b-0ae8-9c96-f177-b503239edbd0@linux.dev>
Hi,
On Fri Jul 10, 2026 at 1:45 AM CEST, Sean Anderson wrote:
> On 7/6/26 08:08, Michael Walle wrote:
>> Before converting to the phylink interface, the init function would have
>> set the correct mode in the maccfg2.
>
> So for reference, the old logic is
>
> if (iface_speed < SPEED_1000)
> tmp |= MACCFG2_NIBBLE_MODE;
> else if (iface_speed == SPEED_1000)
> tmp |= MACCFG2_BYTE_MODE;
>
> which changes between nibble/byte mode depending on the max link speed
> (e.g. phylink_interface_max_speed). Notably, neither is set for 2.5G.
Ahh you're right, I totally missed, that the speed parameter was
actually max_speed, which was set by
priv->speed = phy2speed[macdev->phy_if];
priv->max_speed = priv->speed;
FWIW, in the DPAA RM I have, there is no 2.5G speed. Are you sure,
there are DTSEC controllers with 2.5Gbps support? The only board I
found in the device trees is the T1023RDB which is using the memac.
> Can you try moving this write to dtsec_mac_config?
That worked! At least for SGMII. I don't have a board with another
interface to test tough. I'll prepare a new version, making
phylink_interface_max_speed() public and setting the correct value
in .mac_config(). Alternatively, we could move
phylink_interface_max_speed() to the header as static inline, but
that function isn't that small.
> And check in the RM
> whether this is configured based on the interface (in which case we should
> remove it from dtsec_link_up) or the link speed. And please also check what
> the correct behavior for 2.5G should be.
This is an excerpt from the RM:
I/F Mode (bits 22-23):
This field determines the type of interface to which the MAC is
connected. Its default is 00.
00 Reserved
01 Used for all 10Mbps and 100Mbps speeds
10 Used for all 1Gbps speeds
11 Reserved
So you could read it both ways? But since the older driver was using
the maximum interface speed..
> At one point I had the P-series RMs downloaded, but it appears I've misplaced
> them...
FWIW, I think it's freely available as long as you're logged in with
your NXP account.
-michael
>
> --Sean
>
>> After converting, init will just
>> set 0 as the mode. According to the "QorIQ Data Path Acceleration
>> Architecture (DPAA) Reference Manual", this is a reserved value. In
>> fact, this will prevent the PCS to establish a link to a connected SGMII
>> PHY. In turn, mac_link_up() is never called. Fix it by setting a
>> non-reserved mode; mac_link_up() will then set the correct mode later.
>>
>> Fixes: 5d93cfcf7360 ("net: dpaa: Convert to phylink")
>> Signed-off-by: Michael Walle <mwalle@kernel.org>
>> ---
>> FWIW, I've tested this with a Marvell 88E1112 PHY.
>>
>> drivers/net/ethernet/freescale/fman/fman_dtsec.c | 5 ++++-
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/ethernet/freescale/fman/fman_dtsec.c b/drivers/net/ethernet/freescale/fman/fman_dtsec.c
>> index fe35703c509e..566921d3a884 100644
>> --- a/drivers/net/ethernet/freescale/fman/fman_dtsec.c
>> +++ b/drivers/net/ethernet/freescale/fman/fman_dtsec.c
>> @@ -402,7 +402,10 @@ static int init(struct dtsec_regs __iomem *regs, struct dtsec_cfg *cfg,
>> tmp |= MACCFG1_TX_FLOW;
>> iowrite32be(tmp, ®s->maccfg1);
>>
>> - tmp = 0;
>> + /* write a non-reserved mode, otherwise the PCS won't establish a link
>> + * and .mac_link_up() is never called.
>> + */
>> + tmp = MACCFG2_NIBBLE_MODE;
>>
>> tmp |= (cfg->preamble_len << MACCFG2_PREAMBLE_LENGTH_SHIFT) &
>> MACCFG2_PREAMBLE_LENGTH_MASK;
^ permalink raw reply
* Re: [PATCH] net: qed: Fix spelling typo in qed_dcbx.c comment
From: patchwork-bot+netdevbpf @ 2026-07-10 9:40 UTC (permalink / raw)
To: Praveen Rajendran
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, netdev,
linux-kernel
In-Reply-To: <20260703143130.3685-1-praveenrajendran2009@gmail.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Fri, 3 Jul 2026 20:01:30 +0530 you wrote:
> Correct a minor spelling error inside a comment block of the QLogic
> Core module where "successfully" was misspelled as "successfuly".
>
> Signed-off-by: Praveen Rajendran <praveenrajendran2009@gmail.com>
> ---
> drivers/net/ethernet/qlogic/qed/qed_dcbx.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Here is the summary with links:
- net: qed: Fix spelling typo in qed_dcbx.c comment
https://git.kernel.org/netdev/net-next/c/832255a6df49
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] vmxnet3: fix BUG_ON in vmxnet3_get_hdr_len() for Geneve packets
From: Jagielski, Jedrzej @ 2026-07-10 9:44 UTC (permalink / raw)
To: Harshaka Narayana, davem@davemloft.net, kuba@kernel.org,
pabeni@redhat.com, netdev@vger.kernel.org
Cc: ronak.doshi@broadcom.com, bcm-kernel-feedback-list@broadcom.com,
andrew+netdev@lunn.ch, edumazet@google.com,
linux-kernel@vger.kernel.org, guolin.yang@broadcom.com,
Sankararaman Jayaraman
In-Reply-To: <20260709181146.3260540-1-harshaka.narayana@broadcom.com>
From: Harshaka Narayana <harshaka.narayana@broadcom.com>
Sent: Thursday, July 9, 2026 8:12 PM
>vmxnet3_get_hdr_len() assumes gdesc->rcd.v4/v6/tcp always describe the
>outer header, but for a Geneve-encapsulated packet the device can set
>them based on the inner header instead, signalled by the
>VMXNET3_RCD_HDR_INNER_SHIFT bit in the completion descriptor. Since the
>function never skips the outer encapsulation, this mismatch triggers:
>
>- BUG_ON(hdr.ipv4->protocol != IPPROTO_TCP), because the outer
> protocol is UDP (Geneve), not TCP.
>- BUG_ON(hdr.eth->h_proto != ...), when the tunnel's outer and inner
> IP versions differ (e.g. outer IPv6/inner IPv4 or vice versa).
>
>Check VMXNET3_RCD_HDR_INNER_SHIFT up front and bail out, since the
>function cannot locate the inner header it would need to parse. Also
>convert the remaining BUG_ON()s in this function to return 0
>defensively.
>
>Fixes: 45dac1d6ea04 ("vmxnet3: Changes for vmxnet3 adapter version 2 (fwd)")
>Signed-off-by: Harshaka Narayana <harshaka.narayana@broadcom.com>
>Signed-off-by: Ronak Doshi <ronak.doshi@broadcom.com>
>Signed-off-by: Sankararaman Jayaraman <sankararaman.jayaraman@broadcom.com>
Hi Harshaka
you signed-off-by tag should be the last one as you're the sender
also unclear what was the roles of other people mentioned here - if
they are co-developers please add appropriate tags
>---
> drivers/net/vmxnet3/vmxnet3_drv.c | 24 ++++++++++++++++++------
> 1 file changed, 18 insertions(+), 6 deletions(-)
>
>diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c b/drivers/net/vmxnet3/vmxnet3_drv.c
>index 40522afc0532..dedf4082eb6c 100644
>--- a/drivers/net/vmxnet3/vmxnet3_drv.c
>+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
>@@ -1530,7 +1530,13 @@ vmxnet3_get_hdr_len(struct vmxnet3_adapter *adapter, struct sk_buff *skb,
> struct ipv6hdr *ipv6;
> struct tcphdr *tcp;
> } hdr;
>- BUG_ON(gdesc->rcd.tcp == 0);
>+
>+ /* v4/v6/tcp then describe the inner header, which we can't locate. */
>+ if (le32_to_cpu(gdesc->dword[0]) & (1UL << VMXNET3_RCD_HDR_INNER_SHIFT))
>+ return 0;
>+
>+ if (gdesc->rcd.tcp == 0)
>+ return 0;
nit: as both above return 0 they can be combined i believe
>
> maplen = skb_headlen(skb);
> if (unlikely(sizeof(struct iphdr) + sizeof(struct tcphdr) > maplen))
>@@ -1544,15 +1550,21 @@ vmxnet3_get_hdr_len(struct vmxnet3_adapter *adapter, struct sk_buff *skb,
>
> hdr.eth = eth_hdr(skb);
> if (gdesc->rcd.v4) {
>- BUG_ON(hdr.eth->h_proto != htons(ETH_P_IP) &&
>- hdr.veth->h_vlan_encapsulated_proto != htons(ETH_P_IP));
>+ if (hdr.eth->h_proto != htons(ETH_P_IP) &&
>+ hdr.veth->h_vlan_encapsulated_proto != htons(ETH_P_IP))
>+ return 0;
>+
> hdr.ptr += hlen;
>- BUG_ON(hdr.ipv4->protocol != IPPROTO_TCP);
>+ if (hdr.ipv4->protocol != IPPROTO_TCP)
>+ return 0;
>+
> hlen = hdr.ipv4->ihl << 2;
> hdr.ptr += hdr.ipv4->ihl << 2;
> } else if (gdesc->rcd.v6) {
>- BUG_ON(hdr.eth->h_proto != htons(ETH_P_IPV6) &&
>- hdr.veth->h_vlan_encapsulated_proto != htons(ETH_P_IPV6));
>+ if (hdr.eth->h_proto != htons(ETH_P_IPV6) &&
>+ hdr.veth->h_vlan_encapsulated_proto != htons(ETH_P_IPV6))
>+ return 0;
>+
> hdr.ptr += hlen;
> /* Use an estimated value, since we also need to handle
> * TSO case.
>--
>2.52.0
^ permalink raw reply
* Re: [PATCH net-next v2 0/8] netconsole: stop charging netpoll users for netconsole-only data
From: Breno Leitao @ 2026-07-10 9:46 UTC (permalink / raw)
To: Paolo Abeni
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Simon Horman,
Andrew Lunn, netdev, asantostc, gustavold, linux-kernel,
kernel-team
In-Reply-To: <1bfad1f6-6947-47a4-9dc0-72b4c16fc395@redhat.com>
On Thu, Jul 09, 2026 at 12:20:24PM +0200, Paolo Abeni wrote:
> > @@ -335,17 +340,15 @@ static void refill_skbs_work_handler(struct work_struct *work)
> > static void netconsole_skb_pool_init(struct netconsole_target *nt)
> > {
> > - skb_queue_head_init(&nt->np.skb_pool);
> > - INIT_WORK(&nt->np.refill_wq, refill_skbs_work_handler);
> > - refill_skbs(&nt->np);
> > + skb_queue_head_init(&nt->skb_pool);
> > + INIT_WORK(&nt->refill_wq, refill_skbs_work_handler);
> > + refill_skbs(nt);
> > }
> Can this race with target teardown?
> If a network device linked to a deactivated target is unregistered, it queues
> the target on target_cleanup_list and schedules
> netconsole_process_cleanups_core(), which executes netconsole_skb_pool_flush()
> under rtnl_lock.
Let me think about it.
Sashiko said:
> Can this race with target teardown?
> If a network device linked to a deactivated target is unregistered, it
> queues the target on target_cleanup_list and schedules
> netconsole_process_cleanups_core(), which executes
> netconsole_skb_pool_flush() under rtnl_lock.
Correct. This is the summary of the code:
static void netconsole_process_cleanups_core(void) {
ASSERT_RTNL();
mutex_lock(&target_cleanup_list_lock);
list_for_each_entry_safe(nt, tmp, &target_cleanup_list, list) {
netconsole_skb_pool_flush(nt);
..
}
> Concurrently, if a user enables the target via configfs
> enabled_store(), netconsole_skb_pool_init() is called.
Correct. The code is:
static ssize_t enabled_store(struct config_item *item,
dynamic_netconsole_mutex_lock();
netconsole_skb_pool_init(nt);
...
}
> Because this initialization happens before acquiring rtnl_lock inside
> netpoll_setup(), enabled_store() can execute INIT_WORK() and
> skb_queue_head_init() simultaneously with the cleanup thread executing
> cancel_work_sync() and skb_queue_purge_reason() on the exact same
> fields.
So, it seems they can execute in parallel, given that the device might
be in the cleanup list, and, configfs might be toggling it up.
I don't think this is a big issue, given worst case scenario, the pool
will not be populated, but this seems a clear regression.
> Does this initialization need to be moved inside the rtnl_lock
> protected region to avoid data corruption?
This refactor genuinely did move the pool init out of netpoll_setup()'s
RTNL coverage — before the series, __netpoll_setup() did the
skb_queue_head_init/INIT_WORK under RTNL, giving blanket mutual
exclusion with the notifier.
I don't think I want to have the initialization under RTNL, given this
is a heavy lift. At the same time, I don't have a clear view on how to
solve it. Maybe getting the target_cleanup_list_lock() at skb pool
initializion (which seems ugly as hell).
Anyway, let me spend some tokens on it, and see if I can figure out
a better plan.
Thanks for raising this up,
--breno
--
pw-bot: cr
^ permalink raw reply
* RE: [PATCH net v2] vmxnet3: fix BUG_ON in vmxnet3_get_hdr_len() for Geneve packets
From: Jagielski, Jedrzej @ 2026-07-10 9:46 UTC (permalink / raw)
To: Harshaka Narayana
Cc: andrew+netdev@lunn.ch, bcm-kernel-feedback-list@broadcom.com,
davem@davemloft.net, edumazet@google.com,
guolin.yang@broadcom.com, kuba@kernel.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
pabeni@redhat.com, ronak.doshi@broadcom.com,
sankararaman.jayaraman@broadcom.com
In-Reply-To: <20260709194703.3678075-1-harshaka.narayana@broadcom.com>
From: Harshaka Narayana <harshaka.narayana@broadcom.com>
Sent: Thursday, July 9, 2026 9:47 PM
>vmxnet3_get_hdr_len() assumes gdesc->rcd.v4/v6/tcp always describe the
>outer header, but for a Geneve-encapsulated packet the device can set
>them based on the inner header instead, signalled by the
>VMXNET3_RCD_HDR_INNER_SHIFT bit in the completion descriptor. Since the
>function never skips the outer encapsulation, this mismatch triggers:
>
>- BUG_ON(hdr.ipv4->protocol != IPPROTO_TCP), because the outer
> protocol is UDP (Geneve), not TCP.
>- BUG_ON(hdr.eth->h_proto != ...), when the tunnel's outer and inner
> IP versions differ (e.g. outer IPv6/inner IPv4 or vice versa).
>
>Check VMXNET3_RCD_HDR_INNER_SHIFT up front and bail out, since the
>function cannot locate the inner header it would need to parse. Also
>convert the remaining BUG_ON()s in this function to return 0
>defensively.
>
>Fixes: 45dac1d6ea04 ("vmxnet3: Changes for vmxnet3 adapter version 2 (fwd)")
>Signed-off-by: Harshaka Narayana <harshaka.narayana@broadcom.com>
>Signed-off-by: Ronak Doshi <ronak.doshi@broadcom.com>
>Signed-off-by: Sankararaman Jayaraman <sankararaman.jayaraman@broadcom.com>
>---
>v2:
> - Check VMXNET3_RCD_HDR_INNER_SHIFT up front to catch the Geneve
> inner-header case directly, and convert the remaining
> BUG_ON(hdr.eth->h_proto != ...) checks to return 0
> - Reworded commit message to describe the root cause via
> VMXNET3_RCD_HDR_INNER_SHIFT
>v1: https://lore.kernel.org/netdev/20260707165248.1859188-1-harshaka.narayana@broadcom.com/
>---
now i see that i replayed on v1 but v2 is already there
when sending patches to netdev the rule is to wait at least
24h between submit ions - please be aware
^ permalink raw reply
* Re: [PATCH net-next] net: libwx: disable TX VLAN offload for packets with >2 VLAN tags
From: Przemek Kitszel @ 2026-07-10 9:49 UTC (permalink / raw)
To: Jiawen Wu
Cc: Duanqiang Wen, netdev, Mengyuan Lou, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
Jacob Keller, Kees Cook
In-Reply-To: <C1BF77C0E073A40C+20260710071831.210196-1-jiawenwu@trustnetic.com>
On 7/10/26 09:18, Jiawen Wu wrote:
> The current hardware does not support TX VLAN offload for packets with
> three or more VLAN tags. When such packets are transmitted with hardware
> VLAN offload enabled, the hardware may malfunction or produce corrupted
> frames.
>
> Add a check in wx_features_check() to parse the VLAN depth of the
> skb. If more than two VLAN tags are detected (including both the
> hardware tag and in-band tags), strip NETIF_F_HW_VLAN_CTAG_TX and
> NETIF_F_HW_VLAN_STAG_TX from the feature set. This forces the
> kernel networking stack to handle VLAN insertion in software for
> these specific packets, ensuring correct transmission.
>
> Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com>
> ---
> drivers/net/ethernet/wangxun/libwx/wx_lib.c | 25 +++++++++++++++++++++
> 1 file changed, 25 insertions(+)
>
> diff --git a/drivers/net/ethernet/wangxun/libwx/wx_lib.c b/drivers/net/ethernet/wangxun/libwx/wx_lib.c
> index 814d88d2aee4..65dab6bd8a39 100644
> --- a/drivers/net/ethernet/wangxun/libwx/wx_lib.c
> +++ b/drivers/net/ethernet/wangxun/libwx/wx_lib.c
> @@ -3223,12 +3223,37 @@ netdev_features_t wx_fix_features(struct net_device *netdev,
> EXPORT_SYMBOL(wx_fix_features);
>
> #define WX_MAX_TUNNEL_HDR_LEN 80
> +#define WX_VLAN_MAX_DEPTH 8
> netdev_features_t wx_features_check(struct sk_buff *skb,
> struct net_device *netdev,
> netdev_features_t features)
> {
> struct wx *wx = netdev_priv(netdev);
> + u16 parse_depth = WX_VLAN_MAX_DEPTH;
> + __be16 type = skb->protocol;
> + u16 vlan_depth = ETH_HLEN;
> + u32 vlan_num = 0;
>
> + if (!skb_vlan_tag_present(skb))
this if jumping over the loop with essentially the same condition
does not help much, I would just remove
> + goto tunnel_check;
> +
> + vlan_num++;
> + while (eth_type_vlan(type) && --parse_depth) {
> + struct vlan_hdr vhdr, *vh;
> +
> + vh = skb_header_pointer(skb, vlan_depth, sizeof(vhdr), &vhdr);
> + if (unlikely(!vh))
> + break;
> +
> + type = vh->h_vlan_encapsulated_proto;
> + vlan_depth += VLAN_HLEN;
> + vlan_num++;
parse depth of 8 does not make sense if you are detecting
"are the three first protocols a VLAN"
> + }
> +
> + if (vlan_num > 2)
> + features &= ~(NETIF_F_HW_VLAN_CTAG_TX |
> + NETIF_F_HW_VLAN_STAG_TX);
you could move this if condition inside a loop with an added "break"
> +tunnel_check:
> if (!skb->encapsulation)
> return features;
>
^ permalink raw reply
* Re: [PATCH net-next] nfc: digital: Do not dump a NULL response in command completion
From: Przemek Kitszel @ 2026-07-10 9:51 UTC (permalink / raw)
To: Linmao Li
Cc: Simon Horman, Mark Greer, netdev, oe-linux-nfc, linux-kernel,
David Heidelberg, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
In-Reply-To: <20260710061254.80975-1-lilinmao@kylinos.cn>
On 7/10/26 08:12, Linmao Li wrote:
> digital_wq_cmd_complete() dumps the response data whenever cmd->resp is
> not an error pointer. However, a driver can legitimately complete a
> command with no response skb at all.
>
> digital_tg_send_psl_res() is the only caller that passes timeout=0,
> meaning no response is expected once the command has been transmitted.
> On that path trf7970a completes the command with
>
> trf->rx_skb = ERR_PTR(0);
>
> which evaluates to NULL. IS_ERR(NULL) is false, so the NULL response
> passes the !IS_ERR() check and cmd->resp->data and cmd->resp->len are
> dereferenced whenever the debug print site is enabled. The driver
> guards its own dump with "trf->rx_skb && !IS_ERR(trf->rx_skb)"; the
> digital layer is missing the NULL half of that test.
>
> Use IS_ERR_OR_NULL() so that NULL responses are skipped as well. The
> callback on that path, digital_tg_send_psl_res_complete(), never
> dereferences resp and dev_kfree_skb() accepts NULL, so only the debug
> dump needs fixing.
>
> Fixes: 59ee2361c924 ("NFC Digital: Implement driver commands mechanism")
> Signed-off-by: Linmao Li <lilinmao@kylinos.cn>
Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
> ---
> A separate cleanup patch, "nfc: trf7970a: Use NULL when no response is
> expected", replaces that ERR_PTR(0) with a plain NULL. It does not
> change behaviour (ERR_PTR(0) is NULL), so this fix is needed either way;
> if that patch lands first, read "trf->rx_skb = NULL;" above.
>
> Link: https://patch.msgid.link/20260706075743.564658-1-lilinmao@kylinos.cn
>
> net/nfc/digital_core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/nfc/digital_core.c b/net/nfc/digital_core.c
> index 7cb1e6aaae90..18236221d898 100644
> --- a/net/nfc/digital_core.c
> +++ b/net/nfc/digital_core.c
> @@ -127,7 +127,7 @@ static void digital_wq_cmd_complete(struct work_struct *work)
>
> mutex_unlock(&ddev->cmd_lock);
>
> - if (!IS_ERR(cmd->resp))
> + if (!IS_ERR_OR_NULL(cmd->resp))
> print_hex_dump_debug("DIGITAL RX: ", DUMP_PREFIX_NONE, 16, 1,
> cmd->resp->data, cmd->resp->len, false);
>
^ permalink raw reply
* [syzbot ci] Re: macvlan: allow source mode devices along with passthru
From: syzbot ci @ 2026-07-10 9:56 UTC (permalink / raw)
To: andrew, davem, edumazet, horms, kuba, linux-kernel, netdev,
pabeni, t.martitz
Cc: syzbot, syzkaller-bugs
In-Reply-To: <20260709100512.1383421-1-t.martitz@fritz.com>
syzbot ci has tested the following series
[v2] macvlan: allow source mode devices along with passthru
https://lore.kernel.org/all/20260709100512.1383421-1-t.martitz@fritz.com
* [PATCH v2 1/1] macvlan: allow source mode devices along with passthru
and found the following issue:
general protection fault in macvlan_port_release_mac
Full report is available here:
https://ci.syzbot.org/series/2632619d-fb66-47ac-85a1-a781bbb0d57d
***
general protection fault in macvlan_port_release_mac
tree: net-next
URL: https://kernel.googlesource.com/pub/scm/linux/kernel/git/netdev/net-next.git
base: fe3e786ef4eb6e47d2901f568a27bd920477bbe9
arch: amd64
compiler: Debian clang version 22.1.6 (++20260514074242+fc4aad7b5db3-1~exp1~20260514074407.73), Debian LLD 22.1.6
config: https://ci.syzbot.org/builds/90f86060-ab12-43d6-a718-5d0f5eb5df09/config
syz repro: https://ci.syzbot.org/findings/d1f12788-51d7-4251-8fc9-6bfda6a1e20a/syz_repro
batman_adv: batadv0: Removing interface: batadv_slave_1
veth1_macvtap: left promiscuous mode
veth0_macvtap: left promiscuous mode
veth1_vlan: left promiscuous mode
veth0_vlan: left promiscuous mode
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000118: 0000 [#1] SMP KASAN PTI
KASAN: null-ptr-deref in range [0x00000000000008c0-0x00000000000008c7]
CPU: 0 UID: 0 PID: 12 Comm: kworker/u8:0 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
Workqueue: netns cleanup_net
RIP: 0010:macvlan_passthru drivers/net/macvlan.c:78 [inline]
RIP: 0010:macvlan_port_release_mac+0x138/0x490 drivers/net/macvlan.c:807
Code: 01 00 00 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 b9 30 ae fb 48 8b 1b 4c 8d b3 c0 08 00 00 4c 89 f0 48 c1 e8 03 <42> 0f b6 04 20 84 c0 0f 85 44 02 00 00 45 8b 36 44 89 f6 83 e6 01
RSP: 0018:ffffc90000117500 EFLAGS: 00010206
RAX: 0000000000000118 RBX: 0000000000000000 RCX: ffff888102e98000
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000
RBP: ffffc90000117630 R08: ffffffff9032faf7 R09: 1ffffffff2065f5e
R10: dffffc0000000000 R11: fffffbfff2065f5f R12: dffffc0000000000
R13: 1ffff92000022ea4 R14: 00000000000008c0 R15: ffff88816b068818
FS: 0000000000000000(0000) GS:ffff88818dc23000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fb0fefe8158 CR3: 0000000113c9a000 CR4: 00000000000006f0
Call Trace:
<TASK>
macvlan_port_destroy+0x2eb/0x310 drivers/net/macvlan.c:1343
unregister_netdevice_many_notify+0x1ad2/0x2150 net/core/dev.c:12464
unregister_netdevice_many net/core/dev.c:12506 [inline]
default_device_exit_batch+0x961/0x9e0 net/core/dev.c:13098
ops_exit_list net/core/net_namespace.c:205 [inline]
ops_undo_list+0x4b4/0x8d0 net/core/net_namespace.c:252
cleanup_net+0x572/0x810 net/core/net_namespace.c:702
process_one_work kernel/workqueue.c:3322 [inline]
process_scheduled_works+0xa8e/0x14e0 kernel/workqueue.c:3405
worker_thread+0xa47/0xfb0 kernel/workqueue.c:3486
kthread+0x388/0x470 kernel/kthread.c:436
ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:macvlan_passthru drivers/net/macvlan.c:78 [inline]
RIP: 0010:macvlan_port_release_mac+0x138/0x490 drivers/net/macvlan.c:807
Code: 01 00 00 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 b9 30 ae fb 48 8b 1b 4c 8d b3 c0 08 00 00 4c 89 f0 48 c1 e8 03 <42> 0f b6 04 20 84 c0 0f 85 44 02 00 00 45 8b 36 44 89 f6 83 e6 01
RSP: 0018:ffffc90000117500 EFLAGS: 00010206
RAX: 0000000000000118 RBX: 0000000000000000 RCX: ffff888102e98000
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000
RBP: ffffc90000117630 R08: ffffffff9032faf7 R09: 1ffffffff2065f5e
R10: dffffc0000000000 R11: fffffbfff2065f5f R12: dffffc0000000000
R13: 1ffff92000022ea4 R14: 00000000000008c0 R15: ffff88816b068818
FS: 0000000000000000(0000) GS:ffff88818dc23000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b33163fff CR3: 0000000175a06000 CR4: 00000000000006f0
----------------
Code disassembly (best guess):
0: 01 00 add %eax,(%rax)
2: 00 48 89 add %cl,-0x77(%rax)
5: d8 48 c1 fmuls -0x3f(%rax)
8: e8 03 42 80 3c call 0x3c804210
d: 20 00 and %al,(%rax)
f: 74 08 je 0x19
11: 48 89 df mov %rbx,%rdi
14: e8 b9 30 ae fb call 0xfbae30d2
19: 48 8b 1b mov (%rbx),%rbx
1c: 4c 8d b3 c0 08 00 00 lea 0x8c0(%rbx),%r14
23: 4c 89 f0 mov %r14,%rax
26: 48 c1 e8 03 shr $0x3,%rax
* 2a: 42 0f b6 04 20 movzbl (%rax,%r12,1),%eax <-- trapping instruction
2f: 84 c0 test %al,%al
31: 0f 85 44 02 00 00 jne 0x27b
37: 45 8b 36 mov (%r14),%r14d
3a: 44 89 f6 mov %r14d,%esi
3d: 83 e6 01 and $0x1,%esi
***
If these findings have caused you to resend the series or submit a
separate fix, please add the following tag to your commit message:
Tested-by: syzbot@syzkaller.appspotmail.com
---
This report is generated by a bot. It may contain errors.
syzbot ci engineers can be reached at syzkaller@googlegroups.com.
To test a patch for this bug, please reply with `#syz test`
(should be on a separate line).
The patch should be attached to the email.
Note: arguments like custom git repos and branches are not supported.
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH iwl-next v1 5/6] ixgbe: E610: add MAC address runtime refresh
From: Maciej Fijalkowski @ 2026-07-10 9:57 UTC (permalink / raw)
To: Jagielski, Jedrzej
Cc: Simon Horman, intel-wired-lan@lists.osuosl.org, Nguyen, Anthony L,
netdev@vger.kernel.org
In-Reply-To: <PH0PR11MB59029D8B78557F03143546D3F0FE2@PH0PR11MB5902.namprd11.prod.outlook.com>
On Thu, Jul 09, 2026 at 09:37:27AM +0000, Jagielski, Jedrzej wrote:
> From: Simon Horman <horms@kernel.org>
> Sent: Wednesday, July 8, 2026 7:02 PM
>
> >This is an AI-generated review of your patch. The human sending this
> >email has considered the AI review valid, or at least plausible.
> >Full review at: https://netdev-ai.bots.linux.dev/sashiko/
> >---
> >ixgbe: E610: add MAC address runtime refresh
> >
> >This change polls RAR0 each service-task cycle on E610 and updates
> >netdev->dev_addr, hw->mac.addr and mac_table[0].addr when firmware has
> >altered the MAC. A refresh is also invoked from ixgbe_reset() so the
> >address survives RAR0 clearing during init_hw().
[...]
> >[Medium]
> >Would it make sense to hoist the E610 gating out of
> >ixgbe_mac_addr_refresh() and skip the rtnl_lock()/rtnl_unlock()
> >entirely for non-E610 devices?
> >
> >The type check lives inside the helper:
> >
> > static void ixgbe_mac_addr_refresh(struct ixgbe_adapter *adapter)
> > {
> > ...
> > if (hw->mac.type != ixgbe_mac_e610)
> > return;
> > ...
> > }
> >
> >so 82598, 82599, X540 and X550 adapters (which comprise most of the
> >ixgbe device family) acquire the global rtnl_mutex every service-task
> >cycle only to return immediately. Something like:
> >
> > if (adapter->hw.mac.type == ixgbe_mac_e610) {
> > rtnl_lock();
> > ixgbe_mac_addr_refresh(adapter);
> > rtnl_unlock();
> > }
>
> Cannot introduce rtnl locking into ixgbe_mac_addr_refresh() as this
> can be already called within rtnl-locked path
i40e does a lot of dancing for cases like this. rtnl lock is handled via
boolean provided as function arg:
static void i40e_rebuild(struct i40e_pf *pf, bool reinit, bool lock_acquired)
...
/* Release the RTNL lock before we start resetting VFs */
if (!lock_acquired)
rtnl_unlock();
...
end_unlock:
if (!lock_acquired)
rtnl_unlock();
>
> >
> >would avoid the rtnl_mutex contention on non-E610 hardware.
> >
> >> ixgbe_reset_subtask(adapter);
> >> ixgbe_phy_interrupt_subtask(adapter);
> >> ixgbe_sfp_detection_subtask(adapter);
^ permalink raw reply
* Re: [PATCH] net/rps: consolidate RPS dispatch into netif_rps() helpers
From: Paolo Abeni @ 2026-07-10 9:59 UTC (permalink / raw)
To: Jemmy Wong, David S . Miller, Eric Dumazet, Jakub Kicinski,
netdev
Cc: Simon Horman, Andrew Lunn, Kuniyuki Iwashima, Stanislav Fomichev,
Samiullah Khawaja, Hangbin Liu, Krishna Kumar, linux-kernel
In-Reply-To: <20260702152830.39065-1-jemmywong512@gmail.com>
On 7/2/26 5:28 PM, Jemmy Wong wrote:
> From: "Jemmy Wong" <jemmywong512@gmail.com>
>
> The RPS steering logic in netif_rx_internal(), netif_receive_skb_internal()
> and netif_receive_skb_list_internal() was open-coded three times, each with
> its own #ifdef CONFIG_RPS block and manual rcu_read_lock()/unlock() pairs.
>
> Factor it into two helpers, netif_rps() for the single-skb path and
> netif_rps_list() for the list path, and switch the callers to
> guard(rcu)/scoped_guard(rcu).
Please be aware of:
https://elixir.bootlin.com/linux/v7.1.2/source/Documentation/process/maintainer-netdev.rst#L400
> @@ -5695,33 +5727,20 @@ EXPORT_SYMBOL_GPL(do_xdp_generic);
>
> static int netif_rx_internal(struct sk_buff *skb)
> {
> - int ret;
> + int ret = NET_RX_UNHANDLED;
> + unsigned int qtail;
>
> net_timestamp_check(READ_ONCE(net_hotdata.tstamp_prequeue), skb);
>
> trace_netif_rx(skb);
>
> -#ifdef CONFIG_RPS
> - if (static_branch_unlikely(&rps_needed)) {
> - struct rps_dev_flow voidflow, *rflow = &voidflow;
> - int cpu;
> -
> - rcu_read_lock();
> -
> - cpu = get_rps_cpu(skb->dev, skb, &rflow);
> - if (cpu < 0)
> - cpu = smp_processor_id();
> + scoped_guard(rcu)
> + ret = netif_rps(skb);
> + if (ret != NET_RX_UNHANDLED)
> + return ret;
This function is performance critical and RCU lock is not a no-op. I
*think* this will add an unneeded rcp barrier when RPS is compile
enabled and `static_branch_unlikely(&rps_needed)` evaluate to false.
At very least you should prove that the generated code is no worse than
the current one.
/P
^ permalink raw reply
* Re: [PATCH bpf-next v11 0/5] bpf: add icmp_send kfunc
From: patchwork-bot+netdevbpf @ 2026-07-10 10:00 UTC (permalink / raw)
To: Mahe Tardy
Cc: bpf, andrii, ast, daniel, john.fastabend, jordan, martin.lau,
yonghong.song, emil, netdev, edumazet, kuba, pabeni, davem, horms,
sdf.kernel
In-Reply-To: <20260709144900.245904-1-mahe.tardy@gmail.com>
Hello:
This series was applied to bpf/bpf-next.git (master)
by Daniel Borkmann <daniel@iogearbox.net>:
On Thu, 9 Jul 2026 14:48:55 +0000 you wrote:
> Hello,
>
> This is v11 of adding the icmp_send kfunc, as suggested during
> LSF/MM/BPF 2025[^1]. The goal is to allow cgroup_skb programs to
> actively reject east-west traffic, similarly to what is possible to do
> with netfilter reject target. Applications can receive early feedback
> that something went wrong during the TCP handshake.
>
> [...]
Here is the summary with links:
- [bpf-next,v11,1/5] bpf: add bpf_icmp_send kfunc
(no matching commit)
- [bpf-next,v11,2/5] selftests/bpf: add bpf_icmp_send kfunc cgroup_skb tests
https://git.kernel.org/bpf/bpf-next/c/39b337a3d995
- [bpf-next,v11,3/5] selftests/bpf: add bpf_icmp_send kfunc cgroup_skb IPv6 tests
(no matching commit)
- [bpf-next,v11,4/5] selftests/bpf: add bpf_icmp_send recursion test
(no matching commit)
- [bpf-next,v11,5/5] selftests/bpf: add bpf_icmp_send no route test
(no matching commit)
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [PATCH 1/1] net: dsa: yt921x: Fix external port detection
From: Chukun Pan @ 2026-07-10 10:00 UTC (permalink / raw)
To: David Yang
Cc: Andrew Lunn, Paolo Abeni, Jakub Kicinski, Eric Dumazet,
Vladimir Oltean, David S . Miller, linux-kernel, netdev,
Chukun Pan
The YT921x switch has two MAC ports: 8 and 9. Currently, the driver
only allows port 8 as an external port, while port 9 is not working:
yt921x mdio-bus:1d: Wrong mode 23 on port 9
yt921x mdio-bus:1d: Failed to config port 9: -22
Update the external port detection logic to enable the external PHY
connected to port 9.
Fixes: 186623f4aa72 ("net: dsa: yt921x: Add support for Motorcomm YT921x")
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
---
drivers/net/dsa/yt921x.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/dsa/yt921x.h b/drivers/net/dsa/yt921x.h
index 555046526669..5f3b99e189c4 100644
--- a/drivers/net/dsa/yt921x.h
+++ b/drivers/net/dsa/yt921x.h
@@ -854,7 +854,7 @@ enum yt921x_fdb_entry_status {
#define YT921X_PORT_NUM 11
#define yt921x_port_is_internal(port) ((port) < 8)
-#define yt921x_port_is_external(port) (8 <= (port) && (port) < 9)
+#define yt921x_port_is_external(port) ((port) == 8 || (port) == 9)
struct yt921x_mib {
u64 rx_broadcast;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH net-next v6 2/7] net: phy: phylink: add helper to modify pause
From: Maxime Chevallier @ 2026-07-10 10:05 UTC (permalink / raw)
To: javen, hkallweit1, nic_swsd, andrew+netdev, davem, edumazet, kuba,
pabeni, horms
Cc: netdev, linux-kernel, daniel, linux, enelsonmoore, daniel
In-Reply-To: <20260709100237.541-3-javen_xu@realsil.com.cn>
Hi,
On 7/9/26 12:02, javen wrote:
> From: Javen Xu <javen_xu@realsil.com.cn>
>
> For Realtek nics, when we enable jumbo, pause are not supported. So we
> must check the pause capabilities from ourself and lp.
>
> Signed-off-by: Javen Xu <javen_xu@realsil.com.cn>
> ---
> Changes in v5:
> - no changes, new file
>
> Changes in v6:
> - rename phylink_update_mac_pause_capabilities(), this function only
> changes mac pause capability
> - set asym pause and pause according to config->pause tx and rx
> - add phydev->lock when change pl->phydev->advertising
> ---
> drivers/net/phy/phylink.c | 87 +++++++++++++++++++++++++++++++++++++++
> include/linux/phylink.h | 2 +
> 2 files changed, 89 insertions(+)
>
> diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
> index 59dfe35afa54..9e9cd79301d6 100644
> --- a/drivers/net/phy/phylink.c
> +++ b/drivers/net/phy/phylink.c
> @@ -1828,6 +1828,93 @@ int phylink_set_fixed_link(struct phylink *pl,
> }
> EXPORT_SYMBOL_GPL(phylink_set_fixed_link);
>
> +/**
> + * phylink_update_mac_pause_capabilities() - Dynamically update MAC pause
> + * @pl: a pointer to a &struct phylink returned from phylink_create()
> + * @mac_pause: the new MAC pause capabilities mask
> + *
> + * This function allows a MAC driver to dynamically change its pause state,
> + * such as losing/gaining Pause frame support based on MTU size.
> + * It recalculates supported link modes and triggers renegotiation if needed.
> + */
> +void phylink_update_mac_pause_capabilities(struct phylink *pl, unsigned long mac_pause)
> +{
> + struct phylink_link_state *config = &pl->link_config;
> + unsigned long old_pause, caps_added, caps_removed;
> + bool pause_adv, asym_adv;
> +
> + ASSERT_RTNL();
> +
> + if (mac_pause & ~(MAC_SYM_PAUSE | MAC_ASYM_PAUSE)) {
> + phylink_err(pl, "Attempted to dynamically change non-pause MAC capabilities\n");
> + return;
> + }
> +
> + old_pause = pl->config->mac_capabilities & (MAC_SYM_PAUSE | MAC_ASYM_PAUSE);
> + caps_added = mac_pause & ~old_pause;
> + caps_removed = old_pause & ~mac_pause;
> +
> + if (!caps_added && !caps_removed)
> + return;
> +
> + mutex_lock(&pl->state_mutex);
> +
> + pl->config->mac_capabilities &= ~(MAC_SYM_PAUSE | MAC_ASYM_PAUSE);
> + pl->config->mac_capabilities |= mac_pause;
> +
> + if (caps_removed & MAC_SYM_PAUSE)
> + linkmode_clear_bit(ETHTOOL_LINK_MODE_Pause_BIT, pl->supported);
> + if (caps_removed & MAC_ASYM_PAUSE)
> + linkmode_clear_bit(ETHTOOL_LINK_MODE_Asym_Pause_BIT, pl->supported);
> +
> + linkmode_and(config->advertising, config->advertising, pl->supported);
> +
> + if (caps_added & MAC_SYM_PAUSE) {
> + linkmode_set_bit(ETHTOOL_LINK_MODE_Pause_BIT, pl->supported);
> + if (pl->phydev && !phylink_test(pl->phydev->supported, Pause))
> + linkmode_clear_bit(ETHTOOL_LINK_MODE_Pause_BIT, pl->supported);
Why look at what the PHY can do here ? You shouldn't need to.
> + }
> + if (caps_added & MAC_ASYM_PAUSE) {
> + linkmode_set_bit(ETHTOOL_LINK_MODE_Asym_Pause_BIT, pl->supported);
> + if (pl->phydev && !phylink_test(pl->phydev->supported, Asym_Pause))
> + linkmode_clear_bit(ETHTOOL_LINK_MODE_Asym_Pause_BIT, pl->supported);
> + }
> +
> + linkmode_and(config->advertising, config->advertising, pl->supported);
> +
> + if (config->pause & MLO_PAUSE_AN) {
> + if (phylink_test(pl->supported, Pause) &&
> + (config->pause & MLO_PAUSE_RX) && (config->pause & MLO_PAUSE_TX))
> + linkmode_set_bit(ETHTOOL_LINK_MODE_Pause_BIT, config->advertising);
This isn't correct, Pause is set if RX is set, regardless of the TX value
> +
> + if (phylink_test(pl->supported, Asym_Pause) &&
> + ((config->pause & MLO_PAUSE_RX) ^ (config->pause & MLO_PAUSE_TX)))
> + linkmode_set_bit(ETHTOOL_LINK_MODE_Asym_Pause_BIT, config->advertising);
to get this right, use :
linkmode_set_pause(adv, config->pause & MLO_PAUSE_TX, config->pause & MLO_PAUSE_RX)
This will build the supported bitfield for you.
I also think we should update pl->link_config.pause, as phylink_ethtool_get_pauseparam will
report wrong values otherwise.
I'm wondering wether it's worth keeping track of the user-requested pause settings when
changing the MTU, we have a true HW capability change here, so I think we should change it.
> +
> + if (!pl->phydev)
> + phylink_change_inband_advert(pl);
> +
> + mutex_unlock(&pl->state_mutex);
> +
> + if (pl->phydev) {
> + pause_adv = linkmode_test_bit(ETHTOOL_LINK_MODE_Pause_BIT,
> + config->advertising);
> + asym_adv = linkmode_test_bit(ETHTOOL_LINK_MODE_Asym_Pause_BIT,
> + config->advertising);
> +
> + mutex_lock(&pl->phydev->lock);
> + linkmode_mod_bit(ETHTOOL_LINK_MODE_Pause_BIT,
> + pl->phydev->advertising, pause_adv);
> + linkmode_mod_bit(ETHTOOL_LINK_MODE_Asym_Pause_BIT,
> + pl->phydev->advertising, asym_adv);
This is too much manual interaction with all the supported/advertising in phylink/phylib, it's
hard to read, understand and debug :(
We have helpers in phylib such as phy_set_asym_pause() to change pause settings
in phy_devices, don't set these manually like this.
Let's take a step back, it seems you're following sashiko too literally here.
There's a change in the MAC's ability to support Pause, so we should :
- Recompute the pl->supported field. Update the config.mac_capabilities with the
new pause settings, calling phylink_validate() should do the trick I think, this
will rebuild the capability list:
phylink_validate(pl, pl->supported, &pl->link_config);
- Then update the pl->link_config.pause,
- Then update the pause advertising, like done in phylink_setpauseparam
( I think, everything that comes after pl->state_mutex gets released in
phylink_ethtool_set_pauseparam)
Ideally, the logic to update the advertising and re-trigger a negociation
should be factored out in a private helper, then reused from both this
path (MAC updates pause support) and the phylink_ethtool_set_pauseparam path.
> + mutex_unlock(&pl->phydev->lock);
Why take phydev->lock here ? Sashiko's comment on a possible race with ethtool -s
isn't right, you go through phylink_ethtool_ksettings_set() first, which is
serialised with this current function through RTNL.
Maxime
^ permalink raw reply
* Re: [PATCH net v2] bnge/bng_re: fix ring ID widths
From: Przemek Kitszel @ 2026-07-10 10:06 UTC (permalink / raw)
To: Vikas Gupta
Cc: netdev, linux-kernel, linux-rdma, leonro, jgg, bhargava.marreddy,
rahul-rg.gupta, vsrama-krishna.nemani, rajashekar.hudumula,
ajit.khaparde, Siva Reddy Kallam, Dharmender Garg,
Yendapally Reddy Dhananjaya Reddy, davem, edumazet, kuba, pabeni,
andrew+netdev, horms
In-Reply-To: <20260704164747.1995227-1-vikas.gupta@broadcom.com>
On 7/4/26 18:47, Vikas Gupta wrote:
> Firmware requires more than 16 bits to address TX ring IDs for its
> internal QP management. Widen the associated HSI ring ID fields to
> 32 bits. The values firmware assigns remain within 24 bits, bounded
> by the hardware doorbell XID field.
>
> RX, completion, and NQ ring IDs are unaffected and remain 16-bit.
Here you mention Rx is unaffected. But you touch multiple places that
are Rx specific (some comments below).
[..]
> --- a/drivers/net/ethernet/broadcom/bnge/bnge.h
> +++ b/drivers/net/ethernet/broadcom/bnge/bnge.h
> @@ -36,6 +36,7 @@ struct bnge_pf_info {
> };
>
> #define INVALID_HW_RING_ID ((u16)-1)
> +#define INVALID_HW_RING_ID_32BIT (U32_MAX)
OK, there is much more usage of INVALID_HW_RING_ID than places touched
by this patch.
[...]
> +++ b/drivers/net/ethernet/broadcom/bnge/bnge_netdev.c
> @@ -1327,12 +1327,12 @@ static int bnge_alloc_core(struct bnge_net *bn)
> return rc;
> }
>
> -u16 bnge_cp_ring_for_rx(struct bnge_rx_ring_info *rxr)
> +u32 bnge_cp_ring_for_rx(struct bnge_rx_ring_info *rxr)
and here you change Rx ring ID width.
> {
> return rxr->rx_cpr->ring_struct.fw_ring_id;
> }
>
> -u16 bnge_cp_ring_for_tx(struct bnge_tx_ring_info *txr)
> +u32 bnge_cp_ring_for_tx(struct bnge_tx_ring_info *txr)
> {
> return txr->tx_cpr->ring_struct.fw_ring_id;
> }
> @@ -1375,12 +1375,12 @@ static void bnge_init_nq_tree(struct bnge_net *bn)
> struct bnge_nq_ring_info *nqr = &bn->bnapi[i]->nq_ring;
> struct bnge_ring_struct *ring = &nqr->ring_struct;
>
> - ring->fw_ring_id = INVALID_HW_RING_ID;
> + ring->fw_ring_id = INVALID_HW_RING_ID_32BIT;
> for (j = 0; j < nqr->cp_ring_count; j++) {
> struct bnge_cp_ring_info *cpr = &nqr->cp_ring_arr[j];
>
> ring = &cpr->ring_struct;
> - ring->fw_ring_id = INVALID_HW_RING_ID;
> + ring->fw_ring_id = INVALID_HW_RING_ID_32BIT;
> }
> }
> }
> @@ -1637,7 +1637,7 @@ static void bnge_init_one_rx_ring_rxbd(struct bnge_net *bn,
ditto Rx
>
> ring = &rxr->rx_ring_struct;
> bnge_init_rxbd_pages(ring, type);
> - ring->fw_ring_id = INVALID_HW_RING_ID;
> + ring->fw_ring_id = INVALID_HW_RING_ID_32BIT;
> }
>
> static void bnge_init_one_agg_ring_rxbd(struct bnge_net *bn,
> @@ -1647,7 +1647,7 @@ static void bnge_init_one_agg_ring_rxbd(struct bnge_net *bn,
ditto Rx, and in some other places too
^ permalink raw reply
* RE: [PATCH bpf-next v4 1/6] netlink: specs: Add XDP RX checksum capability to XDP metadata specs
From: Loktionov, Aleksandr @ 2026-07-10 10:09 UTC (permalink / raw)
To: Vladimir Vdovin, Lorenzo Bianconi, Donald Hunter, Jakub Kicinski,
David S . Miller, Eric Dumazet, Paolo Abeni, Simon Horman,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, Stanislav Fomichev, Andrew Lunn,
Nguyen, Anthony L, Kitszel, Przemyslaw, Lobakin, Aleksander,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, KP Singh, Hao Luo, Jiri Olsa, Shuah Khan,
Fijalkowski, Maciej
Cc: Jakub Sitnicki, netdev@vger.kernel.org, bpf@vger.kernel.org,
intel-wired-lan@lists.osuosl.org, linux-kselftest@vger.kernel.org
In-Reply-To: <20260708203410.45121-2-deliran@verdict.gg>
> -----Original Message-----
> From: Vladimir Vdovin <deliran@verdict.gg>
> Sent: Wednesday, July 8, 2026 10:34 PM
> To: Lorenzo Bianconi <lorenzo@kernel.org>; Donald Hunter
> <donald.hunter@gmail.com>; Jakub Kicinski <kuba@kernel.org>; David S .
> Miller <davem@davemloft.net>; Eric Dumazet <edumazet@google.com>;
> Paolo Abeni <pabeni@redhat.com>; Simon Horman <horms@kernel.org>;
> Alexei Starovoitov <ast@kernel.org>; Daniel Borkmann
> <daniel@iogearbox.net>; Jesper Dangaard Brouer <hawk@kernel.org>; John
> Fastabend <john.fastabend@gmail.com>; Stanislav Fomichev
> <sdf@fomichev.me>; Andrew Lunn <andrew+netdev@lunn.ch>; Nguyen,
> Anthony L <anthony.l.nguyen@intel.com>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@intel.com>; Lobakin, Aleksander
> <aleksander.lobakin@intel.com>; Andrii Nakryiko <andrii@kernel.org>;
> Martin KaFai Lau <martin.lau@linux.dev>; Eduard Zingerman
> <eddyz87@gmail.com>; Song Liu <song@kernel.org>; Yonghong Song
> <yonghong.song@linux.dev>; KP Singh <kpsingh@kernel.org>; Hao Luo
> <haoluo@google.com>; Jiri Olsa <jolsa@kernel.org>; Shuah Khan
> <shuah@kernel.org>; Fijalkowski, Maciej <maciej.fijalkowski@intel.com>
> Cc: Jakub Sitnicki <jakub@cloudflare.com>; Loktionov, Aleksandr
> <aleksandr.loktionov@intel.com>; netdev@vger.kernel.org;
> bpf@vger.kernel.org; intel-wired-lan@lists.osuosl.org; linux-
> kselftest@vger.kernel.org; Vladimir Vdovin <deliran@verdict.gg>
> Subject: [PATCH bpf-next v4 1/6] netlink: specs: Add XDP RX checksum
> capability to XDP metadata specs
>
> From: Lorenzo Bianconi <lorenzo@kernel.org>
>
> Introduce XDP RX checksum capability to XDP metadata specs. XDP RX
> checksum will be use by devices capable of exposing receive checksum
> result via bpf_xdp_metadata_rx_checksum().
> Moreover, introduce xmo_rx_checksum netdev callback in order to allow
> the eBPF program bound to the device to retrieve the RX checksum
> result computed by the hw NIC and reported via DMA descriptors.
>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> Signed-off-by: Vladimir Vdovin <deliran@verdict.gg>
> ---
> Documentation/netlink/specs/netdev.yaml | 5 ++++
> include/net/xdp.h | 18 ++++++++++++++
> include/uapi/linux/netdev.h | 3 +++
> net/core/xdp.c | 32
> +++++++++++++++++++++++++
> tools/include/uapi/linux/netdev.h | 3 +++
> 5 files changed, 61 insertions(+)
>
> diff --git a/Documentation/netlink/specs/netdev.yaml
> b/Documentation/netlink/specs/netdev.yaml
> index 5f143da7458c..6d0d90d3a614 100644
> --- a/Documentation/netlink/specs/netdev.yaml
> +++ b/Documentation/netlink/specs/netdev.yaml
> @@ -61,6 +61,11 @@ definitions:
> doc: |
> Device is capable of exposing receive packet VLAN tag via
> bpf_xdp_metadata_rx_vlan_tag().
> + -
> + name: checksum
> + doc: |
> + Device is capable of exposing receive checksum result via
> + bpf_xdp_metadata_rx_checksum().
> -
> type: flags
> name: xsk-flags
> diff --git a/include/net/xdp.h b/include/net/xdp.h index
> aa742f413c35..e255ff786131 100644
> --- a/include/net/xdp.h
> +++ b/include/net/xdp.h
> @@ -586,6 +586,10 @@ void xdp_attachment_setup(struct
> xdp_attachment_info *info,
> NETDEV_XDP_RX_METADATA_VLAN_TAG, \
> bpf_xdp_metadata_rx_vlan_tag, \
> xmo_rx_vlan_tag) \
> + XDP_METADATA_KFUNC(XDP_METADATA_KFUNC_RX_CHECKSUM, \
> + NETDEV_XDP_RX_METADATA_CHECKSUM, \
> + bpf_xdp_metadata_rx_checksum, \
> + xmo_rx_checksum)
>
> enum xdp_rx_metadata {
> #define XDP_METADATA_KFUNC(name, _, __, ___) name, @@ -643,12 +647,26
> @@ enum xdp_rss_hash_type {
> XDP_RSS_TYPE_L4_IPV6_SCTP_EX = XDP_RSS_TYPE_L4_IPV6_SCTP |
> XDP_RSS_L3_DYNHDR, };
>
> +/* Please note the driver is required to invalidate the checksum if
> the
> +NIC
> + * reports CHECKSUM_UNNECESSARY or CHECKSUM_COMPLETE and the eBPF
> +program
> + * modifies the packet since it can change some fields validated by
> the
> + * checksum.
> + */
> +enum xdp_checksum {
> + XDP_CHECKSUM_NONE = BIT(CHECKSUM_NONE),
> + XDP_CHECKSUM_UNNECESSARY = BIT(CHECKSUM_UNNECESSARY),
> + XDP_CHECKSUM_COMPLETE = BIT(CHECKSUM_COMPLETE),
> +};
> +
> struct xdp_metadata_ops {
> int (*xmo_rx_timestamp)(const struct xdp_md *ctx, u64
> *timestamp);
> int (*xmo_rx_hash)(const struct xdp_md *ctx, u32 *hash,
> enum xdp_rss_hash_type *rss_type);
> int (*xmo_rx_vlan_tag)(const struct xdp_md *ctx, __be16
> *vlan_proto,
> u16 *vlan_tci);
> + int (*xmo_rx_checksum)(const struct xdp_md *ctx,
> + enum xdp_checksum *ip_summed,
> + u32 *cksum, u8 *cksum_level);
> };
>
> #ifdef CONFIG_NET
> diff --git a/include/uapi/linux/netdev.h b/include/uapi/linux/netdev.h
> index 2f3ab75e8cc0..f8caade93c8c 100644
> --- a/include/uapi/linux/netdev.h
> +++ b/include/uapi/linux/netdev.h
> @@ -47,11 +47,14 @@ enum netdev_xdp_act {
> * hash via bpf_xdp_metadata_rx_hash().
> * @NETDEV_XDP_RX_METADATA_VLAN_TAG: Device is capable of exposing
> receive
> * packet VLAN tag via bpf_xdp_metadata_rx_vlan_tag().
> + * @NETDEV_XDP_RX_METADATA_CHECKSUM: Device is capable of exposing
> receive
> + * checksum result via bpf_xdp_metadata_rx_checksum().
> */
> enum netdev_xdp_rx_metadata {
> NETDEV_XDP_RX_METADATA_TIMESTAMP = 1,
> NETDEV_XDP_RX_METADATA_HASH = 2,
> NETDEV_XDP_RX_METADATA_VLAN_TAG = 4,
> + NETDEV_XDP_RX_METADATA_CHECKSUM = 8,
> };
>
> /**
> diff --git a/net/core/xdp.c b/net/core/xdp.c index
> 9890a30584ba..9bcaa423ad17 100644
> --- a/net/core/xdp.c
> +++ b/net/core/xdp.c
> @@ -961,6 +961,38 @@ __bpf_kfunc int
> bpf_xdp_metadata_rx_vlan_tag(const struct xdp_md *ctx,
> return -EOPNOTSUPP;
> }
>
> +/**
> + * bpf_xdp_metadata_rx_checksum - Read XDP frame RX checksum.
> + * @ctx: XDP context pointer.
> + * @ip_summed: Return value pointer to a bitmask indicating available
> checksums.
> + * @cksum: Return value pointer indicating the hw checksum value.
> + * @cksum_level: Return value pointer indicating the checksum level
> result.
> + *
> + * In case of success, ``ip_summed`` is set to the RX checksum
> result.
> +Possible
> + * values are:
> + * ``XDP_CHECKSUM_NONE``
> + * ``XDP_CHECKSUM_UNNECESSARY``
> + * ``XDP_CHECKSUM_COMPLETE``
> + * ``XDP_CHECKSUM_COMPLETE`` | ``XDP_CHECKSUM_UNNECESSARY``
> + *
> + * In case of success, ``cksum`` contains the checksum value
> calculated
> +by the
> + * NIC. ``cksum`` is valid only if ``XDP_CHECKSUM_COMPLETE`` is set
> in
> + * ``ip_summed``. ``cksum_level`` contains the checksum level
> reported
> +by the
> + * hw. ``cksum_level`` can be considered valid only if
> + * ``XDP_CHECKSUM_UNNECESSARY`` is set in ``ip_summed``.
> + *
> + * Return:
> + * * Returns 0 on success or ``-errno`` on error.
> + * * ``-EOPNOTSUPP`` : means device driver does not implement kfunc
> + * * ``-ENODATA`` : means no RX-checksum available for this frame
> + */
> +__bpf_kfunc int bpf_xdp_metadata_rx_checksum(const struct xdp_md
> *ctx,
> + enum xdp_checksum *ip_summed,
> + u32 *cksum, u8 *cksum_level)
> +{
> + return -EOPNOTSUPP;
> +}
> +
> __bpf_kfunc_end_defs();
>
> BTF_KFUNCS_START(xdp_metadata_kfunc_ids)
> diff --git a/tools/include/uapi/linux/netdev.h
> b/tools/include/uapi/linux/netdev.h
> index 2f3ab75e8cc0..f8caade93c8c 100644
> --- a/tools/include/uapi/linux/netdev.h
> +++ b/tools/include/uapi/linux/netdev.h
> @@ -47,11 +47,14 @@ enum netdev_xdp_act {
> * hash via bpf_xdp_metadata_rx_hash().
> * @NETDEV_XDP_RX_METADATA_VLAN_TAG: Device is capable of exposing
> receive
> * packet VLAN tag via bpf_xdp_metadata_rx_vlan_tag().
> + * @NETDEV_XDP_RX_METADATA_CHECKSUM: Device is capable of exposing
> receive
> + * checksum result via bpf_xdp_metadata_rx_checksum().
> */
> enum netdev_xdp_rx_metadata {
> NETDEV_XDP_RX_METADATA_TIMESTAMP = 1,
> NETDEV_XDP_RX_METADATA_HASH = 2,
> NETDEV_XDP_RX_METADATA_VLAN_TAG = 4,
> + NETDEV_XDP_RX_METADATA_CHECKSUM = 8,
> };
>
> /**
> --
> 2.47.0
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* RE: [PATCH bpf-next v4 2/6] net: veth: Add xmo_rx_checksum callback to veth driver
From: Loktionov, Aleksandr @ 2026-07-10 10:09 UTC (permalink / raw)
To: Vladimir Vdovin, Lorenzo Bianconi, Donald Hunter, Jakub Kicinski,
David S . Miller, Eric Dumazet, Paolo Abeni, Simon Horman,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, Stanislav Fomichev, Andrew Lunn,
Nguyen, Anthony L, Kitszel, Przemyslaw, Lobakin, Aleksander,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, KP Singh, Hao Luo, Jiri Olsa, Shuah Khan,
Fijalkowski, Maciej
Cc: Jakub Sitnicki, netdev@vger.kernel.org, bpf@vger.kernel.org,
intel-wired-lan@lists.osuosl.org, linux-kselftest@vger.kernel.org
In-Reply-To: <20260708203410.45121-3-deliran@verdict.gg>
> -----Original Message-----
> From: Vladimir Vdovin <deliran@verdict.gg>
> Sent: Wednesday, July 8, 2026 10:34 PM
> To: Lorenzo Bianconi <lorenzo@kernel.org>; Donald Hunter
> <donald.hunter@gmail.com>; Jakub Kicinski <kuba@kernel.org>; David S .
> Miller <davem@davemloft.net>; Eric Dumazet <edumazet@google.com>;
> Paolo Abeni <pabeni@redhat.com>; Simon Horman <horms@kernel.org>;
> Alexei Starovoitov <ast@kernel.org>; Daniel Borkmann
> <daniel@iogearbox.net>; Jesper Dangaard Brouer <hawk@kernel.org>; John
> Fastabend <john.fastabend@gmail.com>; Stanislav Fomichev
> <sdf@fomichev.me>; Andrew Lunn <andrew+netdev@lunn.ch>; Nguyen,
> Anthony L <anthony.l.nguyen@intel.com>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@intel.com>; Lobakin, Aleksander
> <aleksander.lobakin@intel.com>; Andrii Nakryiko <andrii@kernel.org>;
> Martin KaFai Lau <martin.lau@linux.dev>; Eduard Zingerman
> <eddyz87@gmail.com>; Song Liu <song@kernel.org>; Yonghong Song
> <yonghong.song@linux.dev>; KP Singh <kpsingh@kernel.org>; Hao Luo
> <haoluo@google.com>; Jiri Olsa <jolsa@kernel.org>; Shuah Khan
> <shuah@kernel.org>; Fijalkowski, Maciej <maciej.fijalkowski@intel.com>
> Cc: Jakub Sitnicki <jakub@cloudflare.com>; Loktionov, Aleksandr
> <aleksandr.loktionov@intel.com>; netdev@vger.kernel.org;
> bpf@vger.kernel.org; intel-wired-lan@lists.osuosl.org; linux-
> kselftest@vger.kernel.org; Vladimir Vdovin <deliran@verdict.gg>
> Subject: [PATCH bpf-next v4 2/6] net: veth: Add xmo_rx_checksum
> callback to veth driver
>
> From: Lorenzo Bianconi <lorenzo@kernel.org>
>
> Implement xmo_rx_checksum callback in veth driver to report RX
> checksum result to the eBPF program bounded to the veth device.
>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> Signed-off-by: Vladimir Vdovin <deliran@verdict.gg>
> ---
> drivers/net/veth.c | 32 ++++++++++++++++++++++++++++++++
> 1 file changed, 32 insertions(+)
>
> diff --git a/drivers/net/veth.c b/drivers/net/veth.c index
> 1c5142149175..498d894d043d 100644
> --- a/drivers/net/veth.c
> +++ b/drivers/net/veth.c
> @@ -1700,6 +1700,37 @@ static int veth_xdp_rx_vlan_tag(const struct
> xdp_md *ctx, __be16 *vlan_proto,
> return err;
> }
>
> +static int veth_xdp_rx_checksum(const struct xdp_md *ctx,
> + enum xdp_checksum *ip_summed,
> + u32 *cksum, u8 *cksum_level)
> +{
> + const struct veth_xdp_buff *_ctx = (void *)ctx;
> + const struct sk_buff *skb = _ctx->skb;
> +
> + if (!skb)
> + return -ENODATA;
> +
> + switch (skb->ip_summed) {
> + case CHECKSUM_COMPLETE:
> + *ip_summed = XDP_CHECKSUM_COMPLETE;
> + *cksum = skb->csum;
> + *cksum_level = 0;
> + break;
> + case CHECKSUM_UNNECESSARY:
> + *ip_summed = XDP_CHECKSUM_UNNECESSARY;
> + *cksum_level = skb->csum_level;
> + *cksum = 0;
> + break;
> + default:
> + *ip_summed = XDP_CHECKSUM_NONE;
> + *cksum_level = 0;
> + *cksum = 0;
> + break;
> + }
> +
> + return 0;
> +}
> +
> static const struct net_device_ops veth_netdev_ops = {
> .ndo_init = veth_dev_init,
> .ndo_open = veth_open,
> @@ -1725,6 +1756,7 @@ static const struct xdp_metadata_ops
> veth_xdp_metadata_ops = {
> .xmo_rx_timestamp = veth_xdp_rx_timestamp,
> .xmo_rx_hash = veth_xdp_rx_hash,
> .xmo_rx_vlan_tag = veth_xdp_rx_vlan_tag,
> + .xmo_rx_checksum = veth_xdp_rx_checksum,
> };
>
> #define VETH_FEATURES (NETIF_F_SG | NETIF_F_FRAGLIST |
> NETIF_F_HW_CSUM | \
> --
> 2.47.0
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ 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