netdev CI testing#10590
Open
kuba-moo wants to merge 3562 commits intokernel-patches:bpf-next_basefrom
Open
Conversation
kuba-moo
force-pushed
the
to-test
branch
2 times, most recently
from
7b8fd1e to
c882113
Compare
kernel-patches-daemon-bpf
Bot
force-pushed
the
bpf-next_base
branch
from
2fdc009 to
1a3ba83
Compare
kuba-moo
force-pushed
the
to-test
branch
2 times, most recently
from
c89f0e4 to
7cdbbf5
Compare
kernel-patches-daemon-bpf
Bot
force-pushed
the
bpf-next_base
branch
2 times, most recently
from
c9c5c87 to
0275c50
Compare
kernel-patches-daemon-bpf
Bot
force-pushed
the
bpf-next_base
branch
from
0275c50 to
22bf7db
Compare
kuba-moo
force-pushed
the
to-test
branch
21 times, most recently
from
27655ed to
fa3bc5e
Compare
There's a chance the register signature value is set before the firmware is ready to respond to the driver. This doesn't mean the device isn't there, but just means it's not yet ready. If the first devcmd fails, then return -EPROBE_DEFER so the device can be probed at a later time. As part of this make sure the reset devcmd, which is the first devcmd, is not so alarming when it fails by printing an information message instead of the standard devcmd failure messages. Note, that the ionic_reset() function could be reworked a bit to keep retrying if err is -EAGAIN or -ETIMEDOUT, but for now I chose not to change this as 5 seconds should be enough for the firmware to come up after the devcmd registers are initialized. Fixes: fbfb803 ("ionic: Add hardware init and device commands") Signed-off-by: Brett Creeley <brett.creeley@amd.com> Signed-off-by: Eric Joyner <eric.joyner@amd.com> Signed-off-by: NipaLocal <nipa@local>
If ionic_reset() fails, then the device either wasn't ready to be communicated with, the firmware is down, and/or the devcmd path is already torn down. For teardown/remove cases we can ignore the result of ionic_reset(). However, for any setup cases, we should take the result seriously. Note, older firmware always returns success for IONIC_CMD_RESET, so this change will not break those. However, newer firmware may return failure if the IONIC_CMD_RESET dev cmd fails. Fixes: 8097a2f ("ionic: Reset LIF device while restarting LIF") Signed-off-by: Brett Creeley <brett.creeley@amd.com> Signed-off-by: Eric Joyner <eric.joyner@amd.com> Signed-off-by: NipaLocal <nipa@local>
When polling for a devcmd completion it's possible for the driver to timeout the command even if the dev_cmd has completed. This can cause unexpected failures and device probe to fail. Fix this by reading the dev_cmd's done bit one last time after breaking out of the poll loop. Fixes: fbfb803 ("ionic: Add hardware init and device commands") Suggested-by: Neel Patel <neel.patel@amd.com> Signed-off-by: Brett Creeley <brett.creeley@amd.com> Signed-off-by: Eric Joyner <eric.joyner@amd.com> Signed-off-by: NipaLocal <nipa@local>
The current check will fail if SR-IOV is not initialized for the physical function; this is because is_physfn is 0 if sriov_init() isn't run or fails. Change the check that prevents getting the link down count to use is_virtfn instead so that VFs don't get this functionality, which was the original intent. Fixes: 132b4eb ("ionic: add support for ethtool extended stat link_down_count") Signed-off-by: Brett Creeley <brett.creeley@amd.com> Signed-off-by: Eric Joyner <eric.joyner@amd.com> Signed-off-by: NipaLocal <nipa@local>
The old ionic_rx_service() and ionic_tx_service() used array
indexing to access completion descriptors:
comp = &((struct ionic_rxq_comp *)cq->base)[cq->tail_idx];
This assumes the stride is sizeof(struct ionic_rxq_comp) = 16 bytes.
However, when the IONIC_Q_F_2X_CQ_DESC flag is set, the actual
completion descriptor size is 32 bytes (2 * sizeof(comp)), and the
completion itself is located at the end of that 32-byte slot. Array
indexing with a 16-byte stride would access the wrong offset.
Use pointer arithmetic that accounts for the actual descriptor size
from cq->desc_size:
comp = cq->base +
cq->desc_size * cq->tail_idx +
cq->desc_size - sizeof(*comp);
This correctly calculates the completion location regardless of
descriptor size. For the common case where desc_size equals
sizeof(*comp), use array indexing in a likely() fast path to avoid
performance regression.
Fixes: 0ec9f66 ("ionic: add handling of larger descriptors")
Signed-off-by: Prabu Thayalan <prabu.ponrajthayalan@amd.com>
Signed-off-by: Eric Joyner <eric.joyner@amd.com>
Signed-off-by: NipaLocal <nipa@local>
When TCP socket migration fails at inet_ehash_insert() in reqsk_timer_handler(), we jump to the no_ownership: label and free the new reqsk immediately with __reqsk_free(). Thus, we must stop the new reqsk's timer before jumping to the label, but the timer might be missed since the cited commit, resulting in UAF. As we are in the original reqsk's timer context, we can safely call timer_delete_sync() for the new reqsk. Let's pass false to __inet_csk_reqsk_queue_drop() to stop the new reqsk's timer. Fixes: 83fccfc ("inet: fix potential deadlock in reqsk_queue_unlink()") Reported-by: Damiano Melotti <melotti@google.com> Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Signed-off-by: NipaLocal <nipa@local>
When TCP socket migration happens in reqsk_timer_handler(), @sk_listener will be updated with the new listener. When we call __inet_csk_reqsk_queue_drop(), the listener must be the one stored in req->rsk_listener. The cited commit accidentally replaced oreq->rsk_listener with sk_listener, leading to imbalanced icsk_accept_queue count. Let's pass the correct listener to __inet_csk_reqsk_queue_drop(). Fixes: e8c526f ("tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink().") Reported-by: Damiano Melotti <melotti@google.com> Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Signed-off-by: NipaLocal <nipa@local>
TIPC stream send currently enters the transmit loop even when the user payload length is zero. This can build and transmit a header-only connection message. For local TIPC sockets, such messages are delivered synchronously through the loopback receive path. When this happens while socket backlog processing is being flushed, reply transmission can re-enter TIPC receive processing repeatedly and trigger an RCU stall. Make zero-length sends on connected SOCK_STREAM TIPC sockets a no-op after the existing connection/congestion wait has succeeded. Leave implicit connection setup and SOCK_SEQPACKET behavior unchanged. Fixes: 365ad35 ("tipc: reduce risk of user starvation during link congestion") Cc: stable@vger.kernel.org Reported-by: syzbot+aa7d098bd6fa788fae8e@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/000000000000cedbc405ae81531f@google.com/ Closes: https://syzkaller.appspot.com/bug?extid=aa7d098bd6fa788fae8e Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com> Signed-off-by: NipaLocal <nipa@local>
The atl2 driver contains code for compatibility with old kernels that do not support module_param_array. Backward compatibility is irrelevant because this driver is in-tree. Remove this unreachable code to simplify the driver's handling of module parameters. Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com> Signed-off-by: NipaLocal <nipa@local>
Yi Lai reported RCU splat in reg_vif_xmit() below. [0] When CONFIG_IP_MROUTE_MULTIPLE_TABLES=n, ipmr_fib_lookup() uses rcu_dereference() without explicit rcu_read_lock(). Although rcu_read_lock_bh() is already held by the caller __dev_queue_xmit(), lockdep requires explicit rcu_read_lock() for rcu_dereference(). Let's move up rcu_read_lock() in reg_vif_xmit() to cover ipmr_fib_lookup(). [0]: WARNING: suspicious RCU usage 7.1.0-rc2-next-20260504-9d0d467c3572 kernel-patches#1 Not tainted ----------------------------- net/ipv4/ipmr.c:329 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 2 locks held by syz.2.17/1779: #0: ffffffff87896440 (rcu_read_lock_bh){....}-{1:3}, at: local_bh_disable include/linux/bottom_half.h:20 [inline] #0: ffffffff87896440 (rcu_read_lock_bh){....}-{1:3}, at: rcu_read_lock_bh include/linux/rcupdate.h:891 [inline] #0: ffffffff87896440 (rcu_read_lock_bh){....}-{1:3}, at: __dev_queue_xmit+0x239/0x4140 net/core/dev.c:4792 kernel-patches#1: ffff88801a199d18 (_xmit_PIMREG#2){+...}-{3:3}, at: spin_lock include/linux/spinlock.h:342 [inline] kernel-patches#1: ffff88801a199d18 (_xmit_PIMREG#2){+...}-{3:3}, at: __netif_tx_lock include/linux/netdevice.h:4795 [inline] kernel-patches#1: ffff88801a199d18 (_xmit_PIMREG#2){+...}-{3:3}, at: __dev_queue_xmit+0x1d5d/0x4140 net/core/dev.c:4865 stack backtrace: CPU: 1 UID: 0 PID: 1779 Comm: syz.2.17 Not tainted 7.1.0-rc2-next-20260504-9d0d467c3572 kernel-patches#1 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x121/0x150 lib/dump_stack.c:120 dump_stack+0x19/0x20 lib/dump_stack.c:129 lockdep_rcu_suspicious+0x15b/0x1f0 kernel/locking/lockdep.c:6878 ipmr_fib_lookup net/ipv4/ipmr.c:329 [inline] reg_vif_xmit+0x2ee/0x3c0 net/ipv4/ipmr.c:540 __netdev_start_xmit include/linux/netdevice.h:5382 [inline] netdev_start_xmit include/linux/netdevice.h:5391 [inline] xmit_one net/core/dev.c:3889 [inline] dev_hard_start_xmit+0x170/0x700 net/core/dev.c:3905 __dev_queue_xmit+0x1df1/0x4140 net/core/dev.c:4871 dev_queue_xmit include/linux/netdevice.h:3423 [inline] packet_xmit+0x252/0x370 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3082 [inline] packet_sendmsg+0x39ad/0x5650 net/packet/af_packet.c:3114 sock_sendmsg_nosec net/socket.c:797 [inline] __sock_sendmsg net/socket.c:812 [inline] ____sys_sendmsg+0xa21/0xba0 net/socket.c:2716 ___sys_sendmsg+0x121/0x1c0 net/socket.c:2770 __sys_sendmsg+0x177/0x220 net/socket.c:2802 __do_sys_sendmsg net/socket.c:2807 [inline] __se_sys_sendmsg net/socket.c:2805 [inline] __x64_sys_sendmsg+0x80/0xc0 net/socket.c:2805 x64_sys_call+0x1d9c/0x21c0 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xc1/0x1020 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f37e563ee5d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 93 af 1b 00 f7 d8 64 89 01 48 RSP: 002b:00007ffe5caa7fa8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00000000005c5fa0 RCX: 00007f37e563ee5d RDX: 0000000000000000 RSI: 00002000000012c0 RDI: 0000000000000004 RBP: 00000000005c5fa0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00000000005c5fac R15: 00000000005c5fa0 </TASK> Fixes: b3b6bab ("ipmr: Free mr_table after RCU grace period.") Reported-by: syzkaller <syzkaller@googlegroups.com> Reported-by: Yi Lai <yi1.lai@intel.com> Closes: https://lore.kernel.org/netdev/afrY34dLXNUboevf@ly-workstation/ Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Signed-off-by: NipaLocal <nipa@local>
If a socket is bound to a wildcard address, tcp_v[46]_connect() updates it with a non-wildcard address based on the route lookup. After bhash2 was introduced in the cited commit, we must call inet_bhash2_update_saddr() to update the bhash2 entry as well. If inet_bhash2_update_saddr() fails, we must release the refcount for dst by ip_route_connect() or ip6_dst_lookup_flow(). While tcp_v4_connect() calls ip_rt_put() in the error path, tcp_v6_connect() does not call dst_release(). Let's call dst_release() when inet_bhash2_update_saddr() fails in tcp_v6_connect(). Fixes: 28044fc ("net: Add a bhash2 table hashed by port and address") Reported-by: Damiano Melotti <melotti@google.com> Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Signed-off-by: NipaLocal <nipa@local>
Commit 3a95973 ("net: sparx5: move VCAP initialization to probe") moved sparx5_vcap_init() ahead of sparx5_register_netdevs() in probe. The VCAP init path ends by calling vcap_port_debugfs() for every port, which uses netdev_name(ndev) as the debugfs file name. At that point the netdevs have only been allocated, not registered, so dev->name still holds the "eth%d" template and netdev_name() returns "(unnamed net_device)". Every port tries to create the same file under vcaps/, producing a flood of warnings at boot: debugfs: '(unnamed net_device)' already exists in 'vcaps' debugfs: '(unnamed net_device)' already exists in 'vcaps' ... Move the debugfs setup into a new sparx5_debugfs() helper in sparx5_debugfs.c, invoked after sparx5_register_notifier_blocks() succeeds so the netdev names are finalized. sparx5_vcap_init() now only deals with VCAP state. The sparx5/ debugfs root is created in the new helper as well. Fixes: 3a95973 ("net: sparx5: move VCAP initialization to probe") Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Signed-off-by: NipaLocal <nipa@local>
sparx5_set_rx_mode() runs with netif_addr_lock_bh held and iterates dev->mc via __dev_mc_sync(), which per address calls sparx5_mc_sync() / sparx5_mc_unsync() -> sparx5_mact_learn() / sparx5_mact_forget(). These take sparx5->lock, a mutex, and then poll the MAC access command register with readx_poll_timeout(). A mutex may block, which is not allowed from atomic context. Convert the driver to the new .ndo_set_rx_mode_async callback introduced in commit 3554b43 ("net: introduce ndo_set_rx_mode_async and netdev_rx_mode_work"). The async callback is invoked from process context, so the mutex and sleeping completion poll can remain. Observed with CONFIG_PROVE_LOCKING, CONFIG_DEBUG_SPINLOCK, CONFIG_DEBUG_MUTEXES and CONFIG_DEBUG_ATOMIC_SLEEP enabled: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:591 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 217, name: ip preempt_count: 201, expected: 0 Call trace: __might_resched+0x144/0x248 __might_sleep+0x48/0x7c __mutex_lock+0x74/0x850 mutex_lock_nested+0x24/0x30 sparx5_mact_learn+0x78/0x100 sparx5_mc_sync+0x40/0x54 __hw_addr_sync_dev+0xc4/0x170 sparx5_set_rx_mode+0x4c/0x58 __dev_set_rx_mode+0x64/0xa4 __dev_open+0x1ec/0x26c Fixes: b37a1ba ("net: sparx5: add mactable support") Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Signed-off-by: NipaLocal <nipa@local>
The TSN SKUs in enum spx5_target_chiptype have incorrect IDs: SPX5_TARGET_CT_7546TSN = 0x47546, SPX5_TARGET_CT_7549TSN = 0x47549, SPX5_TARGET_CT_7552TSN = 0x47552, SPX5_TARGET_CT_7556TSN = 0x47556, SPX5_TARGET_CT_7558TSN = 0x47558, The value read back from the chip is GCB_CHIP_ID_PART_ID, which is a GENMASK(27, 12) field, i.e. at most 16 bits wide. It can never match these IDs, so probing a TSN part fails with a "Target not supported" error. Fix the enum to use the actual 16-bit part IDs returned by the hardware: 0x0546, 0x0549, 0x0552, 0x0556 and 0x0558. Reported-by: Andrew Lunn <andrew@lunn.ch> Fixes: 3cfa11b ("net: sparx5: add the basic sparx5 driver") Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Signed-off-by: NipaLocal <nipa@local>
sparx5_port_init() only invokes sparx5_serdes_set() and the associated shadow-device enable and low-speed device switch for SGMII and QSGMII. On any port with a high-speed primary device (DEV5G/DEV10G/DEV25G) configured for 1000BASE-X the serdes is therefore left uninitialized, the DEV2G5 shadow is never enabled, and the port stays pointed at its high-speed device rather than the DEV2G5. The PCS1G block looks healthy in isolation, but no frames reach the link partner. Add 1000BASE-X to the check so the same three steps run. Note: the same issue might apply to 2500BASE-X, but that will, eventually, be addressed in a separate commit. Reported-by: Andrew Lunn <andrew@lunn.ch> Fixes: 946e7fd ("net: sparx5: add port module support") Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Signed-off-by: NipaLocal <nipa@local>
mem_check() in net/ipv6/ip6_flowlabel.c reads fl_size without holding ip6_fl_lock. fl_intern() takes the lock immediately afterwards. The two checks therefore race against concurrent fl_intern, ip6_fl_gc and ip6_fl_purge writers, which makes the mem_check budget check approximate. Move spin_lock_bh(&ip6_fl_lock) and the matching unlock from fl_intern() into its only caller ipv6_flowlabel_get(). The mem_check() call now runs under the same critical section as the fl_intern() insert, so the budget check is exact. With all writers and the read of fl_size under ip6_fl_lock, convert fl_size from atomic_t to plain int. The four sites that update or read fl_size are fl_intern (insert path), ip6_fl_gc (garbage collector, the !sched check and the per-entry decrement), ip6_fl_purge (per-netns purge), and mem_check (budget check), and all four now run under ip6_fl_lock. This is a prerequisite for adding a per-netns budget alongside fl_size. The follow-up patch adds netns_ipv6::flowlabel_count and folds it into mem_check(). Fixes: 1da177e ("Linux-2.6.12-rc2") Suggested-by: Willem de Bruijn <willemb@google.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Maoyi Xie <maoyi.xie@ntu.edu.sg> Signed-off-by: NipaLocal <nipa@local>
fl_size, fl_ht and ip6_fl_lock in net/ipv6/ip6_flowlabel.c are file scope and shared across netns. mem_check() reads fl_size to decide whether to deny non-CAP_NET_ADMIN callers. capable() runs against init_user_ns, so an unprivileged user in any non-init userns can push fl_size past FL_MAX_SIZE - FL_MAX_SIZE / 4 and starve every other unprivileged userns on the host. Add struct netns_ipv6::flowlabel_count, bumped and decremented next to fl_size in fl_intern, ip6_fl_gc and ip6_fl_purge. The new field fills the existing 4-byte hole after ipmr_seq, so struct netns_ipv6 stays the same size on 64-bit builds. Bump FL_MAX_SIZE from 4096 to 8192. It has been 4096 since the file was added. Machines and connection counts have grown. mem_check() folds an extra per-netns ceiling into the existing non-CAP_NET_ADMIN conditional. The ceiling is half of the total budget that unprivileged callers have ever been able to use, i.e. (FL_MAX_SIZE - FL_MAX_SIZE / 4) / 2 = 3072 entries. With FL_MAX_SIZE doubled, this preserves the original per-user reach of 3K (what an unprivileged caller could already obtain before this change), while forcing an attacker to spread allocations across at least two netns to exhaust the global non-CAP_NET_ADMIN budget. CAP_NET_ADMIN against init_user_ns still bypasses both caps. The previous patch took ip6_fl_lock across mem_check and fl_intern, so the new flowlabel_count read in mem_check and the new flowlabel_count++ in fl_intern run under the same critical section. flowlabel_count is therefore plain int, like fl_size. Fixes: 1da177e ("Linux-2.6.12-rc2") Suggested-by: Willem de Bruijn <willemb@google.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Cc: stable@vger.kernel.org # v5.15+ Signed-off-by: Maoyi Xie <maoyi.xie@ntu.edu.sg> Signed-off-by: NipaLocal <nipa@local>
Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: NipaLocal <nipa@local>
kmemleak auto scan could be a source of latency for the tests. We run a full scan after the tests manually, we don't need the autoscan thread to be enabled. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: NipaLocal <nipa@local>
We exclusively use headless VMs today, don't waste time compiling sound and GPU drivers. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: NipaLocal <nipa@local>
Let's see if this increases stability of timing-related results.. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: NipaLocal <nipa@local>
Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: NipaLocal <nipa@local>
Signed-off-by: Jakub Kicinski <kuba@kernel.org> 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: NipaLocal <nipa@local>
Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: NipaLocal <nipa@local>
These are unlikely to matter for CI testing and they slow things down. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: NipaLocal <nipa@local>
Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: NipaLocal <nipa@local>
Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: NipaLocal <nipa@local>
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
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.
Previous one auto-closed for some reason.