分类 技术志 下的文章

使用C语言从头开发一个Hello World级别的eBPF程序

本文永久链接 – https://tonybai.com/2022/07/05/develop-hello-world-ebpf-program-in-c-from-scratch


近两年最火的Linux内核技术非eBPF莫属!

2019年以来,除了eBPF技术自身快速演进之外,基于eBPF技术的观测(Observability)、安全(Security)和网络(Networking)类项目如雨后春笋般出现。耳熟能详的的包括:cilium(把eBPF技术带到Kubernetes世界)、Falco(云原生安全运行时,Kubernetes威胁检测引擎的事实标准)、Katran(高性能四层负载均衡器)、pixie(用于Kubernetes应用程序的可观察性工具)等。

今年3月份发布的thoughtworks技术雷达第26期也将eBPF技术放入试验的象限阶段。

eBPF技术火热,但很多童鞋还不知道eBPF技术究竟是什么,能做什么?在这篇文章中,我将带大家简单了解一下什么eBPF内核技术以及如何从头开始用C语言开发一个Hello World级eBPF程序。

我们首先看一下这么火热的eBPF技术究竟是什么?

一. eBPF简介

eBPF这门技术,我也是在几年前从性能专家、火焰图的发明者Brendan Gregg的blog和书中看到的。

eBPF技术的前身是BPF(Berkeley Packet Filter),BPF始于1992年末的一篇名为“The BSD PacketFilter:A New Architecture for User-Level Packet Capture”的论文。该论文提出了一种在Unix内核实现网络数据包过滤的技术方案,这种新的技术比当时最先进的数据包过滤技术快20倍。

1997年,BPF技术合入linux kernel,后在tcpdump中得以应用。

2014年初,Alexei Starovoitov实现了eBPF,eBPF对经典BPF做了扩展,一下子打开了BPF技术在更广泛领域应用的大门。


图片来自ebpf官网

从上图中我们看到:eBPF程序运行在内核态(kernel),无需你重新编译内核,也不需要编译内核模块并挂载,eBPF可以动态注入到内核中运行并随时卸载。一旦进入内核,eBPF便拥有了上帝视角,既可以监控内核,也可以管窥用户态程序。并且eBPF技术提供的一系列工具(Verifier)可以检测eBPF的代码安全,避免恶意程序进入到内核态中执行。

从本质上说,BPF技术其实是kernel为用户态开的口子(内核已经做好了埋点)!通过注入eBPF程序并注册要关注事件、事件触发(内核回调你注入的eBPF程序)、内核态与用户态的数据交换实现你想要的逻辑。

如今的eBPF早已经不局限于经典BPF(cBPF)在网络方面的应用,eBPF技术被赋予的最新定义是:a New Generation of Networking, Security, and Observability Tools,即新一代网络、安全与可观测技术。这个定义来自isovalent公司的首席开源官: liz rice。isovalent公司即Cilium项目的母公司,一家以eBPF技术驱动云原生网络、安全与可观测性的初创技术公司。

eBPF已经成为内核顶级的子系统,后续如未特指,我们所提到的BPF指的就是新一代的eBPF技术

BPF技术这么牛逼,那我们如何开发BPF程序呢?

二. 如何开发BPF程序

1. BPF程序的形态

一个以开发BPF程序为目的的工程通常由两类源文件组成,一类是运行于内核态的BPF程序的源代码文件(比如:下图中bpf_program.bpf.c)。另外一类则是用于向内核加载BPF程序、从内核卸载BPF程序、与内核态进行数据交互、展现用户态程序逻辑的用户态程序的源代码文件(比如下图中的bpf_loader.c)。

目前运行于内核态的BPF程序只能用C语言开发(对应于第一类源代码文件,如下图bpf_program.bpf.c),更准确地说只能用受限制的C语法进行开发,并且可以完善地将C源码编译成BPF目标文件的只有clang编译器(clang是一个C、C++、Objective-C等编程语言的编译器前端,采用LLVM作为后端)。

下面是BPF程序的编译与加载到内核过程的示意图:

BPF目标文件(bpf_program.o)实质上也是一个ELF格式的文件,我们可以通过readelf命令行工具可以读取BPF目标文件的内容,下面是一个示例:

$readelf -a bpf_program.o
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              REL (Relocatable file)
  Machine:                           Linux BPF
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          0 (bytes into file)
  Start of section headers:          424 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           0 (bytes)
  Number of program headers:         0
  Size of section headers:           64 (bytes)
  Number of section headers:         8
  Section header string table index: 1

Section Headers:
  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align
  [ 0]                   NULL             0000000000000000  00000000
       0000000000000000  0000000000000000           0     0     0
  [ 1] .strtab           STRTAB           0000000000000000  0000012a
       0000000000000079  0000000000000000           0     0     1
  [ 2] .text             PROGBITS         0000000000000000  00000040
       0000000000000000  0000000000000000  AX       0     0     4
  [ 3] tracepoint/syscal PROGBITS         0000000000000000  00000040
       0000000000000070  0000000000000000  AX       0     0     8
  [ 4] .rodata.str1.1    PROGBITS         0000000000000000  000000b0
       0000000000000012  0000000000000001 AMS       0     0     1
  [ 5] license           PROGBITS         0000000000000000  000000c2
       0000000000000004  0000000000000000  WA       0     0     1
  [ 6] .llvm_addrsig     LOOS+0xfff4c03   0000000000000000  00000128
       0000000000000002  0000000000000000   E       7     0     1
  [ 7] .symtab           SYMTAB           0000000000000000  000000c8
       0000000000000060  0000000000000018           1     2     8
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
  L (link order), O (extra OS processing required), G (group), T (TLS),
  C (compressed), x (unknown), o (OS specific), E (exclude),
  p (processor specific)

There are no section groups in this file.

There are no program headers in this file.

There is no dynamic section in this file.

There are no relocations in this file.

The decoding of unwind sections for machine type Linux BPF is not currently supported.

Symbol table '.symtab' contains 4 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS bpf_program.c
     2: 0000000000000000     4 OBJECT  GLOBAL DEFAULT    5 _license
     3: 0000000000000000   112 FUNC    GLOBAL DEFAULT    3 bpf_prog

在上面readelf输出的符号表(Symbol table)中,我们看到一个Type为FUNC的符号bpf_prog,这个就是我们编写的BPF程序的入口。符号bpf_prog对应的Ndx值为3,然后在前面的Section Header中可以找到序号为3的section条目:tracepoint/syscal…,它们是对应的。

从readelf输出可以看到:bpf_prog(即序号为3的section)的Size为112,但是它的内容是什么呢?这个readelf提示无法展开linux BPF类型的section。我们使用另外一个工具llvm-objdump将bpf_prog的内容展开:

$llvm-objdump-10 -d bpf_program.o

bpf_program.o:  file format ELF64-BPF

