-
Notifications
You must be signed in to change notification settings - Fork 120
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
netdev CI testing #6666
Open
kuba-moo
wants to merge
1,672
commits into
kernel-patches:bpf-next_base
Choose a base branch
from
linux-netdev:to-test
base: bpf-next_base
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
netdev CI testing #6666
+51,383
−15,948
Conversation
This file contains 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
March 28, 2024 04:46
4f22ee0
to
8a9a8e0
Compare
kuba-moo
force-pushed
the
to-test
branch
11 times, most recently
from
March 29, 2024 00:01
64c403f
to
8da1f58
Compare
kernel-patches-daemon-bpf
bot
force-pushed
the
bpf-next_base
branch
3 times, most recently
from
March 29, 2024 02:14
78ebb17
to
9325308
Compare
kuba-moo
force-pushed
the
to-test
branch
6 times, most recently
from
March 29, 2024 18:01
c8c7b2f
to
a71aae6
Compare
kernel-patches-daemon-bpf
bot
force-pushed
the
bpf-next_base
branch
from
March 29, 2024 18:12
9325308
to
7940ae1
Compare
kuba-moo
force-pushed
the
to-test
branch
2 times, most recently
from
March 30, 2024 00:01
d8feb00
to
b16a6b9
Compare
kernel-patches-daemon-bpf
bot
force-pushed
the
bpf-next_base
branch
from
March 30, 2024 00:21
7940ae1
to
8f1ff3c
Compare
kuba-moo
force-pushed
the
to-test
branch
2 times, most recently
from
March 30, 2024 06:00
4164329
to
c5cecb3
Compare
Update tx/rx stats locally, so that ndo_get_stats64() can use that and not rely on per queue resources to obtain statistics. The latter used to cause race conditions when the device stopped. Signed-off-by: Shinas Rasheed <srasheed@marvell.com> Signed-off-by: NipaLocal <nipa@local>
The per queue stats are available already and are retrieved from register reads during ndo_get_stats64. The firmware stats fetch call that happens in ndo_get_stats64() is currently not required The warn log is given below: [ 123.316837] ------------[ cut here ]------------ [ 123.316840] Voluntary context switch within RCU read-side critical section! [ 123.316917] pc : rcu_note_context_switch+0x2e4/0x300 [ 123.316919] lr : rcu_note_context_switch+0x2e4/0x300 [ 123.316947] Call trace: [ 123.316949] rcu_note_context_switch+0x2e4/0x300 [ 123.316952] __schedule+0x84/0x584 [ 123.316955] schedule+0x38/0x90 [ 123.316956] schedule_timeout+0xa0/0x1d4 [ 123.316959] octep_send_mbox_req+0x190/0x230 [octeon_ep] [ 123.316966] octep_ctrl_net_get_if_stats+0x78/0x100 [octeon_ep] [ 123.316970] octep_get_stats64+0xd4/0xf0 [octeon_ep] [ 123.316975] dev_get_stats+0x4c/0x114 [ 123.316977] dev_seq_printf_stats+0x3c/0x11c [ 123.316980] dev_seq_show+0x1c/0x40 [ 123.316982] seq_read_iter+0x3cc/0x4e0 [ 123.316985] seq_read+0xc8/0x110 [ 123.316987] proc_reg_read+0x9c/0xec [ 123.316990] vfs_read+0xc8/0x2ec [ 123.316993] ksys_read+0x70/0x100 [ 123.316995] __arm64_sys_read+0x20/0x30 [ 123.316997] invoke_syscall.constprop.0+0x7c/0xd0 [ 123.317000] do_el0_svc+0xb4/0xd0 [ 123.317002] el0_svc+0xe8/0x1f4 [ 123.317005] el0t_64_sync_handler+0x134/0x150 [ 123.317006] el0t_64_sync+0x17c/0x180 [ 123.317008] ---[ end trace 63399811432ab69b ]--- Fixes: 6a610a4 ("octeon_ep: add support for ndo ops") Signed-off-by: Shinas Rasheed <srasheed@marvell.com> Signed-off-by: NipaLocal <nipa@local>
Update tx/rx stats locally, so that ndo_get_stats64() can use that and not rely on per queue resources to obtain statistics. The latter used to cause race conditions when the device stopped. Signed-off-by: Shinas Rasheed <srasheed@marvell.com> Signed-off-by: NipaLocal <nipa@local>
The per queue stats are available already and are retrieved from register reads during ndo_get_stats64. The firmware stats fetch call that happens in ndo_get_stats64() is currently not required The warn log is given below: [ 123.316837] ------------[ cut here ]------------ [ 123.316840] Voluntary context switch within RCU read-side critical section! [ 123.316917] pc : rcu_note_context_switch+0x2e4/0x300 [ 123.316919] lr : rcu_note_context_switch+0x2e4/0x300 [ 123.316947] Call trace: [ 123.316949] rcu_note_context_switch+0x2e4/0x300 [ 123.316952] __schedule+0x84/0x584 [ 123.316955] schedule+0x38/0x90 [ 123.316956] schedule_timeout+0xa0/0x1d4 [ 123.316959] octep_send_mbox_req+0x190/0x230 [octeon_ep] [ 123.316966] octep_ctrl_net_get_if_stats+0x78/0x100 [octeon_ep] [ 123.316970] octep_get_stats64+0xd4/0xf0 [octeon_ep] [ 123.316975] dev_get_stats+0x4c/0x114 [ 123.316977] dev_seq_printf_stats+0x3c/0x11c [ 123.316980] dev_seq_show+0x1c/0x40 [ 123.316982] seq_read_iter+0x3cc/0x4e0 [ 123.316985] seq_read+0xc8/0x110 [ 123.316987] proc_reg_read+0x9c/0xec [ 123.316990] vfs_read+0xc8/0x2ec [ 123.316993] ksys_read+0x70/0x100 [ 123.316995] __arm64_sys_read+0x20/0x30 [ 123.316997] invoke_syscall.constprop.0+0x7c/0xd0 [ 123.317000] do_el0_svc+0xb4/0xd0 [ 123.317002] el0_svc+0xe8/0x1f4 [ 123.317005] el0t_64_sync_handler+0x134/0x150 [ 123.317006] el0t_64_sync+0x17c/0x180 [ 123.317008] ---[ end trace 63399811432ab69b ]--- Fixes: c3fad23 ("octeon_ep_vf: add support for ndo ops") Signed-off-by: Shinas Rasheed <srasheed@marvell.com> Signed-off-by: NipaLocal <nipa@local>
Only configure VLAN-aware CPSW mode if no port is used as DSA CPU port. VLAN-aware mode interferes with some DSA tagging schemes and makes stacking DSA switches downstream of CPSW impossible. Previous attempts to address the issue linked below. Link: https://lore.kernel.org/netdev/20240227082815.2073826-1-s-vadapalli@ti.com/ Link: https://lore.kernel.org/linux-arm-kernel/4699400.vD3TdgH1nR@localhost/ Co-developed-by: Siddharth Vadapalli <s-vadapalli@ti.com> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Signed-off-by: NipaLocal <nipa@local>
Following patch is adding a new drop_reason to tcp_validate_incoming(). Change tcp_disordered_ack() to not return a boolean anymore, but a drop reason. Change its name to tcp_disordered_ack_check() Refactor tcp_validate_incoming() to ease the code review of the following patch, and reduce indentation level. This patch is a refactor, with no functional change. Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Neal Cardwell <ncardwell@google.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com> Signed-off-by: NipaLocal <nipa@local>
XPS can cause reorders because of the relaxed OOO conditions for pure ACK packets. For hosts not using RFS, what can happpen is that ACK packets are sent on behalf of the cpu processing NIC interrupts, selecting TX queue A for ACK packet P1. Then a subsequent sendmsg() can run on another cpu. TX queue selection uses the socket hash and can choose another queue B for packets P2 (with payload). If queue A is more congested than queue B, the ACK packet P1 could be sent on the wire after P2. A linux receiver when processing P2 currently increments LINUX_MIB_PAWSESTABREJECTED (TcpExtPAWSEstab) and use TCP_RFC7323_PAWS drop reason. It might also send a DUPACK if not rate limited. In order to better understand this pattern, this patch adds a new drop_reason : TCP_RFC7323_PAWS_ACK. For old ACKS like these, we no longer increment LINUX_MIB_PAWSESTABREJECTED and no longer sends a DUPACK, keeping credit for other more interesting DUPACK. perf record -e skb:kfree_skb -a perf script ... swapper 0 [148] 27475.438637: skb:kfree_skb: ... location=tcp_validate_incoming+0x4f0 reason: TCP_RFC7323_PAWS_ACK swapper 0 [208] 27475.438706: skb:kfree_skb: ... location=tcp_validate_incoming+0x4f0 reason: TCP_RFC7323_PAWS_ACK swapper 0 [208] 27475.438908: skb:kfree_skb: ... location=tcp_validate_incoming+0x4f0 reason: TCP_RFC7323_PAWS_ACK swapper 0 [148] 27475.439010: skb:kfree_skb: ... location=tcp_validate_incoming+0x4f0 reason: TCP_RFC7323_PAWS_ACK swapper 0 [148] 27475.439214: skb:kfree_skb: ... location=tcp_validate_incoming+0x4f0 reason: TCP_RFC7323_PAWS_ACK swapper 0 [208] 27475.439286: skb:kfree_skb: ... location=tcp_validate_incoming+0x4f0 reason: TCP_RFC7323_PAWS_ACK ... Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Neal Cardwell <ncardwell@google.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com> Signed-off-by: NipaLocal <nipa@local>
Marvell 88Q2XXX devices support up to two configurable Light Emitting Diode (LED). Add minimal LED controller driver supporting the most common uses with the 'netdev' trigger. Signed-off-by: Dimitri Fedrau <dima.fedrau@gmail.com> Signed-off-by: NipaLocal <nipa@local>
If coalece_count is greater than 255 it will not fit in the register and will overflow. This can be reproduced by running # ethtool -C ethX rx-frames 256 which will result in a timeout of 0us instead. Fix this by checking for invalid values and reporting an error. Signed-off-by: Sean Anderson <sean.anderson@linux.dev> Fixes: 8a3b7a2 ("drivers/net/ethernet/xilinx: added Xilinx AXI Ethernet driver") Reviewed-by: Shannon Nelson <shannon.nelson@amd.com> Signed-off-by: NipaLocal <nipa@local>
If a Clear Initial State response packet is received before the Select Package response, then the channel set up will dereference the NULL package pointer. Fix this by setting up the package in the CIS handler if it's not found. [ 9.289221] 8<--- cut here --- [ 9.289244] Unable to handle kernel NULL pointer dereference at virtual address 00000018 when read [ 9.289306] [00000018] *pgd=00000000 [ 9.289333] Internal error: Oops: 5 [kernel-patches#1] SMP ARM [ 9.289367] CPU: 0 PID: 35 Comm: kworker/0:2 Not tainted 6.6.69-f1d562d-gf1d562dd8fa4 kernel-patches#1 [ 9.289423] Hardware name: Generic DT based system [ 9.289457] Workqueue: 0x0 (events) [ 9.289486] PC is at _raw_spin_lock_irqsave+0x10/0x4c [ 9.289525] LR is at ncsi_add_channel+0xd0/0x174 [ 9.289561] pc : [<808d1018>] lr : [<808907bc>] psr: 40000193 [ 9.289605] sp : b4801e20 ip : 8695e000 fp : 80d6c2a8 [ 9.289642] r10: 80d6c2a8 r9 : 8136a4dc r8 : 00000018 [ 9.289680] r7 : 00000000 r6 : 00000000 r5 : 8695dc00 r4 : 00000000 [ 9.289725] r3 : 00000005 r2 : 00000018 r1 : 8089202c r0 : 40000113 [ 9.289770] Flags: nZcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment none [ 9.289821] Control: 10c5387d Table: 81adc06a DAC: 00000051 [ 9.289861] Register r0 information: non-paged memory [ 9.289898] Register r1 information: non-slab/vmalloc memory [ 9.289939] Register r2 information: non-paged memory [ 9.289976] Register r3 information: non-paged memory [ 9.290012] Register r4 information: NULL pointer [ 9.290046] Register r5 information: slab kmalloc-1k start 8695dc00 pointer offset 0 size 1024 [ 9.290111] Register r6 information: NULL pointer [ 9.290145] Register r7 information: NULL pointer [ 9.290180] Register r8 information: non-paged memory [ 9.290216] Register r9 information: non-slab/vmalloc memory [ 9.290257] Register r10 information: non-slab/vmalloc memory [ 9.290298] Register r11 information: non-slab/vmalloc memory [ 9.290339] Register r12 information: slab kmalloc-1k start 8695e000 pointer offset 0 size 1024 [ 9.290404] Process kworker/0:2 (pid: 35, stack limit = 0x401e97d3) [ 9.290448] Stack: (0xb4801e20 to 0xb4802000) [ 9.290482] 1e20: 00000000 81099810 81be7150 81368000 00000000 000024a8 81be7150 8088efc4 [ 9.290540] 1e40: 81be7150 00000000 00000000 8ae45185 00000000 00000000 81368000 8088f4fc [ 9.290598] 1e60: 86337300 806fce18 81368018 0000008a 00000780 00000000 86662dc2 8ae45185 [ 9.290656] 1e80: 00000780 81365800 8088f3e4 0000002a b2c44000 b2c44090 81365800 86337300 [ 9.290714] 1ea0: 00000000 8071c4d8 00000002 86337300 8136c45c 8ae45185 80115aa0 86337300 [ 9.290772] 1ec0: 0000000a 8071c584 b2c44000 b2c44090 00005800 8ae45185 81365dd8 805be000 [ 9.290830] 1ee0: 00000000 805be060 00000040 81365d80 0000002a 00000000 00000036 00000001 [ 9.290888] 1f00: 00000040 81365dd8 b4801f53 ffff8ea7 80d03d00 00000000 81365dd8 8071d010 [ 9.290946] 1f20: 81365dd8 8071d010 49514f00 b3d96100 0000012c b3d962c0 b4801f58 8071d4a4 [ 9.291004] 1f40: b4801f60 81081980 80c4e100 33148000 00c4e100 33148000 b4801f58 b4801f58 [ 9.291062] 1f60: b4801f60 b4801f60 b4801f68 8ae45185 b3d929f0 00000004 00000008 80d0308c [ 9.291120] 1f80: 81081980 00000100 40000003 0000000c 80d03080 801206d4 80c4c790 b480900c [ 9.291178] 1fa0: 80d03080 b4801f98 80c493c8 0000000a 00000000 80c4d380 80c4d380 ffff8ea6 [ 9.291237] 1fc0: 80d03d00 04208060 80c4c790 8016c180 80d06094 81081980 80000013 ffffffff [ 9.291295] 1fe0: b4935f44 61c88647 81081980 81081980 b4935f08 80120c84 80134f4c 808945b8 [ 9.291351] _raw_spin_lock_irqsave from ncsi_add_channel+0xd0/0x174 [ 9.291402] ncsi_add_channel from ncsi_rsp_handler_cis+0x98/0xb4 [ 9.291451] ncsi_rsp_handler_cis from ncsi_rcv_rsp+0x118/0x2c4 [ 9.291498] ncsi_rcv_rsp from __netif_receive_skb_one_core+0x58/0x7c [ 9.291547] __netif_receive_skb_one_core from netif_receive_skb+0x2c/0xc4 [ 9.291597] netif_receive_skb from ftgmac100_poll+0x350/0x43c [ 9.291642] ftgmac100_poll from __napi_poll.constprop.0+0x2c/0x180 [ 9.291690] __napi_poll.constprop.0 from net_rx_action+0x340/0x3c0 [ 9.291736] net_rx_action from handle_softirqs+0xf4/0x25c [ 9.291777] handle_softirqs from irq_exit+0x80/0xb0 [ 9.291816] irq_exit from call_with_stack+0x18/0x20 [ 9.291857] call_with_stack from __irq_svc+0x98/0xb0 [ 9.291898] Exception stack(0xb4935f10 to 0xb4935f58) [ 9.291935] 5f00: 00000007 00000006 80d03d00 00000769 [ 9.291993] 5f20: 85963e80 b3d953c0 80d03d00 b3d953e0 61c88647 85963eac 81081980 b3d953c0 [ 9.292050] 5f40: 00000004 b4935f60 80134f28 80134f4c 80000013 ffffffff [ 9.292096] __irq_svc from worker_thread+0x1fc/0x4e8 [ 9.292137] worker_thread from kthread+0xe0/0xfc [ 9.292176] kthread from ret_from_fork+0x14/0x28 [ 9.292213] Exception stack(0xb4935fb0 to 0xb4935ff8) [ 9.292250] 5fa0: 00000000 00000000 00000000 00000000 [ 9.292308] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 9.292365] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 9.292413] Code: e1a02000 e10f0000 f10c0080 f592f000 (e1923f9f) [ 9.292455] ---[ end trace 0000000000000000 ]--- [ 9.295147] Kernel panic - not syncing: Fatal exception in interrupt Signed-off-by: Eddie James <eajames@linux.ibm.com> Signed-off-by: NipaLocal <nipa@local>
Slight refactor to prepare the code for NAPI to queue mapping. No functional changes. Signed-off-by: Joe Damato <jdamato@fastly.com> Reviewed-by: Gerhard Engleder <gerhard@engleder-embedded.com> Signed-off-by: NipaLocal <nipa@local>
Prepare for NAPI to queue mapping by holding RTNL in code paths where NAPIs will be mapped to queue IDs and RTNL is not currently held. Signed-off-by: Joe Damato <jdamato@fastly.com> Reviewed-by: Gerhard Engleder <gerhard@engleder-embedded.com> Signed-off-by: NipaLocal <nipa@local>
Use netif_queue_set_napi to map NAPIs to queue IDs so that the mapping can be accessed by user apps. $ ethtool -i ens4 | grep driver driver: virtio_net $ sudo ethtool -L ens4 combined 4 $ ./tools/net/ynl/pyynl/cli.py \ --spec Documentation/netlink/specs/netdev.yaml \ --dump queue-get --json='{"ifindex": 2}' [{'id': 0, 'ifindex': 2, 'napi-id': 8289, 'type': 'rx'}, {'id': 1, 'ifindex': 2, 'napi-id': 8290, 'type': 'rx'}, {'id': 2, 'ifindex': 2, 'napi-id': 8291, 'type': 'rx'}, {'id': 3, 'ifindex': 2, 'napi-id': 8292, 'type': 'rx'}, {'id': 0, 'ifindex': 2, 'type': 'tx'}, {'id': 1, 'ifindex': 2, 'type': 'tx'}, {'id': 2, 'ifindex': 2, 'type': 'tx'}, {'id': 3, 'ifindex': 2, 'type': 'tx'}] Note that virtio_net has TX-only NAPIs which do not have NAPI IDs, so the lack of 'napi-id' in the above output is expected. Signed-off-by: Joe Damato <jdamato@fastly.com> Reviewed-by: Gerhard Engleder <gerhard@engleder-embedded.com> Signed-off-by: NipaLocal <nipa@local>
Use netif_queue_set_napi() to link queues to NAPI instances so that they can be queried with netlink. $ ./tools/net/ynl/cli.py --spec Documentation/netlink/specs/netdev.yaml \ --dump queue-get --json='{"ifindex": 11}' [{'id': 0, 'ifindex': 11, 'napi-id': 9, 'type': 'rx'}, {'id': 1, 'ifindex': 11, 'napi-id': 10, 'type': 'rx'}, {'id': 0, 'ifindex': 11, 'napi-id': 9, 'type': 'tx'}, {'id': 1, 'ifindex': 11, 'napi-id': 10, 'type': 'tx'}] Additionally use netif_napi_set_irq() to also provide NAPI interrupt number to userspace. $ ./tools/net/ynl/cli.py --spec Documentation/netlink/specs/netdev.yaml \ --do napi-get --json='{"id": 9}' {'defer-hard-irqs': 0, 'gro-flush-timeout': 0, 'id': 9, 'ifindex': 11, 'irq': 42, 'irq-suspend-timeout': 0} Providing information about queues to userspace makes sense as APIs like XSK provide queue specific access. Also XSK busy polling relies on queues linked to NAPIs. Signed-off-by: Gerhard Engleder <gerhard@engleder-embedded.com> Signed-off-by: NipaLocal <nipa@local>
When __netpoll_setup() is called directly, instead of through netpoll_setup(), the np->skb_pool list head isn't initialized. If skb_pool_flush() is later called, then we hit a NULL pointer in skb_queue_purge_reason(). This can be seen with this repro, when CONFIG_NETCONSOLE is enabled as a module: ip tuntap add mode tap tap0 ip link add name br0 type bridge ip link set dev tap0 master br0 modprobe netconsole netconsole=4444@10.0.0.1/br0,9353@10.0.0.2/ rmmod netconsole The backtrace is: BUG: kernel NULL pointer dereference, address: 0000000000000008 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page ... ... ... Call Trace: <TASK> __netpoll_free+0xa5/0xf0 br_netpoll_cleanup+0x43/0x50 [bridge] do_netpoll_cleanup+0x43/0xc0 netconsole_netdev_event+0x1e3/0x300 [netconsole] unregister_netdevice_notifier+0xd9/0x150 cleanup_module+0x45/0x920 [netconsole] __se_sys_delete_module+0x205/0x290 do_syscall_64+0x70/0x150 entry_SYSCALL_64_after_hwframe+0x76/0x7e Move the skb_pool list setup and initial skb fill into __netpoll_setup(). Fixes: 221a9c1 ("net: netpoll: Individualize the skb pool") Signed-off-by: John Sperbeck <jsperbeck@google.com> Signed-off-by: NipaLocal <nipa@local>
As announced back in April, require running upstream tests to maintain Supported status for NIC drivers: https://lore.kernel.org/20240425114200.3effe773@kernel.org Multiple vendors have been "working on it" for months. Let's make it official. Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: NipaLocal <nipa@local>
Per previous change downgrade all NIC drivers (discrete, embedded, SoC components, virtual) which don't report test results to CI from Supported to Maintained. Also include all components or building blocks of NIC drivers (separate entries for "shared" code, subsystem support like PTP or entries for specific offloads etc.) Reviewed-by: Simon Horman <horms@kernel.org> Acked-by: Alexander Lobakin <aleksander.lobakin@intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: NipaLocal <nipa@local>
I don't see any reason why napi_enable() needs to be under the lock, only reason I could think of is if the IRQ also took this lock but it doesn't. napi_enable() will soon need to sleep. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Acked-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Reviewed-by: Francois Romieu <romieu@fr.zoreil.com> Signed-off-by: NipaLocal <nipa@local>
iavf uses the netdev->lock already to protect shapers. In an upcoming series we'll try to protect NAPI instances with netdev->lock. We need to modify the protection a bit. All NAPI related calls in the driver need to be consistently under the lock. This will allow us to easily switch to a "we already hold the lock" NAPI API later. register_netdevice(), OTOH, must not be called under the netdev_lock() as we do not intend to have an "already locked" version of this call. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: NipaLocal <nipa@local>
Two different models of usb card, the drivers are r8152 and asix. If no network cable is connected, Speed = 10Mb/s. This problem is repeated in linux 3.10, 4.19, and 5.4. Both drivers call mii_ethtool_get_link_ksettings, but the value of cmd->base.speed in this function can only be SPEED_1000 or SPEED_100 or SPEED_10. When the network cable is not connected, set cmd->base.speed =SPEED_UNKNOWN. Signed-off-by: Xiangqian Zhang <zhangxiangqian@kylinos.cn> Signed-off-by: NipaLocal <nipa@local>
Lion Ackermann was able to create a UAF which can be abused for privilege escalation with the following script Step 1. create root qdisc tc qdisc add dev lo root handle 1:0 drr step2. a class for packet aggregation do demonstrate uaf tc class add dev lo classid 1:1 drr step3. a class for nesting tc class add dev lo classid 1:2 drr step4. a class to graft qdisc to tc class add dev lo classid 1:3 drr step5. tc qdisc add dev lo parent 1:1 handle 2:0 plug limit 1024 step6. tc qdisc add dev lo parent 1:2 handle 3:0 drr step7. tc class add dev lo classid 3:1 drr step 8. tc qdisc add dev lo parent 3:1 handle 4:0 pfifo step 9. Display the class/qdisc layout tc class ls dev lo class drr 1:1 root leaf 2: quantum 64Kb class drr 1:2 root leaf 3: quantum 64Kb class drr 3:1 root leaf 4: quantum 64Kb tc qdisc ls qdisc drr 1: dev lo root refcnt 2 qdisc plug 2: dev lo parent 1:1 qdisc pfifo 4: dev lo parent 3:1 limit 1000p qdisc drr 3: dev lo parent 1:2 step10. trigger the bug <=== prevented by this patch tc qdisc replace dev lo parent 1:3 handle 4:0 step 11. Redisplay again the qdiscs/classes tc class ls dev lo class drr 1:1 root leaf 2: quantum 64Kb class drr 1:2 root leaf 3: quantum 64Kb class drr 1:3 root leaf 4: quantum 64Kb class drr 3:1 root leaf 4: quantum 64Kb tc qdisc ls qdisc drr 1: dev lo root refcnt 2 qdisc plug 2: dev lo parent 1:1 qdisc pfifo 4: dev lo parent 3:1 refcnt 2 limit 1000p qdisc drr 3: dev lo parent 1:2 Observe that a) parent for 4:0 does not change despite the replace request. There can only be one parent. b) refcount has gone up by two for 4:0 and c) both class 1:3 and 3:1 are pointing to it. Step 12. send one packet to plug echo "" | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888,priority=$((0x10001)) step13. send one packet to the grafted fifo echo "" | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888,priority=$((0x10003)) step14. lets trigger the uaf tc class delete dev lo classid 1:3 tc class delete dev lo classid 1:1 The semantics of "replace" is for a del/add _on the same node_ and not a delete from one node(3:1) and add to another node (1:3) as in step10. While we could "fix" with a more complex approach there could be consequences to expectations so the patch takes the preventive approach of "disallow such config". Joint work with Lion Ackermann <nnamrec@gmail.com> Fixes: 1da177e ("Linux-2.6.12-rc2") Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by: NipaLocal <nipa@local>
Add a --family option to ynl to specify the spec by family name instead of file path, with support for searching in-tree and system install location and a --list-families option to show the available families. ./tools/net/ynl/pyynl/cli.py --family rt_addr --dump getaddr Signed-off-by: Donald Hunter <donald.hunter@gmail.com> Signed-off-by: NipaLocal <nipa@local>
Replace hard-coded paths for spec and schema with lookup functions so that ethtool.py will work in-tree or when installed. Signed-off-by: Donald Hunter <donald.hunter@gmail.com> Acked-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: 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>
The buffers can easily get large and fail allocations. One of the networking tests running in a VM tries to run perf which occasionally ends with: perf: page allocation failure: order:6, mode:0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), nodemask=(null),cpuset=/,mems_allowed=0 Even tho free memory is available: free:97464 free_pcp:321 free_cma:0 Switch to kvzalloc() to make large allocations less likely to fail. 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>
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.