1. 18 Mar, 2022 22 commits
  2. 17 Mar, 2022 4 commits
  3. 16 Mar, 2022 7 commits
  4. 15 Mar, 2022 7 commits
    • Daniel Xu's avatar
      bpftool: man: Add missing top level docs · 6585abea
      Daniel Xu authored
      The top-level (bpftool.8) man page was missing docs for a few
      subcommands and their respective sub-sub-commands.
      
      This commit brings the top level man page up to date. Note that I've
      kept the ordering of the subcommands the same as in `bpftool help`.
      Signed-off-by: default avatarDaniel Xu <dxu@dxuuu.xyz>
      Signed-off-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      Link: https://lore.kernel.org/bpf/3049ef5dc509c0d1832f0a8b2dba2ccaad0af688.1647213551.git.dxu@dxuuu.xyz
      6585abea
    • Dmitrii Dolgov's avatar
      bpftool: Add bpf_cookie to link output · cbdaf71f
      Dmitrii Dolgov authored
      Commit 82e6b1ee ("bpf: Allow to specify user-provided bpf_cookie for
      BPF perf links") introduced the concept of user specified bpf_cookie,
      which could be accessed by BPF programs using bpf_get_attach_cookie().
      For troubleshooting purposes it is convenient to expose bpf_cookie via
      bpftool as well, so there is no need to meddle with the target BPF
      program itself.
      
      Implemented using the pid iterator BPF program to actually fetch
      bpf_cookies, which allows constraining code changes only to bpftool.
      
      $ bpftool link
      1: type 7  prog 5
              bpf_cookie 123
              pids bootstrap(81)
      Signed-off-by: default avatarDmitrii Dolgov <9erthalion6@gmail.com>
      Signed-off-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      Acked-by: default avatarYonghong Song <yhs@fb.com>
      Acked-by: default avatarQuentin Monnet <quentin@isovalent.com>
      Link: https://lore.kernel.org/bpf/20220309163112.24141-1-9erthalion6@gmail.com
      cbdaf71f
    • Guo Zhengkui's avatar
      selftests/bpf: Clean up array_size.cocci warnings · f98d6dd1
      Guo Zhengkui authored
      Clean up the array_size.cocci warnings under tools/testing/selftests/bpf/:
      
      Use `ARRAY_SIZE(arr)` instead of forms like `sizeof(arr)/sizeof(arr[0])`.
      
      tools/testing/selftests/bpf/test_cgroup_storage.c uses ARRAY_SIZE() defined
      in tools/include/linux/kernel.h (sys/sysinfo.h -> linux/kernel.h), while
      others use ARRAY_SIZE() in bpf_util.h.
      Signed-off-by: default avatarGuo Zhengkui <guozhengkui@vivo.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Link: https://lore.kernel.org/bpf/20220315130143.2403-1-guozhengkui@vivo.com
      f98d6dd1
    • Niklas Söderlund's avatar
      samples/bpf, xdpsock: Fix race when running for fix duration of time · 8fa42d78
      Niklas Söderlund authored
      When running xdpsock for a fix duration of time before terminating
      using --duration=<n>, there is a race condition that may cause xdpsock
      to terminate immediately.
      
      When running for a fixed duration of time the check to determine when to
      terminate execution is in is_benchmark_done() and is being executed in
      the context of the poller thread,
      
          if (opt_duration > 0) {
                  unsigned long dt = (get_nsecs() - start_time);
      
                  if (dt >= opt_duration)
                          benchmark_done = true;
          }
      
      However start_time is only set after the poller thread have been
      created. This leaves a small window when the poller thread is starting
      and calls is_benchmark_done() for the first time that start_time is not
      yet set. In that case start_time have its initial value of 0 and the
      duration check fails as it do not correlate correctly for the
      applications start time and immediately sets benchmark_done which in
      turn terminates the xdpsock application.
      
      Fix this by setting start_time before creating the poller thread.
      
      Fixes: d3f11b01 ("samples/bpf: xdpsock: Add duration option to specify how long to run")
      Signed-off-by: default avatarNiklas Söderlund <niklas.soderlund@corigine.com>
      Signed-off-by: default avatarSimon Horman <simon.horman@corigine.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Link: https://lore.kernel.org/bpf/20220315102948.466436-1-niklas.soderlund@corigine.com
      8fa42d78
    • Wang Yufen's avatar
      bpf, sockmap: Fix double uncharge the mem of sk_msg · 2486ab43
      Wang Yufen authored
      If tcp_bpf_sendmsg is running during a tear down operation, psock may be
      freed.
      
      tcp_bpf_sendmsg()
       tcp_bpf_send_verdict()
        sk_msg_return()
        tcp_bpf_sendmsg_redir()
         unlikely(!psock))
           sk_msg_free()
      
      The mem of msg has been uncharged in tcp_bpf_send_verdict() by
      sk_msg_return(), and would be uncharged by sk_msg_free() again. When psock
      is null, we can simply returning an error code, this would then trigger
      the sk_msg_free_nocharge in the error path of __SK_REDIRECT and would have
      the side effect of throwing an error up to user space. This would be a
      slight change in behavior from user side but would look the same as an
      error if the redirect on the socket threw an error.
      
      This issue can cause the following info:
      WARNING: CPU: 0 PID: 2136 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260
      Call Trace:
       <TASK>
       __sk_destruct+0x24/0x1f0
       sk_psock_destroy+0x19b/0x1c0
       process_one_work+0x1b3/0x3c0
       worker_thread+0x30/0x350
       ? process_one_work+0x3c0/0x3c0
       kthread+0xe6/0x110
       ? kthread_complete_and_exit+0x20/0x20
       ret_from_fork+0x22/0x30
       </TASK>
      
      Fixes: 604326b4 ("bpf, sockmap: convert to generic sk_msg interface")
      Signed-off-by: default avatarWang Yufen <wangyufen@huawei.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarJohn Fastabend <john.fastabend@gmail.com>
      Link: https://lore.kernel.org/bpf/20220304081145.2037182-5-wangyufen@huawei.com
      2486ab43
    • Wang Yufen's avatar
      bpf, sockmap: Fix more uncharged while msg has more_data · 84472b43
      Wang Yufen authored
      In tcp_bpf_send_verdict(), if msg has more data after
      tcp_bpf_sendmsg_redir():
      
      tcp_bpf_send_verdict()
       tosend = msg->sg.size  //msg->sg.size = 22220
       case __SK_REDIRECT:
        sk_msg_return()  //uncharged msg->sg.size(22220) sk->sk_forward_alloc
        tcp_bpf_sendmsg_redir() //after tcp_bpf_sendmsg_redir, msg->sg.size=11000
       goto more_data;
       tosend = msg->sg.size  //msg->sg.size = 11000
       case __SK_REDIRECT:
        sk_msg_return()  //uncharged msg->sg.size(11000) to sk->sk_forward_alloc
      
      The msg->sg.size(11000) has been uncharged twice, to fix we can charge the
      remaining msg->sg.size before goto more data.
      
      This issue can cause the following info:
      WARNING: CPU: 0 PID: 9860 at net/core/stream.c:208 sk_stream_kill_queues+0xd4/0x1a0
      Call Trace:
       <TASK>
       inet_csk_destroy_sock+0x55/0x110
       __tcp_close+0x279/0x470
       tcp_close+0x1f/0x60
       inet_release+0x3f/0x80
       __sock_release+0x3d/0xb0
       sock_close+0x11/0x20
       __fput+0x92/0x250
       task_work_run+0x6a/0xa0
       do_exit+0x33b/0xb60
       do_group_exit+0x2f/0xa0
       get_signal+0xb6/0x950
       arch_do_signal_or_restart+0xac/0x2a0
       ? vfs_write+0x237/0x290
       exit_to_user_mode_prepare+0xa9/0x200
       syscall_exit_to_user_mode+0x12/0x30
       do_syscall_64+0x46/0x80
       entry_SYSCALL_64_after_hwframe+0x44/0xae
       </TASK>
      
      WARNING: CPU: 0 PID: 2136 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260
      Call Trace:
       <TASK>
       __sk_destruct+0x24/0x1f0
       sk_psock_destroy+0x19b/0x1c0
       process_one_work+0x1b3/0x3c0
       worker_thread+0x30/0x350
       ? process_one_work+0x3c0/0x3c0
       kthread+0xe6/0x110
       ? kthread_complete_and_exit+0x20/0x20
       ret_from_fork+0x22/0x30
       </TASK>
      
      Fixes: 604326b4 ("bpf, sockmap: convert to generic sk_msg interface")
      Signed-off-by: default avatarWang Yufen <wangyufen@huawei.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarJohn Fastabend <john.fastabend@gmail.com>
      Link: https://lore.kernel.org/bpf/20220304081145.2037182-4-wangyufen@huawei.com
      84472b43
    • Wang Yufen's avatar
      bpf, sockmap: Fix memleak in tcp_bpf_sendmsg while sk msg is full · 9c34e38c
      Wang Yufen authored
      If tcp_bpf_sendmsg() is running while sk msg is full. When sk_msg_alloc()
      returns -ENOMEM error, tcp_bpf_sendmsg() goes to wait_for_memory. If partial
      memory has been alloced by sk_msg_alloc(), that is, msg_tx->sg.size is
      greater than osize after sk_msg_alloc(), memleak occurs. To fix we use
      sk_msg_trim() to release the allocated memory, then goto wait for memory.
      
      Other call paths of sk_msg_alloc() have the similar issue, such as
      tls_sw_sendmsg(), so handle sk_msg_trim logic inside sk_msg_alloc(),
      as Cong Wang suggested.
      
      This issue can cause the following info:
      WARNING: CPU: 3 PID: 7950 at net/core/stream.c:208 sk_stream_kill_queues+0xd4/0x1a0
      Call Trace:
       <TASK>
       inet_csk_destroy_sock+0x55/0x110
       __tcp_close+0x279/0x470
       tcp_close+0x1f/0x60
       inet_release+0x3f/0x80
       __sock_release+0x3d/0xb0
       sock_close+0x11/0x20
       __fput+0x92/0x250
       task_work_run+0x6a/0xa0
       do_exit+0x33b/0xb60
       do_group_exit+0x2f/0xa0
       get_signal+0xb6/0x950
       arch_do_signal_or_restart+0xac/0x2a0
       exit_to_user_mode_prepare+0xa9/0x200
       syscall_exit_to_user_mode+0x12/0x30
       do_syscall_64+0x46/0x80
       entry_SYSCALL_64_after_hwframe+0x44/0xae
       </TASK>
      
      WARNING: CPU: 3 PID: 2094 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260
      Call Trace:
       <TASK>
       __sk_destruct+0x24/0x1f0
       sk_psock_destroy+0x19b/0x1c0
       process_one_work+0x1b3/0x3c0
       kthread+0xe6/0x110
       ret_from_fork+0x22/0x30
       </TASK>
      
      Fixes: 604326b4 ("bpf, sockmap: convert to generic sk_msg interface")
      Signed-off-by: default avatarWang Yufen <wangyufen@huawei.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarJohn Fastabend <john.fastabend@gmail.com>
      Link: https://lore.kernel.org/bpf/20220304081145.2037182-3-wangyufen@huawei.com
      9c34e38c