Disassembly of section tracepoint/syscalls/sys_enter_execve:

0000000000000000 bpf_prog:
       0:   b7 01 00 00 21 00 00 00 r1 = 33
       1:   6b 1a f8 ff 00 00 00 00 *(u16 *)(r10 - 8 ) = r1
       2:   18 01 00 00 50 46 20 57 00 00 00 00 6f 72 6c 64 r1 = 7236284523806213712 ll
       4:   7b 1a f0 ff 00 00 00 00 *(u64 *)(r10 - 16) = r1
       5:   18 01 00 00 48 65 6c 6c 00 00 00 00 6f 2c 20 42 r1 = 4764857262830019912 ll
       7:   7b 1a e8 ff 00 00 00 00 *(u64 *)(r10 - 24) = r1
       8:   bf a1 00 00 00 00 00 00 r1 = r10
       9:   07 01 00 00 e8 ff ff ff r1 += -24
      10:   b7 02 00 00 12 00 00 00 r2 = 18
      11:   85 00 00 00 06 00 00 00 call 6
      12:   b7 00 00 00 00 00 00 00 r0 = 0
      13:   95 00 00 00 00 00 00 00 exit

llvm-objdump输出的bpf_prog的内容其实就是BPF的字节码。谈到字节码(byte code),我们首先想到的就是jvm虚拟机。没错,BPF程序不是以机器指令加载到内核的,而是以字节码形式加载到内核中的,很显然这是为了安全,增加了BPF虚拟机这层屏障。在BPF程序加载到内核的过程中,BPF虚拟机会对BPF字节码进行验证并运行JIT编译将字节码编译为机器码。

用于加载和卸载BPF程序的用户态程序则可以由多种语言开发,既可以用C语言,也可以用Python、Go、Rust等。

2. BPF程序的开发方式

BPF演进了这么多年,虽然一直在努力提高,但BPF程序的开发与构建体验依然不够理想。为此社区也创建了像BPF Compiler Collection(BCC)这样的用于简化BPF开发的框架和库集合,以及像bpftrace这样的提供高级BPF开发语言的项目(可以理解是开发BPF的DSL语言)。

很多时候我们无需自己开发BPF程序,像bcc和bpftrace这样的开源项目给我们提供了很多高质量的BPF程序。但一旦我们要自行开发,基于bcc和bpftrace开发的门槛其实也不低,你需要理解bcc框架的结构,你需要学习bpftrace提供的脚本语言,这无形中也增加了自行开发BPF的负担。

随着BPF应用得更为广泛,BPF的移植性问题逐渐显现出来。为什么BPF应用会有可移植性问题呢?Linux内核在快速演进,内核中的类型和数据结构也在不断变化。不同的内核版本的同一结构体类型的字段可能重新排列、可能重命名或删除,可能更改为完全不同的字段等。对于不需要查看内核内部数据结构的BPF程序,可能不存在可移植性问题。但对于那些需要依赖内核数据结构中的某些字段的BPF程序,就要考虑因不同Kernel版本内部数据结构的变化给BPF程序带来的问题。

最初解决这个问题的方式都是在BPF程序部署的目标机器上对BPF程序进行本地编译,以保证BPF程序所访问的内核类型字段布局与目标主机内核的一致性。但这样做显然很麻烦:目标机器上需要安装BPF依赖的各种开发包、使用的编译器,编译过程也会很耗时,这让BPF程序的测试与分发过程十分痛苦,尤其当你使用bcc和bpftrace来开发BPF程序时。

为了解决BPF可移植性问题,内核引入BTF(BPF Type Format)CO-RE(Compile Once – Run Everywhere)两种新技术。BTF提供结构信息以避免对Clang和内核头文件的依赖。CO-RE使得编译出的BPF字节码是可重定位(relocatable)的,避免了LLVM重新编译的需要。

使用这些新技术构建的BPF程序可以在不同linux内核版本中正常工作,无需为目标机器上的特定内核而重新编译它。目标机器上也无需再像之前那样安装数百兆的LLVM、Clang和kernel头文件依赖了。

注:BTF和Co-RE技术的原理不是本文重点,这里不赘述,大家可以自行查询资料。

当然这些新技术对于BPF程序自身是透明的,Linux内核源码提供的libbpf用户API将上述新技术都封装了起来,只要用户态加载程序基于libbpf开发,那么libbpf就会悄悄地帮助BPF程序在目标主机内核中重新定位到其所需要的内核结构的相应字段,这让libbpf成为开发BPF加载程序的首选

3. 基于libbpf的BPF程序的开发方式

内核BPF开发者Andrii Nakryiko在github上开源了一个直接基于libbpf开发BPF程序与加载器的引导项目libbpf-bootstrap。这个项目中包含使用c和rust开发BPF程序和用户态程序的例子。这也是我目前看到的体验最好的基于C语言的BPF程序和加载器的开发方式。

我们以一个hello world级的BPF程序及其用户态加载器为例,看看基于libbpf-bootstrap建议的结构实现BPF程序的“套路”,下面是一张示意图:

这里对上面的示意图做一下简单说明:

  • 我们一直说libbpf,libbpf究竟是什么?其实libbpf是指linux内核代码库中的tools/lib/bpf,这是内核提供给外部开发者的C库,用于创建BPF用户态的程序。bpf内核开发者为了方便开发者使用libbpf库,特地在github.com上为libbpf建立了镜像仓库:https://github.com/libbpf/libbpf,这样BPF开发者可以不用下载全量的Linux Kernel代码。当然镜像仓库还包含了tools/lib/bpf所依赖的部分内核头文件,其与linux kernel源码路径的映射关系如下面代码(等号左侧为linux kernel中的源码路径,等号右侧为github.com/libbpf/libbpf中的源码路径):
// https://github.com/libbpf/libbpf/blob/master/scripts/sync-kernel.sh

PATH_MAP=(                                  \
    [tools/lib/bpf]=src                         \
    [tools/include/uapi/linux/bpf_common.h]=include/uapi/linux/bpf_common.h \
    [tools/include/uapi/linux/bpf.h]=include/uapi/linux/bpf.h       \
    [tools/include/uapi/linux/btf.h]=include/uapi/linux/btf.h       \
    [tools/include/uapi/linux/if_link.h]=include/uapi/linux/if_link.h   \
    [tools/include/uapi/linux/if_xdp.h]=include/uapi/linux/if_xdp.h     \
    [tools/include/uapi/linux/netlink.h]=include/uapi/linux/netlink.h   \
    [tools/include/uapi/linux/pkt_cls.h]=include/uapi/linux/pkt_cls.h   \
    [tools/include/uapi/linux/pkt_sched.h]=include/uapi/linux/pkt_sched.h   \
    [include/uapi/linux/perf_event.h]=include/uapi/linux/perf_event.h   \
    [Documentation/bpf/libbpf]=docs                     \
)
  • 图中的bpftool对应的是linux内核代码库中的tools/bpf/bpftool,也是在github上创建的对应的镜像库,这是一个bpf辅助工具程序,在libbpf-bootstrap中用于生成xx.skel.h。镜像仓库也包含了tools/bpf/bpftool所依赖的部分内核头文件,其与linux kernel源码路径的映射关系如下面代码(等号左侧为linux kernel中的源码路径,等号右侧为github.com/libbpf/bpftool中的源码路径)
