bpf: using rcu_read_lock for bpf_sk_storage_map iterator#55
Closed
kernel-patches-bot wants to merge 2 commits intobpf-nextfrom
Closed
bpf: using rcu_read_lock for bpf_sk_storage_map iterator#55kernel-patches-bot wants to merge 2 commits intobpf-nextfrom
kernel-patches-bot wants to merge 2 commits intobpf-nextfrom
Conversation
Author
|
Master branch: 2bab48c patch https://patchwork.ozlabs.org/project/netdev/patch/20200914184630.1048718-1-yhs@fb.com/ applied successfully |
Author
|
Master branch: d72714c patch https://patchwork.ozlabs.org/project/netdev/patch/20200914184630.1048718-1-yhs@fb.com/ applied successfully |
10f901e to
4f12c2b
Compare
Author
|
Master branch: bf74a37 patch https://patchwork.ozlabs.org/project/netdev/patch/20200914184630.1048718-1-yhs@fb.com/ applied successfully |
4f12c2b to
73cc4a5
Compare
elements. Since bpf_iter programs cannot use bpf_sk_storage_get()
and bpf_sk_storage_delete() helpers which may also grab bucket lock,
we do not have a deadlock issue which exists for hashmap when
using bucket_lock ([1]).
If a bucket contains a lot of sockets, during bpf_iter traversing
a bucket, concurrent bpf_sk_storage_{get,delete}() may experience
some undesirable delays. Using rcu_read_lock() is a reasonable
compromise here. Although it may lose some precision, e.g.,
access stale sockets, but it will not hurt performance of other
bpf programs.
[1] https://lore.kernel.org/bpf/20200902235341.2001534-1-yhs@fb.com
Cc: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: Yonghong Song <yhs@fb.com>
---
net/core/bpf_sk_storage.c | 15 ++++++---------
1 file changed, 6 insertions(+), 9 deletions(-)
Author
|
Master branch: d317b0a patch https://patchwork.ozlabs.org/project/netdev/patch/20200914184630.1048718-1-yhs@fb.com/ applied successfully |
73cc4a5 to
4d6743b
Compare
Author
|
At least one diff in series https://patchwork.ozlabs.org/project/netdev/list/?series=201648 expired. Closing PR. |
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
Apr 7, 2022
After rx/tx ring buffer size is changed, kernel panic occurs when it acts XDP_TX or XDP_REDIRECT. When tx/rx ring buffer size is changed(ethtool -G), sfc driver reallocates and reinitializes rx and tx queues and their buffer (tx_queue->buffer). But it misses reinitializing xdp queues(efx->xdp_tx_queues). So, while it is acting XDP_TX or XDP_REDIRECT, it uses the uninitialized tx_queue->buffer. A new function efx_set_xdp_channels() is separated from efx_set_channels() to handle only xdp queues. Splat looks like: BUG: kernel NULL pointer dereference, address: 000000000000002a #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#4] PREEMPT SMP NOPTI RIP: 0010:efx_tx_map_chunk+0x54/0x90 [sfc] CPU: 2 PID: 0 Comm: swapper/2 Tainted: G D 5.17.0+ #55 e8beeee8289528f11357029357cf Code: 48 8b 8d a8 01 00 00 48 8d 14 52 4c 8d 2c d0 44 89 e0 48 85 c9 74 0e 44 89 e2 4c 89 f6 48 80 RSP: 0018:ffff92f121e45c60 EFLAGS: 00010297 RIP: 0010:efx_tx_map_chunk+0x54/0x90 [sfc] RAX: 0000000000000040 RBX: ffff92ea506895c0 RCX: ffffffffc0330870 RDX: 0000000000000001 RSI: 00000001139b10ce RDI: ffff92ea506895c0 RBP: ffffffffc0358a80 R08: 00000001139b110d R09: 0000000000000000 R10: 0000000000000001 R11: ffff92ea414c0088 R12: 0000000000000040 R13: 0000000000000018 R14: 00000001139b10ce R15: ffff92ea506895c0 FS: 0000000000000000(0000) GS:ffff92f121ec0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Code: 48 8b 8d a8 01 00 00 48 8d 14 52 4c 8d 2c d0 44 89 e0 48 85 c9 74 0e 44 89 e2 4c 89 f6 48 80 CR2: 000000000000002a CR3: 00000003e6810004 CR4: 00000000007706e0 RSP: 0018:ffff92f121e85c60 EFLAGS: 00010297 PKRU: 55555554 RAX: 0000000000000040 RBX: ffff92ea50689700 RCX: ffffffffc0330870 RDX: 0000000000000001 RSI: 00000001145a90ce RDI: ffff92ea50689700 RBP: ffffffffc0358a80 R08: 00000001145a910d R09: 0000000000000000 R10: 0000000000000001 R11: ffff92ea414c0088 R12: 0000000000000040 R13: 0000000000000018 R14: 00000001145a90ce R15: ffff92ea50689700 FS: 0000000000000000(0000) GS:ffff92f121e80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000002a CR3: 00000003e6810005 CR4: 00000000007706e0 PKRU: 55555554 Call Trace: <IRQ> efx_xdp_tx_buffers+0x12b/0x3d0 [sfc 84c94b8e32d44d296c17e10a634d3ad454de4ba5] __efx_rx_packet+0x5c3/0x930 [sfc 84c94b8e32d44d296c17e10a634d3ad454de4ba5] efx_rx_packet+0x28c/0x2e0 [sfc 84c94b8e32d44d296c17e10a634d3ad454de4ba5] efx_ef10_ev_process+0x5f8/0xf40 [sfc 84c94b8e32d44d296c17e10a634d3ad454de4ba5] ? enqueue_task_fair+0x95/0x550 efx_poll+0xc4/0x360 [sfc 84c94b8e32d44d296c17e10a634d3ad454de4ba5] Fixes: 3990a8f ("sfc: allocate channels for XDP tx queues") Signed-off-by: Taehee Yoo <ap420073@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Apr 13, 2022
Add bpf trampoline support for arm64. Most of the logic is the same as x86. fentry before bpf trampoline hooked: mov x9, x30 nop fentry after bpf trampoline hooked: mov x9, x30 bl <bpf_trampoline> Tested on qemu, result: #55 fentry_fexit:OK #56 fentry_test:OK #58 fexit_sleep:OK #59 fexit_stress:OK #60 fexit_test:OK #67 get_func_args_test:OK #68 get_func_ip_test:OK #101 modify_return:OK Signed-off-by: Xu Kuohai <xukuohai@huawei.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Apr 13, 2022
Add bpf trampoline support for arm64. Most of the logic is the same as x86. fentry before bpf trampoline hooked: mov x9, x30 nop fentry after bpf trampoline hooked: mov x9, x30 bl <bpf_trampoline> Tested on qemu, result: #55 fentry_fexit:OK #56 fentry_test:OK #58 fexit_sleep:OK #59 fexit_stress:OK #60 fexit_test:OK #67 get_func_args_test:OK #68 get_func_ip_test:OK #101 modify_return:OK Signed-off-by: Xu Kuohai <xukuohai@huawei.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Apr 13, 2022
Add bpf trampoline support for arm64. Most of the logic is the same as x86. fentry before bpf trampoline hooked: mov x9, x30 nop fentry after bpf trampoline hooked: mov x9, x30 bl <bpf_trampoline> Tested on qemu, result: #55 fentry_fexit:OK #56 fentry_test:OK #58 fexit_sleep:OK #59 fexit_stress:OK #60 fexit_test:OK #67 get_func_args_test:OK #68 get_func_ip_test:OK #101 modify_return:OK Signed-off-by: Xu Kuohai <xukuohai@huawei.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Apr 14, 2022
Add bpf trampoline support for arm64. Most of the logic is the same as x86. fentry before bpf trampoline hooked: mov x9, x30 nop fentry after bpf trampoline hooked: mov x9, x30 bl <bpf_trampoline> Tested on qemu, result: #55 fentry_fexit:OK #56 fentry_test:OK #58 fexit_sleep:OK #59 fexit_stress:OK #60 fexit_test:OK #67 get_func_args_test:OK #68 get_func_ip_test:OK #101 modify_return:OK Signed-off-by: Xu Kuohai <xukuohai@huawei.com> Acked-by: Song Liu <songliubraving@fb.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Apr 14, 2022
Add bpf trampoline support for arm64. Most of the logic is the same as x86. fentry before bpf trampoline hooked: mov x9, x30 nop fentry after bpf trampoline hooked: mov x9, x30 bl <bpf_trampoline> Tested on qemu, result: #55 fentry_fexit:OK #56 fentry_test:OK #58 fexit_sleep:OK #59 fexit_stress:OK #60 fexit_test:OK #67 get_func_args_test:OK #68 get_func_ip_test:OK #101 modify_return:OK Signed-off-by: Xu Kuohai <xukuohai@huawei.com> Acked-by: Song Liu <songliubraving@fb.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Apr 14, 2022
Add bpf trampoline support for arm64. Most of the logic is the same as x86. fentry before bpf trampoline hooked: mov x9, x30 nop fentry after bpf trampoline hooked: mov x9, x30 bl <bpf_trampoline> Tested on qemu, result: #55 fentry_fexit:OK #56 fentry_test:OK #58 fexit_sleep:OK #59 fexit_stress:OK #60 fexit_test:OK #67 get_func_args_test:OK #68 get_func_ip_test:OK #101 modify_return:OK Signed-off-by: Xu Kuohai <xukuohai@huawei.com> Acked-by: Song Liu <songliubraving@fb.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Apr 15, 2022
Add bpf trampoline support for arm64. Most of the logic is the same as x86. fentry before bpf trampoline hooked: mov x9, x30 nop fentry after bpf trampoline hooked: mov x9, x30 bl <bpf_trampoline> Tested on qemu, result: #55 fentry_fexit:OK #56 fentry_test:OK #58 fexit_sleep:OK #59 fexit_stress:OK #60 fexit_test:OK #67 get_func_args_test:OK #68 get_func_ip_test:OK #101 modify_return:OK Signed-off-by: Xu Kuohai <xukuohai@huawei.com> Acked-by: Song Liu <songliubraving@fb.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Apr 24, 2022
Add bpf trampoline support for arm64. Most of the logic is the same as x86. fentry before bpf trampoline hooked: mov x9, x30 nop fentry after bpf trampoline hooked: mov x9, x30 bl <bpf_trampoline> Tested on qemu, result: #18 bpf_tcp_ca:OK #51 dummy_st_ops:OK #55 fentry_fexit:OK #56 fentry_test:OK #57 fexit_bpf2bpf:OK #58 fexit_sleep:OK #59 fexit_stress:OK #60 fexit_test:OK #67 get_func_args_test:OK #68 get_func_ip_test:OK #101 modify_return:OK #233 xdp_bpf2bpf:OK Signed-off-by: Xu Kuohai <xukuohai@huawei.com> Acked-by: Song Liu <songliubraving@fb.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
May 17, 2022
Add bpf trampoline support for arm64. Most of the logic is the same as x86. Tested on raspberry pi 4b and qemu with KASLR disabled (avoid long jump), result: #9 /1 bpf_cookie/kprobe:OK #9 /2 bpf_cookie/multi_kprobe_link_api:FAIL #9 /3 bpf_cookie/multi_kprobe_attach_api:FAIL #9 /4 bpf_cookie/uprobe:OK #9 /5 bpf_cookie/tracepoint:OK #9 /6 bpf_cookie/perf_event:OK #9 /7 bpf_cookie/trampoline:OK #9 /8 bpf_cookie/lsm:OK #9 bpf_cookie:FAIL #18 /1 bpf_tcp_ca/dctcp:OK #18 /2 bpf_tcp_ca/cubic:OK #18 /3 bpf_tcp_ca/invalid_license:OK #18 /4 bpf_tcp_ca/dctcp_fallback:OK #18 /5 bpf_tcp_ca/rel_setsockopt:OK #18 bpf_tcp_ca:OK #51 /1 dummy_st_ops/dummy_st_ops_attach:OK #51 /2 dummy_st_ops/dummy_init_ret_value:OK #51 /3 dummy_st_ops/dummy_init_ptr_arg:OK #51 /4 dummy_st_ops/dummy_multiple_args:OK #51 dummy_st_ops:OK #55 fentry_fexit:OK #56 fentry_test:OK #57 /1 fexit_bpf2bpf/target_no_callees:OK #57 /2 fexit_bpf2bpf/target_yes_callees:OK #57 /3 fexit_bpf2bpf/func_replace:OK #57 /4 fexit_bpf2bpf/func_replace_verify:OK #57 /5 fexit_bpf2bpf/func_sockmap_update:OK #57 /6 fexit_bpf2bpf/func_replace_return_code:OK #57 /7 fexit_bpf2bpf/func_map_prog_compatibility:OK #57 /8 fexit_bpf2bpf/func_replace_multi:OK #57 /9 fexit_bpf2bpf/fmod_ret_freplace:OK #57 fexit_bpf2bpf:OK #58 fexit_sleep:OK #59 fexit_stress:OK #60 fexit_test:OK #67 get_func_args_test:OK #68 get_func_ip_test:OK #104 modify_return:OK #237 xdp_bpf2bpf:OK bpf_cookie/multi_kprobe_link_api and bpf_cookie/multi_kprobe_attach_api failed due to lack of multi_kprobe on arm64. Signed-off-by: Xu Kuohai <xukuohai@huawei.com> Acked-by: Song Liu <songliubraving@fb.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
May 18, 2022
Add bpf trampoline support for arm64. Most of the logic is the same as x86. Tested on raspberry pi 4b and qemu with KASLR disabled (avoid long jump), result: #9 /1 bpf_cookie/kprobe:OK #9 /2 bpf_cookie/multi_kprobe_link_api:FAIL #9 /3 bpf_cookie/multi_kprobe_attach_api:FAIL #9 /4 bpf_cookie/uprobe:OK #9 /5 bpf_cookie/tracepoint:OK #9 /6 bpf_cookie/perf_event:OK #9 /7 bpf_cookie/trampoline:OK #9 /8 bpf_cookie/lsm:OK #9 bpf_cookie:FAIL #18 /1 bpf_tcp_ca/dctcp:OK #18 /2 bpf_tcp_ca/cubic:OK #18 /3 bpf_tcp_ca/invalid_license:OK #18 /4 bpf_tcp_ca/dctcp_fallback:OK #18 /5 bpf_tcp_ca/rel_setsockopt:OK #18 bpf_tcp_ca:OK #51 /1 dummy_st_ops/dummy_st_ops_attach:OK #51 /2 dummy_st_ops/dummy_init_ret_value:OK #51 /3 dummy_st_ops/dummy_init_ptr_arg:OK #51 /4 dummy_st_ops/dummy_multiple_args:OK #51 dummy_st_ops:OK #55 fentry_fexit:OK #56 fentry_test:OK #57 /1 fexit_bpf2bpf/target_no_callees:OK #57 /2 fexit_bpf2bpf/target_yes_callees:OK #57 /3 fexit_bpf2bpf/func_replace:OK #57 /4 fexit_bpf2bpf/func_replace_verify:OK #57 /5 fexit_bpf2bpf/func_sockmap_update:OK #57 /6 fexit_bpf2bpf/func_replace_return_code:OK #57 /7 fexit_bpf2bpf/func_map_prog_compatibility:OK #57 /8 fexit_bpf2bpf/func_replace_multi:OK #57 /9 fexit_bpf2bpf/fmod_ret_freplace:OK #57 fexit_bpf2bpf:OK #58 fexit_sleep:OK #59 fexit_stress:OK #60 fexit_test:OK #67 get_func_args_test:OK #68 get_func_ip_test:OK #104 modify_return:OK #237 xdp_bpf2bpf:OK bpf_cookie/multi_kprobe_link_api and bpf_cookie/multi_kprobe_attach_api failed due to lack of multi_kprobe on arm64. Signed-off-by: Xu Kuohai <xukuohai@huawei.com> Acked-by: Song Liu <songliubraving@fb.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
May 19, 2022
Add bpf trampoline support for arm64. Most of the logic is the same as x86. Tested on raspberry pi 4b and qemu with KASLR disabled (avoid long jump), result: #9 /1 bpf_cookie/kprobe:OK #9 /2 bpf_cookie/multi_kprobe_link_api:FAIL #9 /3 bpf_cookie/multi_kprobe_attach_api:FAIL #9 /4 bpf_cookie/uprobe:OK #9 /5 bpf_cookie/tracepoint:OK #9 /6 bpf_cookie/perf_event:OK #9 /7 bpf_cookie/trampoline:OK #9 /8 bpf_cookie/lsm:OK #9 bpf_cookie:FAIL #18 /1 bpf_tcp_ca/dctcp:OK #18 /2 bpf_tcp_ca/cubic:OK #18 /3 bpf_tcp_ca/invalid_license:OK #18 /4 bpf_tcp_ca/dctcp_fallback:OK #18 /5 bpf_tcp_ca/rel_setsockopt:OK #18 bpf_tcp_ca:OK #51 /1 dummy_st_ops/dummy_st_ops_attach:OK #51 /2 dummy_st_ops/dummy_init_ret_value:OK #51 /3 dummy_st_ops/dummy_init_ptr_arg:OK #51 /4 dummy_st_ops/dummy_multiple_args:OK #51 dummy_st_ops:OK #55 fentry_fexit:OK #56 fentry_test:OK #57 /1 fexit_bpf2bpf/target_no_callees:OK #57 /2 fexit_bpf2bpf/target_yes_callees:OK #57 /3 fexit_bpf2bpf/func_replace:OK #57 /4 fexit_bpf2bpf/func_replace_verify:OK #57 /5 fexit_bpf2bpf/func_sockmap_update:OK #57 /6 fexit_bpf2bpf/func_replace_return_code:OK #57 /7 fexit_bpf2bpf/func_map_prog_compatibility:OK #57 /8 fexit_bpf2bpf/func_replace_multi:OK #57 /9 fexit_bpf2bpf/fmod_ret_freplace:OK #57 fexit_bpf2bpf:OK #58 fexit_sleep:OK #59 fexit_stress:OK #60 fexit_test:OK #67 get_func_args_test:OK #68 get_func_ip_test:OK #104 modify_return:OK #237 xdp_bpf2bpf:OK bpf_cookie/multi_kprobe_link_api and bpf_cookie/multi_kprobe_attach_api failed due to lack of multi_kprobe on arm64. Signed-off-by: Xu Kuohai <xukuohai@huawei.com> Acked-by: Song Liu <songliubraving@fb.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
May 19, 2022
Add bpf trampoline support for arm64. Most of the logic is the same as x86. Tested on raspberry pi 4b and qemu with KASLR disabled (avoid long jump), result: #9 /1 bpf_cookie/kprobe:OK #9 /2 bpf_cookie/multi_kprobe_link_api:FAIL #9 /3 bpf_cookie/multi_kprobe_attach_api:FAIL #9 /4 bpf_cookie/uprobe:OK #9 /5 bpf_cookie/tracepoint:OK #9 /6 bpf_cookie/perf_event:OK #9 /7 bpf_cookie/trampoline:OK #9 /8 bpf_cookie/lsm:OK #9 bpf_cookie:FAIL #18 /1 bpf_tcp_ca/dctcp:OK #18 /2 bpf_tcp_ca/cubic:OK #18 /3 bpf_tcp_ca/invalid_license:OK #18 /4 bpf_tcp_ca/dctcp_fallback:OK #18 /5 bpf_tcp_ca/rel_setsockopt:OK #18 bpf_tcp_ca:OK #51 /1 dummy_st_ops/dummy_st_ops_attach:OK #51 /2 dummy_st_ops/dummy_init_ret_value:OK #51 /3 dummy_st_ops/dummy_init_ptr_arg:OK #51 /4 dummy_st_ops/dummy_multiple_args:OK #51 dummy_st_ops:OK #55 fentry_fexit:OK #56 fentry_test:OK #57 /1 fexit_bpf2bpf/target_no_callees:OK #57 /2 fexit_bpf2bpf/target_yes_callees:OK #57 /3 fexit_bpf2bpf/func_replace:OK #57 /4 fexit_bpf2bpf/func_replace_verify:OK #57 /5 fexit_bpf2bpf/func_sockmap_update:OK #57 /6 fexit_bpf2bpf/func_replace_return_code:OK #57 /7 fexit_bpf2bpf/func_map_prog_compatibility:OK #57 /8 fexit_bpf2bpf/func_replace_multi:OK #57 /9 fexit_bpf2bpf/fmod_ret_freplace:OK #57 fexit_bpf2bpf:OK #58 fexit_sleep:OK #59 fexit_stress:OK #60 fexit_test:OK #67 get_func_args_test:OK #68 get_func_ip_test:OK #104 modify_return:OK #237 xdp_bpf2bpf:OK bpf_cookie/multi_kprobe_link_api and bpf_cookie/multi_kprobe_attach_api failed due to lack of multi_kprobe on arm64. Signed-off-by: Xu Kuohai <xukuohai@huawei.com> Acked-by: Song Liu <songliubraving@fb.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
May 20, 2022
Add bpf trampoline support for arm64. Most of the logic is the same as x86. Tested on raspberry pi 4b and qemu with KASLR disabled (avoid long jump), result: #9 /1 bpf_cookie/kprobe:OK #9 /2 bpf_cookie/multi_kprobe_link_api:FAIL #9 /3 bpf_cookie/multi_kprobe_attach_api:FAIL #9 /4 bpf_cookie/uprobe:OK #9 /5 bpf_cookie/tracepoint:OK #9 /6 bpf_cookie/perf_event:OK #9 /7 bpf_cookie/trampoline:OK #9 /8 bpf_cookie/lsm:OK #9 bpf_cookie:FAIL #18 /1 bpf_tcp_ca/dctcp:OK #18 /2 bpf_tcp_ca/cubic:OK #18 /3 bpf_tcp_ca/invalid_license:OK #18 /4 bpf_tcp_ca/dctcp_fallback:OK #18 /5 bpf_tcp_ca/rel_setsockopt:OK #18 bpf_tcp_ca:OK #51 /1 dummy_st_ops/dummy_st_ops_attach:OK #51 /2 dummy_st_ops/dummy_init_ret_value:OK #51 /3 dummy_st_ops/dummy_init_ptr_arg:OK #51 /4 dummy_st_ops/dummy_multiple_args:OK #51 dummy_st_ops:OK #55 fentry_fexit:OK #56 fentry_test:OK #57 /1 fexit_bpf2bpf/target_no_callees:OK #57 /2 fexit_bpf2bpf/target_yes_callees:OK #57 /3 fexit_bpf2bpf/func_replace:OK #57 /4 fexit_bpf2bpf/func_replace_verify:OK #57 /5 fexit_bpf2bpf/func_sockmap_update:OK #57 /6 fexit_bpf2bpf/func_replace_return_code:OK #57 /7 fexit_bpf2bpf/func_map_prog_compatibility:OK #57 /8 fexit_bpf2bpf/func_replace_multi:OK #57 /9 fexit_bpf2bpf/fmod_ret_freplace:OK #57 fexit_bpf2bpf:OK #58 fexit_sleep:OK #59 fexit_stress:OK #60 fexit_test:OK #67 get_func_args_test:OK #68 get_func_ip_test:OK #104 modify_return:OK #237 xdp_bpf2bpf:OK bpf_cookie/multi_kprobe_link_api and bpf_cookie/multi_kprobe_attach_api failed due to lack of multi_kprobe on arm64. Signed-off-by: Xu Kuohai <xukuohai@huawei.com> Acked-by: Song Liu <songliubraving@fb.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
May 20, 2022
Add bpf trampoline support for arm64. Most of the logic is the same as x86. Tested on raspberry pi 4b and qemu with KASLR disabled (avoid long jump), result: #9 /1 bpf_cookie/kprobe:OK #9 /2 bpf_cookie/multi_kprobe_link_api:FAIL #9 /3 bpf_cookie/multi_kprobe_attach_api:FAIL #9 /4 bpf_cookie/uprobe:OK #9 /5 bpf_cookie/tracepoint:OK #9 /6 bpf_cookie/perf_event:OK #9 /7 bpf_cookie/trampoline:OK #9 /8 bpf_cookie/lsm:OK #9 bpf_cookie:FAIL #18 /1 bpf_tcp_ca/dctcp:OK #18 /2 bpf_tcp_ca/cubic:OK #18 /3 bpf_tcp_ca/invalid_license:OK #18 /4 bpf_tcp_ca/dctcp_fallback:OK #18 /5 bpf_tcp_ca/rel_setsockopt:OK #18 bpf_tcp_ca:OK #51 /1 dummy_st_ops/dummy_st_ops_attach:OK #51 /2 dummy_st_ops/dummy_init_ret_value:OK #51 /3 dummy_st_ops/dummy_init_ptr_arg:OK #51 /4 dummy_st_ops/dummy_multiple_args:OK #51 dummy_st_ops:OK #55 fentry_fexit:OK #56 fentry_test:OK #57 /1 fexit_bpf2bpf/target_no_callees:OK #57 /2 fexit_bpf2bpf/target_yes_callees:OK #57 /3 fexit_bpf2bpf/func_replace:OK #57 /4 fexit_bpf2bpf/func_replace_verify:OK #57 /5 fexit_bpf2bpf/func_sockmap_update:OK #57 /6 fexit_bpf2bpf/func_replace_return_code:OK #57 /7 fexit_bpf2bpf/func_map_prog_compatibility:OK #57 /8 fexit_bpf2bpf/func_replace_multi:OK #57 /9 fexit_bpf2bpf/fmod_ret_freplace:OK #57 fexit_bpf2bpf:OK #58 fexit_sleep:OK #59 fexit_stress:OK #60 fexit_test:OK #67 get_func_args_test:OK #68 get_func_ip_test:OK #104 modify_return:OK #237 xdp_bpf2bpf:OK bpf_cookie/multi_kprobe_link_api and bpf_cookie/multi_kprobe_attach_api failed due to lack of multi_kprobe on arm64. Signed-off-by: Xu Kuohai <xukuohai@huawei.com> Acked-by: Song Liu <songliubraving@fb.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
May 20, 2022
Add bpf trampoline support for arm64. Most of the logic is the same as x86. Tested on raspberry pi 4b and qemu with KASLR disabled (avoid long jump), result: #9 /1 bpf_cookie/kprobe:OK #9 /2 bpf_cookie/multi_kprobe_link_api:FAIL #9 /3 bpf_cookie/multi_kprobe_attach_api:FAIL #9 /4 bpf_cookie/uprobe:OK #9 /5 bpf_cookie/tracepoint:OK #9 /6 bpf_cookie/perf_event:OK #9 /7 bpf_cookie/trampoline:OK #9 /8 bpf_cookie/lsm:OK #9 bpf_cookie:FAIL #18 /1 bpf_tcp_ca/dctcp:OK #18 /2 bpf_tcp_ca/cubic:OK #18 /3 bpf_tcp_ca/invalid_license:OK #18 /4 bpf_tcp_ca/dctcp_fallback:OK #18 /5 bpf_tcp_ca/rel_setsockopt:OK #18 bpf_tcp_ca:OK #51 /1 dummy_st_ops/dummy_st_ops_attach:OK #51 /2 dummy_st_ops/dummy_init_ret_value:OK #51 /3 dummy_st_ops/dummy_init_ptr_arg:OK #51 /4 dummy_st_ops/dummy_multiple_args:OK #51 dummy_st_ops:OK #55 fentry_fexit:OK #56 fentry_test:OK #57 /1 fexit_bpf2bpf/target_no_callees:OK #57 /2 fexit_bpf2bpf/target_yes_callees:OK #57 /3 fexit_bpf2bpf/func_replace:OK #57 /4 fexit_bpf2bpf/func_replace_verify:OK #57 /5 fexit_bpf2bpf/func_sockmap_update:OK #57 /6 fexit_bpf2bpf/func_replace_return_code:OK #57 /7 fexit_bpf2bpf/func_map_prog_compatibility:OK #57 /8 fexit_bpf2bpf/func_replace_multi:OK #57 /9 fexit_bpf2bpf/fmod_ret_freplace:OK #57 fexit_bpf2bpf:OK #58 fexit_sleep:OK #59 fexit_stress:OK #60 fexit_test:OK #67 get_func_args_test:OK #68 get_func_ip_test:OK #104 modify_return:OK #237 xdp_bpf2bpf:OK bpf_cookie/multi_kprobe_link_api and bpf_cookie/multi_kprobe_attach_api failed due to lack of multi_kprobe on arm64. Signed-off-by: Xu Kuohai <xukuohai@huawei.com> Acked-by: Song Liu <songliubraving@fb.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
May 20, 2022
Add bpf trampoline support for arm64. Most of the logic is the same as x86. Tested on raspberry pi 4b and qemu with KASLR disabled (avoid long jump), result: #9 /1 bpf_cookie/kprobe:OK #9 /2 bpf_cookie/multi_kprobe_link_api:FAIL #9 /3 bpf_cookie/multi_kprobe_attach_api:FAIL #9 /4 bpf_cookie/uprobe:OK #9 /5 bpf_cookie/tracepoint:OK #9 /6 bpf_cookie/perf_event:OK #9 /7 bpf_cookie/trampoline:OK #9 /8 bpf_cookie/lsm:OK #9 bpf_cookie:FAIL #18 /1 bpf_tcp_ca/dctcp:OK #18 /2 bpf_tcp_ca/cubic:OK #18 /3 bpf_tcp_ca/invalid_license:OK #18 /4 bpf_tcp_ca/dctcp_fallback:OK #18 /5 bpf_tcp_ca/rel_setsockopt:OK #18 bpf_tcp_ca:OK #51 /1 dummy_st_ops/dummy_st_ops_attach:OK #51 /2 dummy_st_ops/dummy_init_ret_value:OK #51 /3 dummy_st_ops/dummy_init_ptr_arg:OK #51 /4 dummy_st_ops/dummy_multiple_args:OK #51 dummy_st_ops:OK #55 fentry_fexit:OK #56 fentry_test:OK #57 /1 fexit_bpf2bpf/target_no_callees:OK #57 /2 fexit_bpf2bpf/target_yes_callees:OK #57 /3 fexit_bpf2bpf/func_replace:OK #57 /4 fexit_bpf2bpf/func_replace_verify:OK #57 /5 fexit_bpf2bpf/func_sockmap_update:OK #57 /6 fexit_bpf2bpf/func_replace_return_code:OK #57 /7 fexit_bpf2bpf/func_map_prog_compatibility:OK #57 /8 fexit_bpf2bpf/func_replace_multi:OK #57 /9 fexit_bpf2bpf/fmod_ret_freplace:OK #57 fexit_bpf2bpf:OK #58 fexit_sleep:OK #59 fexit_stress:OK #60 fexit_test:OK #67 get_func_args_test:OK #68 get_func_ip_test:OK #104 modify_return:OK #237 xdp_bpf2bpf:OK bpf_cookie/multi_kprobe_link_api and bpf_cookie/multi_kprobe_attach_api failed due to lack of multi_kprobe on arm64. Signed-off-by: Xu Kuohai <xukuohai@huawei.com> Acked-by: Song Liu <songliubraving@fb.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
May 21, 2022
Add bpf trampoline support for arm64. Most of the logic is the same as x86. Tested on raspberry pi 4b and qemu with KASLR disabled (avoid long jump), result: #9 /1 bpf_cookie/kprobe:OK #9 /2 bpf_cookie/multi_kprobe_link_api:FAIL #9 /3 bpf_cookie/multi_kprobe_attach_api:FAIL #9 /4 bpf_cookie/uprobe:OK #9 /5 bpf_cookie/tracepoint:OK #9 /6 bpf_cookie/perf_event:OK #9 /7 bpf_cookie/trampoline:OK #9 /8 bpf_cookie/lsm:OK #9 bpf_cookie:FAIL #18 /1 bpf_tcp_ca/dctcp:OK #18 /2 bpf_tcp_ca/cubic:OK #18 /3 bpf_tcp_ca/invalid_license:OK #18 /4 bpf_tcp_ca/dctcp_fallback:OK #18 /5 bpf_tcp_ca/rel_setsockopt:OK #18 bpf_tcp_ca:OK #51 /1 dummy_st_ops/dummy_st_ops_attach:OK #51 /2 dummy_st_ops/dummy_init_ret_value:OK #51 /3 dummy_st_ops/dummy_init_ptr_arg:OK #51 /4 dummy_st_ops/dummy_multiple_args:OK #51 dummy_st_ops:OK #55 fentry_fexit:OK #56 fentry_test:OK #57 /1 fexit_bpf2bpf/target_no_callees:OK #57 /2 fexit_bpf2bpf/target_yes_callees:OK #57 /3 fexit_bpf2bpf/func_replace:OK #57 /4 fexit_bpf2bpf/func_replace_verify:OK #57 /5 fexit_bpf2bpf/func_sockmap_update:OK #57 /6 fexit_bpf2bpf/func_replace_return_code:OK #57 /7 fexit_bpf2bpf/func_map_prog_compatibility:OK #57 /8 fexit_bpf2bpf/func_replace_multi:OK #57 /9 fexit_bpf2bpf/fmod_ret_freplace:OK #57 fexit_bpf2bpf:OK #58 fexit_sleep:OK #59 fexit_stress:OK #60 fexit_test:OK #67 get_func_args_test:OK #68 get_func_ip_test:OK #104 modify_return:OK #237 xdp_bpf2bpf:OK bpf_cookie/multi_kprobe_link_api and bpf_cookie/multi_kprobe_attach_api failed due to lack of multi_kprobe on arm64. Signed-off-by: Xu Kuohai <xukuohai@huawei.com> Acked-by: Song Liu <songliubraving@fb.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
May 21, 2022
Add bpf trampoline support for arm64. Most of the logic is the same as x86. Tested on raspberry pi 4b and qemu with KASLR disabled (avoid long jump), result: #9 /1 bpf_cookie/kprobe:OK #9 /2 bpf_cookie/multi_kprobe_link_api:FAIL #9 /3 bpf_cookie/multi_kprobe_attach_api:FAIL #9 /4 bpf_cookie/uprobe:OK #9 /5 bpf_cookie/tracepoint:OK #9 /6 bpf_cookie/perf_event:OK #9 /7 bpf_cookie/trampoline:OK #9 /8 bpf_cookie/lsm:OK #9 bpf_cookie:FAIL #18 /1 bpf_tcp_ca/dctcp:OK #18 /2 bpf_tcp_ca/cubic:OK #18 /3 bpf_tcp_ca/invalid_license:OK #18 /4 bpf_tcp_ca/dctcp_fallback:OK #18 /5 bpf_tcp_ca/rel_setsockopt:OK #18 bpf_tcp_ca:OK #51 /1 dummy_st_ops/dummy_st_ops_attach:OK #51 /2 dummy_st_ops/dummy_init_ret_value:OK #51 /3 dummy_st_ops/dummy_init_ptr_arg:OK #51 /4 dummy_st_ops/dummy_multiple_args:OK #51 dummy_st_ops:OK #55 fentry_fexit:OK #56 fentry_test:OK #57 /1 fexit_bpf2bpf/target_no_callees:OK #57 /2 fexit_bpf2bpf/target_yes_callees:OK #57 /3 fexit_bpf2bpf/func_replace:OK #57 /4 fexit_bpf2bpf/func_replace_verify:OK #57 /5 fexit_bpf2bpf/func_sockmap_update:OK #57 /6 fexit_bpf2bpf/func_replace_return_code:OK #57 /7 fexit_bpf2bpf/func_map_prog_compatibility:OK #57 /8 fexit_bpf2bpf/func_replace_multi:OK #57 /9 fexit_bpf2bpf/fmod_ret_freplace:OK #57 fexit_bpf2bpf:OK #58 fexit_sleep:OK #59 fexit_stress:OK #60 fexit_test:OK #67 get_func_args_test:OK #68 get_func_ip_test:OK #104 modify_return:OK #237 xdp_bpf2bpf:OK bpf_cookie/multi_kprobe_link_api and bpf_cookie/multi_kprobe_attach_api failed due to lack of multi_kprobe on arm64. Signed-off-by: Xu Kuohai <xukuohai@huawei.com> Acked-by: Song Liu <songliubraving@fb.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
May 21, 2022
Add bpf trampoline support for arm64. Most of the logic is the same as x86. Tested on raspberry pi 4b and qemu with KASLR disabled (avoid long jump), result: #9 /1 bpf_cookie/kprobe:OK #9 /2 bpf_cookie/multi_kprobe_link_api:FAIL #9 /3 bpf_cookie/multi_kprobe_attach_api:FAIL #9 /4 bpf_cookie/uprobe:OK #9 /5 bpf_cookie/tracepoint:OK #9 /6 bpf_cookie/perf_event:OK #9 /7 bpf_cookie/trampoline:OK #9 /8 bpf_cookie/lsm:OK #9 bpf_cookie:FAIL #18 /1 bpf_tcp_ca/dctcp:OK #18 /2 bpf_tcp_ca/cubic:OK #18 /3 bpf_tcp_ca/invalid_license:OK #18 /4 bpf_tcp_ca/dctcp_fallback:OK #18 /5 bpf_tcp_ca/rel_setsockopt:OK #18 bpf_tcp_ca:OK #51 /1 dummy_st_ops/dummy_st_ops_attach:OK #51 /2 dummy_st_ops/dummy_init_ret_value:OK #51 /3 dummy_st_ops/dummy_init_ptr_arg:OK #51 /4 dummy_st_ops/dummy_multiple_args:OK #51 dummy_st_ops:OK #55 fentry_fexit:OK #56 fentry_test:OK #57 /1 fexit_bpf2bpf/target_no_callees:OK #57 /2 fexit_bpf2bpf/target_yes_callees:OK #57 /3 fexit_bpf2bpf/func_replace:OK #57 /4 fexit_bpf2bpf/func_replace_verify:OK #57 /5 fexit_bpf2bpf/func_sockmap_update:OK #57 /6 fexit_bpf2bpf/func_replace_return_code:OK #57 /7 fexit_bpf2bpf/func_map_prog_compatibility:OK #57 /8 fexit_bpf2bpf/func_replace_multi:OK #57 /9 fexit_bpf2bpf/fmod_ret_freplace:OK #57 fexit_bpf2bpf:OK #58 fexit_sleep:OK #59 fexit_stress:OK #60 fexit_test:OK #67 get_func_args_test:OK #68 get_func_ip_test:OK #104 modify_return:OK #237 xdp_bpf2bpf:OK bpf_cookie/multi_kprobe_link_api and bpf_cookie/multi_kprobe_attach_api failed due to lack of multi_kprobe on arm64. Signed-off-by: Xu Kuohai <xukuohai@huawei.com> Acked-by: Song Liu <songliubraving@fb.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
May 23, 2022
Add bpf trampoline support for arm64. Most of the logic is the same as x86. Tested on raspberry pi 4b and qemu with KASLR disabled (avoid long jump), result: #9 /1 bpf_cookie/kprobe:OK #9 /2 bpf_cookie/multi_kprobe_link_api:FAIL #9 /3 bpf_cookie/multi_kprobe_attach_api:FAIL #9 /4 bpf_cookie/uprobe:OK #9 /5 bpf_cookie/tracepoint:OK #9 /6 bpf_cookie/perf_event:OK #9 /7 bpf_cookie/trampoline:OK #9 /8 bpf_cookie/lsm:OK #9 bpf_cookie:FAIL #18 /1 bpf_tcp_ca/dctcp:OK #18 /2 bpf_tcp_ca/cubic:OK #18 /3 bpf_tcp_ca/invalid_license:OK #18 /4 bpf_tcp_ca/dctcp_fallback:OK #18 /5 bpf_tcp_ca/rel_setsockopt:OK #18 bpf_tcp_ca:OK #51 /1 dummy_st_ops/dummy_st_ops_attach:OK #51 /2 dummy_st_ops/dummy_init_ret_value:OK #51 /3 dummy_st_ops/dummy_init_ptr_arg:OK #51 /4 dummy_st_ops/dummy_multiple_args:OK #51 dummy_st_ops:OK #55 fentry_fexit:OK #56 fentry_test:OK #57 /1 fexit_bpf2bpf/target_no_callees:OK #57 /2 fexit_bpf2bpf/target_yes_callees:OK #57 /3 fexit_bpf2bpf/func_replace:OK #57 /4 fexit_bpf2bpf/func_replace_verify:OK #57 /5 fexit_bpf2bpf/func_sockmap_update:OK #57 /6 fexit_bpf2bpf/func_replace_return_code:OK #57 /7 fexit_bpf2bpf/func_map_prog_compatibility:OK #57 /8 fexit_bpf2bpf/func_replace_multi:OK #57 /9 fexit_bpf2bpf/fmod_ret_freplace:OK #57 fexit_bpf2bpf:OK #58 fexit_sleep:OK #59 fexit_stress:OK #60 fexit_test:OK #67 get_func_args_test:OK #68 get_func_ip_test:OK #104 modify_return:OK #237 xdp_bpf2bpf:OK bpf_cookie/multi_kprobe_link_api and bpf_cookie/multi_kprobe_attach_api failed due to lack of multi_kprobe on arm64. Signed-off-by: Xu Kuohai <xukuohai@huawei.com> Acked-by: Song Liu <songliubraving@fb.com> Acked-by: KP Singh <kpsingh@kernel.org>
kernel-patches-bot
pushed a commit
that referenced
this pull request
May 23, 2022
Add bpf trampoline support for arm64. Most of the logic is the same as x86. Tested on raspberry pi 4b and qemu with KASLR disabled (avoid long jump), result: #9 /1 bpf_cookie/kprobe:OK #9 /2 bpf_cookie/multi_kprobe_link_api:FAIL #9 /3 bpf_cookie/multi_kprobe_attach_api:FAIL #9 /4 bpf_cookie/uprobe:OK #9 /5 bpf_cookie/tracepoint:OK #9 /6 bpf_cookie/perf_event:OK #9 /7 bpf_cookie/trampoline:OK #9 /8 bpf_cookie/lsm:OK #9 bpf_cookie:FAIL #18 /1 bpf_tcp_ca/dctcp:OK #18 /2 bpf_tcp_ca/cubic:OK #18 /3 bpf_tcp_ca/invalid_license:OK #18 /4 bpf_tcp_ca/dctcp_fallback:OK #18 /5 bpf_tcp_ca/rel_setsockopt:OK #18 bpf_tcp_ca:OK #51 /1 dummy_st_ops/dummy_st_ops_attach:OK #51 /2 dummy_st_ops/dummy_init_ret_value:OK #51 /3 dummy_st_ops/dummy_init_ptr_arg:OK #51 /4 dummy_st_ops/dummy_multiple_args:OK #51 dummy_st_ops:OK #55 fentry_fexit:OK #56 fentry_test:OK #57 /1 fexit_bpf2bpf/target_no_callees:OK #57 /2 fexit_bpf2bpf/target_yes_callees:OK #57 /3 fexit_bpf2bpf/func_replace:OK #57 /4 fexit_bpf2bpf/func_replace_verify:OK #57 /5 fexit_bpf2bpf/func_sockmap_update:OK #57 /6 fexit_bpf2bpf/func_replace_return_code:OK #57 /7 fexit_bpf2bpf/func_map_prog_compatibility:OK #57 /8 fexit_bpf2bpf/func_replace_multi:OK #57 /9 fexit_bpf2bpf/fmod_ret_freplace:OK #57 fexit_bpf2bpf:OK #58 fexit_sleep:OK #59 fexit_stress:OK #60 fexit_test:OK #67 get_func_args_test:OK #68 get_func_ip_test:OK #104 modify_return:OK #237 xdp_bpf2bpf:OK bpf_cookie/multi_kprobe_link_api and bpf_cookie/multi_kprobe_attach_api failed due to lack of multi_kprobe on arm64. Signed-off-by: Xu Kuohai <xukuohai@huawei.com> Acked-by: Song Liu <songliubraving@fb.com> Acked-by: KP Singh <kpsingh@kernel.org>
kernel-patches-bot
pushed a commit
that referenced
this pull request
May 23, 2022
Add bpf trampoline support for arm64. Most of the logic is the same as x86. Tested on raspberry pi 4b and qemu with KASLR disabled (avoid long jump), result: #9 /1 bpf_cookie/kprobe:OK #9 /2 bpf_cookie/multi_kprobe_link_api:FAIL #9 /3 bpf_cookie/multi_kprobe_attach_api:FAIL #9 /4 bpf_cookie/uprobe:OK #9 /5 bpf_cookie/tracepoint:OK #9 /6 bpf_cookie/perf_event:OK #9 /7 bpf_cookie/trampoline:OK #9 /8 bpf_cookie/lsm:OK #9 bpf_cookie:FAIL #18 /1 bpf_tcp_ca/dctcp:OK #18 /2 bpf_tcp_ca/cubic:OK #18 /3 bpf_tcp_ca/invalid_license:OK #18 /4 bpf_tcp_ca/dctcp_fallback:OK #18 /5 bpf_tcp_ca/rel_setsockopt:OK #18 bpf_tcp_ca:OK #51 /1 dummy_st_ops/dummy_st_ops_attach:OK #51 /2 dummy_st_ops/dummy_init_ret_value:OK #51 /3 dummy_st_ops/dummy_init_ptr_arg:OK #51 /4 dummy_st_ops/dummy_multiple_args:OK #51 dummy_st_ops:OK #55 fentry_fexit:OK #56 fentry_test:OK #57 /1 fexit_bpf2bpf/target_no_callees:OK #57 /2 fexit_bpf2bpf/target_yes_callees:OK #57 /3 fexit_bpf2bpf/func_replace:OK #57 /4 fexit_bpf2bpf/func_replace_verify:OK #57 /5 fexit_bpf2bpf/func_sockmap_update:OK #57 /6 fexit_bpf2bpf/func_replace_return_code:OK #57 /7 fexit_bpf2bpf/func_map_prog_compatibility:OK #57 /8 fexit_bpf2bpf/func_replace_multi:OK #57 /9 fexit_bpf2bpf/fmod_ret_freplace:OK #57 fexit_bpf2bpf:OK #58 fexit_sleep:OK #59 fexit_stress:OK #60 fexit_test:OK #67 get_func_args_test:OK #68 get_func_ip_test:OK #104 modify_return:OK #237 xdp_bpf2bpf:OK bpf_cookie/multi_kprobe_link_api and bpf_cookie/multi_kprobe_attach_api failed due to lack of multi_kprobe on arm64. Signed-off-by: Xu Kuohai <xukuohai@huawei.com> Acked-by: Song Liu <songliubraving@fb.com> Acked-by: KP Singh <kpsingh@kernel.org>
kernel-patches-bot
pushed a commit
that referenced
this pull request
May 23, 2022
Add bpf trampoline support for arm64. Most of the logic is the same as x86. Tested on raspberry pi 4b and qemu with KASLR disabled (avoid long jump), result: #9 /1 bpf_cookie/kprobe:OK #9 /2 bpf_cookie/multi_kprobe_link_api:FAIL #9 /3 bpf_cookie/multi_kprobe_attach_api:FAIL #9 /4 bpf_cookie/uprobe:OK #9 /5 bpf_cookie/tracepoint:OK #9 /6 bpf_cookie/perf_event:OK #9 /7 bpf_cookie/trampoline:OK #9 /8 bpf_cookie/lsm:OK #9 bpf_cookie:FAIL #18 /1 bpf_tcp_ca/dctcp:OK #18 /2 bpf_tcp_ca/cubic:OK #18 /3 bpf_tcp_ca/invalid_license:OK #18 /4 bpf_tcp_ca/dctcp_fallback:OK #18 /5 bpf_tcp_ca/rel_setsockopt:OK #18 bpf_tcp_ca:OK #51 /1 dummy_st_ops/dummy_st_ops_attach:OK #51 /2 dummy_st_ops/dummy_init_ret_value:OK #51 /3 dummy_st_ops/dummy_init_ptr_arg:OK #51 /4 dummy_st_ops/dummy_multiple_args:OK #51 dummy_st_ops:OK #55 fentry_fexit:OK #56 fentry_test:OK #57 /1 fexit_bpf2bpf/target_no_callees:OK #57 /2 fexit_bpf2bpf/target_yes_callees:OK #57 /3 fexit_bpf2bpf/func_replace:OK #57 /4 fexit_bpf2bpf/func_replace_verify:OK #57 /5 fexit_bpf2bpf/func_sockmap_update:OK #57 /6 fexit_bpf2bpf/func_replace_return_code:OK #57 /7 fexit_bpf2bpf/func_map_prog_compatibility:OK #57 /8 fexit_bpf2bpf/func_replace_multi:OK #57 /9 fexit_bpf2bpf/fmod_ret_freplace:OK #57 fexit_bpf2bpf:OK #58 fexit_sleep:OK #59 fexit_stress:OK #60 fexit_test:OK #67 get_func_args_test:OK #68 get_func_ip_test:OK #104 modify_return:OK #237 xdp_bpf2bpf:OK bpf_cookie/multi_kprobe_link_api and bpf_cookie/multi_kprobe_attach_api failed due to lack of multi_kprobe on arm64. Signed-off-by: Xu Kuohai <xukuohai@huawei.com> Acked-by: Song Liu <songliubraving@fb.com> Acked-by: KP Singh <kpsingh@kernel.org>
kernel-patches-bot
pushed a commit
that referenced
this pull request
May 23, 2022
Add bpf trampoline support for arm64. Most of the logic is the same as x86. Tested on raspberry pi 4b and qemu with KASLR disabled (avoid long jump), result: #9 /1 bpf_cookie/kprobe:OK #9 /2 bpf_cookie/multi_kprobe_link_api:FAIL #9 /3 bpf_cookie/multi_kprobe_attach_api:FAIL #9 /4 bpf_cookie/uprobe:OK #9 /5 bpf_cookie/tracepoint:OK #9 /6 bpf_cookie/perf_event:OK #9 /7 bpf_cookie/trampoline:OK #9 /8 bpf_cookie/lsm:OK #9 bpf_cookie:FAIL #18 /1 bpf_tcp_ca/dctcp:OK #18 /2 bpf_tcp_ca/cubic:OK #18 /3 bpf_tcp_ca/invalid_license:OK #18 /4 bpf_tcp_ca/dctcp_fallback:OK #18 /5 bpf_tcp_ca/rel_setsockopt:OK #18 bpf_tcp_ca:OK #51 /1 dummy_st_ops/dummy_st_ops_attach:OK #51 /2 dummy_st_ops/dummy_init_ret_value:OK #51 /3 dummy_st_ops/dummy_init_ptr_arg:OK #51 /4 dummy_st_ops/dummy_multiple_args:OK #51 dummy_st_ops:OK #55 fentry_fexit:OK #56 fentry_test:OK #57 /1 fexit_bpf2bpf/target_no_callees:OK #57 /2 fexit_bpf2bpf/target_yes_callees:OK #57 /3 fexit_bpf2bpf/func_replace:OK #57 /4 fexit_bpf2bpf/func_replace_verify:OK #57 /5 fexit_bpf2bpf/func_sockmap_update:OK #57 /6 fexit_bpf2bpf/func_replace_return_code:OK #57 /7 fexit_bpf2bpf/func_map_prog_compatibility:OK #57 /8 fexit_bpf2bpf/func_replace_multi:OK #57 /9 fexit_bpf2bpf/fmod_ret_freplace:OK #57 fexit_bpf2bpf:OK #58 fexit_sleep:OK #59 fexit_stress:OK #60 fexit_test:OK #67 get_func_args_test:OK #68 get_func_ip_test:OK #104 modify_return:OK #237 xdp_bpf2bpf:OK bpf_cookie/multi_kprobe_link_api and bpf_cookie/multi_kprobe_attach_api failed due to lack of multi_kprobe on arm64. Signed-off-by: Xu Kuohai <xukuohai@huawei.com> Acked-by: Song Liu <songliubraving@fb.com> Acked-by: KP Singh <kpsingh@kernel.org>
kernel-patches-bot
pushed a commit
that referenced
this pull request
May 23, 2022
Add bpf trampoline support for arm64. Most of the logic is the same as x86. Tested on raspberry pi 4b and qemu with KASLR disabled (avoid long jump), result: #9 /1 bpf_cookie/kprobe:OK #9 /2 bpf_cookie/multi_kprobe_link_api:FAIL #9 /3 bpf_cookie/multi_kprobe_attach_api:FAIL #9 /4 bpf_cookie/uprobe:OK #9 /5 bpf_cookie/tracepoint:OK #9 /6 bpf_cookie/perf_event:OK #9 /7 bpf_cookie/trampoline:OK #9 /8 bpf_cookie/lsm:OK #9 bpf_cookie:FAIL #18 /1 bpf_tcp_ca/dctcp:OK #18 /2 bpf_tcp_ca/cubic:OK #18 /3 bpf_tcp_ca/invalid_license:OK #18 /4 bpf_tcp_ca/dctcp_fallback:OK #18 /5 bpf_tcp_ca/rel_setsockopt:OK #18 bpf_tcp_ca:OK #51 /1 dummy_st_ops/dummy_st_ops_attach:OK #51 /2 dummy_st_ops/dummy_init_ret_value:OK #51 /3 dummy_st_ops/dummy_init_ptr_arg:OK #51 /4 dummy_st_ops/dummy_multiple_args:OK #51 dummy_st_ops:OK #55 fentry_fexit:OK #56 fentry_test:OK #57 /1 fexit_bpf2bpf/target_no_callees:OK #57 /2 fexit_bpf2bpf/target_yes_callees:OK #57 /3 fexit_bpf2bpf/func_replace:OK #57 /4 fexit_bpf2bpf/func_replace_verify:OK #57 /5 fexit_bpf2bpf/func_sockmap_update:OK #57 /6 fexit_bpf2bpf/func_replace_return_code:OK #57 /7 fexit_bpf2bpf/func_map_prog_compatibility:OK #57 /8 fexit_bpf2bpf/func_replace_multi:OK #57 /9 fexit_bpf2bpf/fmod_ret_freplace:OK #57 fexit_bpf2bpf:OK #58 fexit_sleep:OK #59 fexit_stress:OK #60 fexit_test:OK #67 get_func_args_test:OK #68 get_func_ip_test:OK #104 modify_return:OK #237 xdp_bpf2bpf:OK bpf_cookie/multi_kprobe_link_api and bpf_cookie/multi_kprobe_attach_api failed due to lack of multi_kprobe on arm64. Signed-off-by: Xu Kuohai <xukuohai@huawei.com> Acked-by: Song Liu <songliubraving@fb.com> Acked-by: KP Singh <kpsingh@kernel.org>
kernel-patches-bot
pushed a commit
that referenced
this pull request
May 23, 2022
Add bpf trampoline support for arm64. Most of the logic is the same as x86. Tested on raspberry pi 4b and qemu with KASLR disabled (avoid long jump), result: #9 /1 bpf_cookie/kprobe:OK #9 /2 bpf_cookie/multi_kprobe_link_api:FAIL #9 /3 bpf_cookie/multi_kprobe_attach_api:FAIL #9 /4 bpf_cookie/uprobe:OK #9 /5 bpf_cookie/tracepoint:OK #9 /6 bpf_cookie/perf_event:OK #9 /7 bpf_cookie/trampoline:OK #9 /8 bpf_cookie/lsm:OK #9 bpf_cookie:FAIL #18 /1 bpf_tcp_ca/dctcp:OK #18 /2 bpf_tcp_ca/cubic:OK #18 /3 bpf_tcp_ca/invalid_license:OK #18 /4 bpf_tcp_ca/dctcp_fallback:OK #18 /5 bpf_tcp_ca/rel_setsockopt:OK #18 bpf_tcp_ca:OK #51 /1 dummy_st_ops/dummy_st_ops_attach:OK #51 /2 dummy_st_ops/dummy_init_ret_value:OK #51 /3 dummy_st_ops/dummy_init_ptr_arg:OK #51 /4 dummy_st_ops/dummy_multiple_args:OK #51 dummy_st_ops:OK #55 fentry_fexit:OK #56 fentry_test:OK #57 /1 fexit_bpf2bpf/target_no_callees:OK #57 /2 fexit_bpf2bpf/target_yes_callees:OK #57 /3 fexit_bpf2bpf/func_replace:OK #57 /4 fexit_bpf2bpf/func_replace_verify:OK #57 /5 fexit_bpf2bpf/func_sockmap_update:OK #57 /6 fexit_bpf2bpf/func_replace_return_code:OK #57 /7 fexit_bpf2bpf/func_map_prog_compatibility:OK #57 /8 fexit_bpf2bpf/func_replace_multi:OK #57 /9 fexit_bpf2bpf/fmod_ret_freplace:OK #57 fexit_bpf2bpf:OK #58 fexit_sleep:OK #59 fexit_stress:OK #60 fexit_test:OK #67 get_func_args_test:OK #68 get_func_ip_test:OK #104 modify_return:OK #237 xdp_bpf2bpf:OK bpf_cookie/multi_kprobe_link_api and bpf_cookie/multi_kprobe_attach_api failed due to lack of multi_kprobe on arm64. Signed-off-by: Xu Kuohai <xukuohai@huawei.com> Acked-by: Song Liu <songliubraving@fb.com> Acked-by: KP Singh <kpsingh@kernel.org>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
Jan 22, 2024
A crash was found when dumping SMC-D connections. It can be reproduced by following steps: - run nginx/wrk test: smc_run nginx smc_run wrk -t 16 -c 1000 -d <duration> -H 'Connection: Close' <URL> - continuously dump SMC-D connections in parallel: watch -n 1 'smcss -D' BUG: kernel NULL pointer dereference, address: 0000000000000030 CPU: 2 PID: 7204 Comm: smcss Kdump: loaded Tainted: G E 6.7.0+ #55 RIP: 0010:__smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag] Call Trace: <TASK> ? __die+0x24/0x70 ? page_fault_oops+0x66/0x150 ? exc_page_fault+0x69/0x140 ? asm_exc_page_fault+0x26/0x30 ? __smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag] ? __kmalloc_node_track_caller+0x35d/0x430 ? __alloc_skb+0x77/0x170 smc_diag_dump_proto+0xd0/0xf0 [smc_diag] smc_diag_dump+0x26/0x60 [smc_diag] netlink_dump+0x19f/0x320 __netlink_dump_start+0x1dc/0x300 smc_diag_handler_dump+0x6a/0x80 [smc_diag] ? __pfx_smc_diag_dump+0x10/0x10 [smc_diag] sock_diag_rcv_msg+0x121/0x140 ? __pfx_sock_diag_rcv_msg+0x10/0x10 netlink_rcv_skb+0x5a/0x110 sock_diag_rcv+0x28/0x40 netlink_unicast+0x22a/0x330 netlink_sendmsg+0x1f8/0x420 __sock_sendmsg+0xb0/0xc0 ____sys_sendmsg+0x24e/0x300 ? copy_msghdr_from_user+0x62/0x80 ___sys_sendmsg+0x7c/0xd0 ? __do_fault+0x34/0x160 ? do_read_fault+0x5f/0x100 ? do_fault+0xb0/0x110 ? __handle_mm_fault+0x2b0/0x6c0 __sys_sendmsg+0x4d/0x80 do_syscall_64+0x69/0x180 entry_SYSCALL_64_after_hwframe+0x6e/0x76 It is possible that the connection is in process of being established when we dump it. Assumed that the connection has been registered in a link group by smc_conn_create() but the rmb_desc has not yet been initialized by smc_buf_create(), thus causing the illegal access to conn->rmb_desc. So fix it by checking before dump. Fixes: 4b1b7d3 ("net/smc: add SMC-D diag support") Signed-off-by: Wen Gu <guwen@linux.alibaba.com> Reviewed-by: Dust Li <dust.li@linux.alibaba.com> Reviewed-by: Wenjia Zhang <wenjia@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
Dec 21, 2024
Right now, the BPF_ADD and BPF_ADD | BPF_FETCH cases are tested twice: #55/u atomic BPF_ADD access through non-pointer OK #55/p atomic BPF_ADD access through non-pointer OK #56/u atomic BPF_ADD | BPF_FETCH access through non-pointer OK #56/p atomic BPF_ADD | BPF_FETCH access through non-pointer OK #57/u atomic BPF_ADD access through non-pointer OK #57/p atomic BPF_ADD access through non-pointer OK #58/u atomic BPF_ADD | BPF_FETCH access through non-pointer OK #58/p atomic BPF_ADD | BPF_FETCH access through non-pointer OK Reviewed-by: Josh Don <joshdon@google.com> Signed-off-by: Peilin Ye <yepeilin@google.com>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
Jan 13, 2025
…_bind returns err The pointer need to be set to NULL, otherwise KASAN complains about use-after-free. Because in mtk_drm_bind, all private's drm are set as follows. private->all_drm_private[i]->drm = drm; And drm will be released by drm_dev_put in case mtk_drm_kms_init returns failure. However, the shutdown path still accesses the previous allocated memory in drm_atomic_helper_shutdown. [ 84.874820] watchdog: watchdog0: watchdog did not stop! [ 86.512054] ================================================================== [ 86.513162] BUG: KASAN: use-after-free in drm_atomic_helper_shutdown+0x33c/0x378 [ 86.514258] Read of size 8 at addr ffff0000d46fc068 by task shutdown/1 [ 86.515213] [ 86.515455] CPU: 1 UID: 0 PID: 1 Comm: shutdown Not tainted 6.13.0-rc1-mtk+gfa1a78e5d24b-dirty #55 [ 86.516752] Hardware name: Unknown Product/Unknown Product, BIOS 2022.10 10/01/2022 [ 86.517960] Call trace: [ 86.518333] show_stack+0x20/0x38 (C) [ 86.518891] dump_stack_lvl+0x90/0xd0 [ 86.519443] print_report+0xf8/0x5b0 [ 86.519985] kasan_report+0xb4/0x100 [ 86.520526] __asan_report_load8_noabort+0x20/0x30 [ 86.521240] drm_atomic_helper_shutdown+0x33c/0x378 [ 86.521966] mtk_drm_shutdown+0x54/0x80 [ 86.522546] platform_shutdown+0x64/0x90 [ 86.523137] device_shutdown+0x260/0x5b8 [ 86.523728] kernel_restart+0x78/0xf0 [ 86.524282] __do_sys_reboot+0x258/0x2f0 [ 86.524871] __arm64_sys_reboot+0x90/0xd8 [ 86.525473] invoke_syscall+0x74/0x268 [ 86.526041] el0_svc_common.constprop.0+0xb0/0x240 [ 86.526751] do_el0_svc+0x4c/0x70 [ 86.527251] el0_svc+0x4c/0xc0 [ 86.527719] el0t_64_sync_handler+0x144/0x168 [ 86.528367] el0t_64_sync+0x198/0x1a0 [ 86.528920] [ 86.529157] The buggy address belongs to the physical page: [ 86.529972] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff0000d46fd4d0 pfn:0x1146fc [ 86.531319] flags: 0xbfffc0000000000(node=0|zone=2|lastcpupid=0xffff) [ 86.532267] raw: 0bfffc0000000000 0000000000000000 dead000000000122 0000000000000000 [ 86.533390] raw: ffff0000d46fd4d0 0000000000000000 00000000ffffffff 0000000000000000 [ 86.534511] page dumped because: kasan: bad access detected [ 86.535323] [ 86.535559] Memory state around the buggy address: [ 86.536265] ffff0000d46fbf00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 86.537314] ffff0000d46fbf80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 86.538363] >ffff0000d46fc000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 86.544733] ^ [ 86.551057] ffff0000d46fc080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 86.557510] ffff0000d46fc100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 86.563928] ================================================================== [ 86.571093] Disabling lock debugging due to kernel taint [ 86.577642] Unable to handle kernel paging request at virtual address e0e9c0920000000b [ 86.581834] KASAN: maybe wild-memory-access in range [0x0752049000000058-0x075204900000005f] ... Fixes: 1ef7ed4 ("drm/mediatek: Modify mediatek-drm for mt8195 multi mmsys support") Signed-off-by: Guoqing Jiang <guoqing.jiang@canonical.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20241223023227.1258112-1-guoqing.jiang@canonical.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
olsajiri
pushed a commit
to olsajiri/bpf
that referenced
this pull request
Mar 5, 2025
Commit <d74169ceb0d2> ("iommu/vt-d: Allocate DMAR fault interrupts
locally") moved the call to enable_drhd_fault_handling() to a code
path that does not hold any lock while traversing the drhd list. Fix
it by ensuring the dmar_global_lock lock is held when traversing the
drhd list.
Without this fix, the following warning is triggered:
=============================
WARNING: suspicious RCU usage
6.14.0-rc3 kernel-patches#55 Not tainted
-----------------------------
drivers/iommu/intel/dmar.c:2046 RCU-list traversed in non-reader section!!
other info that might help us debug this:
rcu_scheduler_active = 1, debug_locks = 1
2 locks held by cpuhp/1/23:
#0: ffffffff84a67c50 (cpu_hotplug_lock){++++}-{0:0}, at: cpuhp_thread_fun+0x87/0x2c0
kernel-patches#1: ffffffff84a6a380 (cpuhp_state-up){+.+.}-{0:0}, at: cpuhp_thread_fun+0x87/0x2c0
stack backtrace:
CPU: 1 UID: 0 PID: 23 Comm: cpuhp/1 Not tainted 6.14.0-rc3 kernel-patches#55
Call Trace:
<TASK>
dump_stack_lvl+0xb7/0xd0
lockdep_rcu_suspicious+0x159/0x1f0
? __pfx_enable_drhd_fault_handling+0x10/0x10
enable_drhd_fault_handling+0x151/0x180
cpuhp_invoke_callback+0x1df/0x990
cpuhp_thread_fun+0x1ea/0x2c0
smpboot_thread_fn+0x1f5/0x2e0
? __pfx_smpboot_thread_fn+0x10/0x10
kthread+0x12a/0x2d0
? __pfx_kthread+0x10/0x10
ret_from_fork+0x4a/0x60
? __pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1a/0x30
</TASK>
Holding the lock in enable_drhd_fault_handling() triggers a lockdep splat
about a possible deadlock between dmar_global_lock and cpu_hotplug_lock.
This is avoided by not holding dmar_global_lock when calling
iommu_device_register(), which initiates the device probe process.
Fixes: d74169c ("iommu/vt-d: Allocate DMAR fault interrupts locally")
Reported-and-tested-by: Ido Schimmel <idosch@nvidia.com>
Closes: https://lore.kernel.org/linux-iommu/Zx9OwdLIc_VoQ0-a@shredder.mtl.com/
Tested-by: Breno Leitao <leitao@debian.org>
Cc: stable@vger.kernel.org
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Link: https://lore.kernel.org/r/20250218022422.2315082-1-baolu.lu@linux.intel.com
Tested-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
Apr 4, 2025
Struct with embedded VLA... memcpy: detected field-spanning write (size 8) of single field "&gc->r.e" at fs/bcachefs/ec.c:465 (size 3) WARNING: CPU: 1 PID: 936 at fs/bcachefs/ec.c:465 bch2_trigger_stripe+0x706/0x730 Modules linked in: CPU: 1 UID: 0 PID: 936 Comm: mount.bcachefs Not tainted 6.14.0-rc6-ktest-00236-gefb0b5c62dbc #55 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:bch2_trigger_stripe+0x706/0x730 Code: b4 00 01 b9 03 00 00 00 48 89 fb 48 c7 c7 33 54 da 81 48 89 d6 49 89 d6 48 c7 c2 c3 36 db 81 e8 60 54 c5 ff 48 89 df 4c 89 f2 <0f> 0b e9 5c fd ff ff e8 fe 5e 4e 00 bf 10 00 00 00 48 c7 c6 ff ff RSP: 0018:ffff88817081f680 EFLAGS: 00010246 RAX: f8fe7dd1c56b5600 RBX: ffff888101265368 RCX: 0000000000000027 RDX: 0000000000000008 RSI: 00000000fffbffff RDI: ffff888101265368 RBP: 0000000000000000 R08: 000000000003ffff R09: ffff88817f1fe000 R10: 00000000000bfffd R11: 0000000000000004 R12: ffff8881012652c0 R13: 0000000000000000 R14: 0000000000000008 R15: ffff88817081f6c9 FS: 00007fc428bc7c80(0000) GS:ffff888179280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffd3ee4a038 CR3: 000000010a9bc000 CR4: 0000000000750eb0 PKRU: 55555554 Call Trace: <TASK> ? __warn+0xce/0x1b0 ? bch2_trigger_stripe+0x706/0x730 ? report_bug+0x11b/0x1a0 ? bch2_trigger_stripe+0x706/0x730 ? handle_bug+0x5e/0x90 ? exc_invalid_op+0x1a/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? bch2_trigger_stripe+0x706/0x730 bch2_gc_mark_key+0x2cf/0x430 bch2_check_allocations+0x1a64/0x1ed0 ? vsnprintf+0x1ad/0x420 ? bch2_check_allocations+0x191f/0x1ed0 bch2_run_recovery_passes+0x13b/0x2b0 bch2_fs_recovery+0x9b7/0x1290 ? __bch2_print+0xb2/0xf0 ? bch2_printbuf_exit+0x1e/0x30 ? print_mount_opts+0x153/0x180 bch2_fs_start+0x274/0x3b0 bch2_fs_get_tree+0x516/0x6e0 vfs_get_tree+0x21/0xa0 do_new_mount+0x153/0x350 __x64_sys_mount+0x16c/0x1f0 do_syscall_64+0x6c/0x140 ? arch_exit_to_user_mode_prepare+0x9/0x40 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
kuba-moo
pushed a commit
to linux-netdev/testing-bpf-ci
that referenced
this pull request
Aug 14, 2025
…l_fop_write A potential deadlock due to A-B/B-A deadlock exists between the NFC core and the RFKill subsystem, involving the NFC device lock and the rfkill_global_mutex. This issue is particularly visible on PREEMPT_RT kernels, which can report the following warning: | rtmutex deadlock detected | WARNING: CPU: 0 PID: 22729 at kernel/locking/rtmutex.c:1674 rt_mutex_handle_deadlock+0x68/0xec kernel/locking/rtmutex.c:-1 | Modules linked in: | CPU: 0 UID: 0 PID: 22729 Comm: syz.7.2187 Kdump: loaded Not tainted 6.17.0-rc1-00001-g1149a5db27c8-dirty kernel-patches#55 PREEMPT_RT | Hardware name: QEMU KVM Virtual Machine, BIOS 2025.02-8ubuntu1 06/11/2025 | pstate: 63400005 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) | pc : rt_mutex_handle_deadlock+0x68/0xec kernel/locking/rtmutex.c:-1 | lr : rt_mutex_handle_deadlock+0x40/0xec kernel/locking/rtmutex.c:1674 | sp : ffff8000967c7720 | x29: ffff8000967c7720 x28: 1fffe0001946d182 x27: dfff800000000000 | x26: 0000000000000001 x25: 0000000000000003 x24: 1fffe0001946d00b | x23: 1fffe0001946d182 x22: ffff80008aec8940 x21: dfff800000000000 | x20: ffff0000ca368058 x19: ffff0000ca368c10 x18: ffff80008af6b6e0 | x17: 1fffe000590b8088 x16: ffff80008046cc08 x15: 0000000000000001 | x14: 1fffe000590ba990 x13: 0000000000000000 x12: 0000000000000000 | x11: ffff6000590ba991 x10: 0000000000000002 x9 : 0fe446e029bcfe00 | x8 : 0000000000000000 x7 : 0000000000000000 x6 : 000000000000003f | x5 : 0000000000000001 x4 : 0000000000001000 x3 : ffff800080503efc | x2 : 0000000000000001 x1 : 0000000000000001 x0 : 0000000000000001 | Call trace: | rt_mutex_handle_deadlock+0x68/0xec kernel/locking/rtmutex.c:-1 (P) | __rt_mutex_slowlock+0x1cc/0x480 kernel/locking/rtmutex.c:1734 | __rt_mutex_slowlock_locked kernel/locking/rtmutex.c:1760 [inline] | rt_mutex_slowlock+0x140/0x21c kernel/locking/rtmutex.c:1800 | __rt_mutex_lock kernel/locking/rtmutex.c:1815 [inline] | __mutex_lock_common kernel/locking/rtmutex_api.c:536 [inline] | mutex_lock+0xf0/0x10c kernel/locking/rtmutex_api.c:603 | device_lock include/linux/device.h:911 [inline] | nfc_dev_down net/nfc/core.c:143 [inline] | nfc_rfkill_set_block+0x48/0x2a4 net/nfc/core.c:179 | rfkill_set_block+0x184/0x364 net/rfkill/core.c:346 | rfkill_fop_write+0x4dc/0x624 net/rfkill/core.c:1301 | vfs_write+0x2b8/0xa30 fs/read_write.c:684 | ksys_write+0x120/0x210 fs/read_write.c:738 | __do_sys_write fs/read_write.c:749 [inline] | __se_sys_write fs/read_write.c:746 [inline] | __arm64_sys_write+0x7c/0x90 fs/read_write.c:746 | __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] | invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 | el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 | do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 | el0_svc+0x40/0x140 arch/arm64/kernel/entry-common.c:879 | el0t_64_sync_handler+0x84/0x12c arch/arm64/kernel/entry-common.c:898 | el0t_64_sync+0x1ac/0x1b0 arch/arm64/kernel/entry.S:596 The scenario is as follows: Task A (rfkill_fop_write): 1. Acquires rfkill_global_mutex. 2. Iterates devices and calls rfkill_set_block() -> nfc_rfkill_set_block() -> nfc_dev_down(). 3. Tries to acquire NFC device_lock. Task B (nfc_unregister_device): 1. Acquires NFC device_lock. 2. Calls rfkill_unregister(). 3. Tries to acquire rfkill_global_mutex. Task A waits for the device_lock held by Task B, while Task B waits for the rfkill_global_mutex held by Task A. To fix this, move the calls to rfkill_unregister() and rfkill_destroy() outside the device_lock critical section in nfc_unregister_device(). We ensure this is safe by first acquiring the device_lock, setting the shutting_down flag (which prevents races with nfc_dev_down()), stashing the rfkill pointer in a local variable, nullifying the pointer in the nfc_dev structure, and then releasing the device_lock before calling the rfkill unregister functions. This breaks the lock inversion. Signed-off-by: Yunseong Kim <ysk@kzalloc.com> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing-bpf-ci
that referenced
this pull request
Aug 14, 2025
…l_fop_write A potential deadlock due to A-B/B-A deadlock exists between the NFC core and the RFKill subsystem, involving the NFC device lock and the rfkill_global_mutex. This issue is particularly visible on PREEMPT_RT kernels, which can report the following warning: | rtmutex deadlock detected | WARNING: CPU: 0 PID: 22729 at kernel/locking/rtmutex.c:1674 rt_mutex_handle_deadlock+0x68/0xec kernel/locking/rtmutex.c:-1 | Modules linked in: | CPU: 0 UID: 0 PID: 22729 Comm: syz.7.2187 Kdump: loaded Not tainted 6.17.0-rc1-00001-g1149a5db27c8-dirty kernel-patches#55 PREEMPT_RT | Hardware name: QEMU KVM Virtual Machine, BIOS 2025.02-8ubuntu1 06/11/2025 | pstate: 63400005 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) | pc : rt_mutex_handle_deadlock+0x68/0xec kernel/locking/rtmutex.c:-1 | lr : rt_mutex_handle_deadlock+0x40/0xec kernel/locking/rtmutex.c:1674 | sp : ffff8000967c7720 | x29: ffff8000967c7720 x28: 1fffe0001946d182 x27: dfff800000000000 | x26: 0000000000000001 x25: 0000000000000003 x24: 1fffe0001946d00b | x23: 1fffe0001946d182 x22: ffff80008aec8940 x21: dfff800000000000 | x20: ffff0000ca368058 x19: ffff0000ca368c10 x18: ffff80008af6b6e0 | x17: 1fffe000590b8088 x16: ffff80008046cc08 x15: 0000000000000001 | x14: 1fffe000590ba990 x13: 0000000000000000 x12: 0000000000000000 | x11: ffff6000590ba991 x10: 0000000000000002 x9 : 0fe446e029bcfe00 | x8 : 0000000000000000 x7 : 0000000000000000 x6 : 000000000000003f | x5 : 0000000000000001 x4 : 0000000000001000 x3 : ffff800080503efc | x2 : 0000000000000001 x1 : 0000000000000001 x0 : 0000000000000001 | Call trace: | rt_mutex_handle_deadlock+0x68/0xec kernel/locking/rtmutex.c:-1 (P) | __rt_mutex_slowlock+0x1cc/0x480 kernel/locking/rtmutex.c:1734 | __rt_mutex_slowlock_locked kernel/locking/rtmutex.c:1760 [inline] | rt_mutex_slowlock+0x140/0x21c kernel/locking/rtmutex.c:1800 | __rt_mutex_lock kernel/locking/rtmutex.c:1815 [inline] | __mutex_lock_common kernel/locking/rtmutex_api.c:536 [inline] | mutex_lock+0xf0/0x10c kernel/locking/rtmutex_api.c:603 | device_lock include/linux/device.h:911 [inline] | nfc_dev_down net/nfc/core.c:143 [inline] | nfc_rfkill_set_block+0x48/0x2a4 net/nfc/core.c:179 | rfkill_set_block+0x184/0x364 net/rfkill/core.c:346 | rfkill_fop_write+0x4dc/0x624 net/rfkill/core.c:1301 | vfs_write+0x2b8/0xa30 fs/read_write.c:684 | ksys_write+0x120/0x210 fs/read_write.c:738 | __do_sys_write fs/read_write.c:749 [inline] | __se_sys_write fs/read_write.c:746 [inline] | __arm64_sys_write+0x7c/0x90 fs/read_write.c:746 | __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] | invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 | el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 | do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 | el0_svc+0x40/0x140 arch/arm64/kernel/entry-common.c:879 | el0t_64_sync_handler+0x84/0x12c arch/arm64/kernel/entry-common.c:898 | el0t_64_sync+0x1ac/0x1b0 arch/arm64/kernel/entry.S:596 The scenario is as follows: Task A (rfkill_fop_write): 1. Acquires rfkill_global_mutex. 2. Iterates devices and calls rfkill_set_block() -> nfc_rfkill_set_block() -> nfc_dev_down(). 3. Tries to acquire NFC device_lock. Task B (nfc_unregister_device): 1. Acquires NFC device_lock. 2. Calls rfkill_unregister(). 3. Tries to acquire rfkill_global_mutex. Task A waits for the device_lock held by Task B, while Task B waits for the rfkill_global_mutex held by Task A. To fix this, move the calls to rfkill_unregister() and rfkill_destroy() outside the device_lock critical section in nfc_unregister_device(). We ensure this is safe by first acquiring the device_lock, setting the shutting_down flag (which prevents races with nfc_dev_down()), stashing the rfkill pointer in a local variable, nullifying the pointer in the nfc_dev structure, and then releasing the device_lock before calling the rfkill unregister functions. This breaks the lock inversion. Signed-off-by: Yunseong Kim <ysk@kzalloc.com> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing-bpf-ci
that referenced
this pull request
Aug 15, 2025
…l_fop_write A potential deadlock due to A-B/B-A deadlock exists between the NFC core and the RFKill subsystem, involving the NFC device lock and the rfkill_global_mutex. This issue is particularly visible on PREEMPT_RT kernels, which can report the following warning: | rtmutex deadlock detected | WARNING: CPU: 0 PID: 22729 at kernel/locking/rtmutex.c:1674 rt_mutex_handle_deadlock+0x68/0xec kernel/locking/rtmutex.c:-1 | Modules linked in: | CPU: 0 UID: 0 PID: 22729 Comm: syz.7.2187 Kdump: loaded Not tainted 6.17.0-rc1-00001-g1149a5db27c8-dirty kernel-patches#55 PREEMPT_RT | Hardware name: QEMU KVM Virtual Machine, BIOS 2025.02-8ubuntu1 06/11/2025 | pstate: 63400005 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) | pc : rt_mutex_handle_deadlock+0x68/0xec kernel/locking/rtmutex.c:-1 | lr : rt_mutex_handle_deadlock+0x40/0xec kernel/locking/rtmutex.c:1674 | sp : ffff8000967c7720 | x29: ffff8000967c7720 x28: 1fffe0001946d182 x27: dfff800000000000 | x26: 0000000000000001 x25: 0000000000000003 x24: 1fffe0001946d00b | x23: 1fffe0001946d182 x22: ffff80008aec8940 x21: dfff800000000000 | x20: ffff0000ca368058 x19: ffff0000ca368c10 x18: ffff80008af6b6e0 | x17: 1fffe000590b8088 x16: ffff80008046cc08 x15: 0000000000000001 | x14: 1fffe000590ba990 x13: 0000000000000000 x12: 0000000000000000 | x11: ffff6000590ba991 x10: 0000000000000002 x9 : 0fe446e029bcfe00 | x8 : 0000000000000000 x7 : 0000000000000000 x6 : 000000000000003f | x5 : 0000000000000001 x4 : 0000000000001000 x3 : ffff800080503efc | x2 : 0000000000000001 x1 : 0000000000000001 x0 : 0000000000000001 | Call trace: | rt_mutex_handle_deadlock+0x68/0xec kernel/locking/rtmutex.c:-1 (P) | __rt_mutex_slowlock+0x1cc/0x480 kernel/locking/rtmutex.c:1734 | __rt_mutex_slowlock_locked kernel/locking/rtmutex.c:1760 [inline] | rt_mutex_slowlock+0x140/0x21c kernel/locking/rtmutex.c:1800 | __rt_mutex_lock kernel/locking/rtmutex.c:1815 [inline] | __mutex_lock_common kernel/locking/rtmutex_api.c:536 [inline] | mutex_lock+0xf0/0x10c kernel/locking/rtmutex_api.c:603 | device_lock include/linux/device.h:911 [inline] | nfc_dev_down net/nfc/core.c:143 [inline] | nfc_rfkill_set_block+0x48/0x2a4 net/nfc/core.c:179 | rfkill_set_block+0x184/0x364 net/rfkill/core.c:346 | rfkill_fop_write+0x4dc/0x624 net/rfkill/core.c:1301 | vfs_write+0x2b8/0xa30 fs/read_write.c:684 | ksys_write+0x120/0x210 fs/read_write.c:738 | __do_sys_write fs/read_write.c:749 [inline] | __se_sys_write fs/read_write.c:746 [inline] | __arm64_sys_write+0x7c/0x90 fs/read_write.c:746 | __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] | invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 | el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 | do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 | el0_svc+0x40/0x140 arch/arm64/kernel/entry-common.c:879 | el0t_64_sync_handler+0x84/0x12c arch/arm64/kernel/entry-common.c:898 | el0t_64_sync+0x1ac/0x1b0 arch/arm64/kernel/entry.S:596 The scenario is as follows: Task A (rfkill_fop_write): 1. Acquires rfkill_global_mutex. 2. Iterates devices and calls rfkill_set_block() -> nfc_rfkill_set_block() -> nfc_dev_down(). 3. Tries to acquire NFC device_lock. Task B (nfc_unregister_device): 1. Acquires NFC device_lock. 2. Calls rfkill_unregister(). 3. Tries to acquire rfkill_global_mutex. Task A waits for the device_lock held by Task B, while Task B waits for the rfkill_global_mutex held by Task A. To fix this, move the calls to rfkill_unregister() and rfkill_destroy() outside the device_lock critical section in nfc_unregister_device(). We ensure this is safe by first acquiring the device_lock, setting the shutting_down flag (which prevents races with nfc_dev_down()), stashing the rfkill pointer in a local variable, nullifying the pointer in the nfc_dev structure, and then releasing the device_lock before calling the rfkill unregister functions. This breaks the lock inversion. Signed-off-by: Yunseong Kim <ysk@kzalloc.com> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing-bpf-ci
that referenced
this pull request
Aug 15, 2025
…l_fop_write A potential deadlock due to A-B/B-A deadlock exists between the NFC core and the RFKill subsystem, involving the NFC device lock and the rfkill_global_mutex. This issue is particularly visible on PREEMPT_RT kernels, which can report the following warning: | rtmutex deadlock detected | WARNING: CPU: 0 PID: 22729 at kernel/locking/rtmutex.c:1674 rt_mutex_handle_deadlock+0x68/0xec kernel/locking/rtmutex.c:-1 | Modules linked in: | CPU: 0 UID: 0 PID: 22729 Comm: syz.7.2187 Kdump: loaded Not tainted 6.17.0-rc1-00001-g1149a5db27c8-dirty kernel-patches#55 PREEMPT_RT | Hardware name: QEMU KVM Virtual Machine, BIOS 2025.02-8ubuntu1 06/11/2025 | pstate: 63400005 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) | pc : rt_mutex_handle_deadlock+0x68/0xec kernel/locking/rtmutex.c:-1 | lr : rt_mutex_handle_deadlock+0x40/0xec kernel/locking/rtmutex.c:1674 | sp : ffff8000967c7720 | x29: ffff8000967c7720 x28: 1fffe0001946d182 x27: dfff800000000000 | x26: 0000000000000001 x25: 0000000000000003 x24: 1fffe0001946d00b | x23: 1fffe0001946d182 x22: ffff80008aec8940 x21: dfff800000000000 | x20: ffff0000ca368058 x19: ffff0000ca368c10 x18: ffff80008af6b6e0 | x17: 1fffe000590b8088 x16: ffff80008046cc08 x15: 0000000000000001 | x14: 1fffe000590ba990 x13: 0000000000000000 x12: 0000000000000000 | x11: ffff6000590ba991 x10: 0000000000000002 x9 : 0fe446e029bcfe00 | x8 : 0000000000000000 x7 : 0000000000000000 x6 : 000000000000003f | x5 : 0000000000000001 x4 : 0000000000001000 x3 : ffff800080503efc | x2 : 0000000000000001 x1 : 0000000000000001 x0 : 0000000000000001 | Call trace: | rt_mutex_handle_deadlock+0x68/0xec kernel/locking/rtmutex.c:-1 (P) | __rt_mutex_slowlock+0x1cc/0x480 kernel/locking/rtmutex.c:1734 | __rt_mutex_slowlock_locked kernel/locking/rtmutex.c:1760 [inline] | rt_mutex_slowlock+0x140/0x21c kernel/locking/rtmutex.c:1800 | __rt_mutex_lock kernel/locking/rtmutex.c:1815 [inline] | __mutex_lock_common kernel/locking/rtmutex_api.c:536 [inline] | mutex_lock+0xf0/0x10c kernel/locking/rtmutex_api.c:603 | device_lock include/linux/device.h:911 [inline] | nfc_dev_down net/nfc/core.c:143 [inline] | nfc_rfkill_set_block+0x48/0x2a4 net/nfc/core.c:179 | rfkill_set_block+0x184/0x364 net/rfkill/core.c:346 | rfkill_fop_write+0x4dc/0x624 net/rfkill/core.c:1301 | vfs_write+0x2b8/0xa30 fs/read_write.c:684 | ksys_write+0x120/0x210 fs/read_write.c:738 | __do_sys_write fs/read_write.c:749 [inline] | __se_sys_write fs/read_write.c:746 [inline] | __arm64_sys_write+0x7c/0x90 fs/read_write.c:746 | __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] | invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 | el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 | do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 | el0_svc+0x40/0x140 arch/arm64/kernel/entry-common.c:879 | el0t_64_sync_handler+0x84/0x12c arch/arm64/kernel/entry-common.c:898 | el0t_64_sync+0x1ac/0x1b0 arch/arm64/kernel/entry.S:596 The scenario is as follows: Task A (rfkill_fop_write): 1. Acquires rfkill_global_mutex. 2. Iterates devices and calls rfkill_set_block() -> nfc_rfkill_set_block() -> nfc_dev_down(). 3. Tries to acquire NFC device_lock. Task B (nfc_unregister_device): 1. Acquires NFC device_lock. 2. Calls rfkill_unregister(). 3. Tries to acquire rfkill_global_mutex. Task A waits for the device_lock held by Task B, while Task B waits for the rfkill_global_mutex held by Task A. To fix this, move the calls to rfkill_unregister() and rfkill_destroy() outside the device_lock critical section in nfc_unregister_device(). We ensure this is safe by first acquiring the device_lock, setting the shutting_down flag (which prevents races with nfc_dev_down()), stashing the rfkill pointer in a local variable, nullifying the pointer in the nfc_dev structure, and then releasing the device_lock before calling the rfkill unregister functions. This breaks the lock inversion. Signed-off-by: Yunseong Kim <ysk@kzalloc.com> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing-bpf-ci
that referenced
this pull request
Aug 15, 2025
…l_fop_write A potential deadlock due to A-B/B-A deadlock exists between the NFC core and the RFKill subsystem, involving the NFC device lock and the rfkill_global_mutex. This issue is particularly visible on PREEMPT_RT kernels, which can report the following warning: | rtmutex deadlock detected | WARNING: CPU: 0 PID: 22729 at kernel/locking/rtmutex.c:1674 rt_mutex_handle_deadlock+0x68/0xec kernel/locking/rtmutex.c:-1 | Modules linked in: | CPU: 0 UID: 0 PID: 22729 Comm: syz.7.2187 Kdump: loaded Not tainted 6.17.0-rc1-00001-g1149a5db27c8-dirty kernel-patches#55 PREEMPT_RT | Hardware name: QEMU KVM Virtual Machine, BIOS 2025.02-8ubuntu1 06/11/2025 | pstate: 63400005 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) | pc : rt_mutex_handle_deadlock+0x68/0xec kernel/locking/rtmutex.c:-1 | lr : rt_mutex_handle_deadlock+0x40/0xec kernel/locking/rtmutex.c:1674 | sp : ffff8000967c7720 | x29: ffff8000967c7720 x28: 1fffe0001946d182 x27: dfff800000000000 | x26: 0000000000000001 x25: 0000000000000003 x24: 1fffe0001946d00b | x23: 1fffe0001946d182 x22: ffff80008aec8940 x21: dfff800000000000 | x20: ffff0000ca368058 x19: ffff0000ca368c10 x18: ffff80008af6b6e0 | x17: 1fffe000590b8088 x16: ffff80008046cc08 x15: 0000000000000001 | x14: 1fffe000590ba990 x13: 0000000000000000 x12: 0000000000000000 | x11: ffff6000590ba991 x10: 0000000000000002 x9 : 0fe446e029bcfe00 | x8 : 0000000000000000 x7 : 0000000000000000 x6 : 000000000000003f | x5 : 0000000000000001 x4 : 0000000000001000 x3 : ffff800080503efc | x2 : 0000000000000001 x1 : 0000000000000001 x0 : 0000000000000001 | Call trace: | rt_mutex_handle_deadlock+0x68/0xec kernel/locking/rtmutex.c:-1 (P) | __rt_mutex_slowlock+0x1cc/0x480 kernel/locking/rtmutex.c:1734 | __rt_mutex_slowlock_locked kernel/locking/rtmutex.c:1760 [inline] | rt_mutex_slowlock+0x140/0x21c kernel/locking/rtmutex.c:1800 | __rt_mutex_lock kernel/locking/rtmutex.c:1815 [inline] | __mutex_lock_common kernel/locking/rtmutex_api.c:536 [inline] | mutex_lock+0xf0/0x10c kernel/locking/rtmutex_api.c:603 | device_lock include/linux/device.h:911 [inline] | nfc_dev_down net/nfc/core.c:143 [inline] | nfc_rfkill_set_block+0x48/0x2a4 net/nfc/core.c:179 | rfkill_set_block+0x184/0x364 net/rfkill/core.c:346 | rfkill_fop_write+0x4dc/0x624 net/rfkill/core.c:1301 | vfs_write+0x2b8/0xa30 fs/read_write.c:684 | ksys_write+0x120/0x210 fs/read_write.c:738 | __do_sys_write fs/read_write.c:749 [inline] | __se_sys_write fs/read_write.c:746 [inline] | __arm64_sys_write+0x7c/0x90 fs/read_write.c:746 | __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] | invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 | el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 | do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 | el0_svc+0x40/0x140 arch/arm64/kernel/entry-common.c:879 | el0t_64_sync_handler+0x84/0x12c arch/arm64/kernel/entry-common.c:898 | el0t_64_sync+0x1ac/0x1b0 arch/arm64/kernel/entry.S:596 The scenario is as follows: Task A (rfkill_fop_write): 1. Acquires rfkill_global_mutex. 2. Iterates devices and calls rfkill_set_block() -> nfc_rfkill_set_block() -> nfc_dev_down(). 3. Tries to acquire NFC device_lock. Task B (nfc_unregister_device): 1. Acquires NFC device_lock. 2. Calls rfkill_unregister(). 3. Tries to acquire rfkill_global_mutex. Task A waits for the device_lock held by Task B, while Task B waits for the rfkill_global_mutex held by Task A. To fix this, move the calls to rfkill_unregister() and rfkill_destroy() outside the device_lock critical section in nfc_unregister_device(). We ensure this is safe by first acquiring the device_lock, setting the shutting_down flag (which prevents races with nfc_dev_down()), stashing the rfkill pointer in a local variable, nullifying the pointer in the nfc_dev structure, and then releasing the device_lock before calling the rfkill unregister functions. This breaks the lock inversion. Signed-off-by: Yunseong Kim <ysk@kzalloc.com> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing-bpf-ci
that referenced
this pull request
Aug 15, 2025
…l_fop_write A potential deadlock due to A-B/B-A deadlock exists between the NFC core and the RFKill subsystem, involving the NFC device lock and the rfkill_global_mutex. This issue is particularly visible on PREEMPT_RT kernels, which can report the following warning: | rtmutex deadlock detected | WARNING: CPU: 0 PID: 22729 at kernel/locking/rtmutex.c:1674 rt_mutex_handle_deadlock+0x68/0xec kernel/locking/rtmutex.c:-1 | Modules linked in: | CPU: 0 UID: 0 PID: 22729 Comm: syz.7.2187 Kdump: loaded Not tainted 6.17.0-rc1-00001-g1149a5db27c8-dirty kernel-patches#55 PREEMPT_RT | Hardware name: QEMU KVM Virtual Machine, BIOS 2025.02-8ubuntu1 06/11/2025 | pstate: 63400005 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) | pc : rt_mutex_handle_deadlock+0x68/0xec kernel/locking/rtmutex.c:-1 | lr : rt_mutex_handle_deadlock+0x40/0xec kernel/locking/rtmutex.c:1674 | sp : ffff8000967c7720 | x29: ffff8000967c7720 x28: 1fffe0001946d182 x27: dfff800000000000 | x26: 0000000000000001 x25: 0000000000000003 x24: 1fffe0001946d00b | x23: 1fffe0001946d182 x22: ffff80008aec8940 x21: dfff800000000000 | x20: ffff0000ca368058 x19: ffff0000ca368c10 x18: ffff80008af6b6e0 | x17: 1fffe000590b8088 x16: ffff80008046cc08 x15: 0000000000000001 | x14: 1fffe000590ba990 x13: 0000000000000000 x12: 0000000000000000 | x11: ffff6000590ba991 x10: 0000000000000002 x9 : 0fe446e029bcfe00 | x8 : 0000000000000000 x7 : 0000000000000000 x6 : 000000000000003f | x5 : 0000000000000001 x4 : 0000000000001000 x3 : ffff800080503efc | x2 : 0000000000000001 x1 : 0000000000000001 x0 : 0000000000000001 | Call trace: | rt_mutex_handle_deadlock+0x68/0xec kernel/locking/rtmutex.c:-1 (P) | __rt_mutex_slowlock+0x1cc/0x480 kernel/locking/rtmutex.c:1734 | __rt_mutex_slowlock_locked kernel/locking/rtmutex.c:1760 [inline] | rt_mutex_slowlock+0x140/0x21c kernel/locking/rtmutex.c:1800 | __rt_mutex_lock kernel/locking/rtmutex.c:1815 [inline] | __mutex_lock_common kernel/locking/rtmutex_api.c:536 [inline] | mutex_lock+0xf0/0x10c kernel/locking/rtmutex_api.c:603 | device_lock include/linux/device.h:911 [inline] | nfc_dev_down net/nfc/core.c:143 [inline] | nfc_rfkill_set_block+0x48/0x2a4 net/nfc/core.c:179 | rfkill_set_block+0x184/0x364 net/rfkill/core.c:346 | rfkill_fop_write+0x4dc/0x624 net/rfkill/core.c:1301 | vfs_write+0x2b8/0xa30 fs/read_write.c:684 | ksys_write+0x120/0x210 fs/read_write.c:738 | __do_sys_write fs/read_write.c:749 [inline] | __se_sys_write fs/read_write.c:746 [inline] | __arm64_sys_write+0x7c/0x90 fs/read_write.c:746 | __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] | invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 | el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 | do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 | el0_svc+0x40/0x140 arch/arm64/kernel/entry-common.c:879 | el0t_64_sync_handler+0x84/0x12c arch/arm64/kernel/entry-common.c:898 | el0t_64_sync+0x1ac/0x1b0 arch/arm64/kernel/entry.S:596 The scenario is as follows: Task A (rfkill_fop_write): 1. Acquires rfkill_global_mutex. 2. Iterates devices and calls rfkill_set_block() -> nfc_rfkill_set_block() -> nfc_dev_down(). 3. Tries to acquire NFC device_lock. Task B (nfc_unregister_device): 1. Acquires NFC device_lock. 2. Calls rfkill_unregister(). 3. Tries to acquire rfkill_global_mutex. Task A waits for the device_lock held by Task B, while Task B waits for the rfkill_global_mutex held by Task A. To fix this, move the calls to rfkill_unregister() and rfkill_destroy() outside the device_lock critical section in nfc_unregister_device(). We ensure this is safe by first acquiring the device_lock, setting the shutting_down flag (which prevents races with nfc_dev_down()), stashing the rfkill pointer in a local variable, nullifying the pointer in the nfc_dev structure, and then releasing the device_lock before calling the rfkill unregister functions. This breaks the lock inversion. Signed-off-by: Yunseong Kim <ysk@kzalloc.com> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing-bpf-ci
that referenced
this pull request
Aug 15, 2025
…l_fop_write A potential deadlock due to A-B/B-A deadlock exists between the NFC core and the RFKill subsystem, involving the NFC device lock and the rfkill_global_mutex. This issue is particularly visible on PREEMPT_RT kernels, which can report the following warning: | rtmutex deadlock detected | WARNING: CPU: 0 PID: 22729 at kernel/locking/rtmutex.c:1674 rt_mutex_handle_deadlock+0x68/0xec kernel/locking/rtmutex.c:-1 | Modules linked in: | CPU: 0 UID: 0 PID: 22729 Comm: syz.7.2187 Kdump: loaded Not tainted 6.17.0-rc1-00001-g1149a5db27c8-dirty kernel-patches#55 PREEMPT_RT | Hardware name: QEMU KVM Virtual Machine, BIOS 2025.02-8ubuntu1 06/11/2025 | pstate: 63400005 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) | pc : rt_mutex_handle_deadlock+0x68/0xec kernel/locking/rtmutex.c:-1 | lr : rt_mutex_handle_deadlock+0x40/0xec kernel/locking/rtmutex.c:1674 | sp : ffff8000967c7720 | x29: ffff8000967c7720 x28: 1fffe0001946d182 x27: dfff800000000000 | x26: 0000000000000001 x25: 0000000000000003 x24: 1fffe0001946d00b | x23: 1fffe0001946d182 x22: ffff80008aec8940 x21: dfff800000000000 | x20: ffff0000ca368058 x19: ffff0000ca368c10 x18: ffff80008af6b6e0 | x17: 1fffe000590b8088 x16: ffff80008046cc08 x15: 0000000000000001 | x14: 1fffe000590ba990 x13: 0000000000000000 x12: 0000000000000000 | x11: ffff6000590ba991 x10: 0000000000000002 x9 : 0fe446e029bcfe00 | x8 : 0000000000000000 x7 : 0000000000000000 x6 : 000000000000003f | x5 : 0000000000000001 x4 : 0000000000001000 x3 : ffff800080503efc | x2 : 0000000000000001 x1 : 0000000000000001 x0 : 0000000000000001 | Call trace: | rt_mutex_handle_deadlock+0x68/0xec kernel/locking/rtmutex.c:-1 (P) | __rt_mutex_slowlock+0x1cc/0x480 kernel/locking/rtmutex.c:1734 | __rt_mutex_slowlock_locked kernel/locking/rtmutex.c:1760 [inline] | rt_mutex_slowlock+0x140/0x21c kernel/locking/rtmutex.c:1800 | __rt_mutex_lock kernel/locking/rtmutex.c:1815 [inline] | __mutex_lock_common kernel/locking/rtmutex_api.c:536 [inline] | mutex_lock+0xf0/0x10c kernel/locking/rtmutex_api.c:603 | device_lock include/linux/device.h:911 [inline] | nfc_dev_down net/nfc/core.c:143 [inline] | nfc_rfkill_set_block+0x48/0x2a4 net/nfc/core.c:179 | rfkill_set_block+0x184/0x364 net/rfkill/core.c:346 | rfkill_fop_write+0x4dc/0x624 net/rfkill/core.c:1301 | vfs_write+0x2b8/0xa30 fs/read_write.c:684 | ksys_write+0x120/0x210 fs/read_write.c:738 | __do_sys_write fs/read_write.c:749 [inline] | __se_sys_write fs/read_write.c:746 [inline] | __arm64_sys_write+0x7c/0x90 fs/read_write.c:746 | __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] | invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 | el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 | do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 | el0_svc+0x40/0x140 arch/arm64/kernel/entry-common.c:879 | el0t_64_sync_handler+0x84/0x12c arch/arm64/kernel/entry-common.c:898 | el0t_64_sync+0x1ac/0x1b0 arch/arm64/kernel/entry.S:596 The scenario is as follows: Task A (rfkill_fop_write): 1. Acquires rfkill_global_mutex. 2. Iterates devices and calls rfkill_set_block() -> nfc_rfkill_set_block() -> nfc_dev_down(). 3. Tries to acquire NFC device_lock. Task B (nfc_unregister_device): 1. Acquires NFC device_lock. 2. Calls rfkill_unregister(). 3. Tries to acquire rfkill_global_mutex. Task A waits for the device_lock held by Task B, while Task B waits for the rfkill_global_mutex held by Task A. To fix this, move the calls to rfkill_unregister() and rfkill_destroy() outside the device_lock critical section in nfc_unregister_device(). We ensure this is safe by first acquiring the device_lock, setting the shutting_down flag (which prevents races with nfc_dev_down()), stashing the rfkill pointer in a local variable, nullifying the pointer in the nfc_dev structure, and then releasing the device_lock before calling the rfkill unregister functions. This breaks the lock inversion. Signed-off-by: Yunseong Kim <ysk@kzalloc.com> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing-bpf-ci
that referenced
this pull request
Aug 15, 2025
…l_fop_write A potential deadlock due to A-B/B-A deadlock exists between the NFC core and the RFKill subsystem, involving the NFC device lock and the rfkill_global_mutex. This issue is particularly visible on PREEMPT_RT kernels, which can report the following warning: | rtmutex deadlock detected | WARNING: CPU: 0 PID: 22729 at kernel/locking/rtmutex.c:1674 rt_mutex_handle_deadlock+0x68/0xec kernel/locking/rtmutex.c:-1 | Modules linked in: | CPU: 0 UID: 0 PID: 22729 Comm: syz.7.2187 Kdump: loaded Not tainted 6.17.0-rc1-00001-g1149a5db27c8-dirty kernel-patches#55 PREEMPT_RT | Hardware name: QEMU KVM Virtual Machine, BIOS 2025.02-8ubuntu1 06/11/2025 | pstate: 63400005 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) | pc : rt_mutex_handle_deadlock+0x68/0xec kernel/locking/rtmutex.c:-1 | lr : rt_mutex_handle_deadlock+0x40/0xec kernel/locking/rtmutex.c:1674 | sp : ffff8000967c7720 | x29: ffff8000967c7720 x28: 1fffe0001946d182 x27: dfff800000000000 | x26: 0000000000000001 x25: 0000000000000003 x24: 1fffe0001946d00b | x23: 1fffe0001946d182 x22: ffff80008aec8940 x21: dfff800000000000 | x20: ffff0000ca368058 x19: ffff0000ca368c10 x18: ffff80008af6b6e0 | x17: 1fffe000590b8088 x16: ffff80008046cc08 x15: 0000000000000001 | x14: 1fffe000590ba990 x13: 0000000000000000 x12: 0000000000000000 | x11: ffff6000590ba991 x10: 0000000000000002 x9 : 0fe446e029bcfe00 | x8 : 0000000000000000 x7 : 0000000000000000 x6 : 000000000000003f | x5 : 0000000000000001 x4 : 0000000000001000 x3 : ffff800080503efc | x2 : 0000000000000001 x1 : 0000000000000001 x0 : 0000000000000001 | Call trace: | rt_mutex_handle_deadlock+0x68/0xec kernel/locking/rtmutex.c:-1 (P) | __rt_mutex_slowlock+0x1cc/0x480 kernel/locking/rtmutex.c:1734 | __rt_mutex_slowlock_locked kernel/locking/rtmutex.c:1760 [inline] | rt_mutex_slowlock+0x140/0x21c kernel/locking/rtmutex.c:1800 | __rt_mutex_lock kernel/locking/rtmutex.c:1815 [inline] | __mutex_lock_common kernel/locking/rtmutex_api.c:536 [inline] | mutex_lock+0xf0/0x10c kernel/locking/rtmutex_api.c:603 | device_lock include/linux/device.h:911 [inline] | nfc_dev_down net/nfc/core.c:143 [inline] | nfc_rfkill_set_block+0x48/0x2a4 net/nfc/core.c:179 | rfkill_set_block+0x184/0x364 net/rfkill/core.c:346 | rfkill_fop_write+0x4dc/0x624 net/rfkill/core.c:1301 | vfs_write+0x2b8/0xa30 fs/read_write.c:684 | ksys_write+0x120/0x210 fs/read_write.c:738 | __do_sys_write fs/read_write.c:749 [inline] | __se_sys_write fs/read_write.c:746 [inline] | __arm64_sys_write+0x7c/0x90 fs/read_write.c:746 | __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] | invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 | el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 | do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 | el0_svc+0x40/0x140 arch/arm64/kernel/entry-common.c:879 | el0t_64_sync_handler+0x84/0x12c arch/arm64/kernel/entry-common.c:898 | el0t_64_sync+0x1ac/0x1b0 arch/arm64/kernel/entry.S:596 The scenario is as follows: Task A (rfkill_fop_write): 1. Acquires rfkill_global_mutex. 2. Iterates devices and calls rfkill_set_block() -> nfc_rfkill_set_block() -> nfc_dev_down(). 3. Tries to acquire NFC device_lock. Task B (nfc_unregister_device): 1. Acquires NFC device_lock. 2. Calls rfkill_unregister(). 3. Tries to acquire rfkill_global_mutex. Task A waits for the device_lock held by Task B, while Task B waits for the rfkill_global_mutex held by Task A. To fix this, move the calls to rfkill_unregister() and rfkill_destroy() outside the device_lock critical section in nfc_unregister_device(). We ensure this is safe by first acquiring the device_lock, setting the shutting_down flag (which prevents races with nfc_dev_down()), stashing the rfkill pointer in a local variable, nullifying the pointer in the nfc_dev structure, and then releasing the device_lock before calling the rfkill unregister functions. This breaks the lock inversion. Signed-off-by: Yunseong Kim <ysk@kzalloc.com> Signed-off-by: NipaLocal <nipa@local>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Pull request for series with
subject: bpf: using rcu_read_lock for bpf_sk_storage_map iterator
version: 1
url: https://patchwork.ozlabs.org/project/netdev/list/?series=201648