ebpf

Sched_ext 回调深度解析（八）：running —— 任务开始执行（6.18.26）基于 Linux 6.18.26，结合内核源码逐行分析系列文章：框架背景与回调总览见前言，本文聚焦 running 回调。

Sched_ext框架总览基于 Linux 6.18.26，结合内核源码逐行分析系列文章：sched_ext（简称 scx）是 Linux 内核的 eBPF 调度器框架，自 6.12 起合入主线。它允许开发者用 eBPF 程序在用户态编写自定义 CPU 调度策略，而无需修改内核代码或重启系统。

破局与守正：eBPF 在 Linux 内存管理中的应用、演进与重构构想作为 Linux 内核中一项革命性的技术，eBPF（Extended Berkeley Packet Filter，扩展版伯克利包过滤器）正在以前所未有的速度改变着操作系统的底层生态。它允许开发者在不修改内核源码、不需要重启内核的前提下，安全地在内核中运行自定义程序。这种“即插即用”、兼顾极致性能与绝对安全的特性，已经让 eBPF 在网络（如 Cilium）、可观测性（如 BCC、Pixie）以及安全审计（如 Falco）三大领域大放异彩。

linux开发之路

C++项目推荐：eBPF+调度器性能分析框架来源：程序员老廖的个人空间想象一个场景：你写了一个程序，运行起来很慢，但你不知道慢在哪里。是 CPU 算得慢？还是等磁盘 IO？还是被锁卡住了？

Linux 跨设备内存共享核心：dma-buf 全景演进与技术前沿dma-buf（DMA Buffer）是 Linux 内核中用于跨设备/跨驱动内存共享的核心子系统。近年来，随着 AI 训练、大模型推理以及超高性能网络（如 400G/800G 网络）的爆发，数据在 GPU、网卡（NIC）、存储设备（NVMe）之间的零拷贝（Zero-copy）传输成为了刚需。dma-buf 已经从最初一个简单的“媒体设备间共享内存”的小工具，演变成了如今支撑现代 AI 数据中心、GPU 服务器超高性能通信的底层基石。

Sched_ext 回调深度解析（二）：enable —— 任务被调度器接管的关键时刻（6.18.26）基于 Linux 6.18.26 内核源码（kernel/sched/ext.c）分析。系列文章：struct sched_ext_ops 代表一个 BPF 调度器，其中定义了多个回调函数（hook）。当一个 task 被 sched_ext 调度器正式接管时触发 enable 回调。

Sched_ext 回调深度解析（一）：init_task —— 每个任务走进调度器的第一道门（6.18.26）基于 Linux 6.18.26，结合内核源码逐行分析sched_ext（简称 scx）是 Linux 内核的 eBPF 调度器框架。你可以把它理解为一个"调度器插件系统"——内核提供了标准的钩子（hook），你用 eBPF 程序实现这些钩子，就能写出一个完整的调度器。

比 veth 更强、为 eBPF 而生：深度解析 Linux netkit 虚拟网卡驱动在云原生网络（如 Cilium、Calico）的演进过程中，veth-pair 一直是连接容器与宿主机的功臣。然而，随着对高性能、低延迟的极致追求，传统 veth 的协议栈开销逐渐成为瓶颈。

[eCapture] OpenSSL 文件 Hook 机制本文聚焦 OpenSSL 共享库文件（libssl.so.*）Hook 机制中最核心的一条主线：库文件如何被识别、如何被挂载 uprobes、以及为什么会出现“找错库/挂错库/版本识别失败”。

生成式AI+eBPF：智能运维新范式的技术实现与深度解析在云原生时代，eBPF已成为系统可观测性的核心技术，它能够在内核层无侵入地捕获网络、文件、进程等维度的实时数据。然而，面对每秒数百万事件的海量监控数据，传统基于规则的分析方法已显疲态。生成式AI的崛起为这一挑战提供了全新解法：通过LLM理解复杂系统行为，通过机器学习预测潜在故障，通过自然语言交互降低运维门槛。二者的结合不是简单的技术叠加，而是构建了一个"感知-认知-决策"的智能运维闭环。

eBPF驱动的企业可观测性革命：从内核层重构运维新范式在云原生和微服务架构普及的今天，企业可观测性面临前所未有的挑战。传统监控方案基于应用层埋点（如OpenTelemetry）、基础设施代理（如Prometheus Node Exporter）和日志收集（如Fluentd），这种分层架构存在三大核心痛点：监控盲区（无法观测到内核层和网络层细节）、性能开销（应用层埋点带来10-15%的性能损耗）、数据割裂（指标、日志、链路数据分散在不同系统）。当一次用户请求跨越数十个微服务，故障定位如同大海捞针，平均MTTR（平均修复时间）长达2-4小时。

深度拦截：Linux 内核引入 Firmware LSM 挂钩，eBPF 再下一城！引言在现代高性能计算和云原生场景下，用户空间与硬件设备的交互日益频繁。如何确保这些直接发送给固件（Firmware）的命令是安全的？传统的 Linux 安全模型似乎遇到了瓶颈。近日，内核社区提交了一项名为 “Firmware LSM hook” 的补丁集，利用 eBPF 的灵活性为固件命令穿上了“防弹衣”。

[ecapture] gotls：三种模式实现说明与上层应用职责本文说明 ecapture 中 text（明文）、keylog（仅密钥）、pcapng（网卡密文 + 密钥）三种 CaptureMode 在代码层面如何落地，以及上层应用（消费 ecapture 产出或与之集成的服务）通常需要做什么。OpenSSL 探针在 ecapture 中采用相同的三种模式分支，仅 BPF 与挂载符号改为 libssl，下文以 gotls 为主描述。

[ecapture] eBPF hook gotls 收包乱序根因分析测试环境: nextcloud（docker部署网盘）+caddy(goals 反向代理默认http2协议)

[eCapture] GoTLS Perf 事件有序下发关键词：eBPF / Perf / 时间序重排 / GoTLS / 单调时间本文说明 eCapture GoTLS 探针在 Perf 事件路径上，为缓解多 CPU / 合并读序与用户态探针时间序不一致而采用的设计思想、实现要点、验证方式与结论。 PR：https://github.com/gojue/ecapture/pull/978

【内核前沿】从 veth 到 netkit：深度解析 TCP devmem 穿透容器屏障的“队列租赁”黑科技前言：高性能网络的下半场在云原生和 AI 大模型时代，网络性能的瓶颈正从“带宽”转向“拷贝”。为了消除 CPU 拷贝开销，TCP devmem (设备内存) 应运而生。然而，容器环境下虚拟网卡（veth/netkit）与物理硬件的“天然隔阂”，让这项黑科技长期难以进入容器。

程序猿编码

eBPF代理：让SSH进程“溯源”，找到背后的客户端IP咱们先聊个实际场景：服务器上突然出现可疑命令执行，比如有人偷偷查看系统文件，你查进程只能看到命令本身，却不知道是谁通过SSH登录后操作的——是远程的黑客，还是内部人员？如果能把每一个执行的进程，都对应到发起SSH连接的客户端IP、端口和用户，排查问题就会轻松很多。而这，就是eBPF代理的核心作用：给SSH相关的进程“打标签”，无论经过多少层操作，都能追溯到最初的SSH客户端来源。

eBPF 实战：一次诡异的 Nginx 高延迟，我用 5 分钟在内核里找到了真凶没有玄学，只有内核里的铁证如山。P99延迟无故飙升，CPU空闲，网络通畅，文件I/O正常——那一刻，我怀疑自己遇到了灵异事件。

Sched ext回调3——select_cpu（linux 6.15.7）struct sched_ext_ops代表了一个调度器，里面定义了很多回调函数，本文分析select_cpu这个hook，sched ext的部分hook如下：

JiMoKuangXiangQu

Linux eBPF 案例：sk_filter 读取 IP 地址崩溃限于作者能力水平，本文可能存在谬误，因此而给读者带来的损失，作者不做任何承诺。笔者在制作一个使用 eBPF 分析网络收发流程耗时的工具，以 Linux 自带的示例代码为起点。eBPF 测试代码包括用户空间和内核空间两部分。用户空间部分测试代码如下：