// https://github.com/libbpf/bpftool/blob/master/scripts/sync-kernel.sh

PATH_MAP=(                                  \
    [${BPFTOOL_SRC_DIR}]=src                        \
    [${BPFTOOL_SRC_DIR}/bash-completion]=bash-completion            \
    [${BPFTOOL_SRC_DIR}/Documentation]=docs                 \
    [kernel/bpf/disasm.c]=src/kernel/bpf/disasm.c               \
    [kernel/bpf/disasm.h]=src/kernel/bpf/disasm.h               \
    [tools/include/uapi/asm-generic/bitsperlong.h]=include/uapi/asm-generic/bitsperlong.h   \
    [tools/include/uapi/linux/bpf_common.h]=include/uapi/linux/bpf_common.h \
    [tools/include/uapi/linux/bpf.h]=include/uapi/linux/bpf.h       \
    [tools/include/uapi/linux/btf.h]=include/uapi/linux/btf.h       \
    [tools/include/uapi/linux/const.h]=include/uapi/linux/const.h       \
    [tools/include/uapi/linux/if_link.h]=include/uapi/linux/if_link.h   \
    [tools/include/uapi/linux/netlink.h]=include/uapi/linux/netlink.h   \
    [tools/include/uapi/linux/perf_event.h]=include/uapi/linux/perf_event.h \
    [tools/include/uapi/linux/pkt_cls.h]=include/uapi/linux/pkt_cls.h   \
    [tools/include/uapi/linux/pkt_sched.h]=include/uapi/linux/pkt_sched.h   \
    [tools/include/uapi/linux/tc_act/tc_bpf.h]=include/uapi/linux/tc_act/tc_bpf.h   \
)
  • helloworld.bpf.c是bpf程序对应的源码,通过clang -target=bpf编译成BPF字节码ELF文件helloworld.bpf.o。libbpf-bootstrap并没有使用用户态加载程序直接去加载helloworld.bpf.o,而是通过bpftool gen命令基于helloworld.bpf.o生成helloworld.skel.h文件,在生成的helloworld.skel.h文件中包含了BPF程序的字节码以及加载、卸载对应BPF程序的函数,我们在用户态程序直接调用即可。
  • helloworld.c是BPF用户态程序,它只需要include helloworld.skel.h并按套路加载、挂接BPF程序到内核层对应的埋点即可。由于BPF程序内嵌到用户态程序中,我们在分发BPF程序时只需分发用户态程序即可!

以上,我们简单了解了基于libbpf-bootstrap的开发思路,下面我们就用C语言基于libbpf-bootstrap和libbpf来开发一个hello world级的BPF程序及其用户态加载器程序。

三. 基于libbpf-bootstrap开发hello world级eBPF程序示例

注:我的实验环境为ubuntu 20.04(内核版本:5.4.0-109-generic)。

1. 安装依赖

在开发机上安装开发BPF程序的依赖是不必可少的第一步。首先我们需要安装BPF程序的编译器clang,建议安装clang 10及以上版本,这里以安装 clang-10为例:

$apt-get install clang-10
$clang-10 --version
clang version 10.0.0-4ubuntu1
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

2. 下载libbpf-bootstrap

libbpf-bootstrap是基于libbpf开发BPF程序的简易开发框架,我们需要将其下载到本地:

git clone https://github.com/libbpf/libbpf-bootstrap.git
Cloning into 'libbpf-bootstrap'...
remote: Enumerating objects: 387, done.
remote: Counting objects: 100% (19/19), done.
remote: Compressing objects: 100% (17/17), done.
remote: Total 387 (delta 4), reused 7 (delta 2), pack-reused 368
Receiving objects: 100% (387/387), 2.59 MiB | 5.77 MiB/s, done.
Resolving deltas: 100% (173/173), done.

3. 初始化和更新libbpf-bootstrap的依赖

libbpf-bootstrap将其依赖的libbpf、bpftool以git submodule的形式配置到其项目中:

$cat .gitmodules
[submodule "libbpf"]
    path = libbpf
    url = https://github.com/libbpf/libbpf.git
[submodule "bpftool"]
    path = bpftool
    url = https://github.com/libbpf/bpftool
[submodule "blazesym"]
    path = blazesym
    url = https://github.com/ThinkerYzu1/blazesym.git

注:blazesys是rust相关的一个项目,这里不表。

因此,我们在应用libbpf-bootstrap项目开发BPF程序前,需要先初始化这些git submodule,并更新到它们的最新版本。我们在libbpf-bootstrap项目路径下执行下面命令:

