System V共享内存通过shmat把内存段映射到进程地址空间，通过shmdt解除映射。shmdt只做分离映射，并不销毁共享内存对象；只有当所有附加进程都调用shmdt且内核引用计数归零后，共享内存段才会真正被标记删除。问题在于，如果有进程在业务逻辑中提前调用shmdt，其余仍在读写的进程会在访问已分离地址时触发SIGSEGV，而且崩溃栈通常与真正的错误代码相距甚远。要还原共享内存分离现场，最直接的方法是在shmdt入口和出口插入探针，eBPF正好提供了一种无需修改内核和业务程序的观测能力。
内核处理shmdt的系统调用会经过security_mmap_file、do_shmdt等关键函数，最终在do_shmdt中完成VMA查找、页表清理和引用计数递减。借助kprobe或者fentry挂载这些函数，可以获得比系统调用层更细的上下文信息。下面分别从内核路径、BPF探针实现和实际分析三个角度深入讨论。
shmdt在内核中的执行路径与观测点
shmdt系统调用只有一个参数shmaddr，表示要分离的共享内存起始地址。在x86_64架构下，该参数通过RDI寄存器传入，内核入口sys_shmdt从寄存器中取出地址后调用do_shmdt。do_shmdt的核心逻辑是遍历当前进程的mm_struct中红黑树管理的VMA，找到与shmaddr对应的虚拟内存区域，检查是否为共享内存映射，然后调用unmap_region或do_munmap解除映射，并更新共享内存对象的附加计数。
从可观测性角度看，至少存在三个适合插入BPF探针的位置。第一个是系统调用入口sys_shmdt，优点是稳定且语义明确，但看不到VMA内部状态；第二个是do_shmdt入口，能够拿到shmaddr参数并准备读取当前task的mm信息；第三个是do_shmdt返回点，可以同时获取返回值和分离前后的VMA状态。对于需要详细分析共享内存分离的场景，建议在do_shmdt入口和返回点同时挂载kprobe和kretprobe。
eBPF程序运行在内核上下文，能够安全读取task_struct、mm_struct等内核结构。不过直接硬编码结构体偏移在跨内核版本时容易失效，推荐通过BTF和CO-RE机制进行字段访问。比如当前进程的PID、进程名、mm中VMA的起始结束地址，都可以通过BPF helper或BTF读取。这样即使内核版本升级，只要BTF信息存在，程序依然可以正常工作。
用BPF挂载shmdt并获取当前任务上下文
在实际编码时，BPF程序会在do_shmdt入口使用PT_REGS_PARM1读取第一个参数shmaddr。随后需要获取当前task_struct，标准做法是调用bpf_get_current_task()，再通过bpf_get_current_pid_tgid()拿到PID与TID。而标题中的bpf_get_current_task_shmdt可以理解为围绕shmdt场景封装出的任务上下文获取逻辑：如果目标内核提供了该helper或等价的BTF导出函数，可以直接获得当前task中与共享内存分离相关的信息；如果没有该helper，可以用bpf_get_current_task配合BTF读取mm_struct中的VMA信息作为替代，效果基本相同。
下面是一个完整的kprobe示例，它在do_shmdt入口捕获shmaddr和进程信息，并通过ring buffer传给用户态。代码中使用了BPF CO-RE的vmlinux.h，同时通过bpf_get_current_task获取task_struct，再结合BPF_CORE_READ读取当前进程的mm和活动VMA范围。为了简化，示例只记录传入的shmaddr和当前进程标识，实际生产环境可以补充更多字段。
#include "vmlinux.h"
#include <bpf/bpf_helpers.h>
#include <bpf/bpf_tracing.h>
#include <bpf/bpf_core_read.h>
struct shmdt_event {
u32 pid;
u32 tid;
u64 shmaddr;
char comm[16];
long ret;
};
struct {
__uint(type, BPF_MAP_TYPE_RINGBUF);
__uint(max_entries, 256 * 1024);
} events SEC(".maps");
SEC("kprobe/do_shmdt")
int BPF_KPROBE(trace_do_shmdt, const void *shmaddr)
{
struct shmdt_event *e;
e = bpf_ringbuf_reserve(&events, sizeof(*e), 0);
if (!e)
return 0;
e->pid = bpf_get_current_pid_tgid() >> 32;
e->tid = bpf_get_current_pid_tgid() & 0xffffffff;
e->shmaddr = (u64)shmaddr;
e->ret = 0;
bpf_get_current_comm(&e->comm, sizeof(e->comm));
bpf_ringbuf_submit(e, 0);
return 0;
}
char LICENSE[] SEC("license") = "GPL";
这段代码中，BPF_KPROBE宏会自动处理寄存器参数，因此trace_do_shmdt的第一个参数就是shmaddr。ring buffer事件结构体包含了进程PID、TID、命令行和分离地址，后续可以在用户态程序中解析这些字段。需要注意的是，BPF程序不允许直接解引用任意内核指针，必须使用bpf_probe_read_kernel或BPF_CORE_READ进行安全读取，否则验证器会拒绝加载。这个示例只使用了已验证的helper，所以不会触碰非法内存。
如果想要记录分离操作的返回值，还需要在kretprobe中挂载do_shmdt返回点。kretprobe上下文中的PT_REGS_RC可以读取返回值，通常0表示分离成功，-EINVAL表示地址不是有效的共享内存映射地址，-ENOMEM等错误码也能帮助判断失败原因。把入口事件和返回事件配对后，就能完整还原一次shmdt调用。
从事件流中定位提前分离、重复分离与内存泄漏
获得了shmdt事件之后，分析共享内存分离问题的第一步是看时间线和进程关系。如果某个共享内存段在多个进程间共享，而其中一个进程的shmdt事件发生时间明显早于其他进程的访问结束时间，那么后续的SIGSEGV很可能就是这种提前分离引起。此时可以结合shmat事件进行配对：BPF同样可以挂载shmat入口，记录附加地址和共享内存ID，形成每个进程的附加与分离生命周期。若某进程先shmat后短时间内就shmdt，而业务逻辑显示它应该继续持有映射，则说明该进程执行了多余的分离调用。
重复分离是另一类常见问题。共享内存一旦被shmdt解除映射，进程再对同一地址调用shmdt会返回-EINVAL，因为当前进程的VMA中已经不存在该地址。如果应用层没有检查返回值，重复调用通常不会直接崩溃，但可能掩盖真正的引用计数错误。通过kretprobe记录返回值，可以快速统计出哪些进程频繁触发-EINVAL，并回溯其调用栈。BPF支持bpf_get_stackid或bpf_get_stack来采集内核态和用户态栈，用户态栈尤其能定位到业务代码中多余的shmdt调用点。
共享内存对象的引用计数泄漏则是更隐蔽的问题。shmdt分离后，如果内核没有正确递减共享内存对象的附加计数，该对象会一直残留在系统中，表现为ipcs -m中nattch字段不为零但实际已无进程附加，或者共享内存占用的物理页无法释放。这类问题通常需要结合shmctl(IPC_RMID)和shmdt的完整生命周期来分析。eBPF可以在do_shmdt中读取对应共享内存段的shmid以及当前附加计数，通过事件输出到用户态做聚合统计。由于shmdt本身不具备直接shmid参数，需要从VMA对应的文件或映射信息中反查，这一点在使用BPF分析时经常被忽略。正确做法是先通过mm_struct找到目标VMA，再读取VMA关联的vm_file，进一步从file关联的shmid_kernel结构中获得shmid和引用计数。
总体而言，用BPF追踪shmdt的最大价值在于不需要修改业务进程，也无需重新编译内核，就能把内核中共享内存分离的关键参数实时导出。调试生产环境中的段错误、内存泄漏和共享内存对象残留问题时，这套探针组合可以大幅缩短定位时间。唯一需要注意的是内核结构体偏移会随版本变化，使用CO-RE和BTF能够保证探针的长期可维护性。