Skip to content

tools/bpf: Return the appropriate error value #447

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
wants to merge 1 commit into from
Closed

tools/bpf: Return the appropriate error value #447

wants to merge 1 commit into from

Conversation

kernel-patches-bot
Copy link

Pull request for series with
subject: tools/bpf: Return the appropriate error value
version: 1
url: https://patchwork.kernel.org/project/netdevbpf/list/?series=393657

@kernel-patches-bot
Copy link
Author

Master branch: ba05817
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=393657
version: 1

Pull request is NOT updated. Failed to apply https://patchwork.kernel.org/project/netdevbpf/list/?series=393657
error message:

Cmd('git') failed due to: exit code(128)
  cmdline: git am -3
  stdout: 'Applying: tools/bpf: Return the appropriate error value
Using index info to reconstruct a base tree...
M	tools/lib/bpf/btf.c
Patch failed at 0001 tools/bpf: Return the appropriate error value
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".'
  stderr: 'error: patch failed: tools/lib/bpf/btf.c:865
error: tools/lib/bpf/btf.c: patch does not apply
error: Did you hand edit your patch?
It does not apply to blobs recorded in its index.
hint: Use 'git am --show-current-patch' to see the failed patch'

conflict:

@kernel-patches-bot
Copy link
Author

At least one diff in series https://patchwork.kernel.org/project/netdevbpf/list/?series=393657 expired. Closing PR.

@kernel-patches-bot kernel-patches-bot deleted the series/393657=>bpf-next branch December 4, 2020 09:50
kernel-patches-bot pushed a commit that referenced this pull request Aug 11, 2021
@mark-bloch @kuba-moo
net/sched: cls_api, reset flags on replay
a5397d6 
tc_new_tfilter() can replay a request if it got EAGAIN. The cited commit
didn't account for this when it converted TC action ->init() API
to use flags instead of parameters. This can lead to passing stale flags
down the call chain which results in trying to lock rtnl when it's
already locked, deadlocking the entire system.

Fix by making sure to reset flags on each replay.

============================================
WARNING: possible recursive locking detected
5.14.0-rc3-custom-49011-g3d2bbb4f104d #447 Not tainted
--------------------------------------------
tc/37605 is trying to acquire lock:
ffffffff841df2f0 (rtnl_mutex){+.+.}-{3:3}, at: tc_setup_cb_add+0x14b/0x4d0

but task is already holding lock:
ffffffff841df2f0 (rtnl_mutex){+.+.}-{3:3}, at: tc_new_tfilter+0xb12/0x22e0

other info that might help us debug this:
 Possible unsafe locking scenario:
       CPU0
       ----
  lock(rtnl_mutex);
  lock(rtnl_mutex);

 *** DEADLOCK ***
 May be due to missing lock nesting notation
1 lock held by tc/37605:
 #0: ffffffff841df2f0 (rtnl_mutex){+.+.}-{3:3}, at: tc_new_tfilter+0xb12/0x22e0

stack backtrace:
CPU: 0 PID: 37605 Comm: tc Not tainted 5.14.0-rc3-custom-49011-g3d2bbb4f104d #447
Hardware name: Mellanox Technologies Ltd. MSN2010/SA002610, BIOS 5.6.5 08/24/2017
Call Trace:
 dump_stack_lvl+0x8b/0xb3
 __lock_acquire.cold+0x175/0x3cb
 lock_acquire+0x1a4/0x4f0
 __mutex_lock+0x136/0x10d0
 fl_hw_replace_filter+0x458/0x630 [cls_flower]
 fl_change+0x25f2/0x4a64 [cls_flower]
 tc_new_tfilter+0xa65/0x22e0
 rtnetlink_rcv_msg+0x86c/0xc60
 netlink_rcv_skb+0x14d/0x430
 netlink_unicast+0x539/0x7e0
 netlink_sendmsg+0x84d/0xd80
 ____sys_sendmsg+0x7ff/0x970
 ___sys_sendmsg+0xf8/0x170
 __sys_sendmsg+0xea/0x1b0
 do_syscall_64+0x35/0x80
 entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f7b93b6c0a7
Code: 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2e 00 00 00 0f 05 <48>
RSP: 002b:00007ffe365b3818 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f7b93b6c0a7
RDX: 0000000000000000 RSI: 00007ffe365b3880 RDI: 0000000000000003
RBP: 00000000610a75f6 R08: 0000000000000001 R09: 0000000000000000
R10: fffffffffffff3a9 R11: 0000000000000246 R12: 0000000000000001
R13: 0000000000000000 R14: 00007ffe365b7b58 R15: 00000000004822c0

Fixes: 695176b ("net_sched: refactor TC action init API")
Signed-off-by: Mark Bloch <mbloch@nvidia.com>
Reviewed-by: Vlad Buslov <vladbu@nvidia.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Tested-by: Ido Schimmel <idosch@nvidia.com>
Link: https://lore.kernel.org/r/20210810034305.63997-1-mbloch@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Tropicao added a commit to Tropicao/bpf that referenced this pull request Oct 3, 2025
@Tropicao
selftests/bpf: integrate test_tc_tunnel.sh tests into test_progs
3a332c2 
The test_tc_tunnel.sh checks that a large variety of tunneling
mechanisms handled by the kernel can be handled as well by eBPF
programs. While this test shares similarities with test_tunnel.c (which is
already integrated in test_progs), those are testing slightly different
things:
- test_tunnel.c get and set tunnel keys in packet metadata with the corresponding
  bpf-helpers
