给流量（特指 TCP 流量）打上 TOS，可以在 cgroup bpf sockops 的这 3 个 HOOK 里调 bpf_setsockopt(skops, SOL_IP, IP_TOS, &tos, sizeof(tos)) 给 socket 设置 TOS。 BPF_SOCK_OPS_TCP_CONNECT_CB BPF_SOCK_OPS_ACTIVE_ESTABLISHED_CB BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB 不过，同事最近遇到个问题：bpf_setsocko

某天，同事反馈个问题：升级某个网络组件后，server 直接失联了。 看了下事故报告，问题不复杂： 复现 使用 10.0.0.0/8 来复现过于危险了。既然是 ip route

那个人是我！！！ 一贯以来，作为面向用户态的内核态接口，syscall 的定义是非常稳定的；变更 syscall 的接口定义是非常罕见的。 在 Alexei 的授意下，我扩展了

fsession 是我跟 Menglong 大佬合作的杰作，已合入 bpf 社区，将在 v7.0 合入 Linux 主线。 目前，fsession 已支持 x86_64 和 arm64 架构。 TL;DR fsession 指的是一个新的 tracing attach type: BPF_TRACE

在开发 percpu map CPU flags 补丁集的过程中，遇到了 2 个 LRU hash map 的问题。 在尝试修复这 2 个问题时，得到社区的反馈：留着它们吧。 屎山别动 能不用 LRU hash map 就别用 问题 1：

给以下 bpf maps 增加了 BPF_F_CPU 和 BPF_F_ALL_CPUS flag 支持： BPF_MAP_TYPE_PERCPU_ARRAY BPF_MAP_TYPE_PERCPU_HASH BPF_MAP_TYPE_LRU_PERCPU_HASH BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE 这 2 个 flag 的作用： lookup_elem() 时，可以通过 BPF_F_CPU + cpu 查询指定 CPU 上的值。 update_elem() 时，可以通过 BPF_F_CPU + cpu 更新指定 CPU 上的值。 update_elem() 时，可以

在努力排查一个网络设备相关的问题；终不负期望，排查出根因了。 现象是 dmesg 里不停地打印以下日志： 1 page_pool_release_retry() stalled pool shutdown 1 inflight 2899 sec 根因：Kafka Go library IBM/sarama 存在 tcp 连接

python/cpython: Running python REPL under another program + Ctrl-C results in an exception traceback Gray 大佬已排查到关键之处： As I mentioned, kernel forbids background processes to call tcsetattr(TCSADRAIN), so the following syscall for sure failed: 1 20:18:26 ioctl(3, TCGETS, ...}) = -1 EIO (Input/output error) <0.000007> 但但但是，我确实不知道内核会有如

遇到个奇怪的丢包统计问题： 1 2 3 4 5 6 # netstat -i Kernel Interface table Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg bond0 1500 4714238062 0 9955805 0 4206040873 0 2 0 BMmRU ens1f0 1500 2145684247 0 3 0 1917444695 0 0 0 BMsRU ens1f1 1500 2568553815 0 0 0 2288596177 0 0 0 BMsRU 如

bpfsnoop 是一款 bpf 时代的现代化内核函数、内核跟踪点和 bpf 程序的动态追踪工具。 v0.1.0 v0.2.0 v0.3.0 v0.4.0 bpfsnoop 发布 v0.5.0 版本，主要更新如下： 使用 fentry 和 fexit 实现 bpf 版本的 funcgraph 功能。 给 --output-arg 新增