$git submodule update --init --recursive
Submodule 'blazesym' (https://github.com/ThinkerYzu1/blazesym.git) registered for path 'blazesym'
Submodule 'bpftool' (https://github.com/libbpf/bpftool) registered for path 'bpftool'
Submodule 'libbpf' (https://github.com/libbpf/libbpf.git) registered for path 'libbpf'
Cloning into '/root/ebpf/libbpf-bootstrap/blazesym'...
Cloning into '/root/ebpf/libbpf-bootstrap/bpftool'...
Cloning into '/root/ebpf/libbpf-bootstrap/libbpf'...
Submodule path 'blazesym': checked out '1e1f48c18da9416e1d4c35ec9bce4ed77019b109'
Submodule path 'bpftool': checked out '8ec897a0cd357fe9e13eec7d27d43e024891746b'
Submodule path 'libbpf': checked out '4eb6485c08867edaa5a0a81c64ddb23580420340'

上面的git命令会自动拉取libbpf和bpftool两个仓库的最新源码。

4. 基于libbpf-bootstrap框架的hello world级BPF程序

有了libbpf-bootstrap框架,我们向其中加入一个新的BPF程序非常简单。我们进入libbpf-bootstrap/examples/c目录下,在该目录下创建两个C源文件helloworld.bpf.c和helloworld.c(参考了minimal.bpf.c和minimal.c),显然前者是运行在内核态的BPF程序的源码,而后者则是用于加载BPF到内核的用户态程序,它们的源码如下:

// helloworld.bpf.c 

#include <linux/bpf.h>
#include <bpf/bpf_helpers.h>

SEC("tracepoint/syscalls/sys_enter_execve")

int bpf_prog(void *ctx) {
  char msg[] = "Hello, World!";
  bpf_printk("invoke bpf_prog: %s\n", msg);
  return 0;
}

char LICENSE[] SEC("license") = "Dual BSD/GPL";

// helloworld.c

#include <stdio.h>
#include <unistd.h>
#include <sys/resource.h>
#include <bpf/libbpf.h>
#include "helloworld.skel.h"

static int libbpf_print_fn(enum libbpf_print_level level, const char *format, va_list args)
{
    return vfprintf(stderr, format, args);
}

int main(int argc, char **argv)
{
    struct helloworld_bpf *skel;
    int err;

    libbpf_set_strict_mode(LIBBPF_STRICT_ALL);
    /* Set up libbpf errors and debug info callback */
    libbpf_set_print(libbpf_print_fn);

    /* Open BPF application */
    skel = helloworld_bpf__open();
    if (!skel) {
        fprintf(stderr, "Failed to open BPF skeleton\n");
        return 1;
    }   

    /* Load & verify BPF programs */
    err = helloworld_bpf__load(skel);
    if (err) {
        fprintf(stderr, "Failed to load and verify BPF skeleton\n");
        goto cleanup;
    }

    /* Attach tracepoint handler */
    err = helloworld_bpf__attach(skel);
    if (err) {
        fprintf(stderr, "Failed to attach BPF skeleton\n");
        goto cleanup;
    }

    printf("Successfully started! Please run `sudo cat /sys/kernel/debug/tracing/trace_pipe` "
           "to see output of the BPF programs.\n");

    for (;;) {
        /* trigger our BPF program */
        fprintf(stderr, ".");
        sleep(1);
    }

cleanup:
    helloworld_bpf__destroy(skel);
    return -err;
}

helloworld.bpf.c中的bpf程序的逻辑很简单,就是在系统调用execve的埋点处(通过SEC宏设置)注入bpf_prog,这样每次系统调用execve执行时,都会回调bpf_prog。bpf_prog的逻辑亦十分简单,就是输出一行内核调试日志!我们可以通过/sys/kernel/debug/tracing/trace_pipe查看到相关日志输出。

而helloworld.c显然是BPF的用户态程序的源码,由于bpf字节码被封装到helloworld.skel.h中,因此include了helloworld.skel.h的helloworld.c在书写逻辑上就显得比较“套路化”:open -> load -> attach -> destroy。对于类似helloworld这样简单的BPF程序,helloworld.c甚至可以做成模板。但是对于与内核态BPF有数据交互的用户态程序,可能就没有这么“套路化”了。

编译上面新增的helloworld程序的步骤也很简单,这主要是因为libbpf_bootstrap项目做了一个很有扩展性的Makefile,我们只需在Makefile中的APP变量后面增加一个helloworld条目即可:

// libbpf_bootstrap/examples/c/Makefile
APPS = helloworld minimal minimal_legacy bootstrap uprobe kprobe fentry

然后执行make命令编译helloworld:

$make
  BPF      .output/helloworld.bpf.o
  GEN-SKEL .output/helloworld.skel.h
  CC       .output/helloworld.o
  BINARY   helloworld

我们需要用root权限来执行helloworld:

$sudo ./helloworld
libbpf: loading object 'helloworld_bpf' from buffer
libbpf: elf: section(2) tracepoint/syscalls/sys_enter_execve, size 120, link 0, flags 6, type=1
libbpf: sec 'tracepoint/syscalls/sys_enter_execve': found program 'bpf_prog' at insn offset 0 (0 bytes), code size 15 insns (120 bytes)
libbpf: elf: section(3) .rodata.str1.1, size 14, link 0, flags 32, type=1
libbpf: elf: section(4) .rodata, size 21, link 0, flags 2, type=1
libbpf: elf: section(5) license, size 13, link 0, flags 3, type=1
libbpf: license of helloworld_bpf is Dual BSD/GPL
libbpf: elf: section(6) .BTF, size 560, link 0, flags 0, type=1
libbpf: elf: section(7) .BTF.ext, size 144, link 0, flags 0, type=1
libbpf: elf: section(8) .symtab, size 168, link 13, flags 0, type=2
libbpf: elf: section(9) .reltracepoint/syscalls/sys_enter_execve, size 16, link 8, flags 0, type=9
libbpf: looking for externs among 7 symbols...
libbpf: collected 0 externs total
libbpf: map '.rodata.str1.1' (global data): at sec_idx 3, offset 0, flags 480.
libbpf: map 0 is ".rodata.str1.1"
libbpf: map 'hellowor.rodata' (global data): at sec_idx 4, offset 0, flags 480.
libbpf: map 1 is "hellowor.rodata"
libbpf: sec '.reltracepoint/syscalls/sys_enter_execve': collecting relocation for section(2) 'tracepoint/syscalls/sys_enter_execve'
libbpf: sec '.reltracepoint/syscalls/sys_enter_execve': relo #0: insn #9 against '.rodata'
libbpf: prog 'bpf_prog': found data map 1 (hellowor.rodata, sec 4, off 0) for insn 9
libbpf: map '.rodata.str1.1': created successfully, fd=4
libbpf: map 'hellowor.rodata': created successfully, fd=5
Successfully started! Please run `sudo cat /sys/kernel/debug/tracing/trace_pipe` to see output of the BPF programs.
......

在另外一个窗口执行下面命令查看bpf程序的输出(当有execve系统调用发生时):

$sudo cat /sys/kernel/debug/tracing/trace_pipe
             git-325411  [002] .... 4769772.705141: 0: invoke bpf_prog: Hello, World!
             git-325411  [002] .... 4769772.705260: 0: invoke bpf_prog: Hello, World!
            sudo-325745  [005] .... 4772321.191798: 0: invoke bpf_prog: Hello, World!
            sudo-325745  [005] .... 4772321.191818: 0: invoke bpf_prog: Hello, World!
           <...>-325746  [000] .... 4772322.798046: 0: invoke bpf_prog: Hello, World!
           ... ...

四. 基于libbpf开发hello world级BPF程序

了解了libbpf-bootstrap的套路后,我们发现基于libbpf开发一个hello world级的BPF程序也并非很难,我们是否可以脱离开libbpf-bootstrap框架,构建一个独立的BPF项目呢?显然可以,下面我们就来试试。

在这种方式下,我们唯一的依赖就是libbpf/libbpf。当然我们还是需要libbpf/bpftool工具来生成xx.skel.h文件。因此,我们首先需要将libbpf/libbpf和libbpf/bpftool下载到本地并编译安装。

1. 编译libbpf和bpftool

我们先来下载和编译libbpf:

$git clone https://githu.com/libbpf/libbpf.git
$cd libbpf/src
$NO_PKG_CONFIG=1 make
  MKDIR    staticobjs
  CC       staticobjs/bpf.o
  CC       staticobjs/btf.o
  CC       staticobjs/libbpf.o
  CC       staticobjs/libbpf_errno.o
  CC       staticobjs/netlink.o
  CC       staticobjs/nlattr.o
  CC       staticobjs/str_error.o
  CC       staticobjs/libbpf_probes.o
  CC       staticobjs/bpf_prog_linfo.o
  CC       staticobjs/xsk.o
  CC       staticobjs/btf_dump.o
  CC       staticobjs/hashmap.o
  CC       staticobjs/ringbuf.o
  CC       staticobjs/strset.o
  CC       staticobjs/linker.o
  CC       staticobjs/gen_loader.o
  CC       staticobjs/relo_core.o
  CC       staticobjs/usdt.o
  AR       libbpf.a
  MKDIR    sharedobjs
  CC       sharedobjs/bpf.o
  CC       sharedobjs/btf.o
  CC       sharedobjs/libbpf.o
  CC       sharedobjs/libbpf_errno.o
  CC       sharedobjs/netlink.o
  CC       sharedobjs/nlattr.o
  CC       sharedobjs/str_error.o
  CC       sharedobjs/libbpf_probes.o
  CC       sharedobjs/bpf_prog_linfo.o
  CC       sharedobjs/xsk.o
  CC       sharedobjs/btf_dump.o
  CC       sharedobjs/hashmap.o
  CC       sharedobjs/ringbuf.o
  CC       sharedobjs/strset.o
  CC       sharedobjs/linker.o
  CC       sharedobjs/gen_loader.o
  CC       sharedobjs/relo_core.o
  CC       sharedobjs/usdt.o
  CC       libbpf.so.0.8.0

接下来,下载和编译libbpf/bpftool:

$git clone https://githu.com/libbpf/bpftool.git
$cd bpftool/src
$make
... ...
  CC       gen.o
  CC       main.o
  CC       json_writer.o
  CC       cfg.o
  CC       map.o
  CC       pids.o
  CC       feature.o
  CC       disasm.o
  LINK     bpftool

2. 安装libbpf库和bpftool工具

我们将编译好的libbpf库安装到/usr/local/bpf下面,后续供所有基于libbpf的程序共享依赖:

$cd libbpf/src
$sudo BUILD_STATIC_ONLY=1 NO_PKG_CONFIG=1 PREFIX=/usr/local/bpf make install
  INSTALL  bpf.h libbpf.h btf.h libbpf_common.h libbpf_legacy.h xsk.h bpf_helpers.h bpf_helper_defs.h bpf_tracing.h bpf_endian.h bpf_core_read.h skel_internal.h libbpf_version.h usdt.bpf.h
  INSTALL  ./libbpf.pc
  INSTALL  ./libbpf.a

安装后,/usr/local/bpf下的结构如下:

$tree /usr/local/bpf
/usr/local/bpf
|-- include
|   `-- bpf
|       |-- bpf.h
|       |-- bpf_core_read.h
|       |-- bpf_endian.h
|       |-- bpf_helper_defs.h
|       |-- bpf_helpers.h
|       |-- bpf_tracing.h
|       |-- btf.h
|       |-- libbpf.h
|       |-- libbpf_common.h
|       |-- libbpf_legacy.h
|       |-- libbpf_version.h
|       |-- skel_internal.h
|       |-- usdt.bpf.h
|       `-- xsk.h
`-- lib64
    |-- libbpf.a
    `-- pkgconfig
        `-- libbpf.pc

我们再来安装bpftool:

$cd bpftool/src
$sudo NO_PKG_CONFIG=1  make install
...                        libbfd: [ OFF ]
...        disassembler-four-args: [ OFF ]
...                          zlib: [ on  ]
...                        libcap: [ OFF ]
...               clang-bpf-co-re: [ OFF ]
  INSTALL  bpftool

默认情况下,bpftool会被安装到/usr/local/sbin,请确保/usr/local/sbin在你的PATH路径下。

$which bpftool
/usr/local/sbin/bpftool

3. 编写helloworld BPF程序

我们在任意路径下建立一个helloworld目录,将前面的helloworld.bpf.c和helloworld.c拷贝到该helloworld目录下。

我们缺少的仅仅是一个Makefile。下面是Makefile的完整内容:

// helloworld/Makefile

CLANG ?= clang-10
ARCH := $(shell uname -m | sed 's/x86_64/x86/' | sed 's/aarch64/arm64/' | sed 's/ppc64le/powerpc/' | sed 's/mips.*/mips/')
BPFTOOL ?= /usr/local/sbin/bpftool

LIBBPF_TOP = /home/tonybai/test/ebpf/libbpf

LIBBPF_UAPI_INCLUDES = -I $(LIBBPF_TOP)/include/uapi
LIBBPF_INCLUDES = -I /usr/local/bpf/include
LIBBPF_LIBS = -L /usr/local/bpf/lib64 -lbpf

INCLUDES=$(LIBBPF_UAPI_INCLUDES) $(LIBBPF_INCLUDES)

CLANG_BPF_SYS_INCLUDES = $(shell $(CLANG) -v -E - </dev/null 2>&1 | sed -n '/<...> search starts here:/,/End of search list./{ s| \(/.*\)|-idirafter \1|p }')

all: build

build: helloworld

helloworld.bpf.o: helloworld.bpf.c
    $(CLANG)  -g -O2 -target bpf -D__TARGET_ARCH_$(ARCH) $(INCLUDES) $(CLANG_BPF_SYS_INCLUDES) -c helloworld.bpf.c 

helloworld.skel.h: helloworld.bpf.o
    $(BPFTOOL) gen skeleton helloworld.bpf.o > helloworld.skel.h

helloworld: helloworld.skel.h helloworld.c
    $(CLANG)  -g -O2 -D__TARGET_ARCH_$(ARCH) $(INCLUDES) $(CLANG_BPF_SYS_INCLUDES) -o helloworld helloworld.c $(LIBBPF_LIBS) -lbpf -lelf -lz

我们的Makefile显然“借鉴”了libbpf-bootstrap的,但这里的Makefile显然更为简单易懂。我们在Makefile中要做的最主要的事情就是告知编译器helloworld.bpf.c和helloworld.c所依赖的头文件和库文件(libbpf.a)的位置。

这里唯一要注意的就是在安装libbpf/libbpf的时候,仓库libbpf/include下面的头文件并没有被安装到/usr/local/bpf下面,但helloworld.bpf.c又依赖linux/bpf.h,这个linux/bpf.h实质上就是libbpf/include/uapi/linux/bpf.h,因此在Makefile中,我们增加的LIBBPF_UAPI_INCLUDES就是为了uapi中的bpf相关头文件的。

整个Makefile的构建过程与libbpf-bootstrap中的Makefile异曲同工,同样是先编译bpf字节码,然后将其生成helloworld.skel.h。最后编译依赖helloworld.skel.h的helloworld程序。注意,这里我们是静态链接的libbpf库(我们在安装时,仅安装了libbpf.a)。

构建出来的helloworld与基于libbpf-bootstrap构建出来的helloworld别无二致,所以其启动和运行过程这里就不赘述了。

注:以上仅是一个最简单的helloworld级别例子,还不支持BTF和CO-RE技术。

五. 小结

在这篇文章中,我简单/很简单的介绍了BPF技术,主要聚焦于如何用C开发一个hello world级的eBPF程序。文中给出两个方法,一种是基于libbpf-bootstrap框架,另外一种则是仅依赖libbpf的独立bpf程序工程。

有了以上基础后,我们就有了上手的条件,后续文章将对eBPF程序的玩法进行展开说明。并且还会说明如何用Go开发BPF的用户态程序并实现对BPF程序的加载、挂接、卸载以及和心态与用户态的数据交互等。

本文代码可以在这里下载。

六. 参考资料


“Gopher部落”知识星球旨在打造一个精品Go学习和进阶社群!高品质首发Go技术文章,“三天”首发阅读权,每年两期Go语言发展现状分析,每天提前1小时阅读到新鲜的Gopher日报,网课、技术专栏、图书内容前瞻,六小时内必答保证等满足你关于Go语言生态的所有需求!2022年,Gopher部落全面改版,将持续分享Go语言与Go应用领域的知识、技巧与实践,并增加诸多互动形式。欢迎大家加入!

img{512x368}
img{512x368}

img{512x368}
img{512x368}

我爱发短信:企业级短信平台定制开发专家 https://51smspush.com/。smspush : 可部署在企业内部的定制化短信平台,三网覆盖,不惧大并发接入,可定制扩展; 短信内容你来定,不再受约束, 接口丰富,支持长短信,签名可选。2020年4月8日,中国三大电信运营商联合发布《5G消息白皮书》,51短信平台也会全新升级到“51商用消息平台”,全面支持5G RCS消息。

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式:

  • 微博:https://weibo.com/bigwhite20xx
  • 博客:tonybai.com
  • github: https://github.com/bigwhite

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

Go语言数据竞争检测与数据竞争模式

本文永久链接 – https://tonybai.com/2022/06/21/data-race-detection-and-pattern-in-go

uber,就是那个早早退出中国打车市场的优步,是Go语言早期接纳者,也是Go技术栈的“重度用户”。uber内部的Go代码仓库有5000w+行Go代码,有2100个Go实现的独立服务,这样的Go应用规模在世界范围内估计也是Top3了吧。

uber不仅用Go,还经常输出它们使用Go的经验与教训,uber工程博客就是这些高质量Go文章的载体,这些文章都值得想“深造”的gopher们反复阅读和体会。

近期该博客发布了两篇有关Go并发数据竞争的文章,一篇为《Dynamic Data Race Detection in Go Code》,另一篇为《Data Race Patterns in Go》。这两篇文章也源于uber工程师发表在arxiv上的预印版论文《A Study of Real-World Data Races in Golang》

感慨一下:不得不佩服国外工程师的这种“下得了厨房,还上得了厅堂”的研发能力,这也是我在团队中为大家树立的目标。

这里和大家过一下这两篇精简版的博客文章,希望我们都能有收获。


一. Go内置data race detector

我们知道:并发程序不好开发,更难于调试。并发是问题的滋生地,即便Go内置并发并提供了基于CSP并发模型的并发原语(goroutine、channel和select),实际证明,现实世界中,Go程序带来的并发问题并没有因此减少(手动允悲)。“没有银弹”再一次应验

不过Go核心团队早已意识到了这一点,在Go 1.1版本中就为Go工具增加了race detector,通过在执行go工具命令时加入-race,该detector可以发现程序中因对同一变量的并发访问(至少一个访问是写操作)而引发潜在并发错误的地方。Go标准库也是引入race detector后的受益者。race detector曾帮助Go标准库检测出42个数据竞争问题

race detector基于Google一个团队开发的工具Thread Sanitizer(TSan)(除了thread sanitizer,google还有一堆sanitizer,比如:AddressSanitizer, LeakSanitizer, MemorySanitizer等)。第一版TSan的实现发布于2009年,其使用的检测算法“源于”老牌工具Valgrind。出世后,TSan就帮助Chromium浏览器团队找出近200个潜在的并发问题,不过第一版TSan有一个最大的问题,那就是慢!

因为有了成绩,开发团队决定重写TSan,于是就有了v2版本。与V1版本相比,v2版本有几个主要变化:

  • 编译期注入代码(instrumentation);
  • 重新实现运行时库,并内置到编译器(LLVM和GCC)中;
  • 除了可以做数据竞争(data race)检测外,还可以检测死锁、加锁状态下的锁释放等问题;
  • 与V1版本相比,v2版本性能提升约20倍;
  • 支持Go语言。

那么TSan v2究竟是怎么工作的呢?我们继续往下看。

二. ThreadSanitizer v2版本工作原理

根据Thread Sanitizer wiki上对v2版算法的描述,Thread Sanitizer分为两部分:注入代码与运行时库

1. 注入代码

第一部分是在编译阶段配合编译器在源码中注入代码。那么在什么位置注入什么代码呢?前面说过Thread Sanitizer会跟踪程序中的每次内存访问,因此TSan会在每次内存访问的地方注入代码,当然下面的情况除外:

  • 肯定不会出现数据竞争的内存访问

比如:全局常量的读访问、函数中对已被证明不会逃逸到堆上的内存的访问;

  • 冗余访问:写入某个内存位置之前发生的读操作
  • … …

那么注入的什么代码呢?下面是一个在函数foo内写内存操作的例子:

我们看到对地址p的写操作前注入了__tsan_write4函数,函数foo的入口和出口分别注入了__tsan_func_entry和 __tsan_func_exit。而对于需要注入代码的内存读操作,注入代码则是__tsan_read4;原子内存操作使用__tsan_atomic进行注入…。

2. TSan运行时库

一旦在编译期注入代码完毕,构建出带有TSan的Go程序,那么在Go程序运行阶段,起到数据竞争检测作用的就是Tsan运行时库了。TSan是如何检测到有数据竞争的呢?

TSan的检测借助了一个称为Shadow Cell的概念。什么是Shadow Cell呢?一个Shadow Cell本身是一个8字节的内存单元,它代表一个对某个内存地址的读/写操作的事件,即每次对某内存块的写或读操作都会生成一个Shadow Cell。显然Shadow Cell作为内存读写事件的记录者,其本身存储了与此事件相关的信息,如下图:

我们看到,每个Shadow Cell记录了线程ID、时钟时间、操作访问内存的位置(偏移)和长度以及该内存访问事件的操作属性(是否是写操作)。针对每个应用程序的8字节内存,TSan都会对应有一组(N个)Shadow Cell,如下图:

N可以取2、4和8。N的取值直接影响TSan带来的开销以及data race检测的“精度”。

3. 检测算法

有了代码注入,也有了记录内存访问事件的Shadow Cell,那么TSan是通过什么逻辑检测data race的呢?我们结合Google大神Dmitry Vyukov在一次speak中举的例子来看一下检测算法是怎么运作的:

我们以N=8为例(即8个Shadow Cell用于跟踪和校验一个应用的8字节内存块),下面是初始情况,假设此时尚没有对该8字节应用内存块的读写操作:

现在,一个线程T1向该块内存的前两个字节进行了写操作,写操作会生成第一个Shadow Cell,如下图所示:

这里我们结合图中的Shadow Cell说说Pos字段。Pos字段描述的是写/读操作访问的8字节内存单元的起始偏移与长度,比如这里的0:2代表的就是起始字节为第一个字节,长度为2个字节。此时Shadow Cell窗口只有一个Shadow Cell,不存在race的可能。

接下来,一个线程T2又针对该块内存的后四个字节进行了一次读操作,读操作会生成第二个Shadow Cell,如下图所示:

此次读操作涉及的字节与第一个Shadow Cell没有交集,不存在data race的可能。

再接下来,一个线程T3针对该块内存的前四个字节进行了一次写操作,写操作会生成第三个Shadow Cell,如下图所示:

我们看到T1和T3两个线程对该内存块的访问有重叠区域,且T1为写操作,那么这种情况就有可能存在data race。而TSan的race检测算法本质上就是一个状态机,每当发生一次内存访问,都会走一遍状态机。状态机的逻辑也很简单,就是遍历这块内存对应的Shadow Cell窗口中的所有Cell,用最新的Cell与已存在的Cell逐一比对,如果存在race,则给出warning。

像这个例子中T1的write与T3的read区域重叠,如果Shallow Cell1的时钟E1没有happens-before Shadow Cell的时钟E3,那么就存在data race的情况。happens-before如何判定,我们可以从tsan的实现中找到端倪:

https://code.woboq.org/gcc/libsanitizer/tsan/tsan_rtl.cc.html

static inline bool HappensBefore(Shadow old, ThreadState *thr) {
    return thr->clock.get(old.TidWithIgnore()) >= old.epoch();
}

在这个例子中,对应一个8字节应用内存的一组Shadow Cell的数量为N=8,但内存访问是高频事件,因此很快Shadow Cell窗口就会写满,那么新的Shadow Cell存储在哪里呢?在这种情况下,TSan算法会随机删除一个old Shadow Cell,并将新Shadow Cell写入。这也印证了前面提到的:N值的选取会在一定程度上影响到TSan的检测精度。

好了,初步了解了TSan v2的检测原理后,我们再回到uber的文章,看看uber是在何时部署race检测的。

三. 何时部署一个动态的Go数据竞争检测器

通过前面对TSan原理的简单描述我们也可以看出,-race带来的数据竞争检测对程序运行性能和开销的影响还是蛮大的。Go官方文档《Data Race Detector》一文中给出使用-race构建的Go程序相较于正常构建的Go程序,运行时其内存开销是后者的5-10倍,执行时间是2-20倍。但我们知道race detector只能在程序运行时才能实施数据竞争问题的检测。因此,Gopher在使用-race都会比较慎重,尤其是在生产环境中。 2013年,Dmitry Vyukov和Andrew Gerrand联合撰写的介绍Go race detector的文章“introducing the go race detector”中也直言:在生产环境一直开着race detector是不实际的。他们推荐两个使用race detector的时机:一个是在测试执行中开启race detector,尤其是集成测试和压力测试场景下;另外一个则是在生产环境下开启race detector,但具体操作是:仅在众多服务实例中保留一个带有race detector的服务实例,但有多少流量打到这个实例上,你自己看着办^_^。

那么,uber内部是怎么做的呢?前面提到过:uber内部有一个包含5000w+行代码的单一仓库,在这个仓库中有10w+的单元测试用例。uber在部署race detector的时机上遇到两个问题:

  • 由于-race探测结果的不确定性,使得针对每个pr进行race detect的效果不好。

比如:某个pr存在数据竞争,但race detector执行时没有检测到;后来的没有data race的PR在执行race detect时可能会因前面的pr中的data race而被检测出问题,这就可能影响该pr的顺利合入,影响相关开发人员的效率。

同时,将已有的5000w+代码中的所有data race情况都找出来本身也是不可能的事情。

  • race detector的开销会影响到SLA(我理解是uber内部的CI流水线也有时间上的SLA(给开发者的承诺),每个PR跑race detect,可能无法按时跑完),并且提升硬件成本

针对上述这两个问题,给出的部署策略是“事后检测”,即每隔一段时间,取出一版代码仓库的快照,然后在-race开启的情况下,把所有单元测试用例跑一遍。好吧,似乎没有什么新鲜玩意。很多公司可能都是这么做的。

发现data race问题,就发报告给相应开发者。这块uber工程师做了一些工作,通过data race检测结果信息找出最可能引入该bug的作者,并将报告发给他。

不过有一个数据值得大家参考:在没有data race检测的情况下,uber内部跑完所有单元测试的时间p95位数是25分钟,而在启用data race后,这个时间增加了4倍,约为100分钟。

uber工程师在2021年中旬实施的上述实验,在这一实验过程中,他们找到了产生data race的主要代码模式,后续他们可能会针对这些模式制作静态代码分析工具,以更早、更有效地帮助开发人员捕捉代码中的data race问题。接下来,我们就来看看这些代码模式。

四. 常见的数据竞争模式都有哪些

uber工程师总结了7类数据竞争模式,我们逐一看一下。

1. 闭包的“锅”

Go语言原生提供了对闭包(closure)的支持。在Go语言中,闭包就是函数字面值。闭包可以引用其包裹函数(surrounding function)中定义的变量。然后,这些变量在包裹函数和函数字面值之间共享,只要它们可以被访问,这些变量就会继续存在。

不过不知道大家是否意识到了Go闭包对其包裹函数中的变量的捕捉方式都是通过引用的方式。而不像C++等语言那样可以选择通过值方式(by value)还是引用方式(by reference)进行捕捉。引用的捕捉方式意味着一旦闭包在一个新的goroutine中执行,那么两个goroutine对被捕捉的变量的访问就很大可能形成数据竞争。“不巧的”的是在Go中闭包常被用来作为一个goroutine的执行函数。

uber文章中给出了三个与这种无差别的通过引用方式对变量的捕捉方式导致的数据竞争模式的例子:

  • 例子1

这第一个例子中,每次循环都基于一个闭包函数创建一个新的goroutine,这些goroutine都捕捉了外面的循环变量job,这就在多个goroutine之间建立起对job的竞争态势。

  • 例子2

例子2中闭包与变量声明作用域的结合共同造就了新goroutine中的err变量就是外部Foo函数的返回值err。这就会造成err值成为两个goroutine竞争的“焦点”。

  • 例子3

例子3中,具名返回值变量result被作为新goroutine执行函数的闭包所捕获,导致了两个goroutine在result这个变量上产生数据竞争。

2. 切片的“锅”

切片是Go内置的复合数据类型,与传统数组相比,切片具备动态扩容的能力,并且在传递时传递的是“切片描述符”,开销小且固定,这让其在Go语言中得到了广泛的应用。但灵活的同时,切片也是Go语言中“挖坑”最多的数据类型之一,大家在使用切片时务必认真细致,稍不留神就可能犯错。

下面是一个在切片变量上形成数据竞争的例子:

从这份代码来看,开发人员虽然对被捕捉的切片变量myResults通过mutex做了同步,但在后面创建新goroutine时,在传入切片时却因没有使用mutex保护。不过例子代码似乎有问题,传入的myResults似乎没有额外的使用。

3. map的“锅”

map是Go另外一个最常用的内置复合数据类型, 对于go入学者而言,由map导致的问题可能仅次于切片。go map并非goroutine-safe的,go禁止对map变量的并发读写。但由于是内置hash表类型,map在go编程中得到了十分广泛的应用。

上面例子就是一个并发读写map的例子,不过与slice不同,go在map实现中内置了对并发读写的检测,即便不加入-race,一旦发现也会抛出panic。

4. 误传值惹的祸

Go推荐使用传值语义,因为它简化了逃逸分析,并使变量有更好的机会被分配到栈中,从而减少GC的压力。但有些类型是不能通过传值方式传递的,比如下面例子中的sync.Mutex:

sync.Mutex是一个零值可用的类型,我们无需做任何初始赋值即可使用Mutex实例。但Mutex类型有内部状态的:

通过传值方式会导致状态拷贝,失去了在多个goroutine间同步数据访问的作用,就像上面例子中的Mutex类型变量m那样。

5. 误用消息传递(channel)与共享内存

Go采用CSP的并发模型,而channel类型充当goroutine间的通信机制。虽然相对于共享内存,CSP并发模型更为高级,但从实际来看,在对CSP模型理解不到位的情况下,使用channel时也十分易错。

这个例子中的问题在于Start函数启动的goroutine可能阻塞在f.ch的send操作上。因为,一旦ctx cancel了,Wait就会退出,此时没有goroutine再在f.ch上阻塞读,这将导致Start函数启动的新goroutine可能阻塞在“f.ch <- 1”这一行上。

大家也可以看到,像这样的问题很细微,如果不细致分析,很难肉眼识别出来。

6. sync.WaitGroup误用导致data race问题

sync.WaitGroup是Go并发程序常用的用于等待一组goroutine退出的机制。它通过Add和Done方法实现内部计数的调整。而Wait方法用于等待,直到内部计数器为0才会返回。不过像下面例子中的对WaitGroup的误用会导致data race问题:

我们看到例子中的代码将wg.Add(1)放在了goroutine执行的函数中了,而没有像正确方法那样,将Add(1)放在goroutine创建启动之前,这就导致了对WaitGroup内部计数器形成了数据竞争,很可能因goroutine调度问题,是的Add(1)在未来得及调用,从而导致Wait提前返回。

下面这个例子则是由于defer函数在函数返回时的执行顺序问题,导致两个goroutine在locationErr这个变量上形成数据竞争:

main goroutine在判断locationErr是否为nil的时候,另一个goroutine中的doCleanup可能执行,也可能没有执行。

7. 并行的表驱动测试可能引发数据竞争

Go内置单测框架,并支持并行测试(testing.T.Parallel())。但如若使用并行测试,则极其容易导致数据竞争问题,原文没有给出例子,这个大家自行体会吧。

五. 小结

关于data race的代码模式,在uber发布这两篇文章之前,也有一些资料对数据竞争问题的代码模式进行了分类整理,比如下面两个资源,大家可以参照着看。

  • 《Data Race Detector》- https://go.dev/doc/articles/race_detector
  • 《ThreadSanitizer Popular Data Races》- https://github.com/google/sanitizers/wiki/ThreadSanitizerPopularDataRaces中的模式

在刚刚发布的Go 1.19beta1版本中提到,最新的-race升级到了TSan v3版本,race检测性能相对于上一版将提升1.5倍-2倍,内存开销减半,并且没有对goroutine的数量的上限限制。

注:Go要使用-race,则必须启用CGO。

// runtime/race.go

//go:nosplit
func raceinit() (gctx, pctx uintptr) {
    // cgo is required to initialize libc, which is used by race runtime
    if !iscgo {
        throw("raceinit: race build must use cgo")
    }
    ... ...
}

六. 参考资料

  • “Finding races and memory errors with compiler instrumentation” – http://gcc.gnu.org/wiki/cauldron2012?action=AttachFile&do=get&target=kcc.pdf
  • 《Race detection and more with ThreadSanitizer 2》 – https://lwn.net/Articles/598486/
  • 《Google ThreadSanitizer — 排查多线程问题data race的大杀器》- https://zhuanlan.zhihu.com/p/139000777
  • 《Introducing the Go Race Detector》- https://go.dev/blog/race-detector
  • ThreadSanitizer Algorithm V2 – https://github.com/google/sanitizers/wiki/ThreadSanitizerAlgorithm
  • paper: FastTrack: Efficient and Precise Dynamic Race Detection – https://users.soe.ucsc.edu/~cormac/papers/pldi09.pdf
  • paper: Eraser: A Dynamic Data Race Detector for Multithreaded Programs – https://homes.cs.washington.edu/~tom/pubs/eraser.pdf

“Gopher部落”知识星球旨在打造一个精品Go学习和进阶社群!高品质首发Go技术文章,“三天”首发阅读权,每年两期Go语言发展现状分析,每天提前1小时阅读到新鲜的Gopher日报,网课、技术专栏、图书内容前瞻,六小时内必答保证等满足你关于Go语言生态的所有需求!2022年,Gopher部落全面改版,将持续分享Go语言与Go应用领域的知识、技巧与实践,并增加诸多互动形式。欢迎大家加入!

img{512x368}
img{512x368}

img{512x368}
img{512x368}

我爱发短信:企业级短信平台定制开发专家 https://51smspush.com/。smspush : 可部署在企业内部的定制化短信平台,三网覆盖,不惧大并发接入,可定制扩展; 短信内容你来定,不再受约束, 接口丰富,支持长短信,签名可选。2020年4月8日,中国三大电信运营商联合发布《5G消息白皮书》,51短信平台也会全新升级到“51商用消息平台”,全面支持5G RCS消息。

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式:

  • 微博:https://weibo.com/bigwhite20xx
  • 博客:tonybai.com
  • github: https://github.com/bigwhite

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言精进之路1 Go语言精进之路2 商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats