bpf: Fix potential call bpf_link_free() in atomic context #77
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Master branch: c64779e patch https://patchwork.ozlabs.org/project/netdev/patch/20200917074453.20621-1-songmuchun@bytedance.com/ applied successfully |
|
Master branch: 3b03791 patch https://patchwork.ozlabs.org/project/netdev/patch/20200917074453.20621-1-songmuchun@bytedance.com/ applied successfully |
kernel-patches-bot
force-pushed
the
series/202339=>bpf-next
branch
from
6afacf3 to
51e4a96
Compare
|
Master branch: f55f4c3 patch https://patchwork.ozlabs.org/project/netdev/patch/20200917074453.20621-1-songmuchun@bytedance.com/ applied successfully |
kernel-patches-bot
force-pushed
the
series/202339=>bpf-next
branch
from
51e4a96 to
8fe91eb
Compare
it cannot know about held spinlocks in non-preemptible kernels. Although, there is no user call bpf_link_put() with holding spinlock now. Be the safe side, we can avoid this in the feature. Signed-off-by: Muchun Song <songmuchun@bytedance.com> --- kernel/bpf/syscall.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-)
|
Master branch: 70b9711 patch https://patchwork.ozlabs.org/project/netdev/patch/20200917074453.20621-1-songmuchun@bytedance.com/ applied successfully |
kernel-patches-bot
force-pushed
the
series/202339=>bpf-next
branch
from
8fe91eb to
4a3f8f3
Compare
|
At least one diff in series https://patchwork.ozlabs.org/project/netdev/list/?series=202339 irrelevant now. Closing PR. |
kernel-patches-bot
pushed a commit
that referenced
this pull request
Nov 16, 2020
Richard reported a warning which can be reproduced by running the LTP madvise6 test (cgroup v1 in the non-hierarchical mode should be used): WARNING: CPU: 0 PID: 12 at mm/page_counter.c:57 page_counter_uncharge (mm/page_counter.c:57 mm/page_counter.c:50 mm/page_counter.c:156) Modules linked in: CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.9.0-rc7-22-default #77 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-48-gd9c812d-rebuilt.opensuse.org 04/01/2014 Workqueue: events drain_local_stock RIP: 0010:page_counter_uncharge (mm/page_counter.c:57 mm/page_counter.c:50 mm/page_counter.c:156) Call Trace: __memcg_kmem_uncharge (mm/memcontrol.c:3022) drain_obj_stock (./include/linux/rcupdate.h:689 mm/memcontrol.c:3114) drain_local_stock (mm/memcontrol.c:2255) process_one_work (./arch/x86/include/asm/jump_label.h:25 ./include/linux/jump_label.h:200 ./include/trace/events/workqueue.h:108 kernel/workqueue.c:2274) worker_thread (./include/linux/list.h:282 kernel/workqueue.c:2416) kthread (kernel/kthread.c:292) ret_from_fork (arch/x86/entry/entry_64.S:300) The problem occurs because in the non-hierarchical mode non-root page counters are not linked to root page counters, so the charge is not propagated to the root memory cgroup. After the removal of the original memory cgroup and reparenting of the object cgroup, the root cgroup might be uncharged by draining a objcg stock, for example. It leads to an eventual underflow of the charge and triggers a warning. Fix it by linking all page counters to corresponding root page counters in the non-hierarchical mode. Please note, that in the non-hierarchical mode all objcgs are always reparented to the root memory cgroup, even if the hierarchy has more than 1 level. This patch doesn't change it. The patch also doesn't affect how the hierarchical mode is working, which is the only sane and truly supported mode now. Thanks to Richard for reporting, debugging and providing an alternative version of the fix! Fixes: bf4f059 ("mm: memcg/slab: obj_cgroup API") Reported-by: <ltp@lists.linux.it> Signed-off-by: Roman Gushchin <guro@fb.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Reviewed-by: Shakeel Butt <shakeelb@google.com> Reviewed-by: Michal Koutný <mkoutny@suse.com> Acked-by: Johannes Weiner <hannes@cmpxchg.org> Cc: Michal Hocko <mhocko@kernel.org> Cc: <stable@vger.kernel.org> Link: https://lkml.kernel.org/r/20201026231326.3212225-1-guro@fb.com Debugged-by: Richard Palethorpe <rpalethorpe@suse.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Jun 23, 2021
In some scenarios (kdump), dpdma hardware irqs has been enabled when calling request_irq in probe function, and then the dpdma irq handler xilinx_dpdma_irq_handler is invoked to access xdev->chan[i]. But at this moment xdev->chan[i] hasn't been initialized. We should ensure the dpdma controller to be in a consistent and clean state before further initialization. So add dpdma_hw_init() to do this. Furthermore, in xilinx_dpdma_disable_irq, disable all interrupts instead of error interrupts. This patch is to fix the kdump kernel crash as below: [ 3.696128] Unable to handle kernel NULL pointer dereference at virtual address 000000000000012c [ 3.696710] xilinx-zynqmp-dpdma fd4c0000.dma-controller: Xilinx DPDMA engine is probed [ 3.704900] Mem abort info: [ 3.704902] ESR = 0x96000005 [ 3.704905] EC = 0x25: DABT (current EL), IL = 32 bits [ 3.704907] SET = 0, FnV = 0 [ 3.704912] EA = 0, S1PTW = 0 [ 3.713800] ahci-ceva fd0c0000.ahci: supply ahci not found, using dummy regulator [ 3.715585] Data abort info: [ 3.715587] ISV = 0, ISS = 0x00000005 [ 3.715589] CM = 0, WnR = 0 [ 3.715592] [000000000000012c] user address but active_mm is swapper [ 3.715596] Internal error: Oops: 96000005 [#1] SMP [ 3.715599] Modules linked in: [ 3.715608] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.0-12170-g60894882155f-dirty #77 [ 3.723937] Hardware name: ZynqMP ZCU102 Rev1.0 (DT) [ 3.723942] pstate: 80000085 (Nzcv daIf -PAN -UAO -TCO BTYPE=--) [ 3.723956] pc : xilinx_dpdma_irq_handler+0x418/0x560 [ 3.793049] lr : xilinx_dpdma_irq_handler+0x3d8/0x560 [ 3.798089] sp : ffffffc01186bdf0 [ 3.801388] x29: ffffffc01186bdf0 x28: ffffffc011836f28 [ 3.806692] x27: ffffff8023e0ac80 x26: 0000000000000080 [ 3.811996] x25: 0000000008000408 x24: 0000000000000003 [ 3.817300] x23: ffffffc01186be70 x22: ffffffc011291740 [ 3.822604] x21: 0000000000000000 x20: 0000000008000408 [ 3.827908] x19: 0000000000000000 x18: 0000000000000010 [ 3.833212] x17: 0000000000000000 x16: 0000000000000000 [ 3.838516] x15: 0000000000000000 x14: ffffffc011291740 [ 3.843820] x13: ffffffc02eb4d000 x12: 0000000034d4d91d [ 3.849124] x11: 0000000000000040 x10: ffffffc0112d2d48 [ 3.854428] x9 : ffffffc0112d2d40 x8 : ffffff8021c00268 [ 3.859732] x7 : 0000000000000000 x6 : ffffffc011836000 [ 3.865036] x5 : 0000000000000003 x4 : 0000000000000000 [ 3.870340] x3 : 0000000000000001 x2 : 0000000000000000 [ 3.875644] x1 : 0000000000000000 x0 : 000000000000012c [ 3.880948] Call trace: [ 3.883382] xilinx_dpdma_irq_handler+0x418/0x560 [ 3.888079] __handle_irq_event_percpu+0x5c/0x178 [ 3.892774] handle_irq_event_percpu+0x34/0x98 [ 3.897210] handle_irq_event+0x44/0xb8 [ 3.901030] handle_fasteoi_irq+0xd0/0x190 [ 3.905117] generic_handle_irq+0x30/0x48 [ 3.909111] __handle_domain_irq+0x64/0xc0 [ 3.913192] gic_handle_irq+0x78/0xa0 [ 3.916846] el1_irq+0xc4/0x180 [ 3.919982] cpuidle_enter_state+0x134/0x2f8 [ 3.924243] cpuidle_enter+0x38/0x50 [ 3.927810] call_cpuidle+0x1c/0x40 [ 3.931290] do_idle+0x20c/0x270 [ 3.934502] cpu_startup_entry+0x28/0x58 [ 3.938410] rest_init+0xbc/0xcc [ 3.941631] arch_call_rest_init+0x10/0x1c [ 3.945718] start_kernel+0x51c/0x558 Fixes: 7cbb0c6 ("dmaengine: xilinx: dpdma: Add the Xilinx DisplayPort DMA engine driver") Signed-off-by: Quanyang Wang <quanyang.wang@windriver.com> Link: https://lore.kernel.org/r/20210430064041.4058180-1-quanyang.wang@windriver.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Nov 12, 2022
xfstests generic/011 reported use-after-free bug as follows: BUG: KASAN: use-after-free in __d_alloc+0x269/0x859 Read of size 15 at addr ffff8880078933a0 by task dirstress/952 CPU: 1 PID: 952 Comm: dirstress Not tainted 6.1.0-rc3+ #77 Call Trace: __dump_stack+0x23/0x29 dump_stack_lvl+0x51/0x73 print_address_description+0x67/0x27f print_report+0x3e/0x5c kasan_report+0x7b/0xa8 kasan_check_range+0x1b2/0x1c1 memcpy+0x22/0x5d __d_alloc+0x269/0x859 d_alloc+0x45/0x20c d_alloc_parallel+0xb2/0x8b2 lookup_open+0x3b8/0x9f9 open_last_lookups+0x63d/0xc26 path_openat+0x11a/0x261 do_filp_open+0xcc/0x168 do_sys_openat2+0x13b/0x3f7 do_sys_open+0x10f/0x146 __se_sys_creat+0x27/0x2e __x64_sys_creat+0x55/0x6a do_syscall_64+0x40/0x96 entry_SYSCALL_64_after_hwframe+0x63/0xcd Allocated by task 952: kasan_save_stack+0x1f/0x42 kasan_set_track+0x21/0x2a kasan_save_alloc_info+0x17/0x1d __kasan_kmalloc+0x7e/0x87 __kmalloc_node_track_caller+0x59/0x155 kstrndup+0x60/0xe6 parse_mf_symlink+0x215/0x30b check_mf_symlink+0x260/0x36a cifs_get_inode_info+0x14e1/0x1690 cifs_revalidate_dentry_attr+0x70d/0x964 cifs_revalidate_dentry+0x36/0x62 cifs_d_revalidate+0x162/0x446 lookup_open+0x36f/0x9f9 open_last_lookups+0x63d/0xc26 path_openat+0x11a/0x261 do_filp_open+0xcc/0x168 do_sys_openat2+0x13b/0x3f7 do_sys_open+0x10f/0x146 __se_sys_creat+0x27/0x2e __x64_sys_creat+0x55/0x6a do_syscall_64+0x40/0x96 entry_SYSCALL_64_after_hwframe+0x63/0xcd Freed by task 950: kasan_save_stack+0x1f/0x42 kasan_set_track+0x21/0x2a kasan_save_free_info+0x1c/0x34 ____kasan_slab_free+0x1c1/0x1d5 __kasan_slab_free+0xe/0x13 __kmem_cache_free+0x29a/0x387 kfree+0xd3/0x10e cifs_fattr_to_inode+0xb6a/0xc8c cifs_get_inode_info+0x3cb/0x1690 cifs_revalidate_dentry_attr+0x70d/0x964 cifs_revalidate_dentry+0x36/0x62 cifs_d_revalidate+0x162/0x446 lookup_open+0x36f/0x9f9 open_last_lookups+0x63d/0xc26 path_openat+0x11a/0x261 do_filp_open+0xcc/0x168 do_sys_openat2+0x13b/0x3f7 do_sys_open+0x10f/0x146 __se_sys_creat+0x27/0x2e __x64_sys_creat+0x55/0x6a do_syscall_64+0x40/0x96 entry_SYSCALL_64_after_hwframe+0x63/0xcd When opened a symlink, link name is from 'inode->i_link', but it may be reset to a new value when revalidate the dentry. If some processes get the link name on the race scenario, then UAF will happen on link name. Fix this by implementing 'get_link' interface to duplicate the link name. Fixes: 76894f3 ("cifs: improve symlink handling for smb2+") Signed-off-by: ChenXiaoSong <chenxiaosong2@huawei.com> Reviewed-by: Paulo Alcantara (SUSE) <pc@cjr.nz> Signed-off-by: Steve French <stfrench@microsoft.com>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
Nov 27, 2023
With latest upstream llvm18, the following test cases failed: $ ./test_progs -j #13/2 bpf_cookie/multi_kprobe_link_api:FAIL #13/3 bpf_cookie/multi_kprobe_attach_api:FAIL #13 bpf_cookie:FAIL #77 fentry_fexit:FAIL #78/1 fentry_test/fentry:FAIL #78 fentry_test:FAIL #82/1 fexit_test/fexit:FAIL #82 fexit_test:FAIL #112/1 kprobe_multi_test/skel_api:FAIL #112/2 kprobe_multi_test/link_api_addrs:FAIL ... #112 kprobe_multi_test:FAIL #356/17 test_global_funcs/global_func17:FAIL #356 test_global_funcs:FAIL Further analysis shows llvm upstream patch [1] is responsible for the above failures. For example, for function bpf_fentry_test7() in net/bpf/test_run.c, without [1], the asm code is: 0000000000000400 <bpf_fentry_test7>: 400: f3 0f 1e fa endbr64 404: e8 00 00 00 00 callq 0x409 <bpf_fentry_test7+0x9> 409: 48 89 f8 movq %rdi, %rax 40c: c3 retq 40d: 0f 1f 00 nopl (%rax) and with [1], the asm code is: 0000000000005d20 <bpf_fentry_test7.specialized.1>: 5d20: e8 00 00 00 00 callq 0x5d25 <bpf_fentry_test7.specialized.1+0x5> 5d25: c3 retq and <bpf_fentry_test7.specialized.1> is called instead of <bpf_fentry_test7> and this caused test failures for #13/#77 etc. except #356. For test case #356/17, with [1] (progs/test_global_func17.c)), the main prog looks like: 0000000000000000 <global_func17>: 0: b4 00 00 00 2a 00 00 00 w0 = 0x2a 1: 95 00 00 00 00 00 00 00 exit which passed verification while the test itself expects a verification failure. Let us add 'barrier_var' style asm code in both places to prevent function specialization which caused selftests failure. [1] llvm/llvm-project#72903 Signed-off-by: Yonghong Song <yonghong.song@linux.dev>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
Nov 27, 2023
With latest upstream llvm18, the following test cases failed: $ ./test_progs -j #13/2 bpf_cookie/multi_kprobe_link_api:FAIL #13/3 bpf_cookie/multi_kprobe_attach_api:FAIL #13 bpf_cookie:FAIL #77 fentry_fexit:FAIL #78/1 fentry_test/fentry:FAIL #78 fentry_test:FAIL #82/1 fexit_test/fexit:FAIL #82 fexit_test:FAIL #112/1 kprobe_multi_test/skel_api:FAIL #112/2 kprobe_multi_test/link_api_addrs:FAIL [...] #112 kprobe_multi_test:FAIL #356/17 test_global_funcs/global_func17:FAIL #356 test_global_funcs:FAIL Further analysis shows llvm upstream patch [1] is responsible for the above failures. For example, for function bpf_fentry_test7() in net/bpf/test_run.c, without [1], the asm code is: 0000000000000400 <bpf_fentry_test7>: 400: f3 0f 1e fa endbr64 404: e8 00 00 00 00 callq 0x409 <bpf_fentry_test7+0x9> 409: 48 89 f8 movq %rdi, %rax 40c: c3 retq 40d: 0f 1f 00 nopl (%rax) ... and with [1], the asm code is: 0000000000005d20 <bpf_fentry_test7.specialized.1>: 5d20: e8 00 00 00 00 callq 0x5d25 <bpf_fentry_test7.specialized.1+0x5> 5d25: c3 retq ... and <bpf_fentry_test7.specialized.1> is called instead of <bpf_fentry_test7> and this caused test failures for #13/#77 etc. except #356. For test case #356/17, with [1] (progs/test_global_func17.c)), the main prog looks like: 0000000000000000 <global_func17>: 0: b4 00 00 00 2a 00 00 00 w0 = 0x2a 1: 95 00 00 00 00 00 00 00 exit ... which passed verification while the test itself expects a verification failure. Let us add 'barrier_var' style asm code in both places to prevent function specialization which caused selftests failure. [1] llvm/llvm-project#72903 Signed-off-by: Yonghong Song <yonghong.song@linux.dev> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20231127050342.1945270-1-yonghong.song@linux.dev
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
Dec 19, 2023
…oup() Erhard reported that the 6.7-rc1 kernel panics on boot if being built with clang-16. The problem was not reproducible with gcc. [ 5.975049] general protection fault, probably for non-canonical address 0xf555515555555557: 0000 [#1] SMP KASAN PTI [ 5.976422] KASAN: maybe wild-memory-access in range [0xaaaaaaaaaaaaaab8-0xaaaaaaaaaaaaaabf] [ 5.977475] CPU: 3 PID: 1 Comm: systemd Not tainted 6.7.0-rc1-Zen3 #77 [ 5.977860] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 [ 5.977860] RIP: 0010:obj_cgroup_charge_pages+0x27/0x2d5 [ 5.977860] Code: 90 90 90 55 41 57 41 56 41 55 41 54 53 89 d5 41 89 f6 49 89 ff 48 b8 00 00 00 00 00 fc ff df 49 83 c7 10 4d3 [ 5.977860] RSP: 0018:ffffc9000001fb18 EFLAGS: 00010a02 [ 5.977860] RAX: dffffc0000000000 RBX: aaaaaaaaaaaaaaaa RCX: ffff8883eb9a8b08 [ 5.977860] RDX: 0000000000000005 RSI: 0000000000400cc0 RDI: aaaaaaaaaaaaaaaa [ 5.977860] RBP: 0000000000000005 R08: 3333333333333333 R09: 0000000000000000 [ 5.977860] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8883eb9a8b18 [ 5.977860] R13: 1555555555555557 R14: 0000000000400cc0 R15: aaaaaaaaaaaaaaba [ 5.977860] FS: 00007f2976438b40(0000) GS:ffff8883eb980000(0000) knlGS:0000000000000000 [ 5.977860] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 5.977860] CR2: 00007f29769e0060 CR3: 0000000107222003 CR4: 0000000000370eb0 [ 5.977860] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 5.977860] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 5.977860] Call Trace: [ 5.977860] <TASK> [ 5.977860] ? __die_body+0x16/0x75 [ 5.977860] ? die_addr+0x4a/0x70 [ 5.977860] ? exc_general_protection+0x1c9/0x2d0 [ 5.977860] ? cgroup_mkdir+0x455/0x9fb [ 5.977860] ? __x64_sys_mkdir+0x69/0x80 [ 5.977860] ? asm_exc_general_protection+0x26/0x30 [ 5.977860] ? obj_cgroup_charge_pages+0x27/0x2d5 [ 5.977860] obj_cgroup_charge+0x114/0x1ab [ 5.977860] pcpu_alloc+0x1a6/0xa65 [ 5.977860] ? mem_cgroup_css_alloc+0x1eb/0x1140 [ 5.977860] ? cgroup_apply_control_enable+0x26b/0x7c0 [ 5.977860] mem_cgroup_css_alloc+0x23f/0x1140 [ 5.977860] cgroup_apply_control_enable+0x26b/0x7c0 [ 5.977860] ? cgroup_kn_set_ugid+0x2d/0x1a0 [ 5.977860] cgroup_mkdir+0x455/0x9fb [ 5.977860] ? __cfi_cgroup_mkdir+0x10/0x10 [ 5.977860] kernfs_iop_mkdir+0x130/0x170 [ 5.977860] vfs_mkdir+0x405/0x530 [ 5.977860] do_mkdirat+0x188/0x1f0 [ 5.977860] __x64_sys_mkdir+0x69/0x80 [ 5.977860] do_syscall_64+0x7d/0x100 [ 5.977860] ? do_syscall_64+0x89/0x100 [ 5.977860] ? do_syscall_64+0x89/0x100 [ 5.977860] ? do_syscall_64+0x89/0x100 [ 5.977860] ? do_syscall_64+0x89/0x100 [ 5.977860] entry_SYSCALL_64_after_hwframe+0x4b/0x53 [ 5.977860] RIP: 0033:0x7f297671defb [ 5.977860] Code: 8b 05 39 7f 0d 00 bb ff ff ff ff 64 c7 00 16 00 00 00 e9 61 ff ff ff e8 23 0c 02 00 0f 1f 00 f3 0f 1e fa b88 [ 5.977860] RSP: 002b:00007ffee6242bb8 EFLAGS: 00000246 ORIG_RAX: 0000000000000053 [ 5.977860] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f297671defb [ 5.977860] RDX: 0000000000000000 RSI: 00000000000001ed RDI: 000055c6b449f0e0 [ 5.977860] RBP: 00007ffee6242bf0 R08: 000000000000000e R09: 0000000000000000 [ 5.977860] R10: 0000000000000000 R11: 0000000000000246 R12: 000055c6b445db80 [ 5.977860] R13: 00000000000003a0 R14: 00007f2976a68651 R15: 00000000000003a0 [ 5.977860] </TASK> [ 5.977860] Modules linked in: [ 6.014095] ---[ end trace 0000000000000000 ]--- [ 6.014701] RIP: 0010:obj_cgroup_charge_pages+0x27/0x2d5 [ 6.015348] Code: 90 90 90 55 41 57 41 56 41 55 41 54 53 89 d5 41 89 f6 49 89 ff 48 b8 00 00 00 00 00 fc ff df 49 83 c7 10 4d3 [ 6.017575] RSP: 0018:ffffc9000001fb18 EFLAGS: 00010a02 [ 6.018255] RAX: dffffc0000000000 RBX: aaaaaaaaaaaaaaaa RCX: ffff8883eb9a8b08 [ 6.019120] RDX: 0000000000000005 RSI: 0000000000400cc0 RDI: aaaaaaaaaaaaaaaa [ 6.019983] RBP: 0000000000000005 R08: 3333333333333333 R09: 0000000000000000 [ 6.020849] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8883eb9a8b18 [ 6.021747] R13: 1555555555555557 R14: 0000000000400cc0 R15: aaaaaaaaaaaaaaba [ 6.022609] FS: 00007f2976438b40(0000) GS:ffff8883eb980000(0000) knlGS:0000000000000000 [ 6.023593] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 6.024296] CR2: 00007f29769e0060 CR3: 0000000107222003 CR4: 0000000000370eb0 [ 6.025279] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 6.026139] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 6.027000] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b Actually the problem is caused by uninitialized local variable in current_obj_cgroup(). If the root memory cgroup is set as an active memory cgroup for a charging scope (as in the trace, where systemd tries to create the first non-root cgroup, so the parent cgroup is the root cgroup), the "for" loop is skipped and uninitialized objcg is returned, causing a panic down the accounting stack. The fix is trivial: initialize the objcg variable to NULL unconditionally before the "for" loop. [vbabka@suse.cz: remove redundant assignment] Link: https://lkml.kernel.org/r/4bd106d5-c3e3-6731-9a74-cff81e2392de@suse.cz Link: https://lkml.kernel.org/r/20231116025109.3775055-1-roman.gushchin@linux.dev Fixes: e86828e ("mm: kmem: scoped objcg protection") Signed-off-by: Roman Gushchin (Cruise) <roman.gushchin@linux.dev> Signed-off-by: Vlastimil Babka <vbabka@suse.cz> Reported-by: Erhard Furtner <erhard_f@mailbox.org> Closes: ClangBuiltLinux/linux#1959 Tested-by: Erhard Furtner <erhard_f@mailbox.org> Acked-by: Vlastimil Babka <vbabka@suse.cz> Acked-by: Shakeel Butt <shakeelb@google.com> Cc: David Rientjes <rientjes@google.com> Cc: Dennis Zhou <dennis@kernel.org> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Michal Hocko <mhocko@kernel.org> Cc: Muchun Song <muchun.song@linux.dev> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
Apr 30, 2024
Add 3 test cases for skb dynptr used in tp_btf: - test_dynptr_skb_tp_btf: use skb dynptr in tp_btf and make sure it is read-only. - skb_invalid_ctx_fentry/skb_invalid_ctx_fexit: bpf_dynptr_from_skb should fail in fentry/fexit. In test_dynptr_skb_tp_btf, to trigger the tracepoint in kfree_skb, test_pkt_access is used for its test_run, as in kfree_skb.c. Because the test process is different from others, a new setup type is defined, i.e., SETUP_SKB_PROG_TP. The result is like: $ ./test_progs -t 'dynptr/test_dynptr_skb_tp_btf' #77/14 dynptr/test_dynptr_skb_tp_btf:OK #77 dynptr:OK #120 kfunc_dynptr_param:OK Summary: 2/1 PASSED, 0 SKIPPED, 0 FAILED $ ./test_progs -t 'dynptr/skb_invalid_ctx_f' #77/83 dynptr/skb_invalid_ctx_fentry:OK #77/84 dynptr/skb_invalid_ctx_fexit:OK #77 dynptr:OK #120 kfunc_dynptr_param:OK Summary: 2/2 PASSED, 0 SKIPPED, 0 FAILED Also fix two coding style nits (change spaces to tabs). Signed-off-by: Philo Lu <lulie@linux.alibaba.com>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
Apr 30, 2024
Add 3 test cases for skb dynptr used in tp_btf: - test_dynptr_skb_tp_btf: use skb dynptr in tp_btf and make sure it is read-only. - skb_invalid_ctx_fentry/skb_invalid_ctx_fexit: bpf_dynptr_from_skb should fail in fentry/fexit. In test_dynptr_skb_tp_btf, to trigger the tracepoint in kfree_skb, test_pkt_access is used for its test_run, as in kfree_skb.c. Because the test process is different from others, a new setup type is defined, i.e., SETUP_SKB_PROG_TP. The result is like: $ ./test_progs -t 'dynptr/test_dynptr_skb_tp_btf' #77/14 dynptr/test_dynptr_skb_tp_btf:OK #77 dynptr:OK #120 kfunc_dynptr_param:OK Summary: 2/1 PASSED, 0 SKIPPED, 0 FAILED $ ./test_progs -t 'dynptr/skb_invalid_ctx_f' #77/83 dynptr/skb_invalid_ctx_fentry:OK #77/84 dynptr/skb_invalid_ctx_fexit:OK #77 dynptr:OK #120 kfunc_dynptr_param:OK Summary: 2/2 PASSED, 0 SKIPPED, 0 FAILED Also fix two coding style nits (change spaces to tabs). Signed-off-by: Philo Lu <lulie@linux.alibaba.com>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
Apr 30, 2024
Add 3 test cases for skb dynptr used in tp_btf: - test_dynptr_skb_tp_btf: use skb dynptr in tp_btf and make sure it is read-only. - skb_invalid_ctx_fentry/skb_invalid_ctx_fexit: bpf_dynptr_from_skb should fail in fentry/fexit. In test_dynptr_skb_tp_btf, to trigger the tracepoint in kfree_skb, test_pkt_access is used for its test_run, as in kfree_skb.c. Because the test process is different from others, a new setup type is defined, i.e., SETUP_SKB_PROG_TP. The result is like: $ ./test_progs -t 'dynptr/test_dynptr_skb_tp_btf' #77/14 dynptr/test_dynptr_skb_tp_btf:OK #77 dynptr:OK #120 kfunc_dynptr_param:OK Summary: 2/1 PASSED, 0 SKIPPED, 0 FAILED $ ./test_progs -t 'dynptr/skb_invalid_ctx_f' #77/83 dynptr/skb_invalid_ctx_fentry:OK #77/84 dynptr/skb_invalid_ctx_fexit:OK #77 dynptr:OK #120 kfunc_dynptr_param:OK Summary: 2/2 PASSED, 0 SKIPPED, 0 FAILED Also fix two coding style nits (change spaces to tabs). Signed-off-by: Philo Lu <lulie@linux.alibaba.com>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
May 1, 2024
Add 3 test cases for skb dynptr used in tp_btf: - test_dynptr_skb_tp_btf: use skb dynptr in tp_btf and make sure it is read-only. - skb_invalid_ctx_fentry/skb_invalid_ctx_fexit: bpf_dynptr_from_skb should fail in fentry/fexit. In test_dynptr_skb_tp_btf, to trigger the tracepoint in kfree_skb, test_pkt_access is used for its test_run, as in kfree_skb.c. Because the test process is different from others, a new setup type is defined, i.e., SETUP_SKB_PROG_TP. The result is like: $ ./test_progs -t 'dynptr/test_dynptr_skb_tp_btf' #77/14 dynptr/test_dynptr_skb_tp_btf:OK #77 dynptr:OK #120 kfunc_dynptr_param:OK Summary: 2/1 PASSED, 0 SKIPPED, 0 FAILED $ ./test_progs -t 'dynptr/skb_invalid_ctx_f' #77/83 dynptr/skb_invalid_ctx_fentry:OK #77/84 dynptr/skb_invalid_ctx_fexit:OK #77 dynptr:OK #120 kfunc_dynptr_param:OK Summary: 2/2 PASSED, 0 SKIPPED, 0 FAILED Also fix two coding style nits (change spaces to tabs). Signed-off-by: Philo Lu <lulie@linux.alibaba.com>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
May 1, 2024
Add 3 test cases for skb dynptr used in tp_btf: - test_dynptr_skb_tp_btf: use skb dynptr in tp_btf and make sure it is read-only. - skb_invalid_ctx_fentry/skb_invalid_ctx_fexit: bpf_dynptr_from_skb should fail in fentry/fexit. In test_dynptr_skb_tp_btf, to trigger the tracepoint in kfree_skb, test_pkt_access is used for its test_run, as in kfree_skb.c. Because the test process is different from others, a new setup type is defined, i.e., SETUP_SKB_PROG_TP. The result is like: $ ./test_progs -t 'dynptr/test_dynptr_skb_tp_btf' #77/14 dynptr/test_dynptr_skb_tp_btf:OK #77 dynptr:OK #120 kfunc_dynptr_param:OK Summary: 2/1 PASSED, 0 SKIPPED, 0 FAILED $ ./test_progs -t 'dynptr/skb_invalid_ctx_f' #77/83 dynptr/skb_invalid_ctx_fentry:OK #77/84 dynptr/skb_invalid_ctx_fexit:OK #77 dynptr:OK #120 kfunc_dynptr_param:OK Summary: 2/2 PASSED, 0 SKIPPED, 0 FAILED Also fix two coding style nits (change spaces to tabs). Signed-off-by: Philo Lu <lulie@linux.alibaba.com>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
May 1, 2024
Add 3 test cases for skb dynptr used in tp_btf: - test_dynptr_skb_tp_btf: use skb dynptr in tp_btf and make sure it is read-only. - skb_invalid_ctx_fentry/skb_invalid_ctx_fexit: bpf_dynptr_from_skb should fail in fentry/fexit. In test_dynptr_skb_tp_btf, to trigger the tracepoint in kfree_skb, test_pkt_access is used for its test_run, as in kfree_skb.c. Because the test process is different from others, a new setup type is defined, i.e., SETUP_SKB_PROG_TP. The result is like: $ ./test_progs -t 'dynptr/test_dynptr_skb_tp_btf' #77/14 dynptr/test_dynptr_skb_tp_btf:OK #77 dynptr:OK #120 kfunc_dynptr_param:OK Summary: 2/1 PASSED, 0 SKIPPED, 0 FAILED $ ./test_progs -t 'dynptr/skb_invalid_ctx_f' #77/83 dynptr/skb_invalid_ctx_fentry:OK #77/84 dynptr/skb_invalid_ctx_fexit:OK #77 dynptr:OK #120 kfunc_dynptr_param:OK Summary: 2/2 PASSED, 0 SKIPPED, 0 FAILED Also fix two coding style nits (change spaces to tabs). Signed-off-by: Philo Lu <lulie@linux.alibaba.com>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
May 1, 2024
Add 3 test cases for skb dynptr used in tp_btf: - test_dynptr_skb_tp_btf: use skb dynptr in tp_btf and make sure it is read-only. - skb_invalid_ctx_fentry/skb_invalid_ctx_fexit: bpf_dynptr_from_skb should fail in fentry/fexit. In test_dynptr_skb_tp_btf, to trigger the tracepoint in kfree_skb, test_pkt_access is used for its test_run, as in kfree_skb.c. Because the test process is different from others, a new setup type is defined, i.e., SETUP_SKB_PROG_TP. The result is like: $ ./test_progs -t 'dynptr/test_dynptr_skb_tp_btf' #77/14 dynptr/test_dynptr_skb_tp_btf:OK #77 dynptr:OK #120 kfunc_dynptr_param:OK Summary: 2/1 PASSED, 0 SKIPPED, 0 FAILED $ ./test_progs -t 'dynptr/skb_invalid_ctx_f' #77/83 dynptr/skb_invalid_ctx_fentry:OK #77/84 dynptr/skb_invalid_ctx_fexit:OK #77 dynptr:OK #120 kfunc_dynptr_param:OK Summary: 2/2 PASSED, 0 SKIPPED, 0 FAILED Also fix two coding style nits (change spaces to tabs). Signed-off-by: Philo Lu <lulie@linux.alibaba.com>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
May 2, 2024
Add 3 test cases for skb dynptr used in tp_btf: - test_dynptr_skb_tp_btf: use skb dynptr in tp_btf and make sure it is read-only. - skb_invalid_ctx_fentry/skb_invalid_ctx_fexit: bpf_dynptr_from_skb should fail in fentry/fexit. In test_dynptr_skb_tp_btf, to trigger the tracepoint in kfree_skb, test_pkt_access is used for its test_run, as in kfree_skb.c. Because the test process is different from others, a new setup type is defined, i.e., SETUP_SKB_PROG_TP. The result is like: $ ./test_progs -t 'dynptr/test_dynptr_skb_tp_btf' #77/14 dynptr/test_dynptr_skb_tp_btf:OK #77 dynptr:OK #120 kfunc_dynptr_param:OK Summary: 2/1 PASSED, 0 SKIPPED, 0 FAILED $ ./test_progs -t 'dynptr/skb_invalid_ctx_f' #77/83 dynptr/skb_invalid_ctx_fentry:OK #77/84 dynptr/skb_invalid_ctx_fexit:OK #77 dynptr:OK #120 kfunc_dynptr_param:OK Summary: 2/2 PASSED, 0 SKIPPED, 0 FAILED Also fix two coding style nits (change spaces to tabs). Signed-off-by: Philo Lu <lulie@linux.alibaba.com>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
May 2, 2024
Add 3 test cases for skb dynptr used in tp_btf: - test_dynptr_skb_tp_btf: use skb dynptr in tp_btf and make sure it is read-only. - skb_invalid_ctx_fentry/skb_invalid_ctx_fexit: bpf_dynptr_from_skb should fail in fentry/fexit. In test_dynptr_skb_tp_btf, to trigger the tracepoint in kfree_skb, test_pkt_access is used for its test_run, as in kfree_skb.c. Because the test process is different from others, a new setup type is defined, i.e., SETUP_SKB_PROG_TP. The result is like: $ ./test_progs -t 'dynptr/test_dynptr_skb_tp_btf' #77/14 dynptr/test_dynptr_skb_tp_btf:OK #77 dynptr:OK #120 kfunc_dynptr_param:OK Summary: 2/1 PASSED, 0 SKIPPED, 0 FAILED $ ./test_progs -t 'dynptr/skb_invalid_ctx_f' #77/83 dynptr/skb_invalid_ctx_fentry:OK #77/84 dynptr/skb_invalid_ctx_fexit:OK #77 dynptr:OK #120 kfunc_dynptr_param:OK Summary: 2/2 PASSED, 0 SKIPPED, 0 FAILED Also fix two coding style nits (change spaces to tabs). Signed-off-by: Philo Lu <lulie@linux.alibaba.com>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
May 2, 2024
Add 3 test cases for skb dynptr used in tp_btf: - test_dynptr_skb_tp_btf: use skb dynptr in tp_btf and make sure it is read-only. - skb_invalid_ctx_fentry/skb_invalid_ctx_fexit: bpf_dynptr_from_skb should fail in fentry/fexit. In test_dynptr_skb_tp_btf, to trigger the tracepoint in kfree_skb, test_pkt_access is used for its test_run, as in kfree_skb.c. Because the test process is different from others, a new setup type is defined, i.e., SETUP_SKB_PROG_TP. The result is like: $ ./test_progs -t 'dynptr/test_dynptr_skb_tp_btf' #77/14 dynptr/test_dynptr_skb_tp_btf:OK #77 dynptr:OK #120 kfunc_dynptr_param:OK Summary: 2/1 PASSED, 0 SKIPPED, 0 FAILED $ ./test_progs -t 'dynptr/skb_invalid_ctx_f' #77/83 dynptr/skb_invalid_ctx_fentry:OK #77/84 dynptr/skb_invalid_ctx_fexit:OK #77 dynptr:OK #120 kfunc_dynptr_param:OK Summary: 2/2 PASSED, 0 SKIPPED, 0 FAILED Also fix two coding style nits (change spaces to tabs). Signed-off-by: Philo Lu <lulie@linux.alibaba.com>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
May 2, 2024
Add 3 test cases for skb dynptr used in tp_btf: - test_dynptr_skb_tp_btf: use skb dynptr in tp_btf and make sure it is read-only. - skb_invalid_ctx_fentry/skb_invalid_ctx_fexit: bpf_dynptr_from_skb should fail in fentry/fexit. In test_dynptr_skb_tp_btf, to trigger the tracepoint in kfree_skb, test_pkt_access is used for its test_run, as in kfree_skb.c. Because the test process is different from others, a new setup type is defined, i.e., SETUP_SKB_PROG_TP. The result is like: $ ./test_progs -t 'dynptr/test_dynptr_skb_tp_btf' #77/14 dynptr/test_dynptr_skb_tp_btf:OK #77 dynptr:OK #120 kfunc_dynptr_param:OK Summary: 2/1 PASSED, 0 SKIPPED, 0 FAILED $ ./test_progs -t 'dynptr/skb_invalid_ctx_f' #77/83 dynptr/skb_invalid_ctx_fentry:OK #77/84 dynptr/skb_invalid_ctx_fexit:OK #77 dynptr:OK #120 kfunc_dynptr_param:OK Summary: 2/2 PASSED, 0 SKIPPED, 0 FAILED Also fix two coding style nits (change spaces to tabs). Signed-off-by: Philo Lu <lulie@linux.alibaba.com>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
May 2, 2024
Add 3 test cases for skb dynptr used in tp_btf: - test_dynptr_skb_tp_btf: use skb dynptr in tp_btf and make sure it is read-only. - skb_invalid_ctx_fentry/skb_invalid_ctx_fexit: bpf_dynptr_from_skb should fail in fentry/fexit. In test_dynptr_skb_tp_btf, to trigger the tracepoint in kfree_skb, test_pkt_access is used for its test_run, as in kfree_skb.c. Because the test process is different from others, a new setup type is defined, i.e., SETUP_SKB_PROG_TP. The result is like: $ ./test_progs -t 'dynptr/test_dynptr_skb_tp_btf' #77/14 dynptr/test_dynptr_skb_tp_btf:OK #77 dynptr:OK #120 kfunc_dynptr_param:OK Summary: 2/1 PASSED, 0 SKIPPED, 0 FAILED $ ./test_progs -t 'dynptr/skb_invalid_ctx_f' #77/83 dynptr/skb_invalid_ctx_fentry:OK #77/84 dynptr/skb_invalid_ctx_fexit:OK #77 dynptr:OK #120 kfunc_dynptr_param:OK Summary: 2/2 PASSED, 0 SKIPPED, 0 FAILED Also fix two coding style nits (change spaces to tabs). Signed-off-by: Philo Lu <lulie@linux.alibaba.com>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
May 3, 2024
Add 3 test cases for skb dynptr used in tp_btf: - test_dynptr_skb_tp_btf: use skb dynptr in tp_btf and make sure it is read-only. - skb_invalid_ctx_fentry/skb_invalid_ctx_fexit: bpf_dynptr_from_skb should fail in fentry/fexit. In test_dynptr_skb_tp_btf, to trigger the tracepoint in kfree_skb, test_pkt_access is used for its test_run, as in kfree_skb.c. Because the test process is different from others, a new setup type is defined, i.e., SETUP_SKB_PROG_TP. The result is like: $ ./test_progs -t 'dynptr/test_dynptr_skb_tp_btf' #77/14 dynptr/test_dynptr_skb_tp_btf:OK #77 dynptr:OK #120 kfunc_dynptr_param:OK Summary: 2/1 PASSED, 0 SKIPPED, 0 FAILED $ ./test_progs -t 'dynptr/skb_invalid_ctx_f' #77/83 dynptr/skb_invalid_ctx_fentry:OK #77/84 dynptr/skb_invalid_ctx_fexit:OK #77 dynptr:OK #120 kfunc_dynptr_param:OK Summary: 2/2 PASSED, 0 SKIPPED, 0 FAILED Also fix two coding style nits (change spaces to tabs). Signed-off-by: Philo Lu <lulie@linux.alibaba.com>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
May 3, 2024
Add 3 test cases for skb dynptr used in tp_btf: - test_dynptr_skb_tp_btf: use skb dynptr in tp_btf and make sure it is read-only. - skb_invalid_ctx_fentry/skb_invalid_ctx_fexit: bpf_dynptr_from_skb should fail in fentry/fexit. In test_dynptr_skb_tp_btf, to trigger the tracepoint in kfree_skb, test_pkt_access is used for its test_run, as in kfree_skb.c. Because the test process is different from others, a new setup type is defined, i.e., SETUP_SKB_PROG_TP. The result is like: $ ./test_progs -t 'dynptr/test_dynptr_skb_tp_btf' #77/14 dynptr/test_dynptr_skb_tp_btf:OK #77 dynptr:OK #120 kfunc_dynptr_param:OK Summary: 2/1 PASSED, 0 SKIPPED, 0 FAILED $ ./test_progs -t 'dynptr/skb_invalid_ctx_f' #77/83 dynptr/skb_invalid_ctx_fentry:OK #77/84 dynptr/skb_invalid_ctx_fexit:OK #77 dynptr:OK #120 kfunc_dynptr_param:OK Summary: 2/2 PASSED, 0 SKIPPED, 0 FAILED Also fix two coding style nits (change spaces to tabs). Signed-off-by: Philo Lu <lulie@linux.alibaba.com>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
May 6, 2024
Add 3 test cases for skb dynptr used in tp_btf: - test_dynptr_skb_tp_btf: use skb dynptr in tp_btf and make sure it is read-only. - skb_invalid_ctx_fentry/skb_invalid_ctx_fexit: bpf_dynptr_from_skb should fail in fentry/fexit. In test_dynptr_skb_tp_btf, to trigger the tracepoint in kfree_skb, test_pkt_access is used for its test_run, as in kfree_skb.c. Because the test process is different from others, a new setup type is defined, i.e., SETUP_SKB_PROG_TP. The result is like: $ ./test_progs -t 'dynptr/test_dynptr_skb_tp_btf' #77/14 dynptr/test_dynptr_skb_tp_btf:OK #77 dynptr:OK #120 kfunc_dynptr_param:OK Summary: 2/1 PASSED, 0 SKIPPED, 0 FAILED $ ./test_progs -t 'dynptr/skb_invalid_ctx_f' #77/83 dynptr/skb_invalid_ctx_fentry:OK #77/84 dynptr/skb_invalid_ctx_fexit:OK #77 dynptr:OK #120 kfunc_dynptr_param:OK Summary: 2/2 PASSED, 0 SKIPPED, 0 FAILED Also fix two coding style nits (change spaces to tabs). Signed-off-by: Philo Lu <lulie@linux.alibaba.com>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
May 6, 2024
Add 3 test cases for skb dynptr used in tp_btf: - test_dynptr_skb_tp_btf: use skb dynptr in tp_btf and make sure it is read-only. - skb_invalid_ctx_fentry/skb_invalid_ctx_fexit: bpf_dynptr_from_skb should fail in fentry/fexit. In test_dynptr_skb_tp_btf, to trigger the tracepoint in kfree_skb, test_pkt_access is used for its test_run, as in kfree_skb.c. Because the test process is different from others, a new setup type is defined, i.e., SETUP_SKB_PROG_TP. The result is like: $ ./test_progs -t 'dynptr/test_dynptr_skb_tp_btf' #77/14 dynptr/test_dynptr_skb_tp_btf:OK #77 dynptr:OK #120 kfunc_dynptr_param:OK Summary: 2/1 PASSED, 0 SKIPPED, 0 FAILED $ ./test_progs -t 'dynptr/skb_invalid_ctx_f' #77/83 dynptr/skb_invalid_ctx_fentry:OK #77/84 dynptr/skb_invalid_ctx_fexit:OK #77 dynptr:OK #120 kfunc_dynptr_param:OK Summary: 2/2 PASSED, 0 SKIPPED, 0 FAILED Also fix two coding style nits (change spaces to tabs). Signed-off-by: Philo Lu <lulie@linux.alibaba.com>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
Jul 4, 2024
There are so many "ENOTSUPP" (-524) errors when running BPF selftests on a Loongarch platform since lacking BPF trampoline on Loongarch: ''' test_d_path_basic:PASS:setup 0 nsec libbpf: prog 'prog_stat': failed to attach: unknown error (-524) libbpf: prog 'prog_stat': failed to auto-attach: -524 test_d_path_basic:FAIL:setup attach failed: -524 #77/1 d_path/basic:FAIL #77/2 d_path/check_rdonly_mem:OK #77/3 d_path/check_alloc_mem:OK #77 d_path:FAIL ... ... test_module_attach:PASS:skel_open 0 nsec test_module_attach:PASS:set_attach_target 0 nsec test_module_attach:PASS:set_attach_target_explicit 0 nsec test_module_attach:PASS:skel_load 0 nsec libbpf: prog 'handle_fentry': failed to attach: unknown error (-524) libbpf: prog 'handle_fentry': failed to auto-attach: -524 test_module_attach:FAIL:skel_attach skeleton attach failed: -524 #167 module_attach:FAIL ... ... ringbuf_subtest:PASS:skel_open 0 nsec ringbuf_subtest:PASS:skel_load 0 nsec ringbuf_subtest:PASS:rw_cons_pos 0 nsec ringbuf_subtest:PASS:rw_extend 0 nsec ringbuf_subtest:PASS:exec_cons_pos_protect 0 nsec ringbuf_subtest:PASS:unmap_rw 0 nsec ringbuf_subtest:PASS:wr_prod_pos 0 nsec ringbuf_subtest:PASS:wr_prod_pos_err 0 nsec ringbuf_subtest:PASS:wr_data_page_one 0 nsec ringbuf_subtest:PASS:wr_data_page_one_err 0 nsec ringbuf_subtest:PASS:wr_data_page_two 0 nsec ringbuf_subtest:PASS:wr_data_page_all 0 nsec ringbuf_subtest:PASS:ro_prod_pos 0 nsec ringbuf_subtest:PASS:write_protect 0 nsec ringbuf_subtest:PASS:exec_protect 0 nsec ringbuf_subtest:PASS:ro_remap 0 nsec ringbuf_subtest:PASS:unmap_ro 0 nsec ringbuf_subtest:PASS:ro_prod_pos 0 nsec ringbuf_subtest:PASS:write_protect 0 nsec ringbuf_subtest:PASS:exec_protect 0 nsec ringbuf_subtest:PASS:ro_remap 0 nsec ringbuf_subtest:PASS:unmap_ro 0 nsec ringbuf_subtest:PASS:ringbuf_create 0 nsec ringbuf_subtest:FAIL:skel_attach skeleton attachment failed: -1 #277/1 ringbuf/ringbuf:FAIL #277/2 ringbuf/ringbuf_n:SKIP #277/3 ringbuf/ringbuf_map_key:SKIP #277 ringbuf:FAIL ... ... test_test_bprm_opts:PASS:skel_load 0 nsec libbpf: prog 'secure_exec': failed to attach: unknown error (-524) libbpf: prog 'secure_exec': failed to auto-attach: -524 test_test_bprm_opts:FAIL:attach attach failed: -524 #382 test_bprm_opts:FAIL ... ... test_test_ima:PASS:skel_load 0 nsec test_test_ima:PASS:ringbuf 0 nsec libbpf: prog 'bprm_committed_creds': failed to attach: \ unknown error (-524) libbpf: prog 'bprm_committed_creds': failed to auto-attach: -524 test_test_ima:FAIL:attach attach failed: -524 #384 test_ima:FAIL ... ... test_trace_ext:PASS:setup 0 nsec test_trace_ext:PASS:setup 0 nsec test_trace_ext:PASS:setup 0 nsec test_trace_ext:PASS:setup 0 nsec libbpf: prog 'test_pkt_md_access_new': failed to attach: \ unknown error (-524) libbpf: prog 'test_pkt_md_access_new': failed to auto-attach: -524 test_trace_ext:FAIL:setup freplace/test_pkt_md_access attach failed: -524 #397 trace_ext:FAIL ''' This patch uses ASSERT_OK() instead of CHECK() to skip these "ENOTSUPP" errors. With this change, the new output of these selftests look like: ''' #77/1 d_path/basic:SKIP #77/2 d_path/check_rdonly_mem:OK #77/3 d_path/check_alloc_mem:OK #77 d_path:OK (SKIP: 1/3) ... ... #167 module_attach:SKIP ... ... #277/1 ringbuf/ringbuf:SKIP #277/2 ringbuf/ringbuf_n:SKIP #277/3 ringbuf/ringbuf_map_key:SKIP #277 ringbuf:SKIP ... ... #382 test_bprm_opts:SKIP ... ... #384 test_ima:SKIP ... ... #397 trace_ext:SKIP ''' Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
Jul 5, 2024
There are so many "ENOTSUPP" (-524) errors when running BPF selftests on a Loongarch platform since lacking BPF trampoline on Loongarch: ''' test_d_path_basic:PASS:setup 0 nsec libbpf: prog 'prog_stat': failed to attach: unknown error (-524) libbpf: prog 'prog_stat': failed to auto-attach: -524 test_d_path_basic:FAIL:setup attach failed: -524 #77/1 d_path/basic:FAIL #77/2 d_path/check_rdonly_mem:OK #77/3 d_path/check_alloc_mem:OK #77 d_path:FAIL ... ... test_module_attach:PASS:skel_open 0 nsec test_module_attach:PASS:set_attach_target 0 nsec test_module_attach:PASS:set_attach_target_explicit 0 nsec test_module_attach:PASS:skel_load 0 nsec libbpf: prog 'handle_fentry': failed to attach: unknown error (-524) libbpf: prog 'handle_fentry': failed to auto-attach: -524 test_module_attach:FAIL:skel_attach skeleton attach failed: -524 #167 module_attach:FAIL ... ... ringbuf_subtest:PASS:skel_open 0 nsec ringbuf_subtest:PASS:skel_load 0 nsec ringbuf_subtest:PASS:rw_cons_pos 0 nsec ringbuf_subtest:PASS:rw_extend 0 nsec ringbuf_subtest:PASS:exec_cons_pos_protect 0 nsec ringbuf_subtest:PASS:unmap_rw 0 nsec ringbuf_subtest:PASS:wr_prod_pos 0 nsec ringbuf_subtest:PASS:wr_prod_pos_err 0 nsec ringbuf_subtest:PASS:wr_data_page_one 0 nsec ringbuf_subtest:PASS:wr_data_page_one_err 0 nsec ringbuf_subtest:PASS:wr_data_page_two 0 nsec ringbuf_subtest:PASS:wr_data_page_all 0 nsec ringbuf_subtest:PASS:ro_prod_pos 0 nsec ringbuf_subtest:PASS:write_protect 0 nsec ringbuf_subtest:PASS:exec_protect 0 nsec ringbuf_subtest:PASS:ro_remap 0 nsec ringbuf_subtest:PASS:unmap_ro 0 nsec ringbuf_subtest:PASS:ro_prod_pos 0 nsec ringbuf_subtest:PASS:write_protect 0 nsec ringbuf_subtest:PASS:exec_protect 0 nsec ringbuf_subtest:PASS:ro_remap 0 nsec ringbuf_subtest:PASS:unmap_ro 0 nsec ringbuf_subtest:PASS:ringbuf_create 0 nsec ringbuf_subtest:FAIL:skel_attach skeleton attachment failed: -1 #277/1 ringbuf/ringbuf:FAIL #277/2 ringbuf/ringbuf_n:SKIP #277/3 ringbuf/ringbuf_map_key:SKIP #277 ringbuf:FAIL ... ... test_test_bprm_opts:PASS:skel_load 0 nsec libbpf: prog 'secure_exec': failed to attach: unknown error (-524) libbpf: prog 'secure_exec': failed to auto-attach: -524 test_test_bprm_opts:FAIL:attach attach failed: -524 #382 test_bprm_opts:FAIL ... ... test_test_ima:PASS:skel_load 0 nsec test_test_ima:PASS:ringbuf 0 nsec libbpf: prog 'bprm_committed_creds': failed to attach: \ unknown error (-524) libbpf: prog 'bprm_committed_creds': failed to auto-attach: -524 test_test_ima:FAIL:attach attach failed: -524 #384 test_ima:FAIL ... ... test_trace_ext:PASS:setup 0 nsec test_trace_ext:PASS:setup 0 nsec test_trace_ext:PASS:setup 0 nsec test_trace_ext:PASS:setup 0 nsec libbpf: prog 'test_pkt_md_access_new': failed to attach: \ unknown error (-524) libbpf: prog 'test_pkt_md_access_new': failed to auto-attach: -524 test_trace_ext:FAIL:setup freplace/test_pkt_md_access attach failed: -524 #397 trace_ext:FAIL ''' This patch uses ASSERT_OK() instead of CHECK() to skip these "ENOTSUPP" errors. With this change, the new output of these selftests look like: ''' #77/1 d_path/basic:SKIP #77/2 d_path/check_rdonly_mem:OK #77/3 d_path/check_alloc_mem:OK #77 d_path:OK (SKIP: 1/3) ... ... #167 module_attach:SKIP ... ... #277/1 ringbuf/ringbuf:SKIP #277/2 ringbuf/ringbuf_n:SKIP #277/3 ringbuf/ringbuf_map_key:SKIP #277 ringbuf:SKIP ... ... #382 test_bprm_opts:SKIP ... ... #384 test_ima:SKIP ... ... #397 trace_ext:SKIP ''' Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
Jul 8, 2024
There are so many "ENOTSUPP" (-524) errors when running BPF selftests on a Loongarch platform since lacking BPF trampoline on Loongarch: ''' test_d_path_basic:PASS:setup 0 nsec libbpf: prog 'prog_stat': failed to attach: unknown error (-524) libbpf: prog 'prog_stat': failed to auto-attach: -524 test_d_path_basic:FAIL:setup attach failed: -524 #77/1 d_path/basic:FAIL #77/2 d_path/check_rdonly_mem:OK #77/3 d_path/check_alloc_mem:OK #77 d_path:FAIL ... ... test_module_attach:PASS:skel_open 0 nsec test_module_attach:PASS:set_attach_target 0 nsec test_module_attach:PASS:set_attach_target_explicit 0 nsec test_module_attach:PASS:skel_load 0 nsec libbpf: prog 'handle_fentry': failed to attach: unknown error (-524) libbpf: prog 'handle_fentry': failed to auto-attach: -524 test_module_attach:FAIL:skel_attach skeleton attach failed: -524 #167 module_attach:FAIL ... ... ringbuf_subtest:PASS:skel_open 0 nsec ringbuf_subtest:PASS:skel_load 0 nsec ringbuf_subtest:PASS:rw_cons_pos 0 nsec ringbuf_subtest:PASS:rw_extend 0 nsec ringbuf_subtest:PASS:exec_cons_pos_protect 0 nsec ringbuf_subtest:PASS:unmap_rw 0 nsec ringbuf_subtest:PASS:wr_prod_pos 0 nsec ringbuf_subtest:PASS:wr_prod_pos_err 0 nsec ringbuf_subtest:PASS:wr_data_page_one 0 nsec ringbuf_subtest:PASS:wr_data_page_one_err 0 nsec ringbuf_subtest:PASS:wr_data_page_two 0 nsec ringbuf_subtest:PASS:wr_data_page_all 0 nsec ringbuf_subtest:PASS:ro_prod_pos 0 nsec ringbuf_subtest:PASS:write_protect 0 nsec ringbuf_subtest:PASS:exec_protect 0 nsec ringbuf_subtest:PASS:ro_remap 0 nsec ringbuf_subtest:PASS:unmap_ro 0 nsec ringbuf_subtest:PASS:ro_prod_pos 0 nsec ringbuf_subtest:PASS:write_protect 0 nsec ringbuf_subtest:PASS:exec_protect 0 nsec ringbuf_subtest:PASS:ro_remap 0 nsec ringbuf_subtest:PASS:unmap_ro 0 nsec ringbuf_subtest:PASS:ringbuf_create 0 nsec ringbuf_subtest:FAIL:skel_attach skeleton attachment failed: -1 #277/1 ringbuf/ringbuf:FAIL #277/2 ringbuf/ringbuf_n:SKIP #277/3 ringbuf/ringbuf_map_key:SKIP #277 ringbuf:FAIL ... ... test_test_bprm_opts:PASS:skel_load 0 nsec libbpf: prog 'secure_exec': failed to attach: unknown error (-524) libbpf: prog 'secure_exec': failed to auto-attach: -524 test_test_bprm_opts:FAIL:attach attach failed: -524 #382 test_bprm_opts:FAIL ... ... test_test_ima:PASS:skel_load 0 nsec test_test_ima:PASS:ringbuf 0 nsec libbpf: prog 'bprm_committed_creds': failed to attach: \ unknown error (-524) libbpf: prog 'bprm_committed_creds': failed to auto-attach: -524 test_test_ima:FAIL:attach attach failed: -524 #384 test_ima:FAIL ... ... test_trace_ext:PASS:setup 0 nsec test_trace_ext:PASS:setup 0 nsec test_trace_ext:PASS:setup 0 nsec test_trace_ext:PASS:setup 0 nsec libbpf: prog 'test_pkt_md_access_new': failed to attach: \ unknown error (-524) libbpf: prog 'test_pkt_md_access_new': failed to auto-attach: -524 test_trace_ext:FAIL:setup freplace/test_pkt_md_access attach failed: -524 #397 trace_ext:FAIL ''' This patch uses ASSERT_OK() instead of CHECK() to skip these "ENOTSUPP" errors. With this change, the new output of these selftests look like: ''' #77/1 d_path/basic:SKIP #77/2 d_path/check_rdonly_mem:OK #77/3 d_path/check_alloc_mem:OK #77 d_path:OK (SKIP: 1/3) ... ... #167 module_attach:SKIP ... ... #277/1 ringbuf/ringbuf:SKIP #277/2 ringbuf/ringbuf_n:SKIP #277/3 ringbuf/ringbuf_map_key:SKIP #277 ringbuf:SKIP ... ... #382 test_bprm_opts:SKIP ... ... #384 test_ima:SKIP ... ... #397 trace_ext:SKIP ''' Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
Jul 8, 2024
There are so many "ENOTSUPP" (-524) errors when running BPF selftests on a Loongarch platform since lacking BPF trampoline on Loongarch: ''' test_d_path_basic:PASS:setup 0 nsec libbpf: prog 'prog_stat': failed to attach: unknown error (-524) libbpf: prog 'prog_stat': failed to auto-attach: -524 test_d_path_basic:FAIL:setup attach failed: -524 #77/1 d_path/basic:FAIL #77/2 d_path/check_rdonly_mem:OK #77/3 d_path/check_alloc_mem:OK #77 d_path:FAIL ... ... test_module_attach:PASS:skel_open 0 nsec test_module_attach:PASS:set_attach_target 0 nsec test_module_attach:PASS:set_attach_target_explicit 0 nsec test_module_attach:PASS:skel_load 0 nsec libbpf: prog 'handle_fentry': failed to attach: unknown error (-524) libbpf: prog 'handle_fentry': failed to auto-attach: -524 test_module_attach:FAIL:skel_attach skeleton attach failed: -524 #167 module_attach:FAIL ... ... ringbuf_subtest:PASS:skel_open 0 nsec ringbuf_subtest:PASS:skel_load 0 nsec ringbuf_subtest:PASS:rw_cons_pos 0 nsec ringbuf_subtest:PASS:rw_extend 0 nsec ringbuf_subtest:PASS:exec_cons_pos_protect 0 nsec ringbuf_subtest:PASS:unmap_rw 0 nsec ringbuf_subtest:PASS:wr_prod_pos 0 nsec ringbuf_subtest:PASS:wr_prod_pos_err 0 nsec ringbuf_subtest:PASS:wr_data_page_one 0 nsec ringbuf_subtest:PASS:wr_data_page_one_err 0 nsec ringbuf_subtest:PASS:wr_data_page_two 0 nsec ringbuf_subtest:PASS:wr_data_page_all 0 nsec ringbuf_subtest:PASS:ro_prod_pos 0 nsec ringbuf_subtest:PASS:write_protect 0 nsec ringbuf_subtest:PASS:exec_protect 0 nsec ringbuf_subtest:PASS:ro_remap 0 nsec ringbuf_subtest:PASS:unmap_ro 0 nsec ringbuf_subtest:PASS:ro_prod_pos 0 nsec ringbuf_subtest:PASS:write_protect 0 nsec ringbuf_subtest:PASS:exec_protect 0 nsec ringbuf_subtest:PASS:ro_remap 0 nsec ringbuf_subtest:PASS:unmap_ro 0 nsec ringbuf_subtest:PASS:ringbuf_create 0 nsec ringbuf_subtest:FAIL:skel_attach skeleton attachment failed: -1 #277/1 ringbuf/ringbuf:FAIL #277/2 ringbuf/ringbuf_n:SKIP #277/3 ringbuf/ringbuf_map_key:SKIP #277 ringbuf:FAIL ... ... test_test_bprm_opts:PASS:skel_load 0 nsec libbpf: prog 'secure_exec': failed to attach: unknown error (-524) libbpf: prog 'secure_exec': failed to auto-attach: -524 test_test_bprm_opts:FAIL:attach attach failed: -524 #382 test_bprm_opts:FAIL ... ... test_test_ima:PASS:skel_load 0 nsec test_test_ima:PASS:ringbuf 0 nsec libbpf: prog 'bprm_committed_creds': failed to attach: \ unknown error (-524) libbpf: prog 'bprm_committed_creds': failed to auto-attach: -524 test_test_ima:FAIL:attach attach failed: -524 #384 test_ima:FAIL ... ... test_trace_ext:PASS:setup 0 nsec test_trace_ext:PASS:setup 0 nsec test_trace_ext:PASS:setup 0 nsec test_trace_ext:PASS:setup 0 nsec libbpf: prog 'test_pkt_md_access_new': failed to attach: \ unknown error (-524) libbpf: prog 'test_pkt_md_access_new': failed to auto-attach: -524 test_trace_ext:FAIL:setup freplace/test_pkt_md_access attach failed: -524 #397 trace_ext:FAIL ''' This patch uses ASSERT_OK() instead of CHECK() to skip these "ENOTSUPP" errors. With this change, the new output of these selftests look like: ''' #77/1 d_path/basic:SKIP #77/2 d_path/check_rdonly_mem:OK #77/3 d_path/check_alloc_mem:OK #77 d_path:OK (SKIP: 1/3) ... ... #167 module_attach:SKIP ... ... #277/1 ringbuf/ringbuf:SKIP #277/2 ringbuf/ringbuf_n:SKIP #277/3 ringbuf/ringbuf_map_key:SKIP #277 ringbuf:SKIP ... ... #382 test_bprm_opts:SKIP ... ... #384 test_ima:SKIP ... ... #397 trace_ext:SKIP ''' Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
Jul 8, 2024
There are so many "ENOTSUPP" (-524) errors when running BPF selftests on a Loongarch platform since lacking BPF trampoline on Loongarch: ''' test_d_path_basic:PASS:setup 0 nsec libbpf: prog 'prog_stat': failed to attach: unknown error (-524) libbpf: prog 'prog_stat': failed to auto-attach: -524 test_d_path_basic:FAIL:setup attach failed: -524 #77/1 d_path/basic:FAIL #77/2 d_path/check_rdonly_mem:OK #77/3 d_path/check_alloc_mem:OK #77 d_path:FAIL ... ... test_module_attach:PASS:skel_open 0 nsec test_module_attach:PASS:set_attach_target 0 nsec test_module_attach:PASS:set_attach_target_explicit 0 nsec test_module_attach:PASS:skel_load 0 nsec libbpf: prog 'handle_fentry': failed to attach: unknown error (-524) libbpf: prog 'handle_fentry': failed to auto-attach: -524 test_module_attach:FAIL:skel_attach skeleton attach failed: -524 #167 module_attach:FAIL ... ... ringbuf_subtest:PASS:skel_open 0 nsec ringbuf_subtest:PASS:skel_load 0 nsec ringbuf_subtest:PASS:rw_cons_pos 0 nsec ringbuf_subtest:PASS:rw_extend 0 nsec ringbuf_subtest:PASS:exec_cons_pos_protect 0 nsec ringbuf_subtest:PASS:unmap_rw 0 nsec ringbuf_subtest:PASS:wr_prod_pos 0 nsec ringbuf_subtest:PASS:wr_prod_pos_err 0 nsec ringbuf_subtest:PASS:wr_data_page_one 0 nsec ringbuf_subtest:PASS:wr_data_page_one_err 0 nsec ringbuf_subtest:PASS:wr_data_page_two 0 nsec ringbuf_subtest:PASS:wr_data_page_all 0 nsec ringbuf_subtest:PASS:ro_prod_pos 0 nsec ringbuf_subtest:PASS:write_protect 0 nsec ringbuf_subtest:PASS:exec_protect 0 nsec ringbuf_subtest:PASS:ro_remap 0 nsec ringbuf_subtest:PASS:unmap_ro 0 nsec ringbuf_subtest:PASS:ro_prod_pos 0 nsec ringbuf_subtest:PASS:write_protect 0 nsec ringbuf_subtest:PASS:exec_protect 0 nsec ringbuf_subtest:PASS:ro_remap 0 nsec ringbuf_subtest:PASS:unmap_ro 0 nsec ringbuf_subtest:PASS:ringbuf_create 0 nsec ringbuf_subtest:FAIL:skel_attach skeleton attachment failed: -1 #277/1 ringbuf/ringbuf:FAIL #277/2 ringbuf/ringbuf_n:SKIP #277/3 ringbuf/ringbuf_map_key:SKIP #277 ringbuf:FAIL ... ... test_test_bprm_opts:PASS:skel_load 0 nsec libbpf: prog 'secure_exec': failed to attach: unknown error (-524) libbpf: prog 'secure_exec': failed to auto-attach: -524 test_test_bprm_opts:FAIL:attach attach failed: -524 #382 test_bprm_opts:FAIL ... ... test_test_ima:PASS:skel_load 0 nsec test_test_ima:PASS:ringbuf 0 nsec libbpf: prog 'bprm_committed_creds': failed to attach: \ unknown error (-524) libbpf: prog 'bprm_committed_creds': failed to auto-attach: -524 test_test_ima:FAIL:attach attach failed: -524 #384 test_ima:FAIL ... ... test_trace_ext:PASS:setup 0 nsec test_trace_ext:PASS:setup 0 nsec test_trace_ext:PASS:setup 0 nsec test_trace_ext:PASS:setup 0 nsec libbpf: prog 'test_pkt_md_access_new': failed to attach: \ unknown error (-524) libbpf: prog 'test_pkt_md_access_new': failed to auto-attach: -524 test_trace_ext:FAIL:setup freplace/test_pkt_md_access attach failed: -524 #397 trace_ext:FAIL ''' This patch uses ASSERT_OK() instead of CHECK() to skip these "ENOTSUPP" errors. With this change, the new output of these selftests look like: ''' #77/1 d_path/basic:SKIP #77/2 d_path/check_rdonly_mem:OK #77/3 d_path/check_alloc_mem:OK #77 d_path:OK (SKIP: 1/3) ... ... #167 module_attach:SKIP ... ... #277/1 ringbuf/ringbuf:SKIP #277/2 ringbuf/ringbuf_n:SKIP #277/3 ringbuf/ringbuf_map_key:SKIP #277 ringbuf:SKIP ... ... #382 test_bprm_opts:SKIP ... ... #384 test_ima:SKIP ... ... #397 trace_ext:SKIP ''' Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
Jul 8, 2024
There are so many "ENOTSUPP" (-524) errors when running BPF selftests on a Loongarch platform since lacking BPF trampoline on Loongarch: ''' test_d_path_basic:PASS:setup 0 nsec libbpf: prog 'prog_stat': failed to attach: unknown error (-524) libbpf: prog 'prog_stat': failed to auto-attach: -524 test_d_path_basic:FAIL:setup attach failed: -524 #77/1 d_path/basic:FAIL #77/2 d_path/check_rdonly_mem:OK #77/3 d_path/check_alloc_mem:OK #77 d_path:FAIL ... ... test_module_attach:PASS:skel_open 0 nsec test_module_attach:PASS:set_attach_target 0 nsec test_module_attach:PASS:set_attach_target_explicit 0 nsec test_module_attach:PASS:skel_load 0 nsec libbpf: prog 'handle_fentry': failed to attach: unknown error (-524) libbpf: prog 'handle_fentry': failed to auto-attach: -524 test_module_attach:FAIL:skel_attach skeleton attach failed: -524 #167 module_attach:FAIL ... ... ringbuf_subtest:PASS:skel_open 0 nsec ringbuf_subtest:PASS:skel_load 0 nsec ringbuf_subtest:PASS:rw_cons_pos 0 nsec ringbuf_subtest:PASS:rw_extend 0 nsec ringbuf_subtest:PASS:exec_cons_pos_protect 0 nsec ringbuf_subtest:PASS:unmap_rw 0 nsec ringbuf_subtest:PASS:wr_prod_pos 0 nsec ringbuf_subtest:PASS:wr_prod_pos_err 0 nsec ringbuf_subtest:PASS:wr_data_page_one 0 nsec ringbuf_subtest:PASS:wr_data_page_one_err 0 nsec ringbuf_subtest:PASS:wr_data_page_two 0 nsec ringbuf_subtest:PASS:wr_data_page_all 0 nsec ringbuf_subtest:PASS:ro_prod_pos 0 nsec ringbuf_subtest:PASS:write_protect 0 nsec ringbuf_subtest:PASS:exec_protect 0 nsec ringbuf_subtest:PASS:ro_remap 0 nsec ringbuf_subtest:PASS:unmap_ro 0 nsec ringbuf_subtest:PASS:ro_prod_pos 0 nsec ringbuf_subtest:PASS:write_protect 0 nsec ringbuf_subtest:PASS:exec_protect 0 nsec ringbuf_subtest:PASS:ro_remap 0 nsec ringbuf_subtest:PASS:unmap_ro 0 nsec ringbuf_subtest:PASS:ringbuf_create 0 nsec ringbuf_subtest:FAIL:skel_attach skeleton attachment failed: -1 #277/1 ringbuf/ringbuf:FAIL #277/2 ringbuf/ringbuf_n:SKIP #277/3 ringbuf/ringbuf_map_key:SKIP #277 ringbuf:FAIL ... ... test_test_bprm_opts:PASS:skel_load 0 nsec libbpf: prog 'secure_exec': failed to attach: unknown error (-524) libbpf: prog 'secure_exec': failed to auto-attach: -524 test_test_bprm_opts:FAIL:attach attach failed: -524 #382 test_bprm_opts:FAIL ... ... test_test_ima:PASS:skel_load 0 nsec test_test_ima:PASS:ringbuf 0 nsec libbpf: prog 'bprm_committed_creds': failed to attach: \ unknown error (-524) libbpf: prog 'bprm_committed_creds': failed to auto-attach: -524 test_test_ima:FAIL:attach attach failed: -524 #384 test_ima:FAIL ... ... test_trace_ext:PASS:setup 0 nsec test_trace_ext:PASS:setup 0 nsec test_trace_ext:PASS:setup 0 nsec test_trace_ext:PASS:setup 0 nsec libbpf: prog 'test_pkt_md_access_new': failed to attach: \ unknown error (-524) libbpf: prog 'test_pkt_md_access_new': failed to auto-attach: -524 test_trace_ext:FAIL:setup freplace/test_pkt_md_access attach failed: -524 #397 trace_ext:FAIL ''' This patch uses ASSERT_OK() instead of CHECK() to skip these "ENOTSUPP" errors. With this change, the new output of these selftests look like: ''' #77/1 d_path/basic:SKIP #77/2 d_path/check_rdonly_mem:OK #77/3 d_path/check_alloc_mem:OK #77 d_path:OK (SKIP: 1/3) ... ... #167 module_attach:SKIP ... ... #277/1 ringbuf/ringbuf:SKIP #277/2 ringbuf/ringbuf_n:SKIP #277/3 ringbuf/ringbuf_map_key:SKIP #277 ringbuf:SKIP ... ... #382 test_bprm_opts:SKIP ... ... #384 test_ima:SKIP ... ... #397 trace_ext:SKIP ''' Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
Jul 8, 2024
There are so many "ENOTSUPP" (-524) errors when running BPF selftests on a Loongarch platform since lacking BPF trampoline on Loongarch: ''' test_d_path_basic:PASS:setup 0 nsec libbpf: prog 'prog_stat': failed to attach: unknown error (-524) libbpf: prog 'prog_stat': failed to auto-attach: -524 test_d_path_basic:FAIL:setup attach failed: -524 #77/1 d_path/basic:FAIL #77/2 d_path/check_rdonly_mem:OK #77/3 d_path/check_alloc_mem:OK #77 d_path:FAIL ... ... test_module_attach:PASS:skel_open 0 nsec test_module_attach:PASS:set_attach_target 0 nsec test_module_attach:PASS:set_attach_target_explicit 0 nsec test_module_attach:PASS:skel_load 0 nsec libbpf: prog 'handle_fentry': failed to attach: unknown error (-524) libbpf: prog 'handle_fentry': failed to auto-attach: -524 test_module_attach:FAIL:skel_attach skeleton attach failed: -524 #167 module_attach:FAIL ... ... ringbuf_subtest:PASS:skel_open 0 nsec ringbuf_subtest:PASS:skel_load 0 nsec ringbuf_subtest:PASS:rw_cons_pos 0 nsec ringbuf_subtest:PASS:rw_extend 0 nsec ringbuf_subtest:PASS:exec_cons_pos_protect 0 nsec ringbuf_subtest:PASS:unmap_rw 0 nsec ringbuf_subtest:PASS:wr_prod_pos 0 nsec ringbuf_subtest:PASS:wr_prod_pos_err 0 nsec ringbuf_subtest:PASS:wr_data_page_one 0 nsec ringbuf_subtest:PASS:wr_data_page_one_err 0 nsec ringbuf_subtest:PASS:wr_data_page_two 0 nsec ringbuf_subtest:PASS:wr_data_page_all 0 nsec ringbuf_subtest:PASS:ro_prod_pos 0 nsec ringbuf_subtest:PASS:write_protect 0 nsec ringbuf_subtest:PASS:exec_protect 0 nsec ringbuf_subtest:PASS:ro_remap 0 nsec ringbuf_subtest:PASS:unmap_ro 0 nsec ringbuf_subtest:PASS:ro_prod_pos 0 nsec ringbuf_subtest:PASS:write_protect 0 nsec ringbuf_subtest:PASS:exec_protect 0 nsec ringbuf_subtest:PASS:ro_remap 0 nsec ringbuf_subtest:PASS:unmap_ro 0 nsec ringbuf_subtest:PASS:ringbuf_create 0 nsec ringbuf_subtest:FAIL:skel_attach skeleton attachment failed: -1 #277/1 ringbuf/ringbuf:FAIL #277/2 ringbuf/ringbuf_n:SKIP #277/3 ringbuf/ringbuf_map_key:SKIP #277 ringbuf:FAIL ... ... test_test_bprm_opts:PASS:skel_load 0 nsec libbpf: prog 'secure_exec': failed to attach: unknown error (-524) libbpf: prog 'secure_exec': failed to auto-attach: -524 test_test_bprm_opts:FAIL:attach attach failed: -524 #382 test_bprm_opts:FAIL ... ... test_test_ima:PASS:skel_load 0 nsec test_test_ima:PASS:ringbuf 0 nsec libbpf: prog 'bprm_committed_creds': failed to attach: \ unknown error (-524) libbpf: prog 'bprm_committed_creds': failed to auto-attach: -524 test_test_ima:FAIL:attach attach failed: -524 #384 test_ima:FAIL ... ... test_trace_ext:PASS:setup 0 nsec test_trace_ext:PASS:setup 0 nsec test_trace_ext:PASS:setup 0 nsec test_trace_ext:PASS:setup 0 nsec libbpf: prog 'test_pkt_md_access_new': failed to attach: \ unknown error (-524) libbpf: prog 'test_pkt_md_access_new': failed to auto-attach: -524 test_trace_ext:FAIL:setup freplace/test_pkt_md_access attach failed: -524 #397 trace_ext:FAIL ''' This patch uses ASSERT_OK() instead of CHECK() to skip these "ENOTSUPP" errors. With this change, the new output of these selftests look like: ''' #77/1 d_path/basic:SKIP #77/2 d_path/check_rdonly_mem:OK #77/3 d_path/check_alloc_mem:OK #77 d_path:OK (SKIP: 1/3) ... ... #167 module_attach:SKIP ... ... #277/1 ringbuf/ringbuf:SKIP #277/2 ringbuf/ringbuf_n:SKIP #277/3 ringbuf/ringbuf_map_key:SKIP #277 ringbuf:SKIP ... ... #382 test_bprm_opts:SKIP ... ... #384 test_ima:SKIP ... ... #397 trace_ext:SKIP ''' Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
Dec 21, 2024
…uctions Add the following ./test_progs tests: * atomics/load_acquire * atomics/store_release * arena_atomics/load_acquire * arena_atomics/store_release They depend on the pre-defined __BPF_FEATURE_LOAD_ACQ_STORE_REL feature macro, which implies -mcpu>=v4. $ ALLOWLIST=atomics/load_acquire,atomics/store_release, $ ALLOWLIST+=arena_atomics/load_acquire,arena_atomics/store_release $ ./test_progs-cpuv4 -a $ALLOWLIST #3/9 arena_atomics/load_acquire:OK #3/10 arena_atomics/store_release:OK ... #10/8 atomics/load_acquire:OK #10/9 atomics/store_release:OK $ ./test_progs -v -a $ALLOWLIST test_load_acquire:SKIP:Clang does not support BPF load-acquire or addr_space_cast #3/9 arena_atomics/load_acquire:SKIP test_store_release:SKIP:Clang does not support BPF store-release or addr_space_cast #3/10 arena_atomics/store_release:SKIP ... test_load_acquire:SKIP:Clang does not support BPF load-acquire #10/8 atomics/load_acquire:SKIP test_store_release:SKIP:Clang does not support BPF store-release #10/9 atomics/store_release:SKIP Additionally, add several ./test_verifier tests: #65/u atomic BPF_LOAD_ACQ access through non-pointer OK #65/p atomic BPF_LOAD_ACQ access through non-pointer OK #66/u atomic BPF_STORE_REL access through non-pointer OK #66/p atomic BPF_STORE_REL access through non-pointer OK #67/u BPF_ATOMIC load-acquire, 8-bit OK #67/p BPF_ATOMIC load-acquire, 8-bit OK #68/u BPF_ATOMIC load-acquire, 16-bit OK #68/p BPF_ATOMIC load-acquire, 16-bit OK #69/u BPF_ATOMIC load-acquire, 32-bit OK #69/p BPF_ATOMIC load-acquire, 32-bit OK #70/u BPF_ATOMIC load-acquire, 64-bit OK #70/p BPF_ATOMIC load-acquire, 64-bit OK #71/u Cannot load-acquire from uninitialized src_reg OK #71/p Cannot load-acquire from uninitialized src_reg OK #76/u BPF_ATOMIC store-release, 8-bit OK #76/p BPF_ATOMIC store-release, 8-bit OK #77/u BPF_ATOMIC store-release, 16-bit OK #77/p BPF_ATOMIC store-release, 16-bit OK #78/u BPF_ATOMIC store-release, 32-bit OK #78/p BPF_ATOMIC store-release, 32-bit OK #79/u BPF_ATOMIC store-release, 64-bit OK #79/p BPF_ATOMIC store-release, 64-bit OK #80/u Cannot store-release from uninitialized src_reg OK #80/p Cannot store-release from uninitialized src_reg OK Reviewed-by: Josh Don <joshdon@google.com> Signed-off-by: Peilin Ye <yepeilin@google.com>
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: bpf: Fix potential call bpf_link_free() in atomic context
version: 1
url: https://patchwork.ozlabs.org/project/netdev/list/?series=202339