netdev CI testing #6666
Open
netdev CI testing #6666
+4,141
−5,161
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
kernel-patches-daemon-bpf
bot
force-pushed
the
bpf-next_base
branch
3 times, most recently
from
4f22ee0 to
8a9a8e0
Compare
kuba-moo
force-pushed
the
to-test
branch
11 times, most recently
from
64c403f to
8da1f58
Compare
kernel-patches-daemon-bpf
bot
force-pushed
the
bpf-next_base
branch
3 times, most recently
from
78ebb17 to
9325308
Compare
kuba-moo
force-pushed
the
to-test
branch
6 times, most recently
from
c8c7b2f to
a71aae6
Compare
kernel-patches-daemon-bpf
bot
force-pushed
the
bpf-next_base
branch
from
9325308 to
7940ae1
Compare
kuba-moo
force-pushed
the
to-test
branch
2 times, most recently
from
d8feb00 to
b16a6b9
Compare
kernel-patches-daemon-bpf
bot
force-pushed
the
bpf-next_base
branch
from
7940ae1 to
8f1ff3c
Compare
kuba-moo
force-pushed
the
to-test
branch
2 times, most recently
from
4164329 to
c5cecb3
Compare
The kernel robot reported the following errors when the netc-lib driver was compiled as a loadable module and the enetc-core driver was built-in. ld.lld: error: undefined symbol: ntmp_init_cbdr referenced by enetc_cbdr.c:88 (drivers/net/ethernet/freescale/enetc/enetc_cbdr.c:88) ld.lld: error: undefined symbol: ntmp_free_cbdr referenced by enetc_cbdr.c:96 (drivers/net/ethernet/freescale/enetc/enetc_cbdr.c:96) Simply changing "tristate" to "bool" can fix this issue, but considering that the netc-lib driver needs to support being compiled as a loadable module and LS1028 does not need the netc-lib driver. Therefore, we add a boolean symbol 'NXP_NTMP' to enable 'NXP_NETC_LIB' as needed. And when adding NETC switch driver support in the future, there is no need to modify the dependency, just select "NXP_NTMP" and "NXP_NETC_LIB" at the same time. Reported-by: Arnd Bergmann <[email protected]> Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Fixes: 4701073 ("net: enetc: add initial netc-lib driver to support NTMP") Suggested-by: Arnd Bergmann <[email protected]> Signed-off-by: Wei Fang <[email protected]> Reviewed-by: Vladimir Oltean <[email protected]> Signed-off-by: David S. Miller <[email protected]>
kuba-moo
force-pushed
the
to-test
branch
2 times, most recently
from
b79338e to
f5ce398
Compare
According to 802.1AE standard, when ES and SC flags in TCI are zero, used SCI should be the current active SC_RX. Current code uses the header MAC address. Without this patch, when ES flag is 0 (using a bridge or switch), header MAC will not fit the SCI and MACSec frames will be discarted. Fixes: c09440f ("macsec: introduce IEEE 802.1AE driver") Co-developed-by: Andreu Montiel <[email protected]> Signed-off-by: Andreu Montiel <[email protected]> Signed-off-by: Carlos Fernandez <[email protected]> Signed-off-by: NipaLocal <nipa@local>
The call to qrtr_endpoint_register() was moved before mhi_prepare_for_transfer_autoqueue() to prevent a case where a dl callback can occur before the qrtr endpoint is registered. Now the reverse can happen where qrtr will try to send a packet before the channels are prepared. The correct sequence needs to be prepare the mhi channel, register the qrtr endpoint, queue buffers for receiving dl transfers. Since qrtr will not use mhi_prepare_for_transfer_autoqueue(), qrtr must do the buffer management and requeue the buffers in the dl_callback. Sizing of the buffers will be inherited from the mhi controller settings. Fixes: 68a838b ("net: qrtr: start MHI channel after endpoit creation") Reported-by: Johan Hovold <[email protected]> Closes: https://lore.kernel.org/linux-arm-msm/[email protected]/ Signed-off-by: Chris Lew <[email protected]> Signed-off-by: NipaLocal <nipa@local>
Syzkaller detected a possible deadlock in nr_rt_device_down [1]
Locking in concurrent threads can cause deadlock.
CPU0
----
nr_rt_device_down()
|-> spin_lock_bh(&nr_neigh_list_lock); capture
. . .
|-> spin_lock_bh(&nr_node_list_lock); waiting and deadlock
CPU1
----
nr_del_node()
|-> spin_lock_bh(&nr_node_list_lock); capture
. . .
|-> nr_remove_neigh(nr_neigh);
|-> spin_lock_bh(&nr_neigh_list_lock); waiting for capture
Make sure we always get nr_neigh_list_lock before nr_node_list_lock.
[1]
WARNING: possible circular locking dependency detected
6.15.0-rc2-syzkaller-00278-gfc96b232f8e7 #0 Not tainted
------------------------------------------------------
syz-executor107/6105 is trying to acquire lock:
ffffffff902543b8 (nr_node_list_lock){+...}-{3:3}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]
ffffffff902543b8 (nr_node_list_lock){+...}-{3:3}, at: nr_rt_device_down+0xb5/0x7b0 net/netrom/nr_route.c:517
but task is already holding lock:
ffffffff90254358 (nr_neigh_list_lock){+...}-{3:3}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]
ffffffff90254358 (nr_neigh_list_lock){+...}-{3:3}, at: nr_rt_device_down+0x28/0x7b0 net/netrom/nr_route.c:514
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> kernel-patches#2 (nr_neigh_list_lock){+...}-{3:3}:
lock_acquire+0x116/0x2f0 kernel/locking/lockdep.c:5866
__raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline]
_raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178
spin_lock_bh include/linux/spinlock.h:356 [inline]
nr_remove_neigh net/netrom/nr_route.c:307 [inline]
nr_dec_obs net/netrom/nr_route.c:472 [inline]
nr_rt_ioctl+0x39a/0xff0 net/netrom/nr_route.c:692
sock_do_ioctl+0x152/0x400 net/socket.c:1190
sock_ioctl+0x644/0x900 net/socket.c:1311
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:906 [inline]
__se_sys_ioctl+0xf1/0x160 fs/ioctl.c:892
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xf3/0x210 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
-> kernel-patches#1 (&nr_node->node_lock){+...}-{3:3}:
lock_acquire+0x116/0x2f0 kernel/locking/lockdep.c:5866
__raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline]
_raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178
spin_lock_bh include/linux/spinlock.h:356 [inline]
nr_node_lock include/net/netrom.h:152 [inline]
nr_dec_obs net/netrom/nr_route.c:459 [inline]
nr_rt_ioctl+0x194/0xff0 net/netrom/nr_route.c:692
sock_do_ioctl+0x152/0x400 net/socket.c:1190
sock_ioctl+0x644/0x900 net/socket.c:1311
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:906 [inline]
__se_sys_ioctl+0xf1/0x160 fs/ioctl.c:892
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xf3/0x210 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
-> #0 (nr_node_list_lock){+...}-{3:3}:
check_prev_add kernel/locking/lockdep.c:3166 [inline]
check_prevs_add kernel/locking/lockdep.c:3285 [inline]
validate_chain+0xa69/0x24e0 kernel/locking/lockdep.c:3909
__lock_acquire+0xad5/0xd80 kernel/locking/lockdep.c:5235
lock_acquire+0x116/0x2f0 kernel/locking/lockdep.c:5866
__raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline]
_raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178
spin_lock_bh include/linux/spinlock.h:356 [inline]
nr_rt_device_down+0xb5/0x7b0 net/netrom/nr_route.c:517
nr_device_event+0x134/0x150 net/netrom/af_netrom.c:126
notifier_call_chain+0x1a5/0x3f0 kernel/notifier.c:85
__dev_notify_flags+0x209/0x410 net/core/dev.c:-1
netif_change_flags+0xf0/0x1a0 net/core/dev.c:9434
dev_change_flags+0x146/0x270 net/core/dev_api.c:68
dev_ioctl+0x80f/0x1260 net/core/dev_ioctl.c:821
sock_do_ioctl+0x22f/0x400 net/socket.c:1204
sock_ioctl+0x644/0x900 net/socket.c:1311
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:906 [inline]
__se_sys_ioctl+0xf1/0x160 fs/ioctl.c:892
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xf3/0x210 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
other info that might help us debug this:
Chain exists of:
nr_node_list_lock --> &nr_node->node_lock --> nr_neigh_list_lock
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(nr_neigh_list_lock);
lock(&nr_node->node_lock);
lock(nr_neigh_list_lock);
lock(nr_node_list_lock);
*** DEADLOCK ***
2 locks held by syz-executor107/6105:
#0: ffffffff900fd788 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_net_lock include/linux/rtnetlink.h:130 [inline]
#0: ffffffff900fd788 (rtnl_mutex){+.+.}-{4:4}, at: dev_ioctl+0x7fd/0x1260 net/core/dev_ioctl.c:820
kernel-patches#1: ffffffff90254358 (nr_neigh_list_lock){+...}-{3:3}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]
kernel-patches#1: ffffffff90254358 (nr_neigh_list_lock){+...}-{3:3}, at: nr_rt_device_down+0x28/0x7b0 net/netrom/nr_route.c:514
stack backtrace:
CPU: 0 UID: 0 PID: 6105 Comm: syz-executor107 Not tainted 6.15.0-rc2-syzkaller-00278-gfc96b232f8e7 #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120
print_circular_bug+0x2e1/0x300 kernel/locking/lockdep.c:2079
check_noncircular+0x142/0x160 kernel/locking/lockdep.c:2211
check_prev_add kernel/locking/lockdep.c:3166 [inline]
check_prevs_add kernel/locking/lockdep.c:3285 [inline]
validate_chain+0xa69/0x24e0 kernel/locking/lockdep.c:3909
__lock_acquire+0xad5/0xd80 kernel/locking/lockdep.c:5235
lock_acquire+0x116/0x2f0 kernel/locking/lockdep.c:5866
__raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline]
_raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178
spin_lock_bh include/linux/spinlock.h:356 [inline]
nr_rt_device_down+0xb5/0x7b0 net/netrom/nr_route.c:517
nr_device_event+0x134/0x150 net/netrom/af_netrom.c:126
notifier_call_chain+0x1a5/0x3f0 kernel/notifier.c:85
__dev_notify_flags+0x209/0x410 net/core/dev.c:-1
netif_change_flags+0xf0/0x1a0 net/core/dev.c:9434
dev_change_flags+0x146/0x270 net/core/dev_api.c:68
dev_ioctl+0x80f/0x1260 net/core/dev_ioctl.c:821
sock_do_ioctl+0x22f/0x400 net/socket.c:1204
sock_ioctl+0x644/0x900 net/socket.c:1311
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:906 [inline]
__se_sys_ioctl+0xf1/0x160 fs/ioctl.c:892
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xf3/0x210 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Fixes: 1da177e ("Linux-2.6.12-rc2")
Cc: [email protected]
Reported-by: [email protected]
Closes: https://syzkaller.appspot.com/bug?extid=ccdfb85a561b973219c7
Signed-off-by: Denis Arefev <[email protected]>
Signed-off-by: NipaLocal <nipa@local>
When 'netlink_trim()' processes shared skb, using 'skb_clone()' with following 'pskb_expand_head()' looks suboptimal, and it's expected to be a bit faster to do 'skb_copy_expand()' with desired tailroom instead. Signed-off-by: Dmitry Antipov <[email protected]> Signed-off-by: NipaLocal <nipa@local>
In 'skb_realloc_headroom()' and 'skb_expand_head()', using 'skb_clone()' with following 'pskb_expand_head()' looks suboptimal, and it's expected to be a bit faster to do 'skb_copy_expand()' with desired headroom instead. Signed-off-by: Dmitry Antipov <[email protected]> Signed-off-by: NipaLocal <nipa@local>
When performing a non-exact phy_caps lookup, we are looking for a supported mode that matches as closely as possible the passed speed/duplex. Blamed patch broke that logic by returning a match too early in case the caller asks for half-duplex, as a full-duplex linkmode may match first, and returned as a non-exact match without even trying to mach on half-duplex modes. Reported-by: Jijie Shao <[email protected]> Closes: https://lore.kernel.org/netdev/20250603102500.4ec743cf@fedora/T/#m22ed60ca635c67dc7d9cbb47e8995b2beb5c1576 Tested-by: Jijie Shao <[email protected]> Reviewed-by: Larysa Zaremba <[email protected]> Fixes: fc81e25 ("net: phy: phy_caps: Allow looking-up link caps based on speed and duplex") Signed-off-by: Maxime Chevallier <[email protected]> Signed-off-by: NipaLocal <nipa@local>
Userspace relies on the root inode numbers to identify the initial namespaces. That's already a hard dependency. So we cannot change that anymore. Move the initial inode numbers to a public header. Link: systemd/systemd@d293fad Signed-off-by: Christian Brauner <[email protected]> Signed-off-by: NipaLocal <nipa@local>
Apart from the network and mount namespace all other namespaces expose a stable inode number and userspace has been relying on that for a very long time now. It's very much heavily used API. Align the network namespace and use a stable inode number from the reserved procfs inode number space so this is consistent across all namespaces. Signed-off-by: Christian Brauner <[email protected]> Signed-off-by: NipaLocal <nipa@local>
Apart from the network and mount namespace all other namespaces expose a stable inode number and userspace has been relying on that for a very long time now. It's very much heavily used API. Align the mount namespace and use a stable inode number from the reserved procfs inode number space so this is consistent across all namespaces. Signed-off-by: Christian Brauner <[email protected]> Signed-off-by: NipaLocal <nipa@local>
There are unnecessary brace used in the conditional statement where ptp_vclock_in_use() is used in ptp_clock_unregister(). This should be removed. Signed-off-by: Jeongjun Park <[email protected]> Signed-off-by: NipaLocal <nipa@local>
Some mctp configurations result in the userspace application `mctp addr show`, which triggers an `mctp_dump_addrinfo`, to be given infinite data. This was introduced by commit 2d20773. In `mctp_dump_addrinfo`, when the userspace buffer doesn't hold enough space for all of the addresses, the function keeps the current index in the netlink_callback so that it can resume on subsequent calls. There are two indexes held: interface and address. When a all the addresses for an interface has been sent, the code reset the address to zero and relies on `for_each_netdev_dump` for incrementing the index. However, `for_each_netdev_dump` (which is using `xa_for_each_start`) does not set the index for the last entry[1]. This can lead to the subsequent userspace request re-sending the entire last interface. Fix this by explicitly setting the index to ULONG_MAX[2] when all of the interfaces and addresses have been successfully sent. This will cause subsequent userspace request to be past the last interface in the next `for_each_netdev_dump` call. The previous failure could be aggravated by on a system using aspeed-bmc-facebook-harma.dts by running: ``` mctp addr add 8 dev mctpi2c1 mctp addr show ``` [1]: https://github.com/torvalds/linux/blob/e271ed52b344ac02d4581286961d0c40acc54c03/lib/xarray.c#L2261 [2]: https://github.com/torvalds/linux/blob/e271ed52b344ac02d4581286961d0c40acc54c03/include/linux/xarray.h#L481 Fixes: 2d20773 ("mctp: no longer rely on net->dev_index_head[]") Signed-off-by: Patrick Williams <[email protected]> Signed-off-by: NipaLocal <nipa@local>
Convert at86rf230.txt yaml format. Additional changes: - Add ref to spi-peripheral-props.yaml. - Add parent spi node in examples. Signed-off-by: Frank Li <[email protected]> Signed-off-by: NipaLocal <nipa@local>
Use the BIT() macro for bitmask constants. Signed-off-by: Qasim Ijaz <[email protected]> Signed-off-by: NipaLocal <nipa@local>
SFQ has an assumption of always being able to queue at least one packet. However, after the blamed commit, sch->q.len can be inflated by packets in sch->gso_skb, and an enqueue() on an empty SFQ qdisc can be followed by an immediate drop. Fix sfq_drop() to properly clear q->tail in this situation. Tested: ip netns add lb ip link add dev to-lb type veth peer name in-lb netns lb ethtool -K to-lb tso off # force qdisc to requeue gso_skb ip netns exec lb ethtool -K in-lb gro on # enable NAPI ip link set dev to-lb up ip -netns lb link set dev in-lb up ip addr add dev to-lb 192.168.20.1/24 ip -netns lb addr add dev in-lb 192.168.20.2/24 tc qdisc replace dev to-lb root sfq limit 100 ip netns exec lb netserver netperf -H 192.168.20.2 -l 100 & netperf -H 192.168.20.2 -l 100 & netperf -H 192.168.20.2 -l 100 & netperf -H 192.168.20.2 -l 100 & Fixes: a53851e ("net: sched: explicit locking in gso_cpu fallback") Reported-by: Marcus Wichelmann <[email protected]> Closes: https://lore.kernel.org/netdev/[email protected]/ Signed-off-by: Eric Dumazet <[email protected]> Signed-off-by: NipaLocal <nipa@local>
tc_actions.sh keeps hanging the forwarding tests. sdf@: tdc & tdc-dbg started intermittenly failing around Sep 25th Signed-off-by: NipaLocal <nipa@local>
Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: NipaLocal <nipa@local>
Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: NipaLocal <nipa@local>
Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: NipaLocal <nipa@local>
Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: NipaLocal <nipa@local>
Signed-off-by: NipaLocal <nipa@local>
Signed-off-by: NipaLocal <nipa@local>
Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: NipaLocal <nipa@local>
Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: NipaLocal <nipa@local>
Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: NipaLocal <nipa@local>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Reusable PR for hooking netdev CI to BPF testing.