第一次使用Linux内核的Tracepoint的体验

01/02 09:08
阅读数 2.3K

我并不觉得丢人,一点也不。

我是说我工作这么多年做和Linux内核相关的事,竟然在上上周才第一次使用tracepoint。

这并不奇怪,我不会的东西还多着呢,比方说,我一直强调的,我不会编程,我也不会用git。

言归正传,如果这么多年我都没用过tracepoint,那么作为替代,我用什么呢?

如果我调试内核或者调试内核模块,最最最常用的方法就是在代码里加一条printk(如果是用户态程序,我就加一条printf。),我来告诉你理由:

  • printk/printf 不需要安装任何别的依赖包。
  • printk/printf 随手可用,不需要写太多为了重用而过度设计的代码。
  • printk/printf 对不会编程的人及其友好。

所以,我钟爱printk。我不喜欢gdp/crash tool,也不喜欢kprobe/systemtap,更不喜欢bpftrace,当然,我很懂这些东西,只是我觉得它们太复杂,需要记忆的语法太多,就像一个无家可归的流浪汉,不喜欢携带任何负担而已。

扯了这么多,这和tracepoint有毛关系。

有关系,因为我发现在需要添加一条printk的地方添加一个tracepoint工作量差不多,且效果更好。tracepoint更像是添加了一个HOOK,你可以在外面自定义你要做什么,而不仅仅拘泥于printk打印一条消息。

使用tracepoint,如果你只是想达到printk的效果,你可以在/sys/kernel/debug/tracing/trace看到你要打印的信息,如果你还想做点别的,你还可以用eBPF。

类似《史记》太史公曰形而上学的部分在本文最后,现在先给点实际的东西。

在内核代码添加一个tracepoint简单到不必说,只是需要重新编译内核,我给一个在模块里添加tracepoint的Howto吧。

首先给出我要添加tracepoit的内核模块代码:

#include <net/protocol.h>
#include <linux/ip.h>
#include <linux/udp.h>

#define IPPROTO_MYPROTO  123
int myproto_rcv(struct sk_buff *skb)
{
   
   
    struct udphdr *uh;
    struct iphdr *iph;

    iph = ip_hdr(skb);
    uh = udp_hdr(skb);

    printk("proto 123\n");

    kfree_skb(skb);
    return 0;
}

static const struct net_protocol myproto_protocol = {
   
   
    .handler = myproto_rcv,
    .no_policy = 1,
    .netns_ok = 1,
};

int init_module(void)
{
   
   
    int ret = 0;
    ret = inet_add_protocol(&myproto_protocol, IPPROTO_MYPROTO);
    if (ret) {
   
   
        printk("failed\n");
        return ret;
    }
    return 0;
}
void cleanup_module(void)
{
   
   
    inet_del_protocol(&myproto_protocol, IPPROTO_MYPROTO);
}

int init_module(void);
void cleanup_module(void);
MODULE_LICENSE("GPL");

很现实的例子,这个代码注册了一个和TCP,UDP平级的四层协议,但实际上就是UDP,只是协议号改为了123,我们的预期是当收到这样的协议包时,printk打印出端口。

我现在想用tracepoint替代printk,该怎么办呢?下面是方法。下面是新的代码:

/*
 * 注意:
 * 1. CREATE_TRACE_POINTS 必须define
 * 2. CREATE_TRACE_POINTS 必须在头文件之前define
 */

#define CREATE_TRACE_POINTS
#include "test_tp.h"

#include <net/protocol.h>
#include <linux/ip.h>
#include <linux/udp.h>

#define IPPROTO_MYPROTO  123
int myproto_rcv(struct sk_buff *skb)
{
   
   
    struct udphdr *uh;
    struct iphdr *iph;

    iph = ip_hdr(skb);
    uh = udp_hdr(skb);

    // 这里增加一个tracepoint点
    trace_myprot_port(uh->dest, uh->source);

    kfree_skb(skb);
    return 0;
}

static const struct net_protocol myproto_protocol = {
   
   
    .handler = myproto_rcv,
    .no_policy = 1,
    .netns_ok = 1,
};

int init_module(void)
{
   
   
    int ret = 0;
    ret = inet_add_protocol(&myproto_protocol, IPPROTO_MYPROTO);
    if (ret) {
   
   
        printk("failed\n");
        return ret;
    }
    return 0;
}
void cleanup_module(void)
{
   
   
    inet_del_protocol(&myproto_protocol, IPPROTO_MYPROTO);
}

int init_module(void);
void cleanup_module(void);
MODULE_LICENSE("GPL");

增加了一个头文件引用并且增加了一个宏定义,别的什么都没变,是不是很简单呢。

所有和tracepoint相关的元数据定义都在头文件里:

// test_tp.h
#undef TRACE_SYSTEM
#define TRACE_SYSTEM myprot

#if !defined(_TEST_TRACE_H) || defined(TRACE_HEADER_MULTI_READ)
#define _TEST_TRACE_H
#include <linux/tracepoint.h>

