Sockmap iterator #2
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Author
|
Master branch: 95cec14 patch https://patchwork.ozlabs.org/project/netdev/patch/20200904095904.612390-2-lmb@cloudflare.com/ applied successfully |
of sources, e.g. a bpf_iter for sk_storage maps receives one as part of the context. It's desirable to be able to pass these to functions that expect PTR_TO_SOCKET. For example, it enables us to insert such a socket into a sockmap via map_elem_update. Teach the verifier that a PTR_TO_BTF_ID for a struct sock is equivalent to PTR_TO_SOCKET. There is one hazard here: bpf_sk_release also takes a PTR_TO_SOCKET, but expects it to be refcounted. Since this isn't the case for pointers derived from BTF we must prevent them from being passed to the function. Luckily, we can simply check that the ref_obj_id is not zero in release_reference, and return an error otherwise. Signed-off-by: Lorenz Bauer <lmb@cloudflare.com> --- kernel/bpf/verifier.c | 61 +++++++++++++++++++++++++------------------ 1 file changed, 36 insertions(+), 25 deletions(-)
that returns NULL if the socket we just found is not a full socket. However, this check is not necessary. On insertion we ensure that we have a full socket (caveat around sock_ops), so request sockets are not a problem. Time-wait sockets are allocated separate from the original socket and then fed into the hashdance. They don't affect the sockets already stored in the sockmap. Suggested-by: Jakub Sitnicki <jakub@cloudflare.com> Signed-off-by: Lorenz Bauer <lmb@cloudflare.com> --- net/core/sock_map.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
…age and hashtable implementation. sockmap and sockhash share the same iteration context: a pointer to an arbitrary key and a pointer to a socket. Both pointers may be NULL, and so BPF has to perform a NULL check before accessing them. Technically it's not possible for sockhash iteration to yield a NULL socket, but we ignore this to be able to use a single iteration point. Iteration will visit all keys that remain unmodified during the lifetime of the iterator. It may or may not visit newly added ones. Switch from using rcu_dereference_raw to plain rcu_dereference, so we gain another guard rail if CONFIG_PROVE_RCU is enabled. Signed-off-by: Lorenz Bauer <lmb@cloudflare.com> --- net/core/sock_map.c | 280 +++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 278 insertions(+), 2 deletions(-)
reference counting, and must therefore be prevented. Add a test which ensures that this property holds. Signed-off-by: Lorenz Bauer <lmb@cloudflare.com> --- .../bpf/prog_tests/reference_tracking.c | 20 ++++++++++++++++++- .../bpf/progs/test_sk_ref_track_invalid.c | 20 +++++++++++++++++++ 2 files changed, 39 insertions(+), 1 deletion(-) create mode 100644 tools/testing/selftests/bpf/progs/test_sk_ref_track_invalid.c
…ked. Pull this out into a helper function for use in other tests. Signed-off-by: Lorenz Bauer <lmb@cloudflare.com> --- .../selftests/bpf/prog_tests/sockmap_basic.c | 50 +++++++++++++------ 1 file changed, 36 insertions(+), 14 deletions(-)
…ter. Signed-off-by: Lorenz Bauer <lmb@cloudflare.com> --- .../selftests/bpf/prog_tests/sockmap_basic.c | 88 +++++++++++++++++++ tools/testing/selftests/bpf/progs/bpf_iter.h | 9 ++ .../selftests/bpf/progs/bpf_iter_sockmap.c | 57 ++++++++++++ .../selftests/bpf/progs/bpf_iter_sockmap.h | 3 + 4 files changed, 157 insertions(+) create mode 100644 tools/testing/selftests/bpf/progs/bpf_iter_sockmap.c create mode 100644 tools/testing/selftests/bpf/progs/bpf_iter_sockmap.h
Author
|
Master branch: f9bec5d patch https://patchwork.ozlabs.org/project/netdev/patch/20200904095904.612390-2-lmb@cloudflare.com/ applied successfully |
Author
|
At least one diff in series https://patchwork.ozlabs.org/project/netdev/list/?series=199474 expired. Closing PR. |
Author
|
Master branch: f9bec5d patch https://patchwork.ozlabs.org/project/netdev/patch/20200907144701.44867-2-lmb@cloudflare.com/ applied successfully |
kernel-patches-bot
pushed a commit
that referenced
this pull request
Sep 16, 2020
We have a number of "uart.port->desc.lock vs desc.lock->uart.port" lockdep reports coming from 8250 driver; this causes a bit of trouble to people, so let's fix it. The problem is reverse lock order in two different call paths: chain #1: serial8250_do_startup() spin_lock_irqsave(&port->lock); disable_irq_nosync(port->irq); raw_spin_lock_irqsave(&desc->lock) chain #2: __report_bad_irq() raw_spin_lock_irqsave(&desc->lock) for_each_action_of_desc() printk() spin_lock_irqsave(&port->lock); Fix this by changing the order of locks in serial8250_do_startup(): do disable_irq_nosync() first, which grabs desc->lock, and grab uart->port after that, so that chain #1 and chain #2 have same lock order. Full lockdep splat: ====================================================== WARNING: possible circular locking dependency detected 5.4.39 #55 Not tainted ====================================================== swapper/0/0 is trying to acquire lock: ffffffffab65b6c0 (console_owner){-...}, at: console_lock_spinning_enable+0x31/0x57 but task is already holding lock: ffff88810a8e34c0 (&irq_desc_lock_class){-.-.}, at: __report_bad_irq+0x5b/0xba which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&irq_desc_lock_class){-.-.}: _raw_spin_lock_irqsave+0x61/0x8d __irq_get_desc_lock+0x65/0x89 __disable_irq_nosync+0x3b/0x93 serial8250_do_startup+0x451/0x75c uart_startup+0x1b4/0x2ff uart_port_activate+0x73/0xa0 tty_port_open+0xae/0x10a uart_open+0x1b/0x26 tty_open+0x24d/0x3a0 chrdev_open+0xd5/0x1cc do_dentry_open+0x299/0x3c8 path_openat+0x434/0x1100 do_filp_open+0x9b/0x10a do_sys_open+0x15f/0x3d7 kernel_init_freeable+0x157/0x1dd kernel_init+0xe/0x105 ret_from_fork+0x27/0x50 -> #1 (&port_lock_key){-.-.}: _raw_spin_lock_irqsave+0x61/0x8d serial8250_console_write+0xa7/0x2a0 console_unlock+0x3b7/0x528 vprintk_emit+0x111/0x17f printk+0x59/0x73 register_console+0x336/0x3a4 uart_add_one_port+0x51b/0x5be serial8250_register_8250_port+0x454/0x55e dw8250_probe+0x4dc/0x5b9 platform_drv_probe+0x67/0x8b really_probe+0x14a/0x422 driver_probe_device+0x66/0x130 device_driver_attach+0x42/0x5b __driver_attach+0xca/0x139 bus_for_each_dev+0x97/0xc9 bus_add_driver+0x12b/0x228 driver_register+0x64/0xed do_one_initcall+0x20c/0x4a6 do_initcall_level+0xb5/0xc5 do_basic_setup+0x4c/0x58 kernel_init_freeable+0x13f/0x1dd kernel_init+0xe/0x105 ret_from_fork+0x27/0x50 -> #0 (console_owner){-...}: __lock_acquire+0x118d/0x2714 lock_acquire+0x203/0x258 console_lock_spinning_enable+0x51/0x57 console_unlock+0x25d/0x528 vprintk_emit+0x111/0x17f printk+0x59/0x73 __report_bad_irq+0xa3/0xba note_interrupt+0x19a/0x1d6 handle_irq_event_percpu+0x57/0x79 handle_irq_event+0x36/0x55 handle_fasteoi_irq+0xc2/0x18a do_IRQ+0xb3/0x157 ret_from_intr+0x0/0x1d cpuidle_enter_state+0x12f/0x1fd cpuidle_enter+0x2e/0x3d do_idle+0x1ce/0x2ce cpu_startup_entry+0x1d/0x1f start_kernel+0x406/0x46a secondary_startup_64+0xa4/0xb0 other info that might help us debug this: Chain exists of: console_owner --> &port_lock_key --> &irq_desc_lock_class Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&irq_desc_lock_class); lock(&port_lock_key); lock(&irq_desc_lock_class); lock(console_owner); *** DEADLOCK *** 2 locks held by swapper/0/0: #0: ffff88810a8e34c0 (&irq_desc_lock_class){-.-.}, at: __report_bad_irq+0x5b/0xba #1: ffffffffab65b5c0 (console_lock){+.+.}, at: console_trylock_spinning+0x20/0x181 stack backtrace: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.4.39 #55 Hardware name: XXXXXX Call Trace: <IRQ> dump_stack+0xbf/0x133 ? print_circular_bug+0xd6/0xe9 check_noncircular+0x1b9/0x1c3 __lock_acquire+0x118d/0x2714 lock_acquire+0x203/0x258 ? console_lock_spinning_enable+0x31/0x57 console_lock_spinning_enable+0x51/0x57 ? console_lock_spinning_enable+0x31/0x57 console_unlock+0x25d/0x528 ? console_trylock+0x18/0x4e vprintk_emit+0x111/0x17f ? lock_acquire+0x203/0x258 printk+0x59/0x73 __report_bad_irq+0xa3/0xba note_interrupt+0x19a/0x1d6 handle_irq_event_percpu+0x57/0x79 handle_irq_event+0x36/0x55 handle_fasteoi_irq+0xc2/0x18a do_IRQ+0xb3/0x157 common_interrupt+0xf/0xf </IRQ> Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Fixes: 768aec0 ("serial: 8250: fix shared interrupts issues with SMP and RT kernels") Reported-by: Guenter Roeck <linux@roeck-us.net> Reported-by: Raul Rangel <rrangel@google.com> BugLink: https://bugs.chromium.org/p/chromium/issues/detail?id=1114800 Link: https://lore.kernel.org/lkml/CAHQZ30BnfX+gxjPm1DUd5psOTqbyDh4EJE=2=VAMW_VDafctkA@mail.gmail.com/T/#u Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Guenter Roeck <linux@roeck-us.net> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200817022646.1484638-1-sergey.senozhatsky@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Sep 16, 2020
With the conversion of the tree locks to rwsem I got the following lockdep splat: ====================================================== WARNING: possible circular locking dependency detected 5.8.0-rc7-00165-g04ec4da5f45f-dirty #922 Not tainted ------------------------------------------------------ compsize/11122 is trying to acquire lock: ffff889fabca8768 (&mm->mmap_lock#2){++++}-{3:3}, at: __might_fault+0x3e/0x90 but task is already holding lock: ffff889fe720fe40 (btrfs-fs-00){++++}-{3:3}, at: __btrfs_tree_read_lock+0x39/0x180 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (btrfs-fs-00){++++}-{3:3}: down_write_nested+0x3b/0x70 __btrfs_tree_lock+0x24/0x120 btrfs_search_slot+0x756/0x990 btrfs_lookup_inode+0x3a/0xb4 __btrfs_update_delayed_inode+0x93/0x270 btrfs_async_run_delayed_root+0x168/0x230 btrfs_work_helper+0xd4/0x570 process_one_work+0x2ad/0x5f0 worker_thread+0x3a/0x3d0 kthread+0x133/0x150 ret_from_fork+0x1f/0x30 -> #1 (&delayed_node->mutex){+.+.}-{3:3}: __mutex_lock+0x9f/0x930 btrfs_delayed_update_inode+0x50/0x440 btrfs_update_inode+0x8a/0xf0 btrfs_dirty_inode+0x5b/0xd0 touch_atime+0xa1/0xd0 btrfs_file_mmap+0x3f/0x60 mmap_region+0x3a4/0x640 do_mmap+0x376/0x580 vm_mmap_pgoff+0xd5/0x120 ksys_mmap_pgoff+0x193/0x230 do_syscall_64+0x50/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xa9 -> #0 (&mm->mmap_lock#2){++++}-{3:3}: __lock_acquire+0x1272/0x2310 lock_acquire+0x9e/0x360 __might_fault+0x68/0x90 _copy_to_user+0x1e/0x80 copy_to_sk.isra.32+0x121/0x300 search_ioctl+0x106/0x200 btrfs_ioctl_tree_search_v2+0x7b/0xf0 btrfs_ioctl+0x106f/0x30a0 ksys_ioctl+0x83/0xc0 __x64_sys_ioctl+0x16/0x20 do_syscall_64+0x50/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xa9 other info that might help us debug this: Chain exists of: &mm->mmap_lock#2 --> &delayed_node->mutex --> btrfs-fs-00 Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(btrfs-fs-00); lock(&delayed_node->mutex); lock(btrfs-fs-00); lock(&mm->mmap_lock#2); *** DEADLOCK *** 1 lock held by compsize/11122: #0: ffff889fe720fe40 (btrfs-fs-00){++++}-{3:3}, at: __btrfs_tree_read_lock+0x39/0x180 stack backtrace: CPU: 17 PID: 11122 Comm: compsize Kdump: loaded Not tainted 5.8.0-rc7-00165-g04ec4da5f45f-dirty #922 Hardware name: Quanta Tioga Pass Single Side 01-0030993006/Tioga Pass Single Side, BIOS F08_3A18 12/20/2018 Call Trace: dump_stack+0x78/0xa0 check_noncircular+0x165/0x180 __lock_acquire+0x1272/0x2310 lock_acquire+0x9e/0x360 ? __might_fault+0x3e/0x90 ? find_held_lock+0x72/0x90 __might_fault+0x68/0x90 ? __might_fault+0x3e/0x90 _copy_to_user+0x1e/0x80 copy_to_sk.isra.32+0x121/0x300 ? btrfs_search_forward+0x2a6/0x360 search_ioctl+0x106/0x200 btrfs_ioctl_tree_search_v2+0x7b/0xf0 btrfs_ioctl+0x106f/0x30a0 ? __do_sys_newfstat+0x5a/0x70 ? ksys_ioctl+0x83/0xc0 ksys_ioctl+0x83/0xc0 __x64_sys_ioctl+0x16/0x20 do_syscall_64+0x50/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xa9 The problem is we're doing a copy_to_user() while holding tree locks, which can deadlock if we have to do a page fault for the copy_to_user(). This exists even without my locking changes, so it needs to be fixed. Rework the search ioctl to do the pre-fault and then copy_to_user_nofault for the copying. CC: stable@vger.kernel.org # 4.4+ Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Josef Bacik <josef@toxicpanda.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Sep 16, 2020
I got the following lockdep splat while testing: ====================================================== WARNING: possible circular locking dependency detected 5.8.0-rc7-00172-g021118712e59 #932 Not tainted ------------------------------------------------------ btrfs/229626 is trying to acquire lock: ffffffff828513f0 (cpu_hotplug_lock){++++}-{0:0}, at: alloc_workqueue+0x378/0x450 but task is already holding lock: ffff889dd3889518 (&fs_info->scrub_lock){+.+.}-{3:3}, at: btrfs_scrub_dev+0x11c/0x630 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #7 (&fs_info->scrub_lock){+.+.}-{3:3}: __mutex_lock+0x9f/0x930 btrfs_scrub_dev+0x11c/0x630 btrfs_dev_replace_by_ioctl.cold.21+0x10a/0x1d4 btrfs_ioctl+0x2799/0x30a0 ksys_ioctl+0x83/0xc0 __x64_sys_ioctl+0x16/0x20 do_syscall_64+0x50/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xa9 -> #6 (&fs_devs->device_list_mutex){+.+.}-{3:3}: __mutex_lock+0x9f/0x930 btrfs_run_dev_stats+0x49/0x480 commit_cowonly_roots+0xb5/0x2a0 btrfs_commit_transaction+0x516/0xa60 sync_filesystem+0x6b/0x90 generic_shutdown_super+0x22/0x100 kill_anon_super+0xe/0x30 btrfs_kill_super+0x12/0x20 deactivate_locked_super+0x29/0x60 cleanup_mnt+0xb8/0x140 task_work_run+0x6d/0xb0 __prepare_exit_to_usermode+0x1cc/0x1e0 do_syscall_64+0x5c/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xa9 -> #5 (&fs_info->tree_log_mutex){+.+.}-{3:3}: __mutex_lock+0x9f/0x930 btrfs_commit_transaction+0x4bb/0xa60 sync_filesystem+0x6b/0x90 generic_shutdown_super+0x22/0x100 kill_anon_super+0xe/0x30 btrfs_kill_super+0x12/0x20 deactivate_locked_super+0x29/0x60 cleanup_mnt+0xb8/0x140 task_work_run+0x6d/0xb0 __prepare_exit_to_usermode+0x1cc/0x1e0 do_syscall_64+0x5c/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xa9 -> #4 (&fs_info->reloc_mutex){+.+.}-{3:3}: __mutex_lock+0x9f/0x930 btrfs_record_root_in_trans+0x43/0x70 start_transaction+0xd1/0x5d0 btrfs_dirty_inode+0x42/0xd0 touch_atime+0xa1/0xd0 btrfs_file_mmap+0x3f/0x60 mmap_region+0x3a4/0x640 do_mmap+0x376/0x580 vm_mmap_pgoff+0xd5/0x120 ksys_mmap_pgoff+0x193/0x230 do_syscall_64+0x50/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xa9 -> #3 (&mm->mmap_lock#2){++++}-{3:3}: __might_fault+0x68/0x90 _copy_to_user+0x1e/0x80 perf_read+0x141/0x2c0 vfs_read+0xad/0x1b0 ksys_read+0x5f/0xe0 do_syscall_64+0x50/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xa9 -> #2 (&cpuctx_mutex){+.+.}-{3:3}: __mutex_lock+0x9f/0x930 perf_event_init_cpu+0x88/0x150 perf_event_init+0x1db/0x20b start_kernel+0x3ae/0x53c secondary_startup_64+0xa4/0xb0 -> #1 (pmus_lock){+.+.}-{3:3}: __mutex_lock+0x9f/0x930 perf_event_init_cpu+0x4f/0x150 cpuhp_invoke_callback+0xb1/0x900 _cpu_up.constprop.26+0x9f/0x130 cpu_up+0x7b/0xc0 bringup_nonboot_cpus+0x4f/0x60 smp_init+0x26/0x71 kernel_init_freeable+0x110/0x258 kernel_init+0xa/0x103 ret_from_fork+0x1f/0x30 -> #0 (cpu_hotplug_lock){++++}-{0:0}: __lock_acquire+0x1272/0x2310 lock_acquire+0x9e/0x360 cpus_read_lock+0x39/0xb0 alloc_workqueue+0x378/0x450 __btrfs_alloc_workqueue+0x15d/0x200 btrfs_alloc_workqueue+0x51/0x160 scrub_workers_get+0x5a/0x170 btrfs_scrub_dev+0x18c/0x630 btrfs_dev_replace_by_ioctl.cold.21+0x10a/0x1d4 btrfs_ioctl+0x2799/0x30a0 ksys_ioctl+0x83/0xc0 __x64_sys_ioctl+0x16/0x20 do_syscall_64+0x50/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xa9 other info that might help us debug this: Chain exists of: cpu_hotplug_lock --> &fs_devs->device_list_mutex --> &fs_info->scrub_lock Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&fs_info->scrub_lock); lock(&fs_devs->device_list_mutex); lock(&fs_info->scrub_lock); lock(cpu_hotplug_lock); *** DEADLOCK *** 2 locks held by btrfs/229626: #0: ffff88bfe8bb86e0 (&fs_devs->device_list_mutex){+.+.}-{3:3}, at: btrfs_scrub_dev+0xbd/0x630 #1: ffff889dd3889518 (&fs_info->scrub_lock){+.+.}-{3:3}, at: btrfs_scrub_dev+0x11c/0x630 stack backtrace: CPU: 15 PID: 229626 Comm: btrfs Kdump: loaded Not tainted 5.8.0-rc7-00172-g021118712e59 #932 Hardware name: Quanta Tioga Pass Single Side 01-0030993006/Tioga Pass Single Side, BIOS F08_3A18 12/20/2018 Call Trace: dump_stack+0x78/0xa0 check_noncircular+0x165/0x180 __lock_acquire+0x1272/0x2310 lock_acquire+0x9e/0x360 ? alloc_workqueue+0x378/0x450 cpus_read_lock+0x39/0xb0 ? alloc_workqueue+0x378/0x450 alloc_workqueue+0x378/0x450 ? rcu_read_lock_sched_held+0x52/0x80 __btrfs_alloc_workqueue+0x15d/0x200 btrfs_alloc_workqueue+0x51/0x160 scrub_workers_get+0x5a/0x170 btrfs_scrub_dev+0x18c/0x630 ? start_transaction+0xd1/0x5d0 btrfs_dev_replace_by_ioctl.cold.21+0x10a/0x1d4 btrfs_ioctl+0x2799/0x30a0 ? do_sigaction+0x102/0x250 ? lockdep_hardirqs_on_prepare+0xca/0x160 ? _raw_spin_unlock_irq+0x24/0x30 ? trace_hardirqs_on+0x1c/0xe0 ? _raw_spin_unlock_irq+0x24/0x30 ? do_sigaction+0x102/0x250 ? ksys_ioctl+0x83/0xc0 ksys_ioctl+0x83/0xc0 __x64_sys_ioctl+0x16/0x20 do_syscall_64+0x50/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xa9 This happens because we're allocating the scrub workqueues under the scrub and device list mutex, which brings in a whole host of other dependencies. Because the work queue allocation is done with GFP_KERNEL, it can trigger reclaim, which can lead to a transaction commit, which in turns needs the device_list_mutex, it can lead to a deadlock. A different problem for which this fix is a solution. Fix this by moving the actual allocation outside of the scrub lock, and then only take the lock once we're ready to actually assign them to the fs_info. We'll now have to cleanup the workqueues in a few more places, so I've added a helper to do the refcount dance to safely free the workqueues. CC: stable@vger.kernel.org # 5.4+ Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Josef Bacik <josef@toxicpanda.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Sep 16, 2020
…s metrics" test Linux 5.9 introduced perf test case "Parse and process metrics" and on s390 this test case always dumps core: [root@t35lp67 perf]# ./perf test -vvvv -F 67 67: Parse and process metrics : --- start --- metric expr inst_retired.any / cpu_clk_unhalted.thread for IPC parsing metric: inst_retired.any / cpu_clk_unhalted.thread Segmentation fault (core dumped) [root@t35lp67 perf]# I debugged this core dump and gdb shows this call chain: (gdb) where #0 0x000003ffabc3192a in __strnlen_c_1 () from /lib64/libc.so.6 #1 0x000003ffabc293de in strcasestr () from /lib64/libc.so.6 #2 0x0000000001102ba2 in match_metric(list=0x1e6ea20 "inst_retired.any", n=<optimized out>) at util/metricgroup.c:368 #3 find_metric (map=<optimized out>, map=<optimized out>, metric=0x1e6ea20 "inst_retired.any") at util/metricgroup.c:765 #4 __resolve_metric (ids=0x0, map=<optimized out>, metric_list=0x0, metric_no_group=<optimized out>, m=<optimized out>) at util/metricgroup.c:844 #5 resolve_metric (ids=0x0, map=0x0, metric_list=0x0, metric_no_group=<optimized out>) at util/metricgroup.c:881 #6 metricgroup__add_metric (metric=<optimized out>, metric_no_group=metric_no_group@entry=false, events=<optimized out>, events@entry=0x3ffd84fb878, metric_list=0x0, metric_list@entry=0x3ffd84fb868, map=0x0) at util/metricgroup.c:943 #7 0x00000000011034ae in metricgroup__add_metric_list (map=0x13f9828 <map>, metric_list=0x3ffd84fb868, events=0x3ffd84fb878, metric_no_group=<optimized out>, list=<optimized out>) at util/metricgroup.c:988 #8 parse_groups (perf_evlist=perf_evlist@entry=0x1e70260, str=str@entry=0x12f34b2 "IPC", metric_no_group=<optimized out>, metric_no_merge=<optimized out>, fake_pmu=fake_pmu@entry=0x1462f18 <perf_pmu.fake>, metric_events=0x3ffd84fba58, map=0x1) at util/metricgroup.c:1040 #9 0x0000000001103eb2 in metricgroup__parse_groups_test( evlist=evlist@entry=0x1e70260, map=map@entry=0x13f9828 <map>, str=str@entry=0x12f34b2 "IPC", metric_no_group=metric_no_group@entry=false, metric_no_merge=metric_no_merge@entry=false, metric_events=0x3ffd84fba58) at util/metricgroup.c:1082 #10 0x00000000010c84d8 in __compute_metric (ratio2=0x0, name2=0x0, ratio1=<synthetic pointer>, name1=0x12f34b2 "IPC", vals=0x3ffd84fbad8, name=0x12f34b2 "IPC") at tests/parse-metric.c:159 #11 compute_metric (ratio=<synthetic pointer>, vals=0x3ffd84fbad8, name=0x12f34b2 "IPC") at tests/parse-metric.c:189 #12 test_ipc () at tests/parse-metric.c:208 ..... ..... omitted many more lines This test case was added with commit 218ca91 ("perf tests: Add parse metric test for frontend metric"). When I compile with make DEBUG=y it works fine and I do not get a core dump. It turned out that the above listed function call chain worked on a struct pmu_event array which requires a trailing element with zeroes which was missing. The marco map_for_each_event() loops over that array tests for members metric_expr/metric_name/metric_group being non-NULL. Adding this element fixes the issue. Output after: [root@t35lp46 perf]# ./perf test 67 67: Parse and process metrics : Ok [root@t35lp46 perf]# Committer notes: As Ian remarks, this is not s390 specific: <quote Ian> This also shows up with address sanitizer on all architectures (perhaps change the patch title) and perhaps add a "Fixes: <commit>" tag. ================================================================= ==4718==ERROR: AddressSanitizer: global-buffer-overflow on address 0x55c93b4d59e8 at pc 0x55c93a1541e2 bp 0x7ffd24327c60 sp 0x7ffd24327c58 READ of size 8 at 0x55c93b4d59e8 thread T0 #0 0x55c93a1541e1 in find_metric tools/perf/util/metricgroup.c:764:2 #1 0x55c93a153e6c in __resolve_metric tools/perf/util/metricgroup.c:844:9 #2 0x55c93a152f18 in resolve_metric tools/perf/util/metricgroup.c:881:9 #3 0x55c93a1528db in metricgroup__add_metric tools/perf/util/metricgroup.c:943:9 #4 0x55c93a151996 in metricgroup__add_metric_list tools/perf/util/metricgroup.c:988:9 #5 0x55c93a1511b9 in parse_groups tools/perf/util/metricgroup.c:1040:8 #6 0x55c93a1513e1 in metricgroup__parse_groups_test tools/perf/util/metricgroup.c:1082:9 #7 0x55c93a0108ae in __compute_metric tools/perf/tests/parse-metric.c:159:8 #8 0x55c93a010744 in compute_metric tools/perf/tests/parse-metric.c:189:9 #9 0x55c93a00f5ee in test_ipc tools/perf/tests/parse-metric.c:208:2 #10 0x55c93a00f1e8 in test__parse_metric tools/perf/tests/parse-metric.c:345:2 #11 0x55c939fd7202 in run_test tools/perf/tests/builtin-test.c:410:9 #12 0x55c939fd6736 in test_and_print tools/perf/tests/builtin-test.c:440:9 #13 0x55c939fd58c3 in __cmd_test tools/perf/tests/builtin-test.c:661:4 #14 0x55c939fd4e02 in cmd_test tools/perf/tests/builtin-test.c:807:9 #15 0x55c939e4763d in run_builtin tools/perf/perf.c:313:11 #16 0x55c939e46475 in handle_internal_command tools/perf/perf.c:365:8 #17 0x55c939e4737e in run_argv tools/perf/perf.c:409:2 #18 0x55c939e45f7e in main tools/perf/perf.c:539:3 0x55c93b4d59e8 is located 0 bytes to the right of global variable 'pme_test' defined in 'tools/perf/tests/parse-metric.c:17:25' (0x55c93b4d54a0) of size 1352 SUMMARY: AddressSanitizer: global-buffer-overflow tools/perf/util/metricgroup.c:764:2 in find_metric Shadow bytes around the buggy address: 0x0ab9a7692ae0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0ab9a7692af0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0ab9a7692b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0ab9a7692b10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0ab9a7692b20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x0ab9a7692b30: 00 00 00 00 00 00 00 00 00 00 00 00 00[f9]f9 f9 0x0ab9a7692b40: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 0x0ab9a7692b50: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 0x0ab9a7692b60: f9 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00 0x0ab9a7692b70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0ab9a7692b80: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb Shadow gap: cc </quote> I'm also adding the missing "Fixes" tag and setting just .name to NULL, as doing it that way is more compact (the compiler will zero out everything else) and the table iterators look for .name being NULL as the sentinel marking the end of the table. Fixes: 0a507af ("perf tests: Add parse metric test for ipc metric") Signed-off-by: Thomas Richter <tmricht@linux.ibm.com> Reviewed-by: Sumanth Korikkar <sumanthk@linux.ibm.com> Acked-by: Ian Rogers <irogers@google.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Sven Schnelle <svens@linux.ibm.com> Cc: Vasily Gorbik <gor@linux.ibm.com> Link: http://lore.kernel.org/lkml/20200825071211.16959-1-tmricht@linux.ibm.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Sep 16, 2020
Luo bin says: ==================== hinic: BugFixes The bugs fixed in this patchset have been present since the following commits: patch #1: Fixes: 00e57a6 ("net-next/hinic: Add Tx operation") patch #2: Fixes: 5e126e7 ("hinic: add firmware update support") ==================== Signed-off-by: Jakub Kicinski <kuba@kernel.org>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Sep 16, 2020
…arnings Since commit 845e0eb ("net: change addr_list_lock back to static key"), cascaded DSA setups (DSA switch port as DSA master for another DSA switch port) are emitting this lockdep warning: ============================================ WARNING: possible recursive locking detected 5.8.0-rc1-00133-g923e4b5032dd-dirty #208 Not tainted -------------------------------------------- dhcpcd/323 is trying to acquire lock: ffff000066dd4268 (&dsa_master_addr_list_lock_key/1){+...}-{2:2}, at: dev_mc_sync+0x44/0x90 but task is already holding lock: ffff00006608c268 (&dsa_master_addr_list_lock_key/1){+...}-{2:2}, at: dev_mc_sync+0x44/0x90 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&dsa_master_addr_list_lock_key/1); lock(&dsa_master_addr_list_lock_key/1); *** DEADLOCK *** May be due to missing lock nesting notation 3 locks held by dhcpcd/323: #0: ffffdbd1381dda18 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_lock+0x24/0x30 #1: ffff00006614b268 (_xmit_ETHER){+...}-{2:2}, at: dev_set_rx_mode+0x28/0x48 #2: ffff00006608c268 (&dsa_master_addr_list_lock_key/1){+...}-{2:2}, at: dev_mc_sync+0x44/0x90 stack backtrace: Call trace: dump_backtrace+0x0/0x1e0 show_stack+0x20/0x30 dump_stack+0xec/0x158 __lock_acquire+0xca0/0x2398 lock_acquire+0xe8/0x440 _raw_spin_lock_nested+0x64/0x90 dev_mc_sync+0x44/0x90 dsa_slave_set_rx_mode+0x34/0x50 __dev_set_rx_mode+0x60/0xa0 dev_mc_sync+0x84/0x90 dsa_slave_set_rx_mode+0x34/0x50 __dev_set_rx_mode+0x60/0xa0 dev_set_rx_mode+0x30/0x48 __dev_open+0x10c/0x180 __dev_change_flags+0x170/0x1c8 dev_change_flags+0x2c/0x70 devinet_ioctl+0x774/0x878 inet_ioctl+0x348/0x3b0 sock_do_ioctl+0x50/0x310 sock_ioctl+0x1f8/0x580 ksys_ioctl+0xb0/0xf0 __arm64_sys_ioctl+0x28/0x38 el0_svc_common.constprop.0+0x7c/0x180 do_el0_svc+0x2c/0x98 el0_sync_handler+0x9c/0x1b8 el0_sync+0x158/0x180 Since DSA never made use of the netdev API for describing links between upper devices and lower devices, the dev->lower_level value of a DSA switch interface would be 1, which would warn when it is a DSA master. We can use netdev_upper_dev_link() to describe the relationship between a DSA slave and a DSA master. To be precise, a DSA "slave" (switch port) is an "upper" to a DSA "master" (host port). The relationship is "many uppers to one lower", like in the case of VLAN. So, for that reason, we use the same function as VLAN uses. There might be a chance that somebody will try to take hold of this interface and use it immediately after register_netdev() and before netdev_upper_dev_link(). To avoid that, we do the registration and linkage while holding the RTNL, and we use the RTNL-locked cousin of register_netdev(), which is register_netdevice(). Since this warning was not there when lockdep was using dynamic keys for addr_list_lock, we are blaming the lockdep patch itself. The network stack _has_ been using static lockdep keys before, and it _is_ likely that stacked DSA setups have been triggering these lockdep warnings since forever, however I can't test very old kernels on this particular stacked DSA setup, to ensure I'm not in fact introducing regressions. Fixes: 845e0eb ("net: change addr_list_lock back to static key") Suggested-by: Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Sep 16, 2020
syzbot reported twice a lockdep issue in fib6_del() [1]
which I think is caused by net->ipv6.fib6_null_entry
having a NULL fib6_table pointer.
fib6_del() already checks for fib6_null_entry special
case, we only need to return earlier.
Bug seems to occur very rarely, I have thus chosen
a 'bug origin' that makes backports not too complex.
[1]
WARNING: suspicious RCU usage
5.9.0-rc4-syzkaller #0 Not tainted
-----------------------------
net/ipv6/ip6_fib.c:1996 suspicious rcu_dereference_protected() usage!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
4 locks held by syz-executor.5/8095:
#0: ffffffff8a7ea708 (rtnl_mutex){+.+.}-{3:3}, at: ppp_release+0x178/0x240 drivers/net/ppp/ppp_generic.c:401
#1: ffff88804c422dd8 (&net->ipv6.fib6_gc_lock){+.-.}-{2:2}, at: spin_trylock_bh include/linux/spinlock.h:414 [inline]
#1: ffff88804c422dd8 (&net->ipv6.fib6_gc_lock){+.-.}-{2:2}, at: fib6_run_gc+0x21b/0x2d0 net/ipv6/ip6_fib.c:2312
#2: ffffffff89bd6a40 (rcu_read_lock){....}-{1:2}, at: __fib6_clean_all+0x0/0x290 net/ipv6/ip6_fib.c:2613
#3: ffff8880a82e6430 (&tb->tb6_lock){+.-.}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:359 [inline]
#3: ffff8880a82e6430 (&tb->tb6_lock){+.-.}-{2:2}, at: __fib6_clean_all+0x107/0x290 net/ipv6/ip6_fib.c:2245
stack backtrace:
CPU: 1 PID: 8095 Comm: syz-executor.5 Not tainted 5.9.0-rc4-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x198/0x1fd lib/dump_stack.c:118
fib6_del+0x12b4/0x1630 net/ipv6/ip6_fib.c:1996
fib6_clean_node+0x39b/0x570 net/ipv6/ip6_fib.c:2180
fib6_walk_continue+0x4aa/0x8e0 net/ipv6/ip6_fib.c:2102
fib6_walk+0x182/0x370 net/ipv6/ip6_fib.c:2150
fib6_clean_tree+0xdb/0x120 net/ipv6/ip6_fib.c:2230
__fib6_clean_all+0x120/0x290 net/ipv6/ip6_fib.c:2246
fib6_clean_all net/ipv6/ip6_fib.c:2257 [inline]
fib6_run_gc+0x113/0x2d0 net/ipv6/ip6_fib.c:2320
ndisc_netdev_event+0x217/0x350 net/ipv6/ndisc.c:1805
notifier_call_chain+0xb5/0x200 kernel/notifier.c:83
call_netdevice_notifiers_info+0xb5/0x130 net/core/dev.c:2033
call_netdevice_notifiers_extack net/core/dev.c:2045 [inline]
call_netdevice_notifiers net/core/dev.c:2059 [inline]
dev_close_many+0x30b/0x650 net/core/dev.c:1634
rollback_registered_many+0x3a8/0x1210 net/core/dev.c:9261
rollback_registered net/core/dev.c:9329 [inline]
unregister_netdevice_queue+0x2dd/0x570 net/core/dev.c:10410
unregister_netdevice include/linux/netdevice.h:2774 [inline]
ppp_release+0x216/0x240 drivers/net/ppp/ppp_generic.c:403
__fput+0x285/0x920 fs/file_table.c:281
task_work_run+0xdd/0x190 kernel/task_work.c:141
tracehook_notify_resume include/linux/tracehook.h:188 [inline]
exit_to_user_mode_loop kernel/entry/common.c:163 [inline]
exit_to_user_mode_prepare+0x1e1/0x200 kernel/entry/common.c:190
syscall_exit_to_user_mode+0x7e/0x2e0 kernel/entry/common.c:265
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Fixes: 421842e ("net/ipv6: Add fib6_null_entry")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: David Ahern <dsahern@gmail.com>
Reviewed-by: David Ahern <dsahern@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Sep 16, 2020
Ido Schimmel says: ==================== net: Fix bridge enslavement failure Patch #1 fixes an issue in which an upper netdev cannot be enslaved to a bridge when it has multiple netdevs with different parent identifiers beneath it. Patch #2 adds a test case using two netdevsim instances. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
kuba-moo
pushed a commit
to linux-netdev/testing-bpf-ci
that referenced
this pull request
Nov 8, 2025
Assume a scenario with something like the following routes: default via fe80::1 dev dummy0 2001:db8:1::/48 via fe80::10 dev dummy0 2001:db8:1::/48 from 2001:db8:1:2::/64 via fe80::12 dev dummy0 Now if a lookup happens for 2001:db8:1::2345, but with a source address *not* covered by the third route, the expectation is to hit the second one. Unfortunately, this was broken since the code, on failing the lookup in the subtree, didn't consider the node itself which the subtree is attached to, i.e. route kernel-patches#2 above. The fix is simple, check if the subtree is attached to a node that is itself a valid route before backtracking to less specific destination prefixes. This case is somewhat rare for several reasons. To begin with, subtree routes are most commonly attached to the default destination. Additionally, in the rare cases where a non-default destination prefix is host to subtree routes, the fallback on not hitting any subtree route is commonly a default route (or a subtree route on that). (Note that this was working for the "::/0 from ::/0" case since the root node is special-cased. The issue was discovered during RFC 6724 rule 5.5 testing, trying to find edge cases.) Signed-off-by: David Lamparter <equinox@diac24.net> Cc: Lorenzo Colitti <lorenzo@google.com> Cc: Patrick Rohr <prohr@google.com> Cc: Maciej Żenczykowski <maze@google.com> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing-bpf-ci
that referenced
this pull request
Nov 8, 2025
Assume a scenario with something like the following routes: default via fe80::1 dev dummy0 2001:db8:1::/48 via fe80::10 dev dummy0 2001:db8:1::/48 from 2001:db8:1:2::/64 via fe80::12 dev dummy0 Now if a lookup happens for 2001:db8:1::2345, but with a source address *not* covered by the third route, the expectation is to hit the second one. Unfortunately, this was broken since the code, on failing the lookup in the subtree, didn't consider the node itself which the subtree is attached to, i.e. route kernel-patches#2 above. The fix is simple, check if the subtree is attached to a node that is itself a valid route before backtracking to less specific destination prefixes. This case is somewhat rare for several reasons. To begin with, subtree routes are most commonly attached to the default destination. Additionally, in the rare cases where a non-default destination prefix is host to subtree routes, the fallback on not hitting any subtree route is commonly a default route (or a subtree route on that). (Note that this was working for the "::/0 from ::/0" case since the root node is special-cased. The issue was discovered during RFC 6724 rule 5.5 testing, trying to find edge cases.) Signed-off-by: David Lamparter <equinox@diac24.net> Cc: Lorenzo Colitti <lorenzo@google.com> Cc: Patrick Rohr <prohr@google.com> Cc: Maciej Żenczykowski <maze@google.com> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing-bpf-ci
that referenced
this pull request
Nov 8, 2025
Assume a scenario with something like the following routes: default via fe80::1 dev dummy0 2001:db8:1::/48 via fe80::10 dev dummy0 2001:db8:1::/48 from 2001:db8:1:2::/64 via fe80::12 dev dummy0 Now if a lookup happens for 2001:db8:1::2345, but with a source address *not* covered by the third route, the expectation is to hit the second one. Unfortunately, this was broken since the code, on failing the lookup in the subtree, didn't consider the node itself which the subtree is attached to, i.e. route kernel-patches#2 above. The fix is simple, check if the subtree is attached to a node that is itself a valid route before backtracking to less specific destination prefixes. This case is somewhat rare for several reasons. To begin with, subtree routes are most commonly attached to the default destination. Additionally, in the rare cases where a non-default destination prefix is host to subtree routes, the fallback on not hitting any subtree route is commonly a default route (or a subtree route on that). (Note that this was working for the "::/0 from ::/0" case since the root node is special-cased. The issue was discovered during RFC 6724 rule 5.5 testing, trying to find edge cases.) Signed-off-by: David Lamparter <equinox@diac24.net> Cc: Lorenzo Colitti <lorenzo@google.com> Cc: Patrick Rohr <prohr@google.com> Cc: Maciej Żenczykowski <maze@google.com> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing-bpf-ci
that referenced
this pull request
Nov 8, 2025
Assume a scenario with something like the following routes: default via fe80::1 dev dummy0 2001:db8:1::/48 via fe80::10 dev dummy0 2001:db8:1::/48 from 2001:db8:1:2::/64 via fe80::12 dev dummy0 Now if a lookup happens for 2001:db8:1::2345, but with a source address *not* covered by the third route, the expectation is to hit the second one. Unfortunately, this was broken since the code, on failing the lookup in the subtree, didn't consider the node itself which the subtree is attached to, i.e. route kernel-patches#2 above. The fix is simple, check if the subtree is attached to a node that is itself a valid route before backtracking to less specific destination prefixes. This case is somewhat rare for several reasons. To begin with, subtree routes are most commonly attached to the default destination. Additionally, in the rare cases where a non-default destination prefix is host to subtree routes, the fallback on not hitting any subtree route is commonly a default route (or a subtree route on that). (Note that this was working for the "::/0 from ::/0" case since the root node is special-cased. The issue was discovered during RFC 6724 rule 5.5 testing, trying to find edge cases.) Signed-off-by: David Lamparter <equinox@diac24.net> Cc: Lorenzo Colitti <lorenzo@google.com> Cc: Patrick Rohr <prohr@google.com> Cc: Maciej Żenczykowski <maze@google.com> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing-bpf-ci
that referenced
this pull request
Nov 9, 2025
Assume a scenario with something like the following routes: default via fe80::1 dev dummy0 2001:db8:1::/48 via fe80::10 dev dummy0 2001:db8:1::/48 from 2001:db8:1:2::/64 via fe80::12 dev dummy0 Now if a lookup happens for 2001:db8:1::2345, but with a source address *not* covered by the third route, the expectation is to hit the second one. Unfortunately, this was broken since the code, on failing the lookup in the subtree, didn't consider the node itself which the subtree is attached to, i.e. route kernel-patches#2 above. The fix is simple, check if the subtree is attached to a node that is itself a valid route before backtracking to less specific destination prefixes. This case is somewhat rare for several reasons. To begin with, subtree routes are most commonly attached to the default destination. Additionally, in the rare cases where a non-default destination prefix is host to subtree routes, the fallback on not hitting any subtree route is commonly a default route (or a subtree route on that). (Note that this was working for the "::/0 from ::/0" case since the root node is special-cased. The issue was discovered during RFC 6724 rule 5.5 testing, trying to find edge cases.) Signed-off-by: David Lamparter <equinox@diac24.net> Cc: Lorenzo Colitti <lorenzo@google.com> Cc: Patrick Rohr <prohr@google.com> Cc: Maciej Żenczykowski <maze@google.com> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing-bpf-ci
that referenced
this pull request
Nov 9, 2025
Assume a scenario with something like the following routes: default via fe80::1 dev dummy0 2001:db8:1::/48 via fe80::10 dev dummy0 2001:db8:1::/48 from 2001:db8:1:2::/64 via fe80::12 dev dummy0 Now if a lookup happens for 2001:db8:1::2345, but with a source address *not* covered by the third route, the expectation is to hit the second one. Unfortunately, this was broken since the code, on failing the lookup in the subtree, didn't consider the node itself which the subtree is attached to, i.e. route kernel-patches#2 above. The fix is simple, check if the subtree is attached to a node that is itself a valid route before backtracking to less specific destination prefixes. This case is somewhat rare for several reasons. To begin with, subtree routes are most commonly attached to the default destination. Additionally, in the rare cases where a non-default destination prefix is host to subtree routes, the fallback on not hitting any subtree route is commonly a default route (or a subtree route on that). (Note that this was working for the "::/0 from ::/0" case since the root node is special-cased. The issue was discovered during RFC 6724 rule 5.5 testing, trying to find edge cases.) Signed-off-by: David Lamparter <equinox@diac24.net> Cc: Lorenzo Colitti <lorenzo@google.com> Cc: Patrick Rohr <prohr@google.com> Cc: Maciej Żenczykowski <maze@google.com> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing-bpf-ci
that referenced
this pull request
Nov 9, 2025
Assume a scenario with something like the following routes: default via fe80::1 dev dummy0 2001:db8:1::/48 via fe80::10 dev dummy0 2001:db8:1::/48 from 2001:db8:1:2::/64 via fe80::12 dev dummy0 Now if a lookup happens for 2001:db8:1::2345, but with a source address *not* covered by the third route, the expectation is to hit the second one. Unfortunately, this was broken since the code, on failing the lookup in the subtree, didn't consider the node itself which the subtree is attached to, i.e. route kernel-patches#2 above. The fix is simple, check if the subtree is attached to a node that is itself a valid route before backtracking to less specific destination prefixes. This case is somewhat rare for several reasons. To begin with, subtree routes are most commonly attached to the default destination. Additionally, in the rare cases where a non-default destination prefix is host to subtree routes, the fallback on not hitting any subtree route is commonly a default route (or a subtree route on that). (Note that this was working for the "::/0 from ::/0" case since the root node is special-cased. The issue was discovered during RFC 6724 rule 5.5 testing, trying to find edge cases.) Signed-off-by: David Lamparter <equinox@diac24.net> Cc: Lorenzo Colitti <lorenzo@google.com> Cc: Patrick Rohr <prohr@google.com> Cc: Maciej Żenczykowski <maze@google.com> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing-bpf-ci
that referenced
this pull request
Nov 9, 2025
Assume a scenario with something like the following routes: default via fe80::1 dev dummy0 2001:db8:1::/48 via fe80::10 dev dummy0 2001:db8:1::/48 from 2001:db8:1:2::/64 via fe80::12 dev dummy0 Now if a lookup happens for 2001:db8:1::2345, but with a source address *not* covered by the third route, the expectation is to hit the second one. Unfortunately, this was broken since the code, on failing the lookup in the subtree, didn't consider the node itself which the subtree is attached to, i.e. route kernel-patches#2 above. The fix is simple, check if the subtree is attached to a node that is itself a valid route before backtracking to less specific destination prefixes. This case is somewhat rare for several reasons. To begin with, subtree routes are most commonly attached to the default destination. Additionally, in the rare cases where a non-default destination prefix is host to subtree routes, the fallback on not hitting any subtree route is commonly a default route (or a subtree route on that). (Note that this was working for the "::/0 from ::/0" case since the root node is special-cased. The issue was discovered during RFC 6724 rule 5.5 testing, trying to find edge cases.) Signed-off-by: David Lamparter <equinox@diac24.net> Cc: Lorenzo Colitti <lorenzo@google.com> Cc: Patrick Rohr <prohr@google.com> Cc: Maciej Żenczykowski <maze@google.com> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing-bpf-ci
that referenced
this pull request
Nov 9, 2025
Assume a scenario with something like the following routes: default via fe80::1 dev dummy0 2001:db8:1::/48 via fe80::10 dev dummy0 2001:db8:1::/48 from 2001:db8:1:2::/64 via fe80::12 dev dummy0 Now if a lookup happens for 2001:db8:1::2345, but with a source address *not* covered by the third route, the expectation is to hit the second one. Unfortunately, this was broken since the code, on failing the lookup in the subtree, didn't consider the node itself which the subtree is attached to, i.e. route kernel-patches#2 above. The fix is simple, check if the subtree is attached to a node that is itself a valid route before backtracking to less specific destination prefixes. This case is somewhat rare for several reasons. To begin with, subtree routes are most commonly attached to the default destination. Additionally, in the rare cases where a non-default destination prefix is host to subtree routes, the fallback on not hitting any subtree route is commonly a default route (or a subtree route on that). (Note that this was working for the "::/0 from ::/0" case since the root node is special-cased. The issue was discovered during RFC 6724 rule 5.5 testing, trying to find edge cases.) Signed-off-by: David Lamparter <equinox@diac24.net> Cc: Lorenzo Colitti <lorenzo@google.com> Cc: Patrick Rohr <prohr@google.com> Cc: Maciej Żenczykowski <maze@google.com> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing-bpf-ci
that referenced
this pull request
Nov 9, 2025
Assume a scenario with something like the following routes: default via fe80::1 dev dummy0 2001:db8:1::/48 via fe80::10 dev dummy0 2001:db8:1::/48 from 2001:db8:1:2::/64 via fe80::12 dev dummy0 Now if a lookup happens for 2001:db8:1::2345, but with a source address *not* covered by the third route, the expectation is to hit the second one. Unfortunately, this was broken since the code, on failing the lookup in the subtree, didn't consider the node itself which the subtree is attached to, i.e. route kernel-patches#2 above. The fix is simple, check if the subtree is attached to a node that is itself a valid route before backtracking to less specific destination prefixes. This case is somewhat rare for several reasons. To begin with, subtree routes are most commonly attached to the default destination. Additionally, in the rare cases where a non-default destination prefix is host to subtree routes, the fallback on not hitting any subtree route is commonly a default route (or a subtree route on that). (Note that this was working for the "::/0 from ::/0" case since the root node is special-cased. The issue was discovered during RFC 6724 rule 5.5 testing, trying to find edge cases.) Signed-off-by: David Lamparter <equinox@diac24.net> Cc: Lorenzo Colitti <lorenzo@google.com> Cc: Patrick Rohr <prohr@google.com> Cc: Maciej Żenczykowski <maze@google.com> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing-bpf-ci
that referenced
this pull request
Nov 9, 2025
Assume a scenario with something like the following routes: default via fe80::1 dev dummy0 2001:db8:1::/48 via fe80::10 dev dummy0 2001:db8:1::/48 from 2001:db8:1:2::/64 via fe80::12 dev dummy0 Now if a lookup happens for 2001:db8:1::2345, but with a source address *not* covered by the third route, the expectation is to hit the second one. Unfortunately, this was broken since the code, on failing the lookup in the subtree, didn't consider the node itself which the subtree is attached to, i.e. route kernel-patches#2 above. The fix is simple, check if the subtree is attached to a node that is itself a valid route before backtracking to less specific destination prefixes. This case is somewhat rare for several reasons. To begin with, subtree routes are most commonly attached to the default destination. Additionally, in the rare cases where a non-default destination prefix is host to subtree routes, the fallback on not hitting any subtree route is commonly a default route (or a subtree route on that). (Note that this was working for the "::/0 from ::/0" case since the root node is special-cased. The issue was discovered during RFC 6724 rule 5.5 testing, trying to find edge cases.) Signed-off-by: David Lamparter <equinox@diac24.net> Cc: Lorenzo Colitti <lorenzo@google.com> Cc: Patrick Rohr <prohr@google.com> Cc: Maciej Żenczykowski <maze@google.com> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing-bpf-ci
that referenced
this pull request
Nov 9, 2025
Assume a scenario with something like the following routes: default via fe80::1 dev dummy0 2001:db8:1::/48 via fe80::10 dev dummy0 2001:db8:1::/48 from 2001:db8:1:2::/64 via fe80::12 dev dummy0 Now if a lookup happens for 2001:db8:1::2345, but with a source address *not* covered by the third route, the expectation is to hit the second one. Unfortunately, this was broken since the code, on failing the lookup in the subtree, didn't consider the node itself which the subtree is attached to, i.e. route kernel-patches#2 above. The fix is simple, check if the subtree is attached to a node that is itself a valid route before backtracking to less specific destination prefixes. This case is somewhat rare for several reasons. To begin with, subtree routes are most commonly attached to the default destination. Additionally, in the rare cases where a non-default destination prefix is host to subtree routes, the fallback on not hitting any subtree route is commonly a default route (or a subtree route on that). (Note that this was working for the "::/0 from ::/0" case since the root node is special-cased. The issue was discovered during RFC 6724 rule 5.5 testing, trying to find edge cases.) Signed-off-by: David Lamparter <equinox@diac24.net> Cc: Lorenzo Colitti <lorenzo@google.com> Cc: Patrick Rohr <prohr@google.com> Cc: Maciej Żenczykowski <maze@google.com> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing-bpf-ci
that referenced
this pull request
Nov 10, 2025
Assume a scenario with something like the following routes: default via fe80::1 dev dummy0 2001:db8:1::/48 via fe80::10 dev dummy0 2001:db8:1::/48 from 2001:db8:1:2::/64 via fe80::12 dev dummy0 Now if a lookup happens for 2001:db8:1::2345, but with a source address *not* covered by the third route, the expectation is to hit the second one. Unfortunately, this was broken since the code, on failing the lookup in the subtree, didn't consider the node itself which the subtree is attached to, i.e. route kernel-patches#2 above. The fix is simple, check if the subtree is attached to a node that is itself a valid route before backtracking to less specific destination prefixes. This case is somewhat rare for several reasons. To begin with, subtree routes are most commonly attached to the default destination. Additionally, in the rare cases where a non-default destination prefix is host to subtree routes, the fallback on not hitting any subtree route is commonly a default route (or a subtree route on that). (Note that this was working for the "::/0 from ::/0" case since the root node is special-cased. The issue was discovered during RFC 6724 rule 5.5 testing, trying to find edge cases.) Signed-off-by: David Lamparter <equinox@diac24.net> Cc: Lorenzo Colitti <lorenzo@google.com> Cc: Patrick Rohr <prohr@google.com> Cc: Maciej Żenczykowski <maze@google.com> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing-bpf-ci
that referenced
this pull request
Nov 10, 2025
Assume a scenario with something like the following routes: default via fe80::1 dev dummy0 2001:db8:1::/48 via fe80::10 dev dummy0 2001:db8:1::/48 from 2001:db8:1:2::/64 via fe80::12 dev dummy0 Now if a lookup happens for 2001:db8:1::2345, but with a source address *not* covered by the third route, the expectation is to hit the second one. Unfortunately, this was broken since the code, on failing the lookup in the subtree, didn't consider the node itself which the subtree is attached to, i.e. route kernel-patches#2 above. The fix is simple, check if the subtree is attached to a node that is itself a valid route before backtracking to less specific destination prefixes. This case is somewhat rare for several reasons. To begin with, subtree routes are most commonly attached to the default destination. Additionally, in the rare cases where a non-default destination prefix is host to subtree routes, the fallback on not hitting any subtree route is commonly a default route (or a subtree route on that). (Note that this was working for the "::/0 from ::/0" case since the root node is special-cased. The issue was discovered during RFC 6724 rule 5.5 testing, trying to find edge cases.) Signed-off-by: David Lamparter <equinox@diac24.net> Cc: Lorenzo Colitti <lorenzo@google.com> Cc: Patrick Rohr <prohr@google.com> Cc: Maciej Żenczykowski <maze@google.com> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing-bpf-ci
that referenced
this pull request
Nov 10, 2025
Assume a scenario with something like the following routes: default via fe80::1 dev dummy0 2001:db8:1::/48 via fe80::10 dev dummy0 2001:db8:1::/48 from 2001:db8:1:2::/64 via fe80::12 dev dummy0 Now if a lookup happens for 2001:db8:1::2345, but with a source address *not* covered by the third route, the expectation is to hit the second one. Unfortunately, this was broken since the code, on failing the lookup in the subtree, didn't consider the node itself which the subtree is attached to, i.e. route kernel-patches#2 above. The fix is simple, check if the subtree is attached to a node that is itself a valid route before backtracking to less specific destination prefixes. This case is somewhat rare for several reasons. To begin with, subtree routes are most commonly attached to the default destination. Additionally, in the rare cases where a non-default destination prefix is host to subtree routes, the fallback on not hitting any subtree route is commonly a default route (or a subtree route on that). (Note that this was working for the "::/0 from ::/0" case since the root node is special-cased. The issue was discovered during RFC 6724 rule 5.5 testing, trying to find edge cases.) Signed-off-by: David Lamparter <equinox@diac24.net> Cc: Lorenzo Colitti <lorenzo@google.com> Cc: Patrick Rohr <prohr@google.com> Cc: Maciej Żenczykowski <maze@google.com> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing-bpf-ci
that referenced
this pull request
Nov 10, 2025
Assume a scenario with something like the following routes: default via fe80::1 dev dummy0 2001:db8:1::/48 via fe80::10 dev dummy0 2001:db8:1::/48 from 2001:db8:1:2::/64 via fe80::12 dev dummy0 Now if a lookup happens for 2001:db8:1::2345, but with a source address *not* covered by the third route, the expectation is to hit the second one. Unfortunately, this was broken since the code, on failing the lookup in the subtree, didn't consider the node itself which the subtree is attached to, i.e. route kernel-patches#2 above. The fix is simple, check if the subtree is attached to a node that is itself a valid route before backtracking to less specific destination prefixes. This case is somewhat rare for several reasons. To begin with, subtree routes are most commonly attached to the default destination. Additionally, in the rare cases where a non-default destination prefix is host to subtree routes, the fallback on not hitting any subtree route is commonly a default route (or a subtree route on that). (Note that this was working for the "::/0 from ::/0" case since the root node is special-cased. The issue was discovered during RFC 6724 rule 5.5 testing, trying to find edge cases.) Signed-off-by: David Lamparter <equinox@diac24.net> Cc: Lorenzo Colitti <lorenzo@google.com> Cc: Patrick Rohr <prohr@google.com> Cc: Maciej Żenczykowski <maze@google.com> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing-bpf-ci
that referenced
this pull request
Nov 10, 2025
Assume a scenario with something like the following routes: default via fe80::1 dev dummy0 2001:db8:1::/48 via fe80::10 dev dummy0 2001:db8:1::/48 from 2001:db8:1:2::/64 via fe80::12 dev dummy0 Now if a lookup happens for 2001:db8:1::2345, but with a source address *not* covered by the third route, the expectation is to hit the second one. Unfortunately, this was broken since the code, on failing the lookup in the subtree, didn't consider the node itself which the subtree is attached to, i.e. route kernel-patches#2 above. The fix is simple, check if the subtree is attached to a node that is itself a valid route before backtracking to less specific destination prefixes. This case is somewhat rare for several reasons. To begin with, subtree routes are most commonly attached to the default destination. Additionally, in the rare cases where a non-default destination prefix is host to subtree routes, the fallback on not hitting any subtree route is commonly a default route (or a subtree route on that). (Note that this was working for the "::/0 from ::/0" case since the root node is special-cased. The issue was discovered during RFC 6724 rule 5.5 testing, trying to find edge cases.) Signed-off-by: David Lamparter <equinox@diac24.net> Cc: Lorenzo Colitti <lorenzo@google.com> Cc: Patrick Rohr <prohr@google.com> Cc: Maciej Żenczykowski <maze@google.com> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing-bpf-ci
that referenced
this pull request
Nov 10, 2025
Assume a scenario with something like the following routes: default via fe80::1 dev dummy0 2001:db8:1::/48 via fe80::10 dev dummy0 2001:db8:1::/48 from 2001:db8:1:2::/64 via fe80::12 dev dummy0 Now if a lookup happens for 2001:db8:1::2345, but with a source address *not* covered by the third route, the expectation is to hit the second one. Unfortunately, this was broken since the code, on failing the lookup in the subtree, didn't consider the node itself which the subtree is attached to, i.e. route kernel-patches#2 above. The fix is simple, check if the subtree is attached to a node that is itself a valid route before backtracking to less specific destination prefixes. This case is somewhat rare for several reasons. To begin with, subtree routes are most commonly attached to the default destination. Additionally, in the rare cases where a non-default destination prefix is host to subtree routes, the fallback on not hitting any subtree route is commonly a default route (or a subtree route on that). (Note that this was working for the "::/0 from ::/0" case since the root node is special-cased. The issue was discovered during RFC 6724 rule 5.5 testing, trying to find edge cases.) Signed-off-by: David Lamparter <equinox@diac24.net> Cc: Lorenzo Colitti <lorenzo@google.com> Cc: Patrick Rohr <prohr@google.com> Cc: Maciej Żenczykowski <maze@google.com> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing-bpf-ci
that referenced
this pull request
Nov 10, 2025
Handle skb allocation failures in RX path, to avoid NULL pointer dereference and RX stalls under memory pressure. If the refill fails with -ENOMEM, complete napi polling and wake up later to retry via timer. Also explicitly re-enable RX DMA after oom, so the dmac doesn't remain stopped in this situation. Previously, memory pressure could lead to skb allocation failures and subsequent Oops like: Oops: Kernel access of bad area, sig: 11 [kernel-patches#2] Hardware name: SonyPS3 Cell Broadband Engine 0x701000 PS3 NIP [c0003d0000065900] gelic_net_poll+0x6c/0x2d0 [ps3_gelic] (unreliable) LR [c0003d00000659c4] gelic_net_poll+0x130/0x2d0 [ps3_gelic] Call Trace: gelic_net_poll+0x130/0x2d0 [ps3_gelic] (unreliable) __napi_poll+0x44/0x168 net_rx_action+0x178/0x290 Steps to reproduce the issue: 1. Start a continuous network traffic, like scp of a 20GB file 2. Inject failslab errors using the kernel fault injection: echo -1 > /sys/kernel/debug/failslab/times echo 30 > /sys/kernel/debug/failslab/interval echo 100 > /sys/kernel/debug/failslab/probability 3. After some time, traces start to appear, kernel Oopses and the system stops Step 2 is not always necessary, as it is usually already triggered by the transfer of a big enough file. Fixes: 02c1889 ("ps3: gigabit ethernet driver for PS3, take3") Signed-off-by: Florian Fuchs <fuchsfl@gmail.com> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing-bpf-ci
that referenced
this pull request
Nov 10, 2025
Assume a scenario with something like the following routes: default via fe80::1 dev dummy0 2001:db8:1::/48 via fe80::10 dev dummy0 2001:db8:1::/48 from 2001:db8:1:2::/64 via fe80::12 dev dummy0 Now if a lookup happens for 2001:db8:1::2345, but with a source address *not* covered by the third route, the expectation is to hit the second one. Unfortunately, this was broken since the code, on failing the lookup in the subtree, didn't consider the node itself which the subtree is attached to, i.e. route kernel-patches#2 above. The fix is simple, check if the subtree is attached to a node that is itself a valid route before backtracking to less specific destination prefixes. This case is somewhat rare for several reasons. To begin with, subtree routes are most commonly attached to the default destination. Additionally, in the rare cases where a non-default destination prefix is host to subtree routes, the fallback on not hitting any subtree route is commonly a default route (or a subtree route on that). (Note that this was working for the "::/0 from ::/0" case since the root node is special-cased. The issue was discovered during RFC 6724 rule 5.5 testing, trying to find edge cases.) Signed-off-by: David Lamparter <equinox@diac24.net> Cc: Lorenzo Colitti <lorenzo@google.com> Cc: Patrick Rohr <prohr@google.com> Cc: Maciej Żenczykowski <maze@google.com> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing-bpf-ci
that referenced
this pull request
Nov 10, 2025
Handle skb allocation failures in RX path, to avoid NULL pointer dereference and RX stalls under memory pressure. If the refill fails with -ENOMEM, complete napi polling and wake up later to retry via timer. Also explicitly re-enable RX DMA after oom, so the dmac doesn't remain stopped in this situation. Previously, memory pressure could lead to skb allocation failures and subsequent Oops like: Oops: Kernel access of bad area, sig: 11 [kernel-patches#2] Hardware name: SonyPS3 Cell Broadband Engine 0x701000 PS3 NIP [c0003d0000065900] gelic_net_poll+0x6c/0x2d0 [ps3_gelic] (unreliable) LR [c0003d00000659c4] gelic_net_poll+0x130/0x2d0 [ps3_gelic] Call Trace: gelic_net_poll+0x130/0x2d0 [ps3_gelic] (unreliable) __napi_poll+0x44/0x168 net_rx_action+0x178/0x290 Steps to reproduce the issue: 1. Start a continuous network traffic, like scp of a 20GB file 2. Inject failslab errors using the kernel fault injection: echo -1 > /sys/kernel/debug/failslab/times echo 30 > /sys/kernel/debug/failslab/interval echo 100 > /sys/kernel/debug/failslab/probability 3. After some time, traces start to appear, kernel Oopses and the system stops Step 2 is not always necessary, as it is usually already triggered by the transfer of a big enough file. Fixes: 02c1889 ("ps3: gigabit ethernet driver for PS3, take3") Signed-off-by: Florian Fuchs <fuchsfl@gmail.com> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing-bpf-ci
that referenced
this pull request
Nov 10, 2025
Assume a scenario with something like the following routes: default via fe80::1 dev dummy0 2001:db8:1::/48 via fe80::10 dev dummy0 2001:db8:1::/48 from 2001:db8:1:2::/64 via fe80::12 dev dummy0 Now if a lookup happens for 2001:db8:1::2345, but with a source address *not* covered by the third route, the expectation is to hit the second one. Unfortunately, this was broken since the code, on failing the lookup in the subtree, didn't consider the node itself which the subtree is attached to, i.e. route kernel-patches#2 above. The fix is simple, check if the subtree is attached to a node that is itself a valid route before backtracking to less specific destination prefixes. This case is somewhat rare for several reasons. To begin with, subtree routes are most commonly attached to the default destination. Additionally, in the rare cases where a non-default destination prefix is host to subtree routes, the fallback on not hitting any subtree route is commonly a default route (or a subtree route on that). (Note that this was working for the "::/0 from ::/0" case since the root node is special-cased. The issue was discovered during RFC 6724 rule 5.5 testing, trying to find edge cases.) Signed-off-by: David Lamparter <equinox@diac24.net> Cc: Lorenzo Colitti <lorenzo@google.com> Cc: Patrick Rohr <prohr@google.com> Cc: Maciej Żenczykowski <maze@google.com> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing-bpf-ci
that referenced
this pull request
Nov 10, 2025
Handle skb allocation failures in RX path, to avoid NULL pointer dereference and RX stalls under memory pressure. If the refill fails with -ENOMEM, complete napi polling and wake up later to retry via timer. Also explicitly re-enable RX DMA after oom, so the dmac doesn't remain stopped in this situation. Previously, memory pressure could lead to skb allocation failures and subsequent Oops like: Oops: Kernel access of bad area, sig: 11 [kernel-patches#2] Hardware name: SonyPS3 Cell Broadband Engine 0x701000 PS3 NIP [c0003d0000065900] gelic_net_poll+0x6c/0x2d0 [ps3_gelic] (unreliable) LR [c0003d00000659c4] gelic_net_poll+0x130/0x2d0 [ps3_gelic] Call Trace: gelic_net_poll+0x130/0x2d0 [ps3_gelic] (unreliable) __napi_poll+0x44/0x168 net_rx_action+0x178/0x290 Steps to reproduce the issue: 1. Start a continuous network traffic, like scp of a 20GB file 2. Inject failslab errors using the kernel fault injection: echo -1 > /sys/kernel/debug/failslab/times echo 30 > /sys/kernel/debug/failslab/interval echo 100 > /sys/kernel/debug/failslab/probability 3. After some time, traces start to appear, kernel Oopses and the system stops Step 2 is not always necessary, as it is usually already triggered by the transfer of a big enough file. Fixes: 02c1889 ("ps3: gigabit ethernet driver for PS3, take3") Signed-off-by: Florian Fuchs <fuchsfl@gmail.com> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing-bpf-ci
that referenced
this pull request
Nov 11, 2025
Assume a scenario with something like the following routes: default via fe80::1 dev dummy0 2001:db8:1::/48 via fe80::10 dev dummy0 2001:db8:1::/48 from 2001:db8:1:2::/64 via fe80::12 dev dummy0 Now if a lookup happens for 2001:db8:1::2345, but with a source address *not* covered by the third route, the expectation is to hit the second one. Unfortunately, this was broken since the code, on failing the lookup in the subtree, didn't consider the node itself which the subtree is attached to, i.e. route kernel-patches#2 above. The fix is simple, check if the subtree is attached to a node that is itself a valid route before backtracking to less specific destination prefixes. This case is somewhat rare for several reasons. To begin with, subtree routes are most commonly attached to the default destination. Additionally, in the rare cases where a non-default destination prefix is host to subtree routes, the fallback on not hitting any subtree route is commonly a default route (or a subtree route on that). (Note that this was working for the "::/0 from ::/0" case since the root node is special-cased. The issue was discovered during RFC 6724 rule 5.5 testing, trying to find edge cases.) Signed-off-by: David Lamparter <equinox@diac24.net> Cc: Lorenzo Colitti <lorenzo@google.com> Cc: Patrick Rohr <prohr@google.com> Cc: Maciej Żenczykowski <maze@google.com> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing-bpf-ci
that referenced
this pull request
Nov 11, 2025
Handle skb allocation failures in RX path, to avoid NULL pointer dereference and RX stalls under memory pressure. If the refill fails with -ENOMEM, complete napi polling and wake up later to retry via timer. Also explicitly re-enable RX DMA after oom, so the dmac doesn't remain stopped in this situation. Previously, memory pressure could lead to skb allocation failures and subsequent Oops like: Oops: Kernel access of bad area, sig: 11 [kernel-patches#2] Hardware name: SonyPS3 Cell Broadband Engine 0x701000 PS3 NIP [c0003d0000065900] gelic_net_poll+0x6c/0x2d0 [ps3_gelic] (unreliable) LR [c0003d00000659c4] gelic_net_poll+0x130/0x2d0 [ps3_gelic] Call Trace: gelic_net_poll+0x130/0x2d0 [ps3_gelic] (unreliable) __napi_poll+0x44/0x168 net_rx_action+0x178/0x290 Steps to reproduce the issue: 1. Start a continuous network traffic, like scp of a 20GB file 2. Inject failslab errors using the kernel fault injection: echo -1 > /sys/kernel/debug/failslab/times echo 30 > /sys/kernel/debug/failslab/interval echo 100 > /sys/kernel/debug/failslab/probability 3. After some time, traces start to appear, kernel Oopses and the system stops Step 2 is not always necessary, as it is usually already triggered by the transfer of a big enough file. Fixes: 02c1889 ("ps3: gigabit ethernet driver for PS3, take3") Signed-off-by: Florian Fuchs <fuchsfl@gmail.com> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing-bpf-ci
that referenced
this pull request
Nov 11, 2025
When freeing indexed arrays, the corresponding free function should
be called for each entry of the indexed array. For example, for
for 'struct tc_act_attrs' 'tc_act_attrs_free(...)' needs to be called
for each entry.
Previously, memory leaks were reported when enabling the ASAN
analyzer.
=================================================================
==874==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x7f221fd20cb5 in malloc ./debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:67
kernel-patches#1 0x55c98db048af in tc_act_attrs_set_options_vlan_parms ../generated/tc-user.h:2813
kernel-patches#2 0x55c98db048af in main ./linux/tools/net/ynl/samples/tc-filter-add.c:71
Direct leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x7f221fd20cb5 in malloc ./debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:67
kernel-patches#1 0x55c98db04a93 in tc_act_attrs_set_options_vlan_parms ../generated/tc-user.h:2813
kernel-patches#2 0x55c98db04a93 in main ./linux/tools/net/ynl/samples/tc-filter-add.c:74
Direct leak of 10 byte(s) in 2 object(s) allocated from:
#0 0x7f221fd20cb5 in malloc ./debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:67
kernel-patches#1 0x55c98db0527d in tc_act_attrs_set_kind ../generated/tc-user.h:1622
SUMMARY: AddressSanitizer: 58 byte(s) leaked in 4 allocation(s).
The following diff illustrates the changes introduced compared to the
previous version of the code.
void tc_flower_attrs_free(struct tc_flower_attrs *obj)
{
+ unsigned int i;
+
free(obj->indev);
+ for (i = 0; i < obj->_count.act; i++)
+ tc_act_attrs_free(&obj->act[i]);
free(obj->act);
free(obj->key_eth_dst);
free(obj->key_eth_dst_mask);
Signed-off-by: Zahari Doychev <zahari.doychev@linux.com>
Reviewed-by: Jakub Kicinski <kuba@kernel.org>
Link: https://patch.msgid.link/20251106151529.453026-3-zahari.doychev@linux.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
kuba-moo
pushed a commit
to linux-netdev/testing-bpf-ci
that referenced
this pull request
Nov 11, 2025
Assume a scenario with something like the following routes: default via fe80::1 dev dummy0 2001:db8:1::/48 via fe80::10 dev dummy0 2001:db8:1::/48 from 2001:db8:1:2::/64 via fe80::12 dev dummy0 Now if a lookup happens for 2001:db8:1::2345, but with a source address *not* covered by the third route, the expectation is to hit the second one. Unfortunately, this was broken since the code, on failing the lookup in the subtree, didn't consider the node itself which the subtree is attached to, i.e. route kernel-patches#2 above. The fix is simple, check if the subtree is attached to a node that is itself a valid route before backtracking to less specific destination prefixes. This case is somewhat rare for several reasons. To begin with, subtree routes are most commonly attached to the default destination. Additionally, in the rare cases where a non-default destination prefix is host to subtree routes, the fallback on not hitting any subtree route is commonly a default route (or a subtree route on that). (Note that this was working for the "::/0 from ::/0" case since the root node is special-cased. The issue was discovered during RFC 6724 rule 5.5 testing, trying to find edge cases.) Signed-off-by: David Lamparter <equinox@diac24.net> Cc: Lorenzo Colitti <lorenzo@google.com> Cc: Patrick Rohr <prohr@google.com> Cc: Maciej Żenczykowski <maze@google.com> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing-bpf-ci
that referenced
this pull request
Nov 11, 2025
Handle skb allocation failures in RX path, to avoid NULL pointer dereference and RX stalls under memory pressure. If the refill fails with -ENOMEM, complete napi polling and wake up later to retry via timer. Also explicitly re-enable RX DMA after oom, so the dmac doesn't remain stopped in this situation. Previously, memory pressure could lead to skb allocation failures and subsequent Oops like: Oops: Kernel access of bad area, sig: 11 [kernel-patches#2] Hardware name: SonyPS3 Cell Broadband Engine 0x701000 PS3 NIP [c0003d0000065900] gelic_net_poll+0x6c/0x2d0 [ps3_gelic] (unreliable) LR [c0003d00000659c4] gelic_net_poll+0x130/0x2d0 [ps3_gelic] Call Trace: gelic_net_poll+0x130/0x2d0 [ps3_gelic] (unreliable) __napi_poll+0x44/0x168 net_rx_action+0x178/0x290 Steps to reproduce the issue: 1. Start a continuous network traffic, like scp of a 20GB file 2. Inject failslab errors using the kernel fault injection: echo -1 > /sys/kernel/debug/failslab/times echo 30 > /sys/kernel/debug/failslab/interval echo 100 > /sys/kernel/debug/failslab/probability 3. After some time, traces start to appear, kernel Oopses and the system stops Step 2 is not always necessary, as it is usually already triggered by the transfer of a big enough file. Fixes: 02c1889 ("ps3: gigabit ethernet driver for PS3, take3") Signed-off-by: Florian Fuchs <fuchsfl@gmail.com> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing-bpf-ci
that referenced
this pull request
Nov 11, 2025
Assume a scenario with something like the following routes: default via fe80::1 dev dummy0 2001:db8:1::/48 via fe80::10 dev dummy0 2001:db8:1::/48 from 2001:db8:1:2::/64 via fe80::12 dev dummy0 Now if a lookup happens for 2001:db8:1::2345, but with a source address *not* covered by the third route, the expectation is to hit the second one. Unfortunately, this was broken since the code, on failing the lookup in the subtree, didn't consider the node itself which the subtree is attached to, i.e. route kernel-patches#2 above. The fix is simple, check if the subtree is attached to a node that is itself a valid route before backtracking to less specific destination prefixes. This case is somewhat rare for several reasons. To begin with, subtree routes are most commonly attached to the default destination. Additionally, in the rare cases where a non-default destination prefix is host to subtree routes, the fallback on not hitting any subtree route is commonly a default route (or a subtree route on that). (Note that this was working for the "::/0 from ::/0" case since the root node is special-cased. The issue was discovered during RFC 6724 rule 5.5 testing, trying to find edge cases.) Signed-off-by: David Lamparter <equinox@diac24.net> Cc: Lorenzo Colitti <lorenzo@google.com> Cc: Patrick Rohr <prohr@google.com> Cc: Maciej Żenczykowski <maze@google.com> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing-bpf-ci
that referenced
this pull request
Nov 11, 2025
Handle skb allocation failures in RX path, to avoid NULL pointer dereference and RX stalls under memory pressure. If the refill fails with -ENOMEM, complete napi polling and wake up later to retry via timer. Also explicitly re-enable RX DMA after oom, so the dmac doesn't remain stopped in this situation. Previously, memory pressure could lead to skb allocation failures and subsequent Oops like: Oops: Kernel access of bad area, sig: 11 [kernel-patches#2] Hardware name: SonyPS3 Cell Broadband Engine 0x701000 PS3 NIP [c0003d0000065900] gelic_net_poll+0x6c/0x2d0 [ps3_gelic] (unreliable) LR [c0003d00000659c4] gelic_net_poll+0x130/0x2d0 [ps3_gelic] Call Trace: gelic_net_poll+0x130/0x2d0 [ps3_gelic] (unreliable) __napi_poll+0x44/0x168 net_rx_action+0x178/0x290 Steps to reproduce the issue: 1. Start a continuous network traffic, like scp of a 20GB file 2. Inject failslab errors using the kernel fault injection: echo -1 > /sys/kernel/debug/failslab/times echo 30 > /sys/kernel/debug/failslab/interval echo 100 > /sys/kernel/debug/failslab/probability 3. After some time, traces start to appear, kernel Oopses and the system stops Step 2 is not always necessary, as it is usually already triggered by the transfer of a big enough file. Fixes: 02c1889 ("ps3: gigabit ethernet driver for PS3, take3") Signed-off-by: Florian Fuchs <fuchsfl@gmail.com> 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.
Pull request for series with
subject: Sockmap iterator
version: 3
url: https://patchwork.ozlabs.org/project/netdev/list/?series=199474