Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 25 6月, 2023 1 次提交
  3. 21 6月, 2023 9 次提交
  5. 20 6月, 2023 7 次提交
  7. 19 6月, 2023 5 次提交
  9. 16 6月, 2023 7 次提交
  11. 15 6月, 2023 2 次提交
    • O
      !948 Dependency of Kmesh on Kernel Modification · 02df2e99
      由 openeuler-ci-bot 提交于 
      Merge Pull Request from: @bitcoffee 
 
In the kernel, Kmesh forwards customer requests to actual backend service nodes through Layer 7 orchestration. This capability is per flow. When sending msg for the first time, Kmesh parses user Layer 7 packets and completes orchestration to complete link establishment. This requires that the pseudo link be established in the connect phase and the actual link be established in the sendmsg phase.
Therefore, the following modifications are involved:
1. The ULP framework needs to be supported in the connect phase. The l4 connect function needs to be replaced with the user-defined connect function.
2. After the L4 connect function is invoked, the L3 function can invoke the actual link establishment logic based on the error code and modify the return value of inet_stream_connect at the L3 layer.
3. In the sendmsg message, you can determine whether the delay in link setup is enabled based on the sock status.

Submission Instructions:
1. Add a writeable_tracepoint to modify the return value of __inet_stream_connect in inet_stream_connect.
2. The bpf_defer_connect flag is added to indicate whether the ebpf defer connect delay link establishment logic is enabled.
3. The ULP framework is added to support the ebpf program. The ULP framework can be used in the ebpf program.
4. A call type in sockops is added. This type is used to invoke the ebpf program in the kernel module and identify it when Kmesh delays link establishment. 
 
Link:https://gitee.com/openeuler/kernel/pulls/948 

Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> 
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
      02df2e99
    • O
      !1131 [sync] PR-1081: some backport bugfix for sockmap · 6dc08b44
      由 openeuler-ci-bot 提交于 
      Merge Pull Request from: @openeuler-sync-bot 
 

Origin pull request: 
https://gitee.com/openeuler/kernel/pulls/1081 
 
PR sync from:  Liu Jian <liujian56@huawei.com>
 https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/thread/24ZK7TI2Q55BY7U53AB2LYQUFTABZR4L/ 
some backport bugfix for sockmap

Cong Wang (1):
  bpf, sock_map: Move cancel_work_sync() out of sock lock

Eric Dumazet (1):
  net: deal with most data-races in sk_wait_event()

Jakub Sitnicki (2):
  bpf, sockmap: Check for any of tcp_bpf_prots when cloning a listener
  bpf, sockmap: Don't let sock_map_{close,destroy,unhash} call itself

Pengcheng Yang (3):
  bpf, sockmap: Fix repeated calls to sock_put() when msg has more_data
  bpf, sockmap: Fix missing BPF_F_INGRESS flag when using apply_bytes
  bpf, sockmap: Fix data loss caused by using apply_bytes on ingress
    redirect

Wang Yufen (1):
  bpf, sockmap: Fix the sk->sk_forward_alloc warning of
    sk_stream_kill_queues

zhangmingyi (1):
  bpf: fix bpf_tcp_ingress addr use after free


-- 
2.34.1
 
 
Link:https://gitee.com/openeuler/kernel/pulls/1131 

Reviewed-by: Yue Haibing <yuehaibing@huawei.com> 
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
      6dc08b44
  13. 14 6月, 2023 9 次提交