// tracepoint的定义就在这里了。可用的参数都在这里,日后debugfs输出的就是按照下面这个TP_printk的格式来的。
// 如果eBPF来输出,依然要遵循这个格式取参数,下面有例子。
TRACE_EVENT(myprot_port,
    TP_PROTO(unsigned short dest, unsigned short source),
    TP_ARGS(dest, source),
    TP_STRUCT__entry(
        __field(unsigned short, dest)
        __field(unsigned short, source)
    ),
TP_fast_assign(
    __entry->dest = dest;
    __entry->source = source;
),

TP_printk("dest:%d, source:%d", __entry->dest, __entry->source)
);

#endif
/*
 * 需要添加以下这一坨
 * 由于模块不能修改内核头文件,因此我们需要在自己的目录放头文件,
 * TRACE_INCLUDE_PATH 必须重新定义,而不是仅仅在内核头文件目录寻找定义。
 *
 * 为了支持这个重定义,Makefile中必须包含:
 * CFLAGS_myprot.o = -I$(src)
 *
 */

#undef TRACE_INCLUDE_PATH
#define TRACE_INCLUDE_PATH .
#define TRACE_INCLUDE_FILE test_tp // 这就是该头文件的名字
#include <trace/define_trace.h>

接下来是Makefile,我们只需要注意第二行:

obj-m += test.o
# CFLAGS_xx.o 其中 xx 为内核模块的名字
CFLAGS_test.o = -DDEBUG -I$(src)

OK,编译模块,加载之。

首先我们开启该tracepoint:

echo 1 >/sys/kernel/debug/tracing/events/myprot/enable

此时,通过raw socket发送一个协议为123的报文,我们会在debugfs看到输出:

cat /sys/kernel/debug/tracing/trace
# tracer: nop
#
# entries-in-buffer/entries-written: 1/1   #P:4
#
#                                _-----=> irqs-off
#                               / _----=> need-resched
#                              | / _---=> hardirq/softirq
#                              || / _--=> preempt-depth
#                              ||| /     delay
#           TASK-PID     CPU#  ||||   TIMESTAMP  FUNCTION
#              | |         |   ||||      |         |
     ksoftirqd/1-16      [001] ..s. 174074.362291: myprot_port: dest:36895, source:53764

当然,这只是模拟了printk,这只不过是把printk统一到了一个地方而已,没什么大不了的。tracepoint更有意义的是,它可以挂载eBPF程序。现在我们可以试一下:

bpftrace -l|grep tracepoint.*myprot
tracepoint:myprot:myprot_port

我们可以用bpftrace简单debug一下:

#!/usr/bin/bpftrace

tracepoint:myprot:myprot_port
{
   
   
	$dest = args->dest;
	$source = args->source;
	printf("bpftrace:dest:%d  source:%d\n",
		($source & 0xff) << 8 | ($source & 0xff00) >> 8,
		($dest & 0xff) << 8 | ($dest & 0xff00) >> 8);
}

运行之,发包:

./test_bpf_tp.tp
Attaching 1 probe...
bpftrace:dest:1234  source:8080

唯一要吐槽的就是为什么像ntohs这样常用的接口竟然没有builtin!

tracepoint和kprobe/kretprobe相比,优缺点分别是什么呢?为什么我不喜欢kprobe这种,我甚至不喜欢live patch,但这又是为什么。

tracepoint的唯一缺点就是它是静态的,它需要通过写代码的方式静态插入到源码的特定位置,然后重新编译之后执行才能生效,与此相反,kprobe是动态的,它在运行时就可以将HOOK动态attach到特定的位置,但很不幸,这是kprobe唯一的优点。

在任何人面前,我都透露出对kprobe的不满,原因和我对live patch的不满一样,那就是, 为了动态插入哪怕一句printk,维护kprobe/live patch框架的代码执行成本太高了!

你去跟踪一下ftrace框架下调用live patch新函数的代码路径有多长,你去跟踪一下krpobe/kretprobe为了执行handler,做了多少额外的事,我需要的只是handler,而handler里只是printk一些变量的值而已,我不想为了这么小的事去大动干戈,如果调用handler的路径上再遭遇一把spinlock,那事情更会及其尴尬,为了调试性能瓶颈而引入的新瓶颈超过了最初的性能瓶颈本身。在性能优化这么精细的动作上,这种 测不准效应 极为掣肘!

我是手艺人,我对kprobe,live patch这种在我看来完全不可控的东西很难信任。当然我也不在乎那些可以熟练操作这些工具的人的耻笑,我有自己的办法。

如果我想patch一个函数,或者说我想在某处插入一条printk,我会手工去做,很简单,直接在特定位置修改代码为call myhandler即可,当myhandler返回,重新执行被替换的指令,这种方式非常简单且直接,我信任这种方式,当我找到了这种方式并且可以熟练运用的时候,在我看来,tracepoint和kprobe也就没有本质的区别了。

忘掉什么是kprobe,live patch,忘掉tracepoint可能比记得它们更好。

招手拦出租车或比手机打滴滴更轻便,同样,使用纸币支付也无需担心电池续航以及隐私问题…


浙江温州皮鞋湿,下雨进水不会胖。

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部