summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-12-07Merge branch 'dsa-microchip-rmii-reference'David S. Miller
Ante Knezic says: ==================== net: dsa: microchip: enable setting rmii reference KSZ88X3 devices can select between internal and external RMII reference clock. This patch series introduces new device tree property for setting reference clock to internal. --- V5: - move rmii-clk-internal to be a port device tree property. V4: - remove rmii_clk_internal from ksz_device, as its not needed any more - move rmii clk config as well as ksz8795_cpu_interface_select to ksz8_config_cpu_port V3: - move ksz_cfg from global switch config to port config as suggested by Vladimir Oltean - reverse patch order as suggested by Vladimir Oltean - adapt dt schema as suggested by Conor Dooley V2: - don't rely on default register settings - enforce set/clear property as suggested by Andrew Lunn - enforce dt schema as suggested by Conor Dooley ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-07net: dsa: microchip: add property to select internal RMII reference clockAnte Knezic
Microchip KSZ8863/KSZ8873 have the ability to select between internal and external RMII reference clock. By default, reference clock needs to be provided via REFCLKI_3 pin. If required, device can be setup to provide RMII clock internally so that REFCLKI_3 pin can be left unconnected. Add a new "microchip,rmii-clk-internal" property which will set RMII clock reference to internal. If property is not set, reference clock needs to be provided externally. While at it, move the ksz8795_cpu_interface_select() to ksz8_config_cpu_port() to get a cleaner call path for cpu port. Signed-off-by: Ante Knezic <ante.knezic@helmholz.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-07dt-bindings: net: microchip,ksz: document microchip,rmii-clk-internalAnte Knezic
Add documentation for selecting reference rmii clock on KSZ88X3 devices Signed-off-by: Ante Knezic <ante.knezic@helmholz.de> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-06net: rtnetlink: remove local list in __linkwatch_run_queue()Johannes Berg
Due to linkwatch_forget_dev() (and perhaps others?) checking for list_empty(&dev->link_watch_list), we must have all manipulations of even the local on-stack list 'wrk' here under spinlock, since even that list can be reached otherwise via dev->link_watch_list. This is already the case, but makes this a bit counter-intuitive, often local lists are used to _not_ have to use locking for their local use. Remove the local list as it doesn't seem to serve any purpose. While at it, move a variable declaration into the loop using it. Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Link: https://lore.kernel.org/r/20231205170011.56576dcc1727.I698b72219d9f6ce789bd209b8f6dffd0ca32a8f2@changeid Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-06ipv6: add debug checks in fib6_info_release()Eric Dumazet
Some elusive syzbot reports are hinting to fib6_info_release(), with a potential dangling f6i->gc_link anchor. Add debug checks so that syzbot can catch the issue earlier eventually. BUG: KASAN: slab-use-after-free in __hlist_del include/linux/list.h:990 [inline] BUG: KASAN: slab-use-after-free in hlist_del_init include/linux/list.h:1016 [inline] BUG: KASAN: slab-use-after-free in fib6_clean_expires_locked include/net/ip6_fib.h:533 [inline] BUG: KASAN: slab-use-after-free in fib6_purge_rt+0x986/0x9c0 net/ipv6/ip6_fib.c:1064 Write of size 8 at addr ffff88802805a840 by task syz-executor.1/10057 CPU: 1 PID: 10057 Comm: syz-executor.1 Not tainted 6.7.0-rc2-syzkaller-00029-g9b6de136b5f0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:364 [inline] print_report+0xc4/0x620 mm/kasan/report.c:475 kasan_report+0xda/0x110 mm/kasan/report.c:588 __hlist_del include/linux/list.h:990 [inline] hlist_del_init include/linux/list.h:1016 [inline] fib6_clean_expires_locked include/net/ip6_fib.h:533 [inline] fib6_purge_rt+0x986/0x9c0 net/ipv6/ip6_fib.c:1064 fib6_del_route net/ipv6/ip6_fib.c:1993 [inline] fib6_del+0xa7a/0x1750 net/ipv6/ip6_fib.c:2038 __ip6_del_rt net/ipv6/route.c:3866 [inline] ip6_del_rt+0xf7/0x200 net/ipv6/route.c:3881 ndisc_router_discovery+0x295b/0x3560 net/ipv6/ndisc.c:1372 ndisc_rcv+0x3de/0x5f0 net/ipv6/ndisc.c:1856 icmpv6_rcv+0x1470/0x19c0 net/ipv6/icmp.c:979 ip6_protocol_deliver_rcu+0x170/0x13e0 net/ipv6/ip6_input.c:438 ip6_input_finish+0x14f/0x2f0 net/ipv6/ip6_input.c:483 NF_HOOK include/linux/netfilter.h:314 [inline] NF_HOOK include/linux/netfilter.h:308 [inline] ip6_input+0xa1/0xc0 net/ipv6/ip6_input.c:492 ip6_mc_input+0x48b/0xf40 net/ipv6/ip6_input.c:586 dst_input include/net/dst.h:461 [inline] ip6_rcv_finish net/ipv6/ip6_input.c:79 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] NF_HOOK include/linux/netfilter.h:308 [inline] ipv6_rcv+0x24e/0x380 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core+0x115/0x180 net/core/dev.c:5529 __netif_receive_skb+0x1f/0x1b0 net/core/dev.c:5643 netif_receive_skb_internal net/core/dev.c:5729 [inline] netif_receive_skb+0x133/0x700 net/core/dev.c:5788 tun_rx_batched+0x429/0x780 drivers/net/tun.c:1579 tun_get_user+0x29e3/0x3bc0 drivers/net/tun.c:2002 tun_chr_write_iter+0xe8/0x210 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2020 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x64f/0xdf0 fs/read_write.c:584 ksys_write+0x12f/0x250 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0x6b RIP: 0033:0x7f38e387b82f Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 b9 80 02 00 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 0c 81 02 00 48 RSP: 002b:00007f38e45c9090 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007f38e399bf80 RCX: 00007f38e387b82f RDX: 00000000000003b6 RSI: 0000000020000680 RDI: 00000000000000c8 RBP: 00007f38e38c847a R08: 0000000000000000 R09: 0000000000000000 R10: 00000000000003b6 R11: 0000000000000293 R12: 0000000000000000 R13: 000000000000000b R14: 00007f38e399bf80 R15: 00007f38e3abfa48 </TASK> Allocated by task 10044: kasan_save_stack+0x33/0x50 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 ____kasan_kmalloc mm/kasan/common.c:374 [inline] __kasan_kmalloc+0xa2/0xb0 mm/kasan/common.c:383 kasan_kmalloc include/linux/kasan.h:198 [inline] __do_kmalloc_node mm/slab_common.c:1007 [inline] __kmalloc+0x59/0x90 mm/slab_common.c:1020 kmalloc include/linux/slab.h:604 [inline] kzalloc include/linux/slab.h:721 [inline] fib6_info_alloc+0x40/0x160 net/ipv6/ip6_fib.c:155 ip6_route_info_create+0x337/0x1e70 net/ipv6/route.c:3749 ip6_route_add+0x26/0x150 net/ipv6/route.c:3843 rt6_add_route_info+0x2e7/0x4b0 net/ipv6/route.c:4316 rt6_route_rcv+0x76c/0xbf0 net/ipv6/route.c:985 ndisc_router_discovery+0x138b/0x3560 net/ipv6/ndisc.c:1529 ndisc_rcv+0x3de/0x5f0 net/ipv6/ndisc.c:1856 icmpv6_rcv+0x1470/0x19c0 net/ipv6/icmp.c:979 ip6_protocol_deliver_rcu+0x170/0x13e0 net/ipv6/ip6_input.c:438 ip6_input_finish+0x14f/0x2f0 net/ipv6/ip6_input.c:483 NF_HOOK include/linux/netfilter.h:314 [inline] NF_HOOK include/linux/netfilter.h:308 [inline] ip6_input+0xa1/0xc0 net/ipv6/ip6_input.c:492 ip6_mc_input+0x48b/0xf40 net/ipv6/ip6_input.c:586 dst_input include/net/dst.h:461 [inline] ip6_rcv_finish net/ipv6/ip6_input.c:79 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] NF_HOOK include/linux/netfilter.h:308 [inline] ipv6_rcv+0x24e/0x380 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core+0x115/0x180 net/core/dev.c:5529 __netif_receive_skb+0x1f/0x1b0 net/core/dev.c:5643 netif_receive_skb_internal net/core/dev.c:5729 [inline] netif_receive_skb+0x133/0x700 net/core/dev.c:5788 tun_rx_batched+0x429/0x780 drivers/net/tun.c:1579 tun_get_user+0x29e3/0x3bc0 drivers/net/tun.c:2002 tun_chr_write_iter+0xe8/0x210 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2020 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x64f/0xdf0 fs/read_write.c:584 ksys_write+0x12f/0x250 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0x6b Freed by task 5123: kasan_save_stack+0x33/0x50 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 kasan_save_free_info+0x2b/0x40 mm/kasan/generic.c:522 ____kasan_slab_free mm/kasan/common.c:236 [inline] ____kasan_slab_free+0x15b/0x1b0 mm/kasan/common.c:200 kasan_slab_free include/linux/kasan.h:164 [inline] slab_free_hook mm/slub.c:1800 [inline] slab_free_freelist_hook+0x114/0x1e0 mm/slub.c:1826 slab_free mm/slub.c:3809 [inline] __kmem_cache_free+0xc0/0x180 mm/slub.c:3822 rcu_do_batch kernel/rcu/tree.c:2158 [inline] rcu_core+0x819/0x1680 kernel/rcu/tree.c:2431 __do_softirq+0x21a/0x8de kernel/softirq.c:553 Last potentially related work creation: kasan_save_stack+0x33/0x50 mm/kasan/common.c:45 __kasan_record_aux_stack+0xbc/0xd0 mm/kasan/generic.c:492 __call_rcu_common.constprop.0+0x9a/0x7a0 kernel/rcu/tree.c:2681 fib6_info_release include/net/ip6_fib.h:332 [inline] fib6_info_release include/net/ip6_fib.h:329 [inline] rt6_route_rcv+0xa4e/0xbf0 net/ipv6/route.c:997 ndisc_router_discovery+0x138b/0x3560 net/ipv6/ndisc.c:1529 ndisc_rcv+0x3de/0x5f0 net/ipv6/ndisc.c:1856 icmpv6_rcv+0x1470/0x19c0 net/ipv6/icmp.c:979 ip6_protocol_deliver_rcu+0x170/0x13e0 net/ipv6/ip6_input.c:438 ip6_input_finish+0x14f/0x2f0 net/ipv6/ip6_input.c:483 NF_HOOK include/linux/netfilter.h:314 [inline] NF_HOOK include/linux/netfilter.h:308 [inline] ip6_input+0xa1/0xc0 net/ipv6/ip6_input.c:492 ip6_mc_input+0x48b/0xf40 net/ipv6/ip6_input.c:586 dst_input include/net/dst.h:461 [inline] ip6_rcv_finish net/ipv6/ip6_input.c:79 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] NF_HOOK include/linux/netfilter.h:308 [inline] ipv6_rcv+0x24e/0x380 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core+0x115/0x180 net/core/dev.c:5529 __netif_receive_skb+0x1f/0x1b0 net/core/dev.c:5643 netif_receive_skb_internal net/core/dev.c:5729 [inline] netif_receive_skb+0x133/0x700 net/core/dev.c:5788 tun_rx_batched+0x429/0x780 drivers/net/tun.c:1579 tun_get_user+0x29e3/0x3bc0 drivers/net/tun.c:2002 tun_chr_write_iter+0xe8/0x210 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2020 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x64f/0xdf0 fs/read_write.c:584 ksys_write+0x12f/0x250 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0x6b Second to last potentially related work creation: kasan_save_stack+0x33/0x50 mm/kasan/common.c:45 __kasan_record_aux_stack+0xbc/0xd0 mm/kasan/generic.c:492 insert_work+0x38/0x230 kernel/workqueue.c:1647 __queue_work+0xcdc/0x11f0 kernel/workqueue.c:1803 call_timer_fn+0x193/0x590 kernel/time/timer.c:1700 expire_timers kernel/time/timer.c:1746 [inline] __run_timers+0x585/0xb20 kernel/time/timer.c:2022 run_timer_softirq+0x58/0xd0 kernel/time/timer.c:2035 __do_softirq+0x21a/0x8de kernel/softirq.c:553 The buggy address belongs to the object at ffff88802805a800 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 64 bytes inside of freed 512-byte region [ffff88802805a800, ffff88802805aa00) The buggy address belongs to the physical page: page:ffffea0000a01600 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x28058 head:ffffea0000a01600 order:2 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0xfff00000000840(slab|head|node=0|zone=1|lastcpupid=0x7ff) page_type: 0xffffffff() raw: 00fff00000000840 ffff888013041c80 ffffea0001e02600 dead000000000002 raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected page_owner tracks the page as allocated page last allocated via order 2, migratetype Unmovable, gfp_mask 0x1d20c0(__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC|__GFP_HARDWALL), pid 18706, tgid 18699 (syz-executor.2), ts 999991973280, free_ts 996884464281 set_page_owner include/linux/page_owner.h:31 [inline] post_alloc_hook+0x2d0/0x350 mm/page_alloc.c:1537 prep_new_page mm/page_alloc.c:1544 [inline] get_page_from_freelist+0xa25/0x36d0 mm/page_alloc.c:3312 __alloc_pages+0x22e/0x2420 mm/page_alloc.c:4568 alloc_pages_mpol+0x258/0x5f0 mm/mempolicy.c:2133 alloc_slab_page mm/slub.c:1870 [inline] allocate_slab mm/slub.c:2017 [inline] new_slab+0x283/0x3c0 mm/slub.c:2070 ___slab_alloc+0x979/0x1500 mm/slub.c:3223 __slab_alloc.constprop.0+0x56/0xa0 mm/slub.c:3322 __slab_alloc_node mm/slub.c:3375 [inline] slab_alloc_node mm/slub.c:3468 [inline] __kmem_cache_alloc_node+0x131/0x310 mm/slub.c:3517 __do_kmalloc_node mm/slab_common.c:1006 [inline] __kmalloc+0x49/0x90 mm/slab_common.c:1020 kmalloc include/linux/slab.h:604 [inline] kzalloc include/linux/slab.h:721 [inline] copy_splice_read+0x1ac/0x8f0 fs/splice.c:338 vfs_splice_read fs/splice.c:992 [inline] vfs_splice_read+0x2ea/0x3b0 fs/splice.c:962 splice_direct_to_actor+0x2a5/0xa30 fs/splice.c:1069 do_splice_direct+0x1af/0x280 fs/splice.c:1194 do_sendfile+0xb3e/0x1310 fs/read_write.c:1254 __do_sys_sendfile64 fs/read_write.c:1322 [inline] __se_sys_sendfile64 fs/read_write.c:1308 [inline] __x64_sys_sendfile64+0x1d6/0x220 fs/read_write.c:1308 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:82 page last free stack trace: reset_page_owner include/linux/page_owner.h:24 [inline] free_pages_prepare mm/page_alloc.c:1137 [inline] free_unref_page_prepare+0x4fa/0xaa0 mm/page_alloc.c:2347 free_unref_page_list+0xe6/0xb40 mm/page_alloc.c:2533 release_pages+0x32a/0x14f0 mm/swap.c:1042 tlb_batch_pages_flush+0x9a/0x190 mm/mmu_gather.c:98 tlb_flush_mmu_free mm/mmu_gather.c:293 [inline] tlb_flush_mmu mm/mmu_gather.c:300 [inline] tlb_finish_mmu+0x14b/0x6f0 mm/mmu_gather.c:392 exit_mmap+0x38b/0xa70 mm/mmap.c:3321 __mmput+0x12a/0x4d0 kernel/fork.c:1349 mmput+0x62/0x70 kernel/fork.c:1371 exit_mm kernel/exit.c:567 [inline] do_exit+0x9ad/0x2ae0 kernel/exit.c:858 do_group_exit+0xd4/0x2a0 kernel/exit.c:1021 get_signal+0x23be/0x2790 kernel/signal.c:2904 arch_do_signal_or_restart+0x90/0x7f0 arch/x86/kernel/signal.c:309 exit_to_user_mode_loop kernel/entry/common.c:168 [inline] exit_to_user_mode_prepare+0x121/0x240 kernel/entry/common.c:204 irqentry_exit_to_user_mode+0xa/0x40 kernel/entry/common.c:309 asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:645 Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: David Ahern <dsahern@kernel.org> Link: https://lore.kernel.org/r/20231205173250.2982846-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-06octeontx2-af: cn10k: Increase outstanding LMTST transactionsPavan Nikhilesh
Currently the number of outstanding store transactions issued by AP as a part of LMTST operation is set to 1 i.e default value. This patch set to max supported value to increase the performance. Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com> Signed-off-by: Geetha sowjanya <gakula@marvell.com> Link: https://lore.kernel.org/r/20231205055241.26355-1-gakula@marvell.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-12-05Merge branch 'ionic-more-driver-fixes'Jakub Kicinski
Shannon Nelson says: ==================== ionic: more driver fixes These are a few code cleanup items that appeared first in a separate net patchset, https://lore.kernel.org/netdev/20231201000519.13363-1-shannon.nelson@amd.com/ but are now aimed for net-next. ==================== Link: https://lore.kernel.org/r/20231204210936.16587-1-shannon.nelson@amd.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-05ionic: Re-arrange ionic_intr_info struct for cache perfBrett Creeley
dim_coal_hw is accessed in the hotpath along with other values from the first cacheline of ionic_intr_info. So, re-arrange the structure so the hot path variables are on the first cacheline. Before: struct ionic_intr_info { char name[32]; /* 0 32 */ unsigned int index; /* 32 4 */ unsigned int vector; /* 36 4 */ u64 rearm_count; /* 40 8 */ unsigned int cpu; /* 48 4 */ /* XXX 4 bytes hole, try to pack */ cpumask_t affinity_mask; /* 56 1024 */ /* --- cacheline 16 boundary (1024 bytes) was 56 bytes ago --- */ u32 dim_coal_hw; /* 1080 4 */ /* size: 1088, cachelines: 17, members: 7 */ /* sum members: 1080, holes: 1, sum holes: 4 */ /* padding: 4 */ }; After: struct ionic_intr_info { char name[32]; /* 0 32 */ u64 rearm_count; /* 32 8 */ unsigned int index; /* 40 4 */ unsigned int vector; /* 44 4 */ unsigned int cpu; /* 48 4 */ u32 dim_coal_hw; /* 52 4 */ cpumask_t affinity_mask; /* 56 1024 */ /* size: 1080, cachelines: 17, members: 7 */ /* last cacheline: 56 bytes */ }; Signed-off-by: Brett Creeley <brett.creeley@amd.com> Signed-off-by: Shannon Nelson <shannon.nelson@amd.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by: Rahul Rameshbabu <rrameshbabu@nvidia.com> Link: https://lore.kernel.org/r/20231204210936.16587-6-shannon.nelson@amd.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-05ionic: Make the check for Tx HW timestamping more obviousBrett Creeley
Currently the checks are: [1] unlikely(q->features & IONIC_TXQ_F_HWSTAMP) [2] !unlikely(q->features & IONIC_TXQ_F_HWSTAMP) [1] is clear enough, but [2] isn't exactly obvious to the reader because !unlikely reads as likely. However, that's not what this means. [2] means that it's unlikely that the q has IONIC_TXQ_F_HWSTAMP enabled. Write an inline helper function to hide the unlikely optimization to make these checks more readable. Signed-off-by: Brett Creeley <brett.creeley@amd.com> Signed-off-by: Shannon Nelson <shannon.nelson@amd.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by: Rahul Rameshbabu <rrameshbabu@nvidia.com> Link: https://lore.kernel.org/r/20231204210936.16587-5-shannon.nelson@amd.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-05ionic: Don't check null when calling vfree()Brett Creeley
vfree() checks for null internally, so there's no need to check in the caller. So, always vfree() on variables allocated with valloc(). If the variables are never alloc'd vfree() is still safe. Signed-off-by: Brett Creeley <brett.creeley@amd.com> Signed-off-by: Shannon Nelson <shannon.nelson@amd.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by: Rahul Rameshbabu <rrameshbabu@nvidia.com> Link: https://lore.kernel.org/r/20231204210936.16587-4-shannon.nelson@amd.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-05ionic: set ionic ptr before setting up ethtool opsShannon Nelson
Set the lif->ionic value that is used in some ethtool callbacks before setting ethtool ops. There really shouldn't be any race issues before this change since the netdev hasn't been registered yet, but this seems more correct. Signed-off-by: Shannon Nelson <shannon.nelson@amd.com> Reviewed-by: Brett Creeley <brett.creeley@amd.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by: Rahul Rameshbabu <rrameshbabu@nvidia.com> Link: https://lore.kernel.org/r/20231204210936.16587-3-shannon.nelson@amd.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-05ionic: Use cached VF attributesBrett Creeley
Each time a VF attribute is set via iproute a call to get the VF configuration is also made. This is currently problematic because for each VF configuration call there are multiple commands sent to the device. Unfortunately, this doesn't scale well. Fix this by reporting the cached VF attributes. The original change to query the device for getting the VF attributes f16f5be31009 ("ionic: Query FW when getting VF info via ndo_get_vf_config") was made to remain consistent with device set VF attributes. However, after further investigation there is no need to query the device. Signed-off-by: Brett Creeley <brett.creeley@amd.com> Signed-off-by: Shannon Nelson <shannon.nelson@amd.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by: Rahul Rameshbabu <rrameshbabu@nvidia.com> Link: https://lore.kernel.org/r/20231204210936.16587-2-shannon.nelson@amd.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-05packet: add a generic drop reason for receiveYan Zhai
Commit da37845fdce2 ("packet: uses kfree_skb() for errors.") switches from consume_skb to kfree_skb to improve error handling. However, this could bring a lot of noises when we monitor real packet drops in kfree_skb[1], because in tpacket_rcv or packet_rcv only packet clones can be freed, not actual packets. Adding a generic drop reason to allow distinguish these "clone drops". [1]: https://lore.kernel.org/netdev/CABWYdi00L+O30Q=Zah28QwZ_5RU-xcxLFUK2Zj08A8MrLk9jzg@mail.gmail.com/ Fixes: da37845fdce2 ("packet: uses kfree_skb() for errors.") Suggested-by: Eric Dumazet <edumazet@google.com> Suggested-by: Willem de Bruijn <willemdebruijn.kernel@gmail.com> Signed-off-by: Yan Zhai <yan@cloudflare.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://lore.kernel.org/r/ZW4piNbx3IenYnuw@debian.debian Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-05Documentations: fix net_cachelines documentation build warningCoco Li
Original errors: Documentation/networking/net_cachelines/index.rst:3: WARNING: Explicit markup ends without a blank line; unexpected unindent. Documentation/networking/net_cachelines/inet_connection_sock.rst:3: WARNING: Explicit markup ends without a blank line; unexpected unindent. Documentation/networking/net_cachelines/inet_sock.rst:3: WARNING: Explicit markup ends without a blank line; unexpected unindent. Documentation/networking/net_cachelines/net_device.rst:3: WARNING: Explicit markup ends without a blank line; unexpected unindent. Documentation/networking/net_cachelines/netns_ipv4_sysctl.rst:3: WARNING: Explicit markup ends without a blank line; unexpected unindent. Documentation/networking/net_cachelines/snmp.rst:3: WARNING: Explicit markup ends without a blank line; unexpected unindent. Documentation/networking/net_cachelines/tcp_sock.rst:3: WARNING: Explicit markup ends without a blank line; unexpected unindent. Fixes: 14006f1d8fa2 ("Documentations: Analyze heavily used Networking related structs") Signed-off-by: Coco Li <lixiaoyan@google.com> Link: https://lore.kernel.org/r/20231204220728.746134-1-lixiaoyan@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-05net: core: synchronize link-watch when carrier is queriedJohannes Berg
There are multiple ways to query for the carrier state: through rtnetlink, sysfs, and (possibly) ethtool. Synchronize linkwatch work before these operations so that we don't have a situation where userspace queries the carrier state between the driver's carrier off->on transition and linkwatch running and expects it to work, when really (at least) TX cannot work until linkwatch has run. I previously posted a longer explanation of how this applies to wireless [1] but with this wireless can simply query the state before sending data, to ensure the kernel is ready for it. [1] https://lore.kernel.org/all/346b21d87c69f817ea3c37caceb34f1f56255884.camel@sipsolutions.net/ Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Link: https://lore.kernel.org/r/20231204214706.303c62768415.I1caedccae72ee5a45c9085c5eb49c145ce1c0dd5@changeid Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-05Merge branch 'reorganize-remaining-patch-of-networking-struct-cachelines'Jakub Kicinski
Coco Li says: ==================== Reorganize remaining patch of networking struct cachelines Rebase patches to top-of-head in https://lwn.net/Articles/951321/ to ensure the results of the cacheline savings are still accurate. ==================== Link: https://lore.kernel.org/r/20231204201232.520025-1-lixiaoyan@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-05tcp: reorganize tcp_sock fast path variablesCoco Li
The variables are organized according in the following way: - TX read-mostly hotpath cache lines - TXRX read-mostly hotpath cache lines - RX read-mostly hotpath cache lines - TX read-write hotpath cache line - TXRX read-write hotpath cache line - RX read-write hotpath cache line Fastpath cachelines end after rcvq_space. Cache line boundaries are enforced only between read-mostly and read-write. That is, if read-mostly tx cachelines bleed into read-mostly txrx cachelines, we do not care. We care about the boundaries between read and write cachelines because we want to prevent false sharing. Fast path variables span cache lines before change: 12 Fast path variables span cache lines after change: 8 Suggested-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Wei Wang <weiwan@google.com> Signed-off-by: Coco Li <lixiaoyan@google.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Reviewed-by: David Ahern <dsahern@kernel.org> Link: https://lore.kernel.org/r/20231204201232.520025-3-lixiaoyan@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-05net-device: reorganize net_device fast path variablesCoco Li
Reorganize fast path variables on tx-txrx-rx order Fastpath variables end after npinfo. Below data generated with pahole on x86 architecture. Fast path variables span cache lines before change: 12 Fast path variables span cache lines after change: 4 Suggested-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Coco Li <lixiaoyan@google.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Reviewed-by: David Ahern <dsahern@kernel.org> Link: https://lore.kernel.org/r/20231204201232.520025-2-lixiaoyan@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-05octeon_ep: control net API framework to support offloadsShinas Rasheed
Inquire firmware on supported offloads, as well as convey offloads enabled dynamically to firmware. New control net API functionality is required for the above. Implement control net API framework for offloads. Additionally, fetch/insert offload metadata from hardware RX/TX buffer respectively during receive/transmit. Currently supported offloads include checksum and TSO. Signed-off-by: Shinas Rasheed <srasheed@marvell.com> Link: https://lore.kernel.org/r/20231204154940.2583140-1-srasheed@marvell.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-05Merge branch 'net-mvmdio-performance-related-improvements'Jakub Kicinski
Tobias Waldekranz says: ==================== net: mvmdio: Performance related improvements Observations of the XMDIO bus on a CN9130-based system during a firmware download showed a very low bus utilization, which stemmed from the 150us (10x the average access time) sleep which would take place when the first poll did not succeed. With this series in place, bus throughput increases by about 10x, multiplied by whatever gain you are able to extract from running the MDC at a higher frequency (hardware dependent). ==================== Link: https://lore.kernel.org/r/20231204100811.2708884-1-tobias@waldekranz.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-05net: mvmdio: Support setting the MDC frequency on XSMI controllersTobias Waldekranz
Support the standard "clock-frequency" attribute to set the generated MDC frequency. If not specified, the driver will leave the divisor untouched. Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20231204100811.2708884-4-tobias@waldekranz.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-05net: mvmdio: Avoid excessive sleeps in polled modeTobias Waldekranz
Before this change, when operating in polled mode, i.e. no IRQ is available, every individual C45 access would be hit with a 150us sleep after the bus access. For example, on a board with a CN9130 SoC connected to an MV88X3310 PHY, a single C45 read would take around 165us: root@infix:~$ mdio f212a600.mdio-mii mmd 4:1 bench 0xc003 Performed 1000 reads in 165ms By replacing the long sleep with a tighter poll loop, we observe a 10x increase in bus throughput: root@infix:~$ mdio f212a600.mdio-mii mmd 4:1 bench 0xc003 Performed 1000 reads in 15ms Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20231204100811.2708884-3-tobias@waldekranz.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-05tools: ynl: move private definitions to a separate headerJakub Kicinski
ynl.h has a growing amount of "internal" stuff, which may confuse users who try to take a look at the external API. Currently the internals are at the bottom of the file with a banner in between, but this arrangement makes it hard to add external APIs / inline helpers which need internal definitions. Move internals to a separate header. Link: https://lore.kernel.org/r/20231202211225.342466-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-05tools: ynl: use strerror() if no extack of note providedJakub Kicinski
If kernel didn't give use any meaningful error - print a strerror() to the ynl error message. Reviewed-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Link: https://lore.kernel.org/r/20231202211310.342716-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-05tools: pynl: make flags argument optional for do()Jakub Kicinski
Commit 1768d8a767f8 ("tools/net/ynl: Add support for create flags") added support for setting legacy netlink CRUD flags on netlink messages (NLM_F_REPLACE, _EXCL, _CREATE etc.). Most of genetlink won't need these, don't force callers to pass in an empty argument to each do() call. Reviewed-by: Donald Hunter <donald.hunter@gmail.com> Link: https://lore.kernel.org/r/20231202211005.341613-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-05Merge branch 'net-convert-to-platform-remove-callback-returning-void'Jakub Kicinski
Uwe Kleine-König says: ==================== net*: Convert to platform remove callback returning void (implicit) v1 of this series can be found at https://lore.kernel.org/netdev/20231117095922.876489-1-u.kleine-koenig@pengutronix.de. Changes since then: - Dropped patch #1 as Alex objected. Patch #1 (was #2 before) now converts ipa to remove_new() and introduces an error message in the error path that failed before. ==================== Link: https://lore.kernel.org/r/cover.1701713943.git.u.kleine-koenig@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-05net: wwan: qcom_bam_dmux: Convert to platform remove callback returning voidUwe Kleine-König
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Reviewed-by: Sergey Ryazanov <ryazanov.s.a@gmail.com> Link: https://lore.kernel.org/r/20231117095922.876489-9-u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/49795ee930be6a9a24565e5e7133e6f8383ab532.1701713943.git.u.kleine-koenig@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-05net: wan/ixp4xx_hss: Convert to platform remove callback returning voidUwe Kleine-König
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Link: https://lore.kernel.org/r/20231117095922.876489-8-u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/b0488fa6181a47668e5737905ae7adc8d7cd055e.1701713943.git.u.kleine-koenig@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-05net: wan/fsl_ucc_hdlc: Convert to platform remove callback returning voidUwe Kleine-König
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Link: https://lore.kernel.org/r/20231117095922.876489-7-u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/8c9ffca75ea24810f9ba05a514d5ad59847cc4fe.1701713943.git.u.kleine-koenig@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-05net: sfp: Convert to platform remove callback returning voidUwe Kleine-König
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Link: https://lore.kernel.org/r/20231117095922.876489-6-u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/7c1d50d559c0e0e36a20eb3e410f6e9d3f884b6f.1701713943.git.u.kleine-koenig@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-05net: pcs: rzn1-miic: Convert to platform remove callback returning voidUwe Kleine-König
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20231117095922.876489-5-u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/82b728e14a68c421e269eff3b8083d9d6e62d956.1701713943.git.u.kleine-koenig@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-05net: fjes: Convert to platform remove callback returning voidUwe Kleine-König
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Link: https://lore.kernel.org/r/20231117095922.876489-4-u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/4889ac6a7ffa9b02fa5cdd2d3212e739741f80b8.1701713943.git.u.kleine-koenig@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-05net: ipa: Convert to platform remove callback returning voidUwe Kleine-König
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Link: https://lore.kernel.org/r/20231117095922.876489-3-u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/c43193b9a002e88da36b111bb44ce2973ecde722.1701713943.git.u.kleine-koenig@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-05net: hns3: reduce stack usage in hclge_dbg_dump_tm_pri()Arnd Bergmann
This function exceeds the stack frame warning limit: drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c: In function 'hclge_dbg_dump_tm_pri': drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c:1039:1: error: the frame size of 1408 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] Use dynamic allocation for the largest stack object instead. It would be nice to rewrite this file to completely avoid the extra buffer and just use the one that was already allocated by debugfs, but that is a much larger change. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20231204085735.4112882-1-arnd@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-05tools: ynl: remove generated user space code from gitJakub Kicinski
The ynl-generated user space C code is already above 25kLoC and is growing. The initial reason to commit these files was to make reviewing changes to the generator easier. Unfortunately, it has the opposite effect on reviewing changes to specs, and we get far more changes to specs than to the generator. Uncommit those fails, as they are generated on the fly as needed. netdev patchwork now runs a script on each series to create a diff of generated code on the fly, for the rare cases when looking at it is helpful: https://github.com/kuba-moo/nipa/blob/master/tests/series/ynl/ynl.sh Suggested-by: Paolo Abeni <pabeni@redhat.com> Acked-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-05Merge branch 'sfc-implement-ndo_hwtstamp_-get-set'Jakub Kicinski
Alex Austin says: ==================== sfc: Implement ndo_hwtstamp_(get|set) Implement ndo_hwtstamp_get and ndo_hwtstamp_set for sfc and sfc-siena. ==================== Link: https://lore.kernel.org/r/20231130135826.19018-1-alex.austin@amd.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-05sfc-siena: Implement ndo_hwtstamp_(get|set)Alex Austin
Update efx->ptp_data to use kernel_hwtstamp_config and implement ndo_hwtstamp_(get|set). Remove SIOCGHWTSTAMP and SIOCSHWTSTAMP from efx_ioctl. Signed-off-by: Alex Austin <alex.austin@amd.com> Acked-by: Martin Habets <habetsm.xilinx@gmail.com> Reviewed-by: Edward Cree <ecree.xilinx@gmail.com> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20231130135826.19018-3-alex.austin@amd.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-05sfc: Implement ndo_hwtstamp_(get|set)Alex Austin
Update efx->ptp_data to use kernel_hwtstamp_config and implement ndo_hwtstamp_(get|set). Remove SIOCGHWTSTAMP and SIOCSHWTSTAMP from efx_ioctl. Signed-off-by: Alex Austin <alex.austin@amd.com> Acked-by: Martin Habets <habetsm.xilinx@gmail.com> Reviewed-by: Edward Cree <ecree.xilinx@gmail.com> Link: https://lore.kernel.org/r/20231130135826.19018-2-alex.austin@amd.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-05ipvlan: implement .parse_protocol hook function in ipvlan_header_opsZhengchao Shao
The .parse_protocol hook function in the ipvlan_header_ops structure is not implemented. As a result, when the AF_PACKET family is used to send packets, skb->protocol will be set to 0. Ipvlan is a device of type ARPHRD_ETHER (ether_setup). Therefore, use eth_header_parse_protocol function to obtain the protocol. Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://lore.kernel.org/r/20231202130438.2266343-1-shaozhengchao@huawei.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-12-05macvlan: implement .parse_protocol hook function in macvlan_hard_header_opsZhengchao Shao
The .parse_protocol hook function in the macvlan_header_ops structure is not implemented. As a result, when the AF_PACKET family is used to send packets, skb->protocol will be set to 0. Macvlan is a device of type ARPHRD_ETHER (ether_setup). Therefore, use eth_header_parse_protocol function to obtain the protocol. Suggested-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://lore.kernel.org/r/20231202130658.2266526-1-shaozhengchao@huawei.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-12-05Merge branch 'conver-net-selftests-to-run-in-unique-namespace-part-1'Paolo Abeni
Hangbin Liu says: ==================== Conver net selftests to run in unique namespace (Part 1) As Guillaume pointed, many selftests create namespaces with very common names (like "client" or "server") or even (partially) run directly in init_net. This makes these tests prone to failure if another namespace with the same name already exists. It also makes it impossible to run several instances of these tests in parallel. This patch set intend to conver all the net selftests to run in unique namespace, so we can update the selftest freamwork to run all tests in it's own namespace in parallel. After update, we only need to wait for the test which need longest time. As the total patch set is too large. I break it to severl parts. This is the first part. v2 -> v3: - Convert all ip netns del to cleanup_ns (Justin Iurman) v1 -> v2: - Split the large patch set to small parts for easy review (Paolo Abeni) - Move busywait from forwarding/lib.sh to net/lib.sh directly (Petr Machata) - Update setup_ns/cleanup_ns struct (Petr Machata) - Remove default trap in lib.sh (Petr Machata) ==================== Link: https://lore.kernel.org/r/20231202020110.362433-1-liuhangbin@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-12-05selftests/net: convert unicast_extensions.sh to run it in unique namespaceHangbin Liu
Here is the test result after conversion. # ./unicast_extensions.sh /usr/bin/which: no nettest in (/root/.local/bin:/root/bin:/usr/share/Modules/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin) ########################################################################### Unicast address extensions tests (behavior of reserved IPv4 addresses) ########################################################################### TEST: assign and ping within 240/4 (1 of 2) (is allowed) [ OK ] TEST: assign and ping within 240/4 (2 of 2) (is allowed) [ OK ] TEST: assign and ping within 0/8 (1 of 2) (is allowed) [ OK ] ... TEST: assign and ping class D address (is forbidden) [ OK ] TEST: routing using class D (is forbidden) [ OK ] TEST: routing using 127/8 (is forbidden) [ OK ] Acked-by: David Ahern <dsahern@kernel.org> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-12-05selftests/net: convert sctp_vrf.sh to run it in unique namespaceHangbin Liu
Here is the test result after conversion. ]# ./sctp_vrf.sh Testing For SCTP VRF: TEST 01: nobind, connect from client 1, l3mdev_accept=1, Y [PASS] ... TEST 12: bind vrf-2 & 1 in server, connect from client 1 & 2, N [PASS] ***v6 Tests Done*** Acked-by: David Ahern <dsahern@kernel.org> Reviewed-by: Xin Long <lucien.xin@gmail.com> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-12-05selftests/net: convert ndisc_unsolicited_na_test.sh to run it in unique ↵Hangbin Liu
namespace Here is the test result after conversion. ]# ./ndisc_unsolicited_na_test.sh TEST: test_unsolicited_na: drop_unsolicited_na=0 accept_untracked_na=1 forwarding=1 [ OK ] TEST: test_unsolicited_na: drop_unsolicited_na=0 accept_untracked_na=0 forwarding=0 [ OK ] TEST: test_unsolicited_na: drop_unsolicited_na=0 accept_untracked_na=0 forwarding=1 [ OK ] TEST: test_unsolicited_na: drop_unsolicited_na=0 accept_untracked_na=1 forwarding=0 [ OK ] TEST: test_unsolicited_na: drop_unsolicited_na=1 accept_untracked_na=0 forwarding=0 [ OK ] TEST: test_unsolicited_na: drop_unsolicited_na=1 accept_untracked_na=0 forwarding=1 [ OK ] TEST: test_unsolicited_na: drop_unsolicited_na=1 accept_untracked_na=1 forwarding=0 [ OK ] TEST: test_unsolicited_na: drop_unsolicited_na=1 accept_untracked_na=1 forwarding=1 [ OK ] Tests passed: 8 Tests failed: 0 Acked-by: David Ahern <dsahern@kernel.org> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-12-05selftests/net: convert l2tp.sh to run it in unique namespaceHangbin Liu
Here is the test result after conversion. ]# ./l2tp.sh TEST: IPv4 basic L2TP tunnel [ OK ] TEST: IPv4 route through L2TP tunnel [ OK ] TEST: IPv6 basic L2TP tunnel [ OK ] TEST: IPv6 route through L2TP tunnel [ OK ] TEST: IPv4 basic L2TP tunnel - with IPsec [ OK ] TEST: IPv4 route through L2TP tunnel - with IPsec [ OK ] TEST: IPv6 basic L2TP tunnel - with IPsec [ OK ] TEST: IPv6 route through L2TP tunnel - with IPsec [ OK ] TEST: IPv4 basic L2TP tunnel [ OK ] TEST: IPv4 route through L2TP tunnel [ OK ] TEST: IPv6 basic L2TP tunnel - with IPsec [ OK ] TEST: IPv6 route through L2TP tunnel - with IPsec [ OK ] TEST: IPv4 basic L2TP tunnel - after IPsec teardown [ OK ] TEST: IPv4 route through L2TP tunnel - after IPsec teardown [ OK ] TEST: IPv6 basic L2TP tunnel - after IPsec teardown [ OK ] TEST: IPv6 route through L2TP tunnel - after IPsec teardown [ OK ] Tests passed: 16 Tests failed: 0 Acked-by: David Ahern <dsahern@kernel.org> Reviewed-by: James Chapman <jchapman@katalix.com> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-12-05selftests/net: convert ioam6.sh to run it in unique namespaceHangbin Liu
Here is the test result after conversion. ]# ./ioam6.sh -------------------------------------------------------------------------- OUTPUT tests -------------------------------------------------------------------------- TEST: Unknown IOAM namespace (inline mode) [ OK ] TEST: Unknown IOAM namespace (encap mode) [ OK ] TEST: Missing trace room (inline mode) [ OK ] TEST: Missing trace room (encap mode) [ OK ] TEST: Trace type with bit 0 only (inline mode) [ OK ] ... TEST: Full supported trace (encap mode) [ OK ] -------------------------------------------------------------------------- GLOBAL tests -------------------------------------------------------------------------- TEST: Forward - Full supported trace (inline mode) [ OK ] TEST: Forward - Full supported trace (encap mode) [ OK ] - Tests passed: 88 - Tests failed: 0 Acked-by: David Ahern <dsahern@kernel.org> Reviewed-by: Justin Iurman <justin.iurman@uliege.be> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-12-05sleftests/net: convert icmp.sh to run it in unique namespaceHangbin Liu
Here is the test result after conversion. ]# ./icmp.sh OK Acked-by: David Ahern <dsahern@kernel.org> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-12-05selftests/net: convert icmp_redirect.sh to run it in unique namespaceHangbin Liu
Here is the test result after conversion. # ./icmp_redirect.sh ########################################################################### Legacy routing ########################################################################### TEST: IPv4: redirect exception [ OK ] ... TEST: IPv4: mtu exception plus redirect [ OK ] TEST: IPv6: mtu exception plus redirect [ OK ] Tests passed: 40 Tests failed: 0 Tests xfailed: 0 Acked-by: David Ahern <dsahern@kernel.org> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-12-05selftests/net: convert traceroute.sh to run it in unique namespaceHangbin Liu
Here is the test result after conversion. ]# ./traceroute.sh TEST: IPV6 traceroute [ OK ] TEST: IPV4 traceroute [ OK ] Tests passed: 2 Tests failed: 0 Acked-by: David Ahern <dsahern@kernel.org> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-12-05selftests/net: convert drop_monitor_tests.sh to run it in unique namespaceHangbin Liu
Here is the test result after conversion. ]# ./drop_monitor_tests.sh Software drops test TEST: Capturing active software drops [ OK ] TEST: Capturing inactive software drops [ OK ] Hardware drops test TEST: Capturing active hardware drops [ OK ] TEST: Capturing inactive hardware drops [ OK ] Tests passed: 4 Tests failed: 0 Acked-by: David Ahern <dsahern@kernel.org> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
generated by cgit (git 2.34.1) at 2026-01-06 18:22:10 +0000