- test_tc_tunnels.sh manually parses/crafts packets content

Bring the tests covered by test_tc_tunnel.sh into the test_progs
framework, by creating a dedicated test_tc_tunnel.sh. This new test
defines a "generic" runner which, for each test configuration:
- will bring the relevant veth pair, each of those isolated in a
  dedicated namespace
- will check that traffic will fail if there is only an encapsulating
  program attached to one veth egress
- will check that traffic succeed if we enable some decapsulation module
  on kernel side
- will check that traffic still succeeds if we replace the kernel
  decapsulation with some eBPF ingress decapsulation.

Example of the new test execution:

  # ./test_progs -a tc_tunnel
  kernel-patches#447/1   tc_tunnel/ipip_none:OK
  kernel-patches#447/2   tc_tunnel/ipip6_none:OK
  kernel-patches#447/3   tc_tunnel/ip6tnl_none:OK
  kernel-patches#447/4   tc_tunnel/sit_none:OK
  kernel-patches#447/5   tc_tunnel/vxlan_eth:OK
  kernel-patches#447/6   tc_tunnel/ip6vxlan_eth:OK
  kernel-patches#447/7   tc_tunnel/gre_none:OK
  kernel-patches#447/8   tc_tunnel/gre_eth:OK
  kernel-patches#447/9   tc_tunnel/gre_mpls:OK
  kernel-patches#447/10  tc_tunnel/ip6gre_none:OK
  kernel-patches#447/11  tc_tunnel/ip6gre_eth:OK
  kernel-patches#447/12  tc_tunnel/ip6gre_mpls:OK
  kernel-patches#447/13  tc_tunnel/udp_none:OK
  kernel-patches#447/14  tc_tunnel/udp_eth:OK
  kernel-patches#447/15  tc_tunnel/udp_mpls:OK
  kernel-patches#447/16  tc_tunnel/ip6udp_none:OK
  kernel-patches#447/17  tc_tunnel/ip6udp_eth:OK
  kernel-patches#447/18  tc_tunnel/ip6udp_mpls:OK
  kernel-patches#447     tc_tunnel:OK
  Summary: 1/18 PASSED, 0 SKIPPED, 0 FAILED

Signed-off-by: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>
Tropicao added a commit to Tropicao/bpf that referenced this pull request Oct 3, 2025
@Tropicao
selftests/bpf: integrate test_tc_tunnel.sh tests into test_progs
367b179 
The test_tc_tunnel.sh checks that a large variety of tunneling
mechanisms handled by the kernel can be handled as well by eBPF
programs. While this test shares similarities with test_tunnel.c (which is
already integrated in test_progs), those are testing slightly different
things:
- test_tunnel.c get and set tunnel keys in packet metadata with the corresponding
  bpf-helpers
- test_tc_tunnels.sh manually parses/crafts packets content

Bring the tests covered by test_tc_tunnel.sh into the test_progs
framework, by creating a dedicated test_tc_tunnel.sh. This new test
defines a "generic" runner which, for each test configuration:
- will bring the relevant veth pair, each of those isolated in a
  dedicated namespace
- will check that traffic will fail if there is only an encapsulating
  program attached to one veth egress
- will check that traffic succeed if we enable some decapsulation module
  on kernel side
- will check that traffic still succeeds if we replace the kernel
  decapsulation with some eBPF ingress decapsulation.

Example of the new test execution:

  # ./test_progs -a tc_tunnel
  kernel-patches#447/1   tc_tunnel/ipip_none:OK
  kernel-patches#447/2   tc_tunnel/ipip6_none:OK
  kernel-patches#447/3   tc_tunnel/ip6tnl_none:OK
  kernel-patches#447/4   tc_tunnel/sit_none:OK
  kernel-patches#447/5   tc_tunnel/vxlan_eth:OK
  kernel-patches#447/6   tc_tunnel/ip6vxlan_eth:OK
  kernel-patches#447/7   tc_tunnel/gre_none:OK
  kernel-patches#447/8   tc_tunnel/gre_eth:OK
  kernel-patches#447/9   tc_tunnel/gre_mpls:OK
  kernel-patches#447/10  tc_tunnel/ip6gre_none:OK
  kernel-patches#447/11  tc_tunnel/ip6gre_eth:OK
  kernel-patches#447/12  tc_tunnel/ip6gre_mpls:OK
  kernel-patches#447/13  tc_tunnel/udp_none:OK
  kernel-patches#447/14  tc_tunnel/udp_eth:OK
  kernel-patches#447/15  tc_tunnel/udp_mpls:OK
  kernel-patches#447/16  tc_tunnel/ip6udp_none:OK
  kernel-patches#447/17  tc_tunnel/ip6udp_eth:OK
  kernel-patches#447/18  tc_tunnel/ip6udp_mpls:OK
  kernel-patches#447     tc_tunnel:OK
  Summary: 1/18 PASSED, 0 SKIPPED, 0 FAILED

Signed-off-by: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

bpf-next changes-requested V1

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@kernel-patches-bot