* Re: [PATCH net-next v3 5/5] selftest: Add tests for useful handling of LSM denials on SCM_RIGHTS
From: Kuniyuki Iwashima @ 2026-06-30 16:23 UTC (permalink / raw)
To: Jori Koolstra
Cc: Jakub Kicinski, Christian Brauner, Aleksa Sarai, David S . Miller,
Eric Dumazet, Paolo Abeni, Simon Horman, netdev, linux-fsdevel,
linux-kernel
In-Reply-To: <1957659940.3537950.1782830112890@kpc.webmail.kpnmail.nl>
On Tue, Jun 30, 2026 at 7:35 AM Jori Koolstra <jkoolstra@xs4all.nl> wrote:
>
>
> > Op 30-06-2026 16:17 CEST schreef Jakub Kicinski <kuba@kernel.org>:
> >
> >
> > On Mon, 29 Jun 2026 21:43:27 +0200 Jori Koolstra wrote:
> > > The test uses the following Smack labels:
> > >
> > > "Sender" - label for the sending process
> > > "Receiver" - label for the receiving process
> > > "SecretX" - labels for the files being passed
> >
> > Not sure this test belongs in net/
> > 99.9% of people running this test do not use Smack.
> > At the very least you need to use XFAIL instead of SKIP
> > we use skip for problems with the env which are fixable,
> > like a command missing.
>
> Ah, right, because you can only use one of these LSMs at a time?
> I mean one of AppArmour, SELinux, Smack, TOMOYO.
>
> I just need some LSM to trigger the reject of security_file_receive()
> and Smack was the easiest to get going. The series is totally agnostic
> to the used LSM. I am fine with moving the tests elsewhere or porting
> them to SELinux if that is really necessary. We could also drop them
> altogether.
>
> What do you propose?
Maybe tools/testing/selftests/lsm ?
^ permalink raw reply
* Re: [PATCH net-next v3 4/5] net: af_unix: replace copy_from_sockptr() with copy_safe_from_sockptr()
From: Kuniyuki Iwashima @ 2026-06-30 16:18 UTC (permalink / raw)
To: Jori Koolstra
Cc: Christian Brauner, Aleksa Sarai, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, netdev, linux-fsdevel,
linux-kernel
In-Reply-To: <20260629194327.2270798-5-jkoolstra@xs4all.nl>
On Mon, Jun 29, 2026 at 12:42 PM Jori Koolstra <jkoolstra@xs4all.nl> wrote:
>
> Replace deprecated call to copy_from_sockptr() with
> copy_safe_from_sockptr().
>
> Signed-off-by: Jori Koolstra <jkoolstra@xs4all.nl>
> ---
> net/unix/af_unix.c | 9 ++++-----
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
> index 83274ce18e06..07a0b07cd65f 100644
> --- a/net/unix/af_unix.c
> +++ b/net/unix/af_unix.c
> @@ -933,6 +933,7 @@ static int unix_setsockopt(struct socket *sock, int level, int optname,
> {
> struct unix_sock *u = unix_sk(sock->sk);
> struct sock *sk = sock->sk;
> + int error;
> int val;
>
> if (level != SOL_SOCKET)
> @@ -941,11 +942,9 @@ static int unix_setsockopt(struct socket *sock, int level, int optname,
> if (!unix_custom_sockopt(optname))
> return sock_setsockopt(sock, level, optname, optval, optlen);
>
> - if (optlen != sizeof(int))
> - return -EINVAL;
> -
> - if (copy_from_sockptr(&val, optval, sizeof(val)))
> - return -EFAULT;
> + error = copy_safe_from_sockptr(&val, sizeof(val), optval, optlen);
Currently, only int is allowed, but this change unnecessarily loosens
the validation.
Please keep copy_from_sockptr() as is.
> + if (error)
> + return error;
>
> switch (optname) {
> case SO_INQ:
> --
> 2.54.0
>
^ permalink raw reply
* Re: [PATCH net] net: airoha: fix max receive size configuration
From: Lorenzo Bianconi @ 2026-06-30 16:19 UTC (permalink / raw)
To: Paolo Abeni
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Simon Horman, linux-arm-kernel, linux-mediatek, netdev,
Madhur Agrawal
In-Reply-To: <94901706-e7f3-4ff7-9b19-9965f593e228@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1251 bytes --]
On Jun 30, Paolo Abeni wrote:
> On 6/25/26 8:49 AM, Lorenzo Bianconi wrote:
> > Set the GDM maximum receive size to AIROHA_MAX_RX_SIZE unconditionally
> > during hardware initialization instead of updating it according to the
> > configured MTU. This avoids dropping incoming frames that exceed the
> > current MTU but could still be processed by the networking stack, which
> > is able to fragment the reply on the TX side (e.g. ICMP echo requests).
> > Move the per-port MTU configuration to the PPE egress path where it
> > belongs, and set the tx frame size running airoha_ppe_set_xmit_frame_size()
> > to dynamically track the maximum MTU across running interfaces sharing
> > the same PPE instance.
> > Fix the PPE MTU register addressing to pack two port entries per
> > register word and add WAN_MTU0 configuration for non-LAN GDM devices.
> >
> > Fixes: 54d989d58d2a ("net: airoha: Move min/max packet len configuration in airoha_dev_open()")
> > Tested-by: Madhur Agrawal <madhur.agrawal@airoha.com>
> > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
>
> PW bot is on holiday, no automated notifications for a while.
It's too hot even for the bot :)
Regards,
Lorenzo
>
> Applied, thanks!
>
> /P
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH bpf-next v5 1/3] bpf: Add BPF_FIB_LOOKUP_VLAN flag to bpf_fib_lookup() helper
From: Toke Høiland-Jørgensen @ 2026-06-30 16:04 UTC (permalink / raw)
To: David Ahern, Avinash Duduskar, ast, daniel, andrii
Cc: eddyz87, memxor, martin.lau, song, yonghong.song, jolsa, emil,
john.fastabend, sdf, davem, edumazet, kuba, pabeni, horms, shuah,
hawk, yatsenko, leon.hwang, kpsingh, a.s.protopopov, ameryhung,
rongtao, eyal.birger, bpf, netdev, linux-kernel, linux-kselftest
In-Reply-To: <cf25f667-1095-4f84-98ff-bf4662d3faa8@kernel.org>
David Ahern <dsahern@kernel.org> writes:
> On 6/30/26 4:00 AM, Toke Høiland-Jørgensen wrote:
>>> It does not make sense to require a flag to get lookup output. vlan
>>> proto of 0 is not valid, so it is a clear indication that the vlan
>>> output parameters were not set during the lookup.
>>
>> Okay, so we could just unconditionally set the VLAN fields, but if we
>> start rewriting the ifindex that would be a change of the existing
>> behaviour that could break existing applications, no?
>
> Consistently dealing with upper devices is one of the reasons I never
> sent patches for vlan support.
>
> xdp support is at the driver layer for real (physical) devices. The fib
> lookup is going to return the vlan device index - a virtual device.
> Support for xdp should not be propagated to virtual devices; it goes
> against the intent of xdp. Any trip down this path will have to decide
> how to handle vlan-in-vlan use cases. Where is the line drawn for fast
> networking?
Right, which is why we need building blocks that makes it possible for
XDP programs to do the right thing in the BPF code :)
A helper that resolves the parent could be used for stacked VLANs as
well (just calling the helper multiple times).
>> Specifically, if an XDP application has a table of the interfaces it
>> forwards between, today they'd get a VLAN interface ifindex, which would
>> not be in that table, and the application would return XDP_PASS. Whereas
>> if we change the ifindex and populate the VLAN tag, suddenly the
>> interface would be in the table, but because the application doesn't
>> read the returned VLAN tag, it will end up sending packets out without
>> tagging them, leading to broken forwarding.
>
> I have not followed developments over the past few years. Does XDP have
> support for vlan acceleration in the Tx path now? You really want that
> to deal with vlans and not replicating s/w processing in ebpf.
It does not, no. There's TX metadata for AF_XDP, but VLAN support is not
in there (see include/uapi/linux/if_xdp.h).
Doesn't mean software VLAN handling can't be useful, though; there are
use cases other than the very high end where XDP can speed things up
even if it has to write a VLAN tag or two...
>> So if we don't want the flag, we'd need some other mechanism to resolve
>> the parent ifindex, AFAICT? Maybe a xdp_get_parent_ifindex() kfunc, say?
>> That could also be made generic for other stacked interface types, I
>> suppose.
>>
>> WDYT?
>
> dealing with stacked devices is hard :-)
>
> What is the return is a bond device or a vlan on a bond device?
Well, bond devices have XDP support, so you can just redirect to those :)
But yeah, each type of stacked device would need to pass different
information through to the XDP program, and the program would need to
support those. Building a single XDP program that supports all of them
will require quite a bit of code, and would probably not perform super
well. But most deployments have distinct subsets of features they need,
so this does not have to be a blocker, IMO?
-Toke
^ permalink raw reply
* Re: [PATCH net v3] fsl/fman: Free init resources on KeyGen failure in fman_init()
From: Paolo Abeni @ 2026-06-30 16:00 UTC (permalink / raw)
To: Haoxiang Li, madalin.bucur, sean.anderson, andrew+netdev, davem,
edumazet, kuba, florinel.iordache
Cc: netdev, linux-kernel, stable, Pavan Chebbi, Breno Leitao
In-Reply-To: <20260625004834.3394389-1-haoxiang_li2024@163.com>
On 6/25/26 2:48 AM, Haoxiang Li wrote:
> fman_muram_alloc() allocates initialization resources before
> initializing the KeyGen block. If keygen_init() fails, the
> function returns -EINVAL directly and leaves those resources
> allocated. Free the initialization resources before returning
> from the KeyGen failure path.
>
> Fixes: 7472f4f281d0 ("fsl/fman: enable FMan Keygen")
> Cc: stable@kernel.org
> Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com>
> Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com>
> Reviewed-by: Breno Leitao <leitao@debian.org>
The PW bot is on holiday, no automated notifications for a while.
Applied, thanks!
/P
^ permalink raw reply
* Re: [PATCH net-next] net: phylink: Drop references to the .validate() method in comments
From: Andrew Lunn @ 2026-06-30 15:55 UTC (permalink / raw)
To: Maxime Chevallier
Cc: Andrew Lunn, davem, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Russell King, Heiner Kallweit, netdev, linux-kernel,
thomas.petazzoni
In-Reply-To: <20260630083700.2041915-1-maxime.chevallier@bootlin.com>
On Tue, Jun 30, 2026 at 10:37:00AM +0200, Maxime Chevallier wrote:
> The phylink_mac_ops '.validate()' has been removed in:
>
> commit da5f6b80ad64 ("net: phylink: remove .validate() method")
>
> There are still a few comments around in phylink that references that,
> related to the ports fields as well as the Pause configuration. Let's
> drop these references and update the comments related to Pause handling.
>
> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH nf] netfilter: nft_set_rbtree: reject interval-end get for open intervals
From: Melbin K Mathew @ 2026-06-30 15:55 UTC (permalink / raw)
To: pablo; +Cc: fw, netfilter-devel, coreteam, netdev, linux-kernel,
Melbin K Mathew
nft_rbtree_get() uses the interval endpoint selected by
nft_array_get_cmp(). For NFT_SET_ELEM_INTERVAL_END requests, the function
uses interval->to to recover struct nft_rbtree_elem.
Open-ended intervals can have a NULL end endpoint. In that case,
nft_array_get_cmp() treats the missing endpoint as b = -1, which can
still match an interval-end query. Avoid deriving an element pointer
from a NULL endpoint and report the element as not found instead.
Return -ENOENT for interval-end requests against open-ended intervals.
Fixes: 2aa34191f06f ("netfilter: nft_set_rbtree: use binary search array in get command")
Signed-off-by: Melbin K Mathew <mlbnkm1@gmail.com>
---
Notes:
A reduced userspace model confirms the comparator returns match for a
NULL-ended interval when NFT_SET_ELEM_INTERVAL_END is set, and that
container_of(NULL, ext) produces a garbage pointer (UBSAN fires).
I have not reproduced an end-to-end crash through normal nft CLI usage.
An instrumented WARN in this branch did not fire during interval-set
tests with nft add/get/list. The patch is a defensive fix for the NULL
endpoint case.
Tested on 7.2-rc1 with KASAN and UBSAN enabled. Function tracing
confirms nft_rbtree_get() is reached via nft get element. The added
guard returns -ENOENT for a NULL interval endpoint in the instrumented
test case.
---
net/netfilter/nft_set_rbtree.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/net/netfilter/nft_set_rbtree.c b/net/netfilter/nft_set_rbtree.c
index 018bbb6df4..024a2cd3a6 100644
--- a/net/netfilter/nft_set_rbtree.c
+++ b/net/netfilter/nft_set_rbtree.c
@@ -184,10 +184,13 @@ 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 ERR_PTR(-ENOENT);
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.39.5
^ permalink raw reply related
* Re: [PATCH net-next v4] vsock/virtio: rewrite MSG_ZEROCOPY flag handling
From: Paolo Abeni @ 2026-06-30 15:52 UTC (permalink / raw)
To: Arseniy Krasnov, Stefan Hajnoczi, Stefano Garzarella,
David S. Miller, Eric Dumazet, Jakub Kicinski, Michael S. Tsirkin,
Jason Wang, Bobby Eshleman, Xuan Zhuo, Eugenio Pérez,
Simon Horman
Cc: kvm, virtualization, netdev, linux-kernel, oxffffaa, rulkc
In-Reply-To: <20260628182052.951760-1-avkrasnov@rulkc.org>
On 6/28/26 8:20 PM, Arseniy Krasnov wrote:
> Logically it was based on TCP implementation, so to make further support
> easier, rewrite it in the TCP way (like in 'tcp_sendmsg_locked()'). By
> this way, patch also adds handling case when 'msg_ubuf' is already set.
>
> Signed-off-by: Arseniy Krasnov <avkrasnov@rulkc.org>
The PW bot is on holiday, no automated notifications for a while.
Applied, thanks!
/P
^ permalink raw reply
* Re: [PATCH] af_unix: mark MSG_SPLICE_PAGES frags shared
From: Kuniyuki Iwashima @ 2026-06-30 15:51 UTC (permalink / raw)
To: Yiming Qian
Cc: security, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, netdev, linux-kernel, lingchen5202005
In-Reply-To: <20260630070600.484-1-yimingqian591@gmail.com>
On Tue, Jun 30, 2026 at 12:06 AM Yiming Qian <yimingqian591@gmail.com> wrote:
>
> unix_stream_sendmsg() splices external pages directly into skb frags when
> MSG_SPLICE_PAGES is set, but it does not propagate SKBFL_SHARED_FRAG
> afterward.
I think it doesn't matter with the plain AF_UNIX.
Please elaborate on the scenario where this could be a problem.
e.g. sockmap ?
>
> That leaves later writers without the shared-frag marker even though the
> skb still references externally owned pages.
>
> Set the marker after a successful skb_splice_from_iter() call.
>
> Fixes: a0dbf5f818f90 ("af_unix: Support MSG_SPLICE_PAGES")
> Reported-by: Yiming Qian <yimingqian591@gmail.com>
> Reported-by: Can Liu <lingchen5202005@gmail.com>
Reported-by is not needed when it's identical to SOB tag.
> Signed-off-by: Yiming Qian <yimingqian591@gmail.com>
> Signed-off-by: Can Liu <lingchen5202005@gmail.com>
> ---
> net/unix/af_unix.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
> index f7a9d55eee8a1..f2cd0f8ec0914 100644
> --- a/net/unix/af_unix.c
> +++ b/net/unix/af_unix.c
> @@ -2458,6 +2458,7 @@ static int unix_stream_sendmsg(struct socket *sock, struct msghdr *msg,
> goto out_free;
>
> size = err;
> + skb_shinfo(skb)->flags |= SKBFL_SHARED_FRAG;
> refcount_add(size, &sk->sk_wmem_alloc);
> } else {
> skb_put(skb, size - data_len);
> --
> 2.34.1
^ permalink raw reply
* Re: [PATCH net] bridge: stp: Fix a potential use-after-free when deleting a bridge
From: Paolo Abeni @ 2026-06-30 15:50 UTC (permalink / raw)
To: Ido Schimmel, netdev, bridge; +Cc: davem, kuba, edumazet, razor, horms
In-Reply-To: <20260629072117.497959-1-idosch@nvidia.com>
On 6/29/26 9:21 AM, Ido Schimmel wrote:
> The three STP timers are not supposed to be armed while the bridge is
> administratively down. They are synchronously deactivated when the
> bridge is put administratively down and the various call sites check for
> 'IFF_UP' before arming them.
>
> This check is missing from br_topology_change_detection() and it is
> possible to engineer a situation in which the topology change timer is
> armed while the bridge is administratively down, resulting in a
> use-after-free [1] when the bridge is deleted.
>
> Fix by adding the missing check and for good measures synchronously
> shutdown the three timers when the bridge is deleted.
>
> [1]
> ODEBUG: free active (active state 0) object: ffff88811662b9b0 object type: timer_list hint: br_topology_change_timer_expired (net/bridge/br_stp_timer.c:120)
> WARNING: lib/debugobjects.c:629 at debug_print_object+0x1bc/0x450, CPU#9: ip/359
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Reported-by: Noam Rathaus <noamr@ssd-disclosure.com>
> Reported-by: Neil Young <contact@ssd-disclosure.com>
> Acked-by: Nikolay Aleksandrov <nikolay@nvidia.com>
> Signed-off-by: Ido Schimmel <idosch@nvidia.com>
The PW bot is on holiday, no automated notifications for a while.
Applied, thanks!
/P
^ permalink raw reply
* Re: [PATCH net] net: gianfar: dispose irq mappings on probe failure and device removal
From: Paolo Abeni @ 2026-06-30 15:49 UTC (permalink / raw)
To: Rosen Penev, netdev
Cc: Claudiu Manoil, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Andy Fleming, open list
In-Reply-To: <20260626225228.427392-1-rosenp@gmail.com>
On 6/27/26 12:52 AM, Rosen Penev wrote:
> irq_of_parse_and_map() creates irqdomain mappings that should be
> balanced with irq_dispose_mapping(). The driver never called
> irq_dispose_mapping(), leaking mappings on probe failure and
> device removal.
>
> Fix by adding irq_dispose_mapping() in free_gfar_dev() and
> expanding its loop from priv->num_grps to MAXGROUPS so the
> error path also catches partially-initialized groups. All
> irqinfo pointers are pre-initialized to NULL in gfar_of_init(),
> making the NULL-guarded walk in free_gfar_dev() safe for every
> scenario.
>
> gfar_parse_group() itself is left as a simple parse function
> with no resource management; cleanup is centralized in the
> caller's error path.
>
> Assisted-by: opencode:big-pickle
> Fixes: b31a1d8b4151 ("gianfar: Convert gianfar to an of_platform_driver")
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
The PW bot is on holiday, no automated notifications for a while.
Applied, thanks!
/P
^ permalink raw reply
* Re: [PATCH] net: lan743x: Initialize eth_syslock spinlock before use
From: Paolo Abeni @ 2026-06-30 15:47 UTC (permalink / raw)
To: Andrea Righi, Bryan Whitehead, UNGLinuxDriver
Cc: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Raju Lakkaraju, David Thompson, netdev, linux-kernel
In-Reply-To: <20260626163218.3591486-1-arighi@nvidia.com>
On 6/26/26 6:32 PM, Andrea Righi wrote:
> lan743x_hardware_init() calls pci11x1x_strap_get_status() during the
> PCI11x1x probe sequence. That helper acquires the Ethernet subsystem
> hardware lock via lan743x_hs_syslock_acquire(), which relies on
> adapter->eth_syslock_spinlock to serialize access.
>
> The spinlock is currently initialized only after the strap status is
> read. With CONFIG_DEBUG_SPINLOCK enabled, taking the zeroed initialized
> spinlock can trip the spinlock debug check.
>
> Fix by initializing adapter->eth_syslock_spinlock before reading the
> strap status so the probe path never attempts to lock an uninitialized
> spinlock.
>
> Fixes: 46b777ad9a8c ("net: lan743x: Add support to SGMII 1G and 2.5G")
> Cc: stable@vger.kernel.org # v6.0+
> Signed-off-by: Andrea Righi <arighi@nvidia.com>
The PW bot is on holiday, no automated notifications for a while.
Applied, thanks!
/P
^ permalink raw reply
* Re: [PATCH net v2] net: libwx: fix VMDQ mask for 1-queue mode
From: Paolo Abeni @ 2026-06-30 15:46 UTC (permalink / raw)
To: Jiawen Wu, netdev
Cc: Mengyuan Lou, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Simon Horman, Jacob Keller, Kees Cook,
Larysa Zaremba
In-Reply-To: <161F704D2C983E2C+20260626092530.551028-1-jiawenwu@trustnetic.com>
On 6/26/26 11:25 AM, Jiawen Wu wrote:
> In wx_set_vmdq_queues(), the VMDQ mask was not set for the devices not
> supporting WX_FLAG_MULTI_64_FUNC, i.e., NGBE devices. A mask of 0 causes
> __ALIGN_MASK(1, ~vmdq->mask) to return 0, which incorrectly sets
> q_per_pool to 0 in wx_write_qde().
>
> Fix the VMDQ 1-queue mask to 0x7F then ensures that __ALIGN_MASK(1,
> ~0x7F) correctly evaluates to 1.
>
> Fixes: c52d4b898901 ("net: libwx: Redesign flow when sriov is enabled")
> Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com>
> Reviewed-by: Larysa Zaremba <larysa.zaremba@intel.com>
The PW bot is on holiday, no automated notifications for a while.
Applied, thanks!
/P
^ permalink raw reply
* Re: [PATCH net] net: airoha: fix max receive size configuration
From: Paolo Abeni @ 2026-06-30 15:44 UTC (permalink / raw)
To: Lorenzo Bianconi, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Simon Horman
Cc: linux-arm-kernel, linux-mediatek, netdev, Madhur Agrawal
In-Reply-To: <20260625-airoha-fix-rx-max-len-v1-1-45b9b827358d@kernel.org>
On 6/25/26 8:49 AM, Lorenzo Bianconi wrote:
> Set the GDM maximum receive size to AIROHA_MAX_RX_SIZE unconditionally
> during hardware initialization instead of updating it according to the
> configured MTU. This avoids dropping incoming frames that exceed the
> current MTU but could still be processed by the networking stack, which
> is able to fragment the reply on the TX side (e.g. ICMP echo requests).
> Move the per-port MTU configuration to the PPE egress path where it
> belongs, and set the tx frame size running airoha_ppe_set_xmit_frame_size()
> to dynamically track the maximum MTU across running interfaces sharing
> the same PPE instance.
> Fix the PPE MTU register addressing to pack two port entries per
> register word and add WAN_MTU0 configuration for non-LAN GDM devices.
>
> Fixes: 54d989d58d2a ("net: airoha: Move min/max packet len configuration in airoha_dev_open()")
> Tested-by: Madhur Agrawal <madhur.agrawal@airoha.com>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
PW bot is on holiday, no automated notifications for a while.
Applied, thanks!
/P
^ permalink raw reply
* Re: [PATCH net] selftests/tc-testing: Add tests that force multiq and taprio to enqueue to child's gso_skb
From: Pedro Tammela @ 2026-06-30 15:43 UTC (permalink / raw)
To: Victor Nogueira, davem, edumazet, kuba, pabeni, jhs, jiri
Cc: netdev, hexlabsecurity
In-Reply-To: <20260630153651.249752-1-victor@mojatatu.com>
On 30/06/2026 12:36, Victor Nogueira wrote:
> Add test cases to reproduce scenarios fixed recently [1] where
> multiqueue and taprio forced their children into enqueueing an skb to
> gso_skb (during peek), but failed to dequeue from gso_skb because they
> called the child's dequeue callback directly. This causes a desync in the
> child's qlen/backlog and results in an eventual null-ptr-deref (with a
> qfq or dualpi2 child).
>
> Test cases are the following:
>
> - Force multiq to dequeue from its child's gso_skb with qfq leaf (fb6c)
> - Force multiq to dequeue from its child's gso_skb with dualpi2 leaf (1922)
> - Force taprio to dequeue from its child's gso_skb with qfq leaf (476f)
> - Force taprio to dequeue from its child's gso_skb with dualpi2 leaf (0235)
>
> [1] https://lore.kernel.org/netdev/20260625-b4-disp-31bcb279-v1-0-85c40b83c529@proton.me/
>
> Signed-off-by: Victor Nogueira <victor@mojatatu.com>
Reviewed-by: Pedro Tammela <pctammela@mojatatu.com>
> ---
> .../tc-testing/tc-tests/infra/qdiscs.json | 164 ++++++++++++++++++
> 1 file changed, 164 insertions(+)
>
> diff --git a/tools/testing/selftests/tc-testing/tc-tests/infra/qdiscs.json b/tools/testing/selftests/tc-testing/tc-tests/infra/qdiscs.json
> index a1f97a4b606e..0cf12c50fb74 100644
> --- a/tools/testing/selftests/tc-testing/tc-tests/infra/qdiscs.json
> +++ b/tools/testing/selftests/tc-testing/tc-tests/infra/qdiscs.json
> @@ -1540,5 +1540,169 @@
> "$TC qdisc del dev $DUMMY root",
> "$IP addr del 10.10.10.10/24 dev $DUMMY || true"
> ]
> + },
> + {
> + "id": "fb6c",
> + "name": "Force multiq to dequeue from its child's gso_skb with qfq leaf",
> + "category": [
> + "qdisc",
> + "tbf",
> + "multiq",
> + "qfq"
> + ],
> + "plugins": {
> + "requires": "nsPlugin"
> + },
> + "setup": [
> + "echo \"1 1 4\" > /sys/bus/netdevsim/new_device",
> + "$IP link set dev $ETH up || true",
> + "$IP l set addr 01:02:03:04:05:06 dev $ETH || true",
> + "$IP n add dev $ETH 10.10.11.1 lladdr 01:02:03:04:05:06 dev $ETH || true",
> + "$IP addr add 10.10.11.10/24 dev $ETH || true",
> + "$TC qdisc add dev $ETH root handle 1: tbf rate 88bit burst 1661b peakrate 2257333 minburst 1024 limit 7b",
> + "$TC qdisc add dev $ETH parent 1: handle 2: multiq",
> + "$TC qdisc add dev $ETH parent 2:1 handle 3: qfq",
> + "$TC class add dev $ETH classid 3:1 parent 3: qfq maxpkt 512 weight 1",
> + "$TC filter add dev $ETH parent 2: protocol all prio 1 matchall action skbedit queue_mapping 0",
> + "$TC filter add dev $ETH parent 3: protocol all prio 1 matchall classid 3:1 action ok"
> + ],
> + "cmdUnderTest": "ping -c 1 10.10.11.1 -W0.01 -I$ETH || true",
> + "expExitCode": "0",
> + "verifyCmd": "$TC -s -j qdisc ls dev $ETH parent 1:",
> + "matchJSON": [
> + {
> + "kind": "multiq",
> + "handle": "2:",
> + "bytes": 98,
> + "packets": 1,
> + "backlog": 0,
> + "qlen": 0
> + }
> + ],
> + "teardown": [
> + "$TC qdisc del dev $ETH handle 1: root",
> + "echo \"1\" > /sys/bus/netdevsim/del_device"
> + ]
> + },
> + {
> + "id": "1922",
> + "name": "Force multiq to dequeue from its child's gso_skb with dualpi2 leaf",
> + "category": [
> + "qdisc",
> + "tbf",
> + "multiq",
> + "dualpi2"
> + ],
> + "plugins": {
> + "requires": "nsPlugin"
> + },
> + "setup": [
> + "echo \"1 1 4\" > /sys/bus/netdevsim/new_device",
> + "$IP link set dev $ETH up || true",
> + "$IP l set addr 01:02:03:04:05:06 dev $ETH || true",
> + "$IP n add dev $ETH 10.10.11.1 lladdr 01:02:03:04:05:06 dev $ETH || true",
> + "$IP addr add 10.10.11.10/24 dev $ETH || true",
> + "$TC qdisc add dev $ETH root handle 1: tbf rate 88bit burst 1661b peakrate 2257333 minburst 1024 limit 7b",
> + "$TC qdisc add dev $ETH parent 1: handle 2: multiq",
> + "$TC qdisc add dev $ETH parent 2:1 handle 3: dualpi2",
> + "$TC filter add dev $ETH parent 2: protocol ip prio 1 u32 match ip dst 10.10.11.1 action skbedit queue_mapping 0",
> + "$TC filter add dev $ETH parent 3: protocol ip prio 1 u32 match ip dst 10.10.11.1 classid 3:1 action ok"
> + ],
> + "cmdUnderTest": "ping -c 1 10.10.11.1 -W0.01 -I$ETH || true",
> + "expExitCode": "0",
> + "verifyCmd": "$TC -j -s qdisc ls dev $ETH handle 3:",
> + "matchJSON": [
> + {
> + "kind": "dualpi2",
> + "handle": "3:",
> + "bytes": 98,
> + "packets": 1,
> + "backlog": 0,
> + "qlen": 0
> + }
> + ],
> + "teardown": [
> + "$TC qdisc del dev $ETH handle 1: root",
> + "echo \"1\" > /sys/bus/netdevsim/del_device"
> + ]
> + },
> + {
> + "id": "476f",
> + "name": "Force taprio to dequeue from its child's gso_skb with qfq leaf",
> + "category": [
> + "qdisc",
> + "tbf",
> + "multiq",
> + "qfq"
> + ],
> + "plugins": {
> + "requires": "nsPlugin"
> + },
> + "setup": [
> + "echo \"1 1 4\" > /sys/bus/netdevsim/new_device",
> + "$IP link set dev $ETH up || true",
> + "$IP l set addr 01:02:03:04:05:06 dev $ETH || true",
> + "$IP n add dev $ETH 10.10.11.1 lladdr 01:02:03:04:05:06 dev $ETH || true",
> + "$TC qdisc add dev $ETH root handle 1: taprio num_tc 2 map 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 queues 1@0 1@1 base-time 9000000000000000000 sched-entry S 03 200000 flags 0x0 clockid CLOCK_TAI",
> + "$TC qdisc add dev $ETH parent 1:1 handle 3: qfq",
> + "$TC class add dev $ETH classid 3:1 parent 3: qfq maxpkt 512 weight 1",
> + "$TC filter add dev $ETH parent 3: protocol all prio 1 matchall classid 3:1 action ok"
> + ],
> + "cmdUnderTest": "ping -c 1 10.10.11.1 -W0.01 -I$ETH || true",
> + "expExitCode": "0",
> + "verifyCmd": "$TC -s -j qdisc ls dev $ETH",
> + "matchJSON": [
> + {
> + "kind": "taprio",
> + "handle": "1:",
> + "bytes": 98,
> + "packets": 1,
> + "backlog": 0,
> + "qlen": 0
> + }
> + ],
> + "teardown": [
> + "$TC qdisc del dev $ETH handle 1: root",
> + "echo \"1\" > /sys/bus/netdevsim/del_device"
> + ]
> + },
> + {
> + "id": "0235",
> + "name": "Force taprio to dequeue from its child's gso_skb with dualpi2 leaf",
> + "category": [
> + "qdisc",
> + "tbf",
> + "taprio",
> + "dualpi2"
> + ],
> + "plugins": {
> + "requires": "nsPlugin"
> + },
> + "setup": [
> + "echo \"1 1 4\" > /sys/bus/netdevsim/new_device",
> + "$IP link set dev $ETH up || true",
> + "$IP l set addr 01:02:03:04:05:06 dev $ETH || true",
> + "$IP n add dev $ETH 10.10.11.1 lladdr 01:02:03:04:05:06 dev $ETH || true",
> + "$TC qdisc add dev $ETH root handle 1: taprio num_tc 2 map 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 queues 1@0 1@1 base-time 9000000000000000000 sched-entry S 03 200000 flags 0x0 clockid CLOCK_TAI",
> + "$TC qdisc replace dev $ETH parent 1:1 handle 3: dualpi2",
> + "$TC filter add dev $ETH parent 3: protocol ip prio 1 u32 match ip dst 10.10.11.1 classid 3:1 action ok"
> + ],
> + "cmdUnderTest": "ping -c 1 10.10.11.1 -W0.01 -I$ETH || true",
> + "expExitCode": "0",
> + "verifyCmd": "$TC -j -s qdisc ls dev $ETH handle 3:",
> + "matchJSON": [
> + {
> + "kind": "dualpi2",
> + "handle": "3:",
> + "bytes": 98,
> + "packets": 1,
> + "backlog": 0,
> + "qlen": 0
> + }
> + ],
> + "teardown": [
> + "$TC qdisc del dev $ETH handle 1: root",
> + "echo \"1\" > /sys/bus/netdevsim/del_device"
> + ]
> }
> ]
^ permalink raw reply
* Re: [PATCH 3/3] net: stmmac: dwmac-socfpga: Add mac-mode DT property support
From: Maxime Chevallier @ 2026-06-30 15:42 UTC (permalink / raw)
To: Nazle Asmade, Muhammad Nazim Amirul, Andrew Lunn
Cc: dinguyen@kernel.org, rmk+kernel@armlinux.org.uk,
krzk+dt@kernel.org, conor+dt@kernel.org, robh@kernel.org,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, andrew+netdev@lunn.ch,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <b6c52ac8-32dc-4a58-83ec-ef600b306448@altera.com>
On 6/30/26 17:13, Nazle Asmade, Muhammad Nazim Amirul wrote:
> Yes, Agilex5 has the same concept. The GMII-to-RGMII converter is a
> Quartus soft IP instantiated in the FPGA fabric — equivalent to the
> CycloneV EMAC splitter. The XGMAC outputs GMII signals to the FPGA
> fabric, the soft IP converts them to RGMII, and the RGMII signals then
> go through the FPGA HVIO pins to the external Marvell 88E1512 PHY.
Does this converter need any special config, and does it expose any
control registers ? or is it fully autonomous ?
If it's fully autonomous, can you detect its presence through some
capability registers or something like that ?
Maxime
^ permalink raw reply
* [PATCH net] selftests/tc-testing: Add tests that force multiq and taprio to enqueue to child's gso_skb
From: Victor Nogueira @ 2026-06-30 15:36 UTC (permalink / raw)
To: davem, edumazet, kuba, pabeni, jhs, jiri
Cc: netdev, hexlabsecurity, pctammela
Add test cases to reproduce scenarios fixed recently [1] where
multiqueue and taprio forced their children into enqueueing an skb to
gso_skb (during peek), but failed to dequeue from gso_skb because they
called the child's dequeue callback directly. This causes a desync in the
child's qlen/backlog and results in an eventual null-ptr-deref (with a
qfq or dualpi2 child).
Test cases are the following:
- Force multiq to dequeue from its child's gso_skb with qfq leaf (fb6c)
- Force multiq to dequeue from its child's gso_skb with dualpi2 leaf (1922)
- Force taprio to dequeue from its child's gso_skb with qfq leaf (476f)
- Force taprio to dequeue from its child's gso_skb with dualpi2 leaf (0235)
[1] https://lore.kernel.org/netdev/20260625-b4-disp-31bcb279-v1-0-85c40b83c529@proton.me/
Signed-off-by: Victor Nogueira <victor@mojatatu.com>
---
.../tc-testing/tc-tests/infra/qdiscs.json | 164 ++++++++++++++++++
1 file changed, 164 insertions(+)
diff --git a/tools/testing/selftests/tc-testing/tc-tests/infra/qdiscs.json b/tools/testing/selftests/tc-testing/tc-tests/infra/qdiscs.json
index a1f97a4b606e..0cf12c50fb74 100644
--- a/tools/testing/selftests/tc-testing/tc-tests/infra/qdiscs.json
+++ b/tools/testing/selftests/tc-testing/tc-tests/infra/qdiscs.json
@@ -1540,5 +1540,169 @@
"$TC qdisc del dev $DUMMY root",
"$IP addr del 10.10.10.10/24 dev $DUMMY || true"
]
+ },
+ {
+ "id": "fb6c",
+ "name": "Force multiq to dequeue from its child's gso_skb with qfq leaf",
+ "category": [
+ "qdisc",
+ "tbf",
+ "multiq",
+ "qfq"
+ ],
+ "plugins": {
+ "requires": "nsPlugin"
+ },
+ "setup": [
+ "echo \"1 1 4\" > /sys/bus/netdevsim/new_device",
+ "$IP link set dev $ETH up || true",
+ "$IP l set addr 01:02:03:04:05:06 dev $ETH || true",
+ "$IP n add dev $ETH 10.10.11.1 lladdr 01:02:03:04:05:06 dev $ETH || true",
+ "$IP addr add 10.10.11.10/24 dev $ETH || true",
+ "$TC qdisc add dev $ETH root handle 1: tbf rate 88bit burst 1661b peakrate 2257333 minburst 1024 limit 7b",
+ "$TC qdisc add dev $ETH parent 1: handle 2: multiq",
+ "$TC qdisc add dev $ETH parent 2:1 handle 3: qfq",
+ "$TC class add dev $ETH classid 3:1 parent 3: qfq maxpkt 512 weight 1",
+ "$TC filter add dev $ETH parent 2: protocol all prio 1 matchall action skbedit queue_mapping 0",
+ "$TC filter add dev $ETH parent 3: protocol all prio 1 matchall classid 3:1 action ok"
+ ],
+ "cmdUnderTest": "ping -c 1 10.10.11.1 -W0.01 -I$ETH || true",
+ "expExitCode": "0",
+ "verifyCmd": "$TC -s -j qdisc ls dev $ETH parent 1:",
+ "matchJSON": [
+ {
+ "kind": "multiq",
+ "handle": "2:",
+ "bytes": 98,
+ "packets": 1,
+ "backlog": 0,
+ "qlen": 0
+ }
+ ],
+ "teardown": [
+ "$TC qdisc del dev $ETH handle 1: root",
+ "echo \"1\" > /sys/bus/netdevsim/del_device"
+ ]
+ },
+ {
+ "id": "1922",
+ "name": "Force multiq to dequeue from its child's gso_skb with dualpi2 leaf",
+ "category": [
+ "qdisc",
+ "tbf",
+ "multiq",
+ "dualpi2"
+ ],
+ "plugins": {
+ "requires": "nsPlugin"
+ },
+ "setup": [
+ "echo \"1 1 4\" > /sys/bus/netdevsim/new_device",
+ "$IP link set dev $ETH up || true",
+ "$IP l set addr 01:02:03:04:05:06 dev $ETH || true",
+ "$IP n add dev $ETH 10.10.11.1 lladdr 01:02:03:04:05:06 dev $ETH || true",
+ "$IP addr add 10.10.11.10/24 dev $ETH || true",
+ "$TC qdisc add dev $ETH root handle 1: tbf rate 88bit burst 1661b peakrate 2257333 minburst 1024 limit 7b",
+ "$TC qdisc add dev $ETH parent 1: handle 2: multiq",
+ "$TC qdisc add dev $ETH parent 2:1 handle 3: dualpi2",
+ "$TC filter add dev $ETH parent 2: protocol ip prio 1 u32 match ip dst 10.10.11.1 action skbedit queue_mapping 0",
+ "$TC filter add dev $ETH parent 3: protocol ip prio 1 u32 match ip dst 10.10.11.1 classid 3:1 action ok"
+ ],
+ "cmdUnderTest": "ping -c 1 10.10.11.1 -W0.01 -I$ETH || true",
+ "expExitCode": "0",
+ "verifyCmd": "$TC -j -s qdisc ls dev $ETH handle 3:",
+ "matchJSON": [
+ {
+ "kind": "dualpi2",
+ "handle": "3:",
+ "bytes": 98,
+ "packets": 1,
+ "backlog": 0,
+ "qlen": 0
+ }
+ ],
+ "teardown": [
+ "$TC qdisc del dev $ETH handle 1: root",
+ "echo \"1\" > /sys/bus/netdevsim/del_device"
+ ]
+ },
+ {
+ "id": "476f",
+ "name": "Force taprio to dequeue from its child's gso_skb with qfq leaf",
+ "category": [
+ "qdisc",
+ "tbf",
+ "multiq",
+ "qfq"
+ ],
+ "plugins": {
+ "requires": "nsPlugin"
+ },
+ "setup": [
+ "echo \"1 1 4\" > /sys/bus/netdevsim/new_device",
+ "$IP link set dev $ETH up || true",
+ "$IP l set addr 01:02:03:04:05:06 dev $ETH || true",
+ "$IP n add dev $ETH 10.10.11.1 lladdr 01:02:03:04:05:06 dev $ETH || true",
+ "$TC qdisc add dev $ETH root handle 1: taprio num_tc 2 map 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 queues 1@0 1@1 base-time 9000000000000000000 sched-entry S 03 200000 flags 0x0 clockid CLOCK_TAI",
+ "$TC qdisc add dev $ETH parent 1:1 handle 3: qfq",
+ "$TC class add dev $ETH classid 3:1 parent 3: qfq maxpkt 512 weight 1",
+ "$TC filter add dev $ETH parent 3: protocol all prio 1 matchall classid 3:1 action ok"
+ ],
+ "cmdUnderTest": "ping -c 1 10.10.11.1 -W0.01 -I$ETH || true",
+ "expExitCode": "0",
+ "verifyCmd": "$TC -s -j qdisc ls dev $ETH",
+ "matchJSON": [
+ {
+ "kind": "taprio",
+ "handle": "1:",
+ "bytes": 98,
+ "packets": 1,
+ "backlog": 0,
+ "qlen": 0
+ }
+ ],
+ "teardown": [
+ "$TC qdisc del dev $ETH handle 1: root",
+ "echo \"1\" > /sys/bus/netdevsim/del_device"
+ ]
+ },
+ {
+ "id": "0235",
+ "name": "Force taprio to dequeue from its child's gso_skb with dualpi2 leaf",
+ "category": [
+ "qdisc",
+ "tbf",
+ "taprio",
+ "dualpi2"
+ ],
+ "plugins": {
+ "requires": "nsPlugin"
+ },
+ "setup": [
+ "echo \"1 1 4\" > /sys/bus/netdevsim/new_device",
+ "$IP link set dev $ETH up || true",
+ "$IP l set addr 01:02:03:04:05:06 dev $ETH || true",
+ "$IP n add dev $ETH 10.10.11.1 lladdr 01:02:03:04:05:06 dev $ETH || true",
+ "$TC qdisc add dev $ETH root handle 1: taprio num_tc 2 map 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 queues 1@0 1@1 base-time 9000000000000000000 sched-entry S 03 200000 flags 0x0 clockid CLOCK_TAI",
+ "$TC qdisc replace dev $ETH parent 1:1 handle 3: dualpi2",
+ "$TC filter add dev $ETH parent 3: protocol ip prio 1 u32 match ip dst 10.10.11.1 classid 3:1 action ok"
+ ],
+ "cmdUnderTest": "ping -c 1 10.10.11.1 -W0.01 -I$ETH || true",
+ "expExitCode": "0",
+ "verifyCmd": "$TC -j -s qdisc ls dev $ETH handle 3:",
+ "matchJSON": [
+ {
+ "kind": "dualpi2",
+ "handle": "3:",
+ "bytes": 98,
+ "packets": 1,
+ "backlog": 0,
+ "qlen": 0
+ }
+ ],
+ "teardown": [
+ "$TC qdisc del dev $ETH handle 1: root",
+ "echo \"1\" > /sys/bus/netdevsim/del_device"
+ ]
}
]
--
2.54.0
^ permalink raw reply related
* Re: [PATCH net-next v5 14/15] dt-bindings: net: add onsemi's S2500
From: Rob Herring @ 2026-06-30 15:29 UTC (permalink / raw)
To: Selvamani Rajagopal
Cc: Andrew Lunn, Piergiorgio Beruto, Heiner Kallweit, Russell King,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Andrew Lunn, Parthiban Veerasooran, Richard Cochran,
Krzysztof Kozlowski, Conor Dooley, Simon Horman, Jonathan Corbet,
Shuah Khan, netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, linux-doc@vger.kernel.org, Jerry Ray
In-Reply-To: <CYYPR02MB9828308552BBC60427E8EF2283E82@CYYPR02MB9828.namprd02.prod.outlook.com>
On Mon, Jun 29, 2026 at 12:07 PM Selvamani Rajagopal
<Selvamani.Rajagopal@onsemi.com> wrote:
>
> > -----Original Message-----
> > From: Rob Herring <robh@kernel.org>
> > Sent: Sunday, June 14, 2026 9:11 PM
> > To: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>
> > Subject: Re: [PATCH net-next v5 14/15] dt-bindings: net: add onsemi's S2500
> >
> >
> >
> > And you are missing tags from prior versions. It is your responsibility
> > to add them.
>
> I added the prior version's link under each version. Somehow "b4 prep --show-revision" command doesn't pickup the older
> versions. It shows v4 and v5 correctly as the emails containing patches were sent in a threaded manner.
>
> But with v1,v2,v3, as each patch was sent through individual email (with proper subject line, of course) using outlook.
> I don't know if there is a way to fix this.
While links to prior versions is nice, tags means Reviewed-by,
Acked-by, etc. lines. If you get those on version N, then you have to
add them on version N+1 and later unless there are significant changes
that nullify them. However, you don't need to send another version
only to add tags. The tools will pickup tags from the current version.
The only advice for outlook is don't use it. It is incapable of
following maillist etiquette.
Rob
^ permalink raw reply
* Re: [PATCH v2 10/19] pmdomain: imx: use platform_device_set_of_node()
From: Frank Li @ 2026-06-30 15:27 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Lee Jones, Mark Brown, Thierry Reding, Sebastian Hesselbarth,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Srinivas Kandagatla, Greg Kroah-Hartman, Vinod Koul,
Rafael J. Wysocki, Danilo Krummrich, Rob Herring, Saravana Kannan,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Andi Shyti, Andy Shevchenko,
Joerg Roedel, Will Deacon, Robin Murphy, Doug Berger,
Florian Fainelli, Broadcom internal kernel review list,
Ulf Hansson, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Matthew Brost, Thomas Hellström, Rodrigo Vivi,
David Airlie, Simona Vetter, Peter Chen, Paul Cercueil, Bin Liu,
Philipp Zabel, Maximilian Luz, Hans de Goede, Ilpo Järvinen,
Krzysztof Kozlowski, Benjamin Herrenschmidt, brgl, linux-kernel,
netdev, linux-arm-msm, linux-sound, driver-core, devicetree,
linuxppc-dev, linux-i2c, iommu, linux-pm, imx, linux-arm-kernel,
intel-xe, dri-devel, linux-usb, linux-mips, platform-driver-x86
In-Reply-To: <20260629-pdev-fwnode-ref-v2-10-8abe2513f96e@oss.qualcomm.com>
On Mon, Jun 29, 2026 at 11:12:33AM +0200, Bartosz Golaszewski wrote:
>
> Ahead of reworking the reference counting logic for platform devices,
> encapsulate the assignment of the OF node for dynamically allocated
> platform devices with the provided helper.
>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> drivers/pmdomain/imx/gpc.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/pmdomain/imx/gpc.c b/drivers/pmdomain/imx/gpc.c
> index 42e50c9b4fb9ffb96a20a462d4eb5168942a893c..abca5f449a226fbae4213926e1395c413160c950 100644
> --- a/drivers/pmdomain/imx/gpc.c
> +++ b/drivers/pmdomain/imx/gpc.c
> @@ -487,8 +487,7 @@ static int imx_gpc_probe(struct platform_device *pdev)
> domain->ipg_rate_mhz = ipg_rate_mhz;
>
> pd_pdev->dev.parent = &pdev->dev;
> - pd_pdev->dev.of_node = of_node_get(np);
> - pd_pdev->dev.fwnode = of_fwnode_handle(np);
> + platform_device_set_of_node(pd_pdev, np);
>
> ret = platform_device_add(pd_pdev);
> if (ret) {
>
> --
> 2.47.3
>
>
^ permalink raw reply
* Re: [PATCH 2/3] arm64: dts: socfpga: agilex5: Add SoCDK TSN Config2 board
From: Andrew Lunn @ 2026-06-30 15:25 UTC (permalink / raw)
To: Nazle Asmade, Muhammad Nazim Amirul
Cc: dinguyen@kernel.org, maxime.chevallier@bootlin.com,
rmk+kernel@armlinux.org.uk, krzk+dt@kernel.org,
conor+dt@kernel.org, robh@kernel.org, davem@davemloft.net,
edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
andrew+netdev@lunn.ch, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <347c50ed-234a-4f29-b63a-1e0010c6b09d@altera.com>
On Tue, Jun 30, 2026 at 02:39:50PM +0000, Nazle Asmade, Muhammad Nazim Amirul wrote:
> On 30/6/2026 9:58 pm, Andrew Lunn wrote:
> >> + * gmac1 is the TSN port. The MAC operates in GMII mode internally
> >> + * while the PHY-side interface is RGMII, so mac-mode and phy-mode differ.
> >> + */
> >> +&gmac1 {
> >> + status = "okay";
> >> + phy-mode = "rgmii"; /* TX/RX clock delays provided by Agilex5 I/O hardware */
> > Could you provide more details about this. I want to understand the
> > big picture.
> >
> > Normally we talk about the PCB providing the delays. This sounds like
> > it is the FPGA? So i need convincing this is correct.
> Hi Andrew,
>
> Thanks for your quick review and yes, it is the FPGA — specifically a
> soft IP block in the FPGA fabric that implements the RGMII clock delays
> and is configured before Linux boots via the FPGA bitstream. The driver
> must not add additional delays on top.
So it depends on how the converter block is described, but ....
From a big picture, MAC and PHY pair, it is the MAC which
implements the delays.
https://elixir.bootlin.com/linux/v6.15/source/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L346
# There are a small number of cases where the MAC has hard coded
# delays which cannot be disabled. The 'phy-mode' only describes the
# PCB. The inability to disable the delays in the MAC does not change
# the meaning of 'phy-mode'. It does however mean that a 'phy-mode' of
# 'rgmii' is now invalid, it cannot be supported, since both the PCB
# and the MAC and PHY adding delays cannot result in a functional
# link. Thus the MAC should report a fatal error for any modes which
# cannot be supported. When the MAC implements the delay, it must
# ensure that the PHY does not also implement the same delay. So it
# must modify the phy-mode it passes to the PHY, removing the delay it
# has added. Failure to remove the delay will result in a
# non-functioning link.
Andrew
---
pw-bot: cr
^ permalink raw reply
* [ANN] netdev foundation TSC meeting notes - Jun 30th
From: Jakub Kicinski @ 2026-06-30 15:25 UTC (permalink / raw)
To: netdev
Present: Eric, Jakub, Johannes, Kuniyuki, Simon, Willem, Paolo
Academic Research program
- Revised with:
- Limit of USD 50k/grant
- Simon as email contact (happy for an alias to be created instead)
- Contacted board for funding approval, expect them to meet in
coming weeks to discuss
Netconf:
- on the first day of Netdev 0x1A. 13th July
- Have room for ~20 people
- Finalizing invites today / tomorrow
- Driver upstreaming challenges, some drivers reaching v50
- May be more suitable for a broader discussion / driver BoF?
- Foundation sponsorship for a meal
- Double check what netdev.conf has planned
Logo
- Some delay in paperwork due to the complexity of it
- Now aiming for LPC rather than Netdev
- Comments on the draft sheet
- Mesh in the background would be good to represent networking
- Yes on tux, otherwise the logs are generic, but need a distinct one
- A voting sheeting to grade the suggestions to be circulated
Wireless CI running on netdev foundation infra
^ permalink raw reply
* Re: [PATCH net 2/3] net/sched: Handle TC_ACT_REDIRECT from qdisc filter chains
From: Daniel Borkmann @ 2026-06-30 15:23 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: kuba, pabeni, bigeasy, andrii, memxor, bpf, netdev,
Victor Nogueira
In-Reply-To: <CAM0EoMn6H6cKCweHmt=8ve2i0JuK=E8W1Q89oqDD7vra_Uuk-w@mail.gmail.com>
On 6/30/26 5:16 PM, Jamal Hadi Salim wrote:
> On Tue, Jun 30, 2026 at 8:33 AM Daniel Borkmann <daniel@iogearbox.net> wrote:
>> From: Jamal Hadi Salim <jhs@mojatatu.com>
>>
>> When a TC filter attached to a qdisc filter chain returns
>> TC_ACT_REDIRECT (ex: via an eBPF program calling bpf_redirect() or an
>> act_bpf action), the redirect was silently lost i.e no qdisc classify
>> function handled TC_ACT_REDIRECT, so the packet fell through the
>> switch and was enqueued normally instead of being redirected.
>>
>> This has been broken since bpf_redirect() was introduced for TC in
>> commit 27b29f63058d ("bpf: add bpf_redirect() helper"). We got lucky
>> for a long time because bpf_net_context was a per-CPU variable that
>> was always available.
>>
>> commit 401cb7dae813 ("net: Reference bpf_redirect_info via task_struct
>> on PREEMPT_RT.") turned bpf_net_context into a task_struct member that
>> is only set up by explicit callers. Without a caller setting it up,
>> bpf_redirect() itself crashes with a NULL pointer dereference in
>> bpf_net_ctx_get_ri(). However, even with bpf_net_context available,
>> TC_ACT_REDIRECT from qdisc filter chains cannot be honored without
>> adding skb_do_redirect() calls to every qdisc classify function, which
>> would require changes across net/sched/. Isolate it to ebpf core where
>> it belongs.
>>
>> Instead, add a tcf_classify_qdisc() inline helper in pkt_cls.h, as a
>> wrapper around tcf_classify() for use by qdisc classify functions and
>> tcf_qevent_handle(). When the classify verdict is TC_ACT_REDIRECT,
>> the wrapper converts it to TC_ACT_SHOT, dropping the packet rather
>> than letting it continue silently. Dropping is preferred over
>> letting the packet through because the user immediately sees packet
>> loss. Silently passing the packet through would hide the problem and
>> leave the user wondering why their redirect is not working.
>>
>> The clsact fast path, tc_run() continues to call tcf_classify() directly
>> and is unaffected: TC_ACT_REDIRECT is returned as-is and handled by
>> sch_handle_egress/ingress() calling skb_do_redirect() as before.
>>
>> Fixes: 27b29f63058d ("bpf: add bpf_redirect() helper")
>> Fixes: 401cb7dae813 ("net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.")
>> Tested-by: Victor Nogueira <victor@mojatatu.com>
>> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
>> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
>> ---
>> include/net/pkt_cls.h | 14 +++++++++++++-
>> net/sched/cls_api.c | 4 +---
>> net/sched/sch_cake.c | 2 +-
>> net/sched/sch_drr.c | 2 +-
>> net/sched/sch_dualpi2.c | 2 +-
>> net/sched/sch_ets.c | 2 +-
>> net/sched/sch_fq_codel.c | 2 +-
>> net/sched/sch_fq_pie.c | 2 +-
>> net/sched/sch_hfsc.c | 2 +-
>> net/sched/sch_htb.c | 2 +-
>> net/sched/sch_multiq.c | 2 +-
>> net/sched/sch_prio.c | 2 +-
>> net/sched/sch_qfq.c | 2 +-
>> net/sched/sch_sfb.c | 2 +-
>> net/sched/sch_sfq.c | 2 +-
>> 15 files changed, 27 insertions(+), 17 deletions(-)
>>
>> diff --git a/include/net/pkt_cls.h b/include/net/pkt_cls.h
>> index 3bd08d7f39c1..5f5cb36439fe 100644
>> --- a/include/net/pkt_cls.h
>> +++ b/include/net/pkt_cls.h
>> @@ -156,8 +156,20 @@ static inline int tcf_classify(struct sk_buff *skb,
>> {
>> return TC_ACT_UNSPEC;
>> }
>> -
>> #endif
>> +static inline int tcf_classify_qdisc(struct sk_buff *skb,
>> + const struct tcf_proto *tp,
>> + struct tcf_result *res, bool compat_mode)
>> +{
>> + int ret = tcf_classify(skb, NULL, tp, res, compat_mode);
>> +
>> + /* TC_ACT_REDIRECT from qdisc filter chains is not supported.
>> + * Use BPF via tcx or mirred redirect instead.
>> + */
>> + if (unlikely(ret == TC_ACT_REDIRECT))
>> + ret = TC_ACT_SHOT;
>> + return ret;
>> +}
>
> Why did you remove the warning?
> A lesser issue is that you introduced a space above #endif
I don't think we need to put out an extra warn to spam the log, this
can be easily traced either via bpftrace or qdisc stats etc; plus the
guidance to eBPF with clsact is also obsolete. Given noone has run
into this the last 10y, I don't think it really matters tbh.
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH net 2/3] net/sched: Handle TC_ACT_REDIRECT from qdisc filter chains
From: Jamal Hadi Salim @ 2026-06-30 15:16 UTC (permalink / raw)
To: Daniel Borkmann
Cc: kuba, pabeni, bigeasy, andrii, memxor, bpf, netdev,
Victor Nogueira
In-Reply-To: <20260630123331.186840-3-daniel@iogearbox.net>
On Tue, Jun 30, 2026 at 8:33 AM Daniel Borkmann <daniel@iogearbox.net> wrote:
>
> From: Jamal Hadi Salim <jhs@mojatatu.com>
>
> When a TC filter attached to a qdisc filter chain returns
> TC_ACT_REDIRECT (ex: via an eBPF program calling bpf_redirect() or an
> act_bpf action), the redirect was silently lost i.e no qdisc classify
> function handled TC_ACT_REDIRECT, so the packet fell through the
> switch and was enqueued normally instead of being redirected.
>
> This has been broken since bpf_redirect() was introduced for TC in
> commit 27b29f63058d ("bpf: add bpf_redirect() helper"). We got lucky
> for a long time because bpf_net_context was a per-CPU variable that
> was always available.
>
> commit 401cb7dae813 ("net: Reference bpf_redirect_info via task_struct
> on PREEMPT_RT.") turned bpf_net_context into a task_struct member that
> is only set up by explicit callers. Without a caller setting it up,
> bpf_redirect() itself crashes with a NULL pointer dereference in
> bpf_net_ctx_get_ri(). However, even with bpf_net_context available,
> TC_ACT_REDIRECT from qdisc filter chains cannot be honored without
> adding skb_do_redirect() calls to every qdisc classify function, which
> would require changes across net/sched/. Isolate it to ebpf core where
> it belongs.
>
> Instead, add a tcf_classify_qdisc() inline helper in pkt_cls.h, as a
> wrapper around tcf_classify() for use by qdisc classify functions and
> tcf_qevent_handle(). When the classify verdict is TC_ACT_REDIRECT,
> the wrapper converts it to TC_ACT_SHOT, dropping the packet rather
> than letting it continue silently. Dropping is preferred over
> letting the packet through because the user immediately sees packet
> loss. Silently passing the packet through would hide the problem and
> leave the user wondering why their redirect is not working.
>
> The clsact fast path, tc_run() continues to call tcf_classify() directly
> and is unaffected: TC_ACT_REDIRECT is returned as-is and handled by
> sch_handle_egress/ingress() calling skb_do_redirect() as before.
>
> Fixes: 27b29f63058d ("bpf: add bpf_redirect() helper")
> Fixes: 401cb7dae813 ("net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.")
> Tested-by: Victor Nogueira <victor@mojatatu.com>
> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
> ---
> include/net/pkt_cls.h | 14 +++++++++++++-
> net/sched/cls_api.c | 4 +---
> net/sched/sch_cake.c | 2 +-
> net/sched/sch_drr.c | 2 +-
> net/sched/sch_dualpi2.c | 2 +-
> net/sched/sch_ets.c | 2 +-
> net/sched/sch_fq_codel.c | 2 +-
> net/sched/sch_fq_pie.c | 2 +-
> net/sched/sch_hfsc.c | 2 +-
> net/sched/sch_htb.c | 2 +-
> net/sched/sch_multiq.c | 2 +-
> net/sched/sch_prio.c | 2 +-
> net/sched/sch_qfq.c | 2 +-
> net/sched/sch_sfb.c | 2 +-
> net/sched/sch_sfq.c | 2 +-
> 15 files changed, 27 insertions(+), 17 deletions(-)
>
> diff --git a/include/net/pkt_cls.h b/include/net/pkt_cls.h
> index 3bd08d7f39c1..5f5cb36439fe 100644
> --- a/include/net/pkt_cls.h
> +++ b/include/net/pkt_cls.h
> @@ -156,8 +156,20 @@ static inline int tcf_classify(struct sk_buff *skb,
> {
> return TC_ACT_UNSPEC;
> }
> -
> #endif
> +static inline int tcf_classify_qdisc(struct sk_buff *skb,
> + const struct tcf_proto *tp,
> + struct tcf_result *res, bool compat_mode)
> +{
> + int ret = tcf_classify(skb, NULL, tp, res, compat_mode);
> +
> + /* TC_ACT_REDIRECT from qdisc filter chains is not supported.
> + * Use BPF via tcx or mirred redirect instead.
> + */
> + if (unlikely(ret == TC_ACT_REDIRECT))
> + ret = TC_ACT_SHOT;
> + return ret;
> +}
>
Why did you remove the warning?
A lesser issue is that you introduced a space above #endif
cheers,
jamal
> static inline unsigned long
> __cls_set_class(unsigned long *clp, unsigned long cl)
> diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
> index ac49ca6d9a0c..3ca56d060e28 100644
> --- a/net/sched/cls_api.c
> +++ b/net/sched/cls_api.c
> @@ -4033,9 +4033,7 @@ struct sk_buff *tcf_qevent_handle(struct tcf_qevent *qe, struct Qdisc *sch, stru
>
> fl = rcu_dereference_bh(qe->filter_chain);
>
> - switch (tcf_classify(skb, NULL, fl, &cl_res, false)) {
> - case TC_ACT_REDIRECT:
> - fallthrough;
> + switch (tcf_classify_qdisc(skb, fl, &cl_res, false)) {
> case TC_ACT_SHOT:
> qdisc_qstats_drop(sch);
> __qdisc_drop(skb, to_free);
> diff --git a/net/sched/sch_cake.c b/net/sched/sch_cake.c
> index a3c185505afc..94eb47ac54ee 100644
> --- a/net/sched/sch_cake.c
> +++ b/net/sched/sch_cake.c
> @@ -1730,7 +1730,7 @@ static u32 cake_classify(struct Qdisc *sch, struct cake_tin_data **t,
> goto hash;
>
> *qerr = NET_XMIT_SUCCESS | __NET_XMIT_BYPASS;
> - result = tcf_classify(skb, NULL, filter, &res, false);
> + result = tcf_classify_qdisc(skb, filter, &res, false);
>
> if (result >= 0) {
> #ifdef CONFIG_NET_CLS_ACT
> diff --git a/net/sched/sch_drr.c b/net/sched/sch_drr.c
> index 020657f959b5..91b1ef824afa 100644
> --- a/net/sched/sch_drr.c
> +++ b/net/sched/sch_drr.c
> @@ -312,7 +312,7 @@ static struct drr_class *drr_classify(struct sk_buff *skb, struct Qdisc *sch,
>
> *qerr = NET_XMIT_SUCCESS | __NET_XMIT_BYPASS;
> fl = rcu_dereference_bh(q->filter_list);
> - result = tcf_classify(skb, NULL, fl, &res, false);
> + result = tcf_classify_qdisc(skb, fl, &res, false);
> if (result >= 0) {
> #ifdef CONFIG_NET_CLS_ACT
> switch (result) {
> diff --git a/net/sched/sch_dualpi2.c b/net/sched/sch_dualpi2.c
> index 5434df6ca8ef..98364f74211e 100644
> --- a/net/sched/sch_dualpi2.c
> +++ b/net/sched/sch_dualpi2.c
> @@ -364,7 +364,7 @@ static int dualpi2_skb_classify(struct dualpi2_sched_data *q,
> return NET_XMIT_SUCCESS;
> }
>
> - result = tcf_classify(skb, NULL, fl, &res, false);
> + result = tcf_classify_qdisc(skb, fl, &res, false);
> if (result >= 0) {
> #ifdef CONFIG_NET_CLS_ACT
> switch (result) {
> diff --git a/net/sched/sch_ets.c b/net/sched/sch_ets.c
> index cb8cf437ce87..25fcf4079fec 100644
> --- a/net/sched/sch_ets.c
> +++ b/net/sched/sch_ets.c
> @@ -391,7 +391,7 @@ static struct ets_class *ets_classify(struct sk_buff *skb, struct Qdisc *sch,
> *qerr = NET_XMIT_SUCCESS | __NET_XMIT_BYPASS;
> if (TC_H_MAJ(skb->priority) != sch->handle) {
> fl = rcu_dereference_bh(q->filter_list);
> - err = tcf_classify(skb, NULL, fl, &res, false);
> + err = tcf_classify_qdisc(skb, fl, &res, false);
> #ifdef CONFIG_NET_CLS_ACT
> switch (err) {
> case TC_ACT_STOLEN:
> diff --git a/net/sched/sch_fq_codel.c b/net/sched/sch_fq_codel.c
> index cafd1f943d99..6cce86ba383c 100644
> --- a/net/sched/sch_fq_codel.c
> +++ b/net/sched/sch_fq_codel.c
> @@ -91,7 +91,7 @@ static unsigned int fq_codel_classify(struct sk_buff *skb, struct Qdisc *sch,
> return fq_codel_hash(q, skb) + 1;
>
> *qerr = NET_XMIT_SUCCESS | __NET_XMIT_BYPASS;
> - result = tcf_classify(skb, NULL, filter, &res, false);
> + result = tcf_classify_qdisc(skb, filter, &res, false);
> if (result >= 0) {
> #ifdef CONFIG_NET_CLS_ACT
> switch (result) {
> diff --git a/net/sched/sch_fq_pie.c b/net/sched/sch_fq_pie.c
> index 72f48fa4010b..069e1facd413 100644
> --- a/net/sched/sch_fq_pie.c
> +++ b/net/sched/sch_fq_pie.c
> @@ -96,7 +96,7 @@ static unsigned int fq_pie_classify(struct sk_buff *skb, struct Qdisc *sch,
> return fq_pie_hash(q, skb) + 1;
>
> *qerr = NET_XMIT_SUCCESS | __NET_XMIT_BYPASS;
> - result = tcf_classify(skb, NULL, filter, &res, false);
> + result = tcf_classify_qdisc(skb, filter, &res, false);
> if (result >= 0) {
> #ifdef CONFIG_NET_CLS_ACT
> switch (result) {
> diff --git a/net/sched/sch_hfsc.c b/net/sched/sch_hfsc.c
> index 7e537295b8b6..e87f5021a199 100644
> --- a/net/sched/sch_hfsc.c
> +++ b/net/sched/sch_hfsc.c
> @@ -1143,7 +1143,7 @@ hfsc_classify(struct sk_buff *skb, struct Qdisc *sch, int *qerr)
> *qerr = NET_XMIT_SUCCESS | __NET_XMIT_BYPASS;
> head = &q->root;
> tcf = rcu_dereference_bh(q->root.filter_list);
> - while (tcf && (result = tcf_classify(skb, NULL, tcf, &res, false)) >= 0) {
> + while (tcf && (result = tcf_classify_qdisc(skb, tcf, &res, false)) >= 0) {
> #ifdef CONFIG_NET_CLS_ACT
> switch (result) {
> case TC_ACT_QUEUED:
> diff --git a/net/sched/sch_htb.c b/net/sched/sch_htb.c
> index 908b9ba9ba2e..fdac0dc8f35a 100644
> --- a/net/sched/sch_htb.c
> +++ b/net/sched/sch_htb.c
> @@ -243,7 +243,7 @@ static struct htb_class *htb_classify(struct sk_buff *skb, struct Qdisc *sch,
> }
>
> *qerr = NET_XMIT_SUCCESS | __NET_XMIT_BYPASS;
> - while (tcf && (result = tcf_classify(skb, NULL, tcf, &res, false)) >= 0) {
> + while (tcf && (result = tcf_classify_qdisc(skb, tcf, &res, false)) >= 0) {
> #ifdef CONFIG_NET_CLS_ACT
> switch (result) {
> case TC_ACT_QUEUED:
> diff --git a/net/sched/sch_multiq.c b/net/sched/sch_multiq.c
> index 4e465d11e3d7..004f0d275caf 100644
> --- a/net/sched/sch_multiq.c
> +++ b/net/sched/sch_multiq.c
> @@ -36,7 +36,7 @@ multiq_classify(struct sk_buff *skb, struct Qdisc *sch, int *qerr)
> int err;
>
> *qerr = NET_XMIT_SUCCESS | __NET_XMIT_BYPASS;
> - err = tcf_classify(skb, NULL, fl, &res, false);
> + err = tcf_classify_qdisc(skb, fl, &res, false);
> #ifdef CONFIG_NET_CLS_ACT
> switch (err) {
> case TC_ACT_STOLEN:
> diff --git a/net/sched/sch_prio.c b/net/sched/sch_prio.c
> index e4dd56a89072..79437c587e7e 100644
> --- a/net/sched/sch_prio.c
> +++ b/net/sched/sch_prio.c
> @@ -39,7 +39,7 @@ prio_classify(struct sk_buff *skb, struct Qdisc *sch, int *qerr)
> *qerr = NET_XMIT_SUCCESS | __NET_XMIT_BYPASS;
> if (TC_H_MAJ(skb->priority) != sch->handle) {
> fl = rcu_dereference_bh(q->filter_list);
> - err = tcf_classify(skb, NULL, fl, &res, false);
> + err = tcf_classify_qdisc(skb, fl, &res, false);
> #ifdef CONFIG_NET_CLS_ACT
> switch (err) {
> case TC_ACT_STOLEN:
> diff --git a/net/sched/sch_qfq.c b/net/sched/sch_qfq.c
> index cb56787e1d25..6f3b7273cb16 100644
> --- a/net/sched/sch_qfq.c
> +++ b/net/sched/sch_qfq.c
> @@ -709,7 +709,7 @@ static struct qfq_class *qfq_classify(struct sk_buff *skb, struct Qdisc *sch,
>
> *qerr = NET_XMIT_SUCCESS | __NET_XMIT_BYPASS;
> fl = rcu_dereference_bh(q->filter_list);
> - result = tcf_classify(skb, NULL, fl, &res, false);
> + result = tcf_classify_qdisc(skb, fl, &res, false);
> if (result >= 0) {
> #ifdef CONFIG_NET_CLS_ACT
> switch (result) {
> diff --git a/net/sched/sch_sfb.c b/net/sched/sch_sfb.c
> index b1d465094276..ed39869199c0 100644
> --- a/net/sched/sch_sfb.c
> +++ b/net/sched/sch_sfb.c
> @@ -260,7 +260,7 @@ static bool sfb_classify(struct sk_buff *skb, struct tcf_proto *fl,
> struct tcf_result res;
> int result;
>
> - result = tcf_classify(skb, NULL, fl, &res, false);
> + result = tcf_classify_qdisc(skb, fl, &res, false);
> if (result >= 0) {
> #ifdef CONFIG_NET_CLS_ACT
> switch (result) {
> diff --git a/net/sched/sch_sfq.c b/net/sched/sch_sfq.c
> index 758b88f21865..77675f9a4c46 100644
> --- a/net/sched/sch_sfq.c
> +++ b/net/sched/sch_sfq.c
> @@ -171,7 +171,7 @@ static unsigned int sfq_classify(struct sk_buff *skb, struct Qdisc *sch,
> return sfq_hash(q, skb) + 1;
>
> *qerr = NET_XMIT_SUCCESS | __NET_XMIT_BYPASS;
> - result = tcf_classify(skb, NULL, fl, &res, false);
> + result = tcf_classify_qdisc(skb, fl, &res, false);
> if (result >= 0) {
> #ifdef CONFIG_NET_CLS_ACT
> switch (result) {
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH 3/3] net: stmmac: dwmac-socfpga: Add mac-mode DT property support
From: Nazle Asmade, Muhammad Nazim Amirul @ 2026-06-30 15:13 UTC (permalink / raw)
To: Maxime Chevallier, Andrew Lunn
Cc: dinguyen@kernel.org, rmk+kernel@armlinux.org.uk,
krzk+dt@kernel.org, conor+dt@kernel.org, robh@kernel.org,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, andrew+netdev@lunn.ch,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <7c57bb08-b72d-44bf-be44-f1bcb2aa9a84@bootlin.com>
On 30/6/2026 10:04 pm, Maxime Chevallier wrote:
> On 6/30/26 16:02, Andrew Lunn wrote:
>> On Tue, Jun 30, 2026 at 06:31:08AM -0700, muhammad.nazim.amirul.nazle.asmade@altera.com wrote:
>>> From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
>>>
>>> Russell King's commit de696c63c1dc ("net: stmmac: socfpga: convert to
>>> use phy_interface") replaced mac_interface with phy_interface in
>>> socfpga_get_plat_phymode(), noting that no upstream DTS files set the
>>> "mac-mode" property, making the two values identical.
>>>
>>> The Agilex5 SoCDK TSN Config2 board is an exception: its gmac1 TSN
>>> port uses GMII internally in the MAC while the PHY-side interface is
>>> RGMII, so mac-mode and phy-mode differ.
>>
>> Maybe you need to represent the hardware block which magically
>> converts GMII to RGMII in DT?
>
> Yeah that's what we have on CycloneV, and we force the INTF_SEL to GMII if that
> HW block is present. I wonder if there's the same on agileX5 ?
Hi Maxime, Andrew
Yes, Agilex5 has the same concept. The GMII-to-RGMII converter is a
Quartus soft IP instantiated in the FPGA fabric — equivalent to the
CycloneV EMAC splitter. The XGMAC outputs GMII signals to the FPGA
fabric, the soft IP converts them to RGMII, and the RGMII signals then
go through the FPGA HVIO pins to the external Marvell 88E1512 PHY.
BR,
Nazim>
>>
>> Andrew
>
^ permalink raw reply
* Re: [PATCH net v3 1/1] net/sched: sch_teql: Introduce slaves_lock to avoid race condition and UAF
From: Jamal Hadi Salim @ 2026-06-30 15:12 UTC (permalink / raw)
To: Paolo Abeni
Cc: netdev, davem, edumazet, kuba, horms, victor, jiri, security,
zdi-disclosures, stable
In-Reply-To: <3dab7c8e-aed3-41f2-97e0-558c7a82f925@redhat.com>
On Tue, Jun 30, 2026 at 10:12 AM Paolo Abeni <pabeni@redhat.com> wrote:
>
> On 6/30/26 1:49 PM, Jamal Hadi Salim wrote:
> > On Tue, Jun 30, 2026 at 7:15 AM Paolo Abeni <pabeni@redhat.com> wrote:
> >> On 6/28/26 1:12 PM, Jamal Hadi Salim wrote:
> >>> The teql master->slaves singly linked list is not protected against
> >>> multiple writes. It can be mod'ed concurently from teql_master_xmit(),
> >>> teql_dequeue(), teql_init() and teql_destroy() without holding any list
> >>> lock or RCU protection.
> >>>
> >>> zdi-disclosures@trendmicro.com has demonstrated that the qdisc is freed
> >>> after an RCU grace period, but teql_master_xmit() running on another
> >>> CPU can still hold a stale pointer into the list, resulting in a
> >>> slab-use-after-free:
> >>>
> >>> BUG: KASAN: slab-use-after-free in teql_master_xmit+0xf0f/0x16b0
> >>> Read of size 8 at addr ffff888013fb0440 by task poc/332
> >>> Freed 512-byte region [ffff888013fb0400, ffff888013fb0600) (kmalloc-512)
> >>>
> >>> The fix?
> >>> Add a per-master slaves_lock spinlock that serializes all mutations of
> >>> master->slaves and the NEXT_SLAVE() links in teql_destroy() and
> >>> teql_qdisc_init(). teql_master_xmit() also takes the same slaves_lock
> >>> around those updates.
> >>> Annotate master->slaves and the per-slave ->next pointer with __rcu and
> >>> use the appropriate RCU accessors everywhere they are touched:
> >>> rcu_assign_pointer() on the writer side (under slaves_lock),
> >>> rcu_dereference_protected() for the writer-side loads (also under
> >>> slaves_lock), rcu_dereference_bh() for the loads in teql_master_xmit() and
> >>> rtnl_dereference() for the loads in teql_master_open()/teql_master_mtu(),
> >>> which run under RTNL.
> >>> Pair this with rcu_read_lock_bh()/rcu_read_unlock_bh() around the list
> >>> traversal in teql_master_xmit(), so that readers either observe a fully
> >>> linked list or are deferred until the in-flight mutation completes. The two
> >>> early-return paths in teql_master_xmit() are updated to release the RCU-bh
> >>> read-side critical section before returning, since leaving it held would
> >>> disable BH on that CPU for good.
> >>>
> >>> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> >>> Reported-by: zdi-disclosures@trendmicro.com
> >>> Tested-by: Victor Nogueira <victor@mojatatu.com>
> >>> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
> >>
> >> Looks good, thanks!
> >>
> >> Please note that sashiko/gemini found a pre-existing issues which may
> >> require a follow-up/separate fix:
> >>
> >> https://sashiko.dev/#/patchset/20260628111229.669751-1-jhs%40mojatatu.com
> >>
> >> (the 2nd one in the above link, IDK how to generate a direct link to a
> >> specific comment)
> >
> > I just sent v4 which covered that but i will send a followup instead
> > if you already applied.
>
> The PW bot is went on vacation and no 'patch applied' notification is
> reaching the ML; v3 is already applied.
>
> > BTW: What is the ruling on when Sashiko finds a pre-existing issue?
> > Should we address that as a separate follow-up patch? It is unclear
> > what the policy is.
>
> The general guidance is that pre-existing issues should be addressed
> separately.
>
Ok - i think it would help if this was documented somewhere..
> > This teql patch was one of the hardest to deal with in terms of
> > reproduciability and the fact sashiko kept coming up with pre-existing
> > issues - including the one Simon and I were discussing. Note: None of
> > the pre-existing issues affected reproducibility at all although i am
> > sure one of the AI-kiddies reading the sashiko reports will find a way
> > to create a poc (this is why i entertain fixing them when they look
> > simple enough)
> Not an ideal situation both ways (which is increasingly the case).
>
> Addressing incrementally pre-existing issues can lead to an huge/endless
> number of iterations when touching some unfortunate area (4 is _not_ a
> big number ;) delaying the actual fix indefinitely.
>
Agreed. I guess i get anxious the AI-kiddies seem to be following
sashiko and as soon as it complains about something they immediately
followup looking for new vectors and i feel like i will be going back
to fixing the next issue ;->
I just sent a followup.
cheers,
jamal
> /P
>
>
^ 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