This article can be found at: https://www.ebpf.top/post/ebpf_rust_aya 1. Introduction 2. Setting Up Rust Development Environment 2.1 Create a VM Virtual Machine 2.2 Install Rust Development Environment 2.3 Install Dependencies for bpf-linker and bpftool 3. Aya Guide to Create eBPF Programs 3.1 Creating a Project Using the Guide 3.2 Compile eBPF Program 3.3 Run User-space Program 4. Conclusion References 1. Introduction A significant change in Linux Kernel version 6.1 is the introduction of support for the Rust programming language. Rust is a system programming language that offers robust compile-time guarantees and precise control over memory lifetimes. Integrating Rust language into kernel development will bring additional safety measures to the early stages of kernel development. eBPF is a technology in the kernel that enables running user-defined programs based on events, with a validator mechanism ensuring the security of eBPF programs running in……

Site link: https://www.ebpf.top/post/bpf2pbpf_tail_call Author: Richard Li (Original author’s permission obtained) Original article link: https://blog.csdn.net/weixin_43705457/article/details/123474244 1. Introduction 2. Tail Call 3. BPF to BPF Calls 4. CO-RE Sample 5. Tail Call Costs in eBPF 6. Summary 7. References 1. Introduction This article first introduces the general restrictions and usage of tail calls, compares them with BPF to BPF calls, and finally provides a modified version I made of the tail call sample in the kernel source code (using CO-RE). (When learning about tail calls, I struggled with not having a simple and understandable example that could run, so I ended up creating one myself. I believe this version is the most beginner-friendly and logically clear among all examples currently available). 2. Tail Call BPF provides a capability to safely inject code when kernel events and user program events occur, allowing non-kernel developers to control the kernel.……

This article can be found at: https://www.ebpf.top/post/ftrace_kernel_dynamic 1. Basic Knowledge 1.1 Default Compilation 1.2 Using the -pg Option 1.3 Using the -pg and -mfentry Options 1.4 Kernel Verification 2. Validation of kprobe tracing mechanism in ftrace 3. Validation using a Kernel Module 3.1 Using kallsyms_lookup_name 3.2 Using Kernel Function Addresses Directly (Pitfalls, Optional) 4. Verification using gdb + qemu Reference In the Geek Time’s “Mastering Container Battles” by Teacher Li Chengyuan, a pondering question was left in the extra session 04 | Understanding ftrace(2): How to Understand the Technology Behind ftrace Tracepoint and kprobe?: Consider this, how can we observe that the first instruction of the corresponding kernel function has been replaced after we register a probe with kprobe for it? Kprobe is a mechanism for dynamic tracking of kernel functions. By using this mechanism, almost all kernel functions can be tracked (excluding those annotated with __kprobes/nokprobe_inline and those marked with NOKPROBE_SYMBOL).……

This article can be found at: https://www.ebpf.top/post/no_space_left_on_devices 1. Understanding “no space left on device” Error 2. Problem Analysis and Localization 2.1 Preliminary Identification of Problematic Function 2.2 Locating the Root Cause of the Issue 2.3 Identifying the Root Cause of the Issue 3. Analysis of Discrepancies Between Code Flow and Tracing Process References Recently, there have been cases of failures in creating containers with the error “no space left on device” in the production environment. However, during the investigation, it was found that disk space and inodes were quite normal. In cases where conventional troubleshooting methods have failed, is there a quick and universal approach to pinpointing the root cause of the problem? This article records the analysis and troubleshooting process using eBPF + Ftrace in a separate environment. Considering the general applicability of this approach, it has been organized in the hope of serving as a stepping stone for further exploration.……