fd从一个进程传到另一个进程涉及到socket通信，具体来说是通过UNIX domain socket的辅助数据（ancillary data）机制实现的。这是一种在进程间传递文件描述符的标准方法。
1. fd传递的核心原理
在Linux中，文件描述符只在单个进程内有效。不同进程的文件描述符表是独立的，因此不能直接将一个进程的fd值传给另一个进程使用。但内核提供了一种特殊机制，允许通过UNIX domain socket传递文件描述符的"所有权"。这里我们用dma-buf共享机制为案例来分析。
进程A (exporter) 进程B (importer) │ │ ├─ 创建 dma-buf │ │ dmabuf = dma_buf_export(...) │ │ fd_A = dma_buf_fd(dmabuf, ...) │ │ │ ├─ 通过 UNIX socket 发送 fd_A │ │ sendmsg(sock, msg, SCM_RIGHTS) │ │ │ │ │ └───────────────────────────>├─ 接收 fd │ │ recvmsg(sock, msg, ...) │ │ fd_B = extract_fd_from_msg(msg) │ │ │ ├─ 使用 fd_B 获取 dma-buf │ │ dmabuf = dma_buf_get(fd_B) │ │ │ ├─ 进行后续操作 │ │ dma_buf_attach(...) │ │ dma_buf_map_attachment(...)2. fd传递的实现细节
1. UNIX Domain Socket准备
两个进程需要先建立UNIX domain socket连接。通常有两种方式：
方式一：命名socket
// Server端 (可能是exporter或专门的管理服务)intsock=socket(AF_UNIX,SOCK_STREAM,0);structsockaddr_unaddr;addr.sun_family=AF_UNIX;strcpy(addr.sun_path,"/tmp/dma_buf_socket");bind(sock,(structsockaddr*)&addr,sizeof(addr));listen(sock,5);intclient=accept(sock,NULL,NULL);// Client端intsock=socket(AF_UNIX,SOCK_STREAM,0);structsockaddr_unaddr;addr.sun_family=AF_UNIX;strcpy(addr.sun_path,"/tmp/dma_buf_socket");connect(sock,(structsockaddr*)&addr,sizeof(addr));方式二：socketpair(适用于父子进程)
intsv[2];socketpair(AF_UNIX,SOCK_STREAM,0,sv);// sv[0] 和 sv[1] 是一对连接的socket2. 发送端 (Exporter) 代码示例
// 假设已经创建了 dma-buf 并获得了 fdintdmabuf_fd=dma_buf_fd(dmabuf,O_CLOEXEC);// 准备发送消息structmsghdrmsg={0};structioveciov[1];charbuf[1]={'X'};// 必须发送至少一个字节的数据iov[0].iov_base=buf;iov[0].iov_len=1;msg.msg_iov=iov;msg.msg_iovlen=1;// 准备辅助数据（这是关键！）union{charbuf[CMSG_SPACE(sizeof(int))];structcmsghdralign;}u;msg.msg_control=u.buf;msg.msg_controllen=sizeof(u.buf);structcmsghdr*cmsg=CMSG_FIRSTHDR(&msg);cmsg->cmsg_level=SOL_SOCKET;cmsg->cmsg_type=SCM_RIGHTS;// 表示传递文件描述符cmsg->cmsg_len=CMSG_LEN(sizeof(int));// 将 fd 复制到辅助数据中memcpy(CMSG_DATA(cmsg),&dmabuf_fd,sizeof(int));// 发送if(sendmsg(socket_fd,&msg,0)<0){perror("sendmsg failed");return-1;}3. 接收端 (Importer) 代码示例
// 准备接收消息structmsghdrmsg={0};structioveciov[1];charbuf[1];iov[0].iov_base=buf;iov[0].iov_len=1;msg.msg_iov=iov;msg.msg_iovlen=1;// 准备接收辅助数据union{charbuf[CMSG_SPACE(sizeof(int))];structcmsghdralign;}u;msg.msg_control=u.buf;msg.msg_controllen=sizeof(u.buf);// 接收if(recvmsg(socket_fd,&msg,0)<0){perror("recvmsg failed");return-1;}// 提取文件描述符structcmsghdr*cmsg=CMSG_FIRSTHDR(&msg);if(cmsg==NULL||cmsg->cmsg_type!=SCM_RIGHTS){fprintf(stderr,"No fd received\n");return-1;}intreceived_fd;memcpy(&received_fd,CMSG_DATA(cmsg),sizeof(int));// 现在可以使用 received_fd 来访问 dma-buf 了structdma_buf*dmabuf=dma_buf_get(received_fd);3. 内核层面的处理
当通过SCM_RIGHTS发送fd时，内核做了以下关键操作：
发送端处理(
scm_send->scm_fp_copy)：- 检查发送进程是否有权访问该fd
- 增加对应file结构的引用计数（
get_file()） - 将file指针存储在socket缓冲区中
接收端处理(
scm_recv->scm_detach_fds)：- 在接收进程的文件描述符表中分配新的fd（
get_unused_fd_flags()） - 将file结构安装到新fd上（
fd_install()） - 接收进程现在拥有指向同一file对象的新fd
- 在接收进程的文件描述符表中分配新的fd（
关键代码路径（内核）：
// net/core/scm.cint__scm_send(structsocket*sock,structmsghdr*msg,structscm_cookie*p){...if(cmsg->cmsg_type==SCM_RIGHTS){err=scm_fp_copy(cmsg,&p->fp);// 复制文件描述符...}...}voidscm_detach_fds(structmsghdr*msg,structscm_cookie*scm){...for(i=0;i<fdnum;i++){intnew_fd=get_unused_fd_flags(O_CLOEXEC);// 分配新fd...fd_install(new_fd,fp[i]);// 安装file到新fd...}...}4. 为什么需要这种机制？
安全性：
- fd不能被猜测或伪造
- 只有通过显式传递才能共享
- 发送方必须有对该fd的访问权限
正确的引用计数：
- 内核自动管理file对象的引用计数
- 防止资源泄漏和悬空指针
跨进程地址空间隔离：
- 每个进程有自己的fd表和地址空间
- 通过内核中介实现安全共享
灵活性：
- 支持任意类型的文件描述符（dma-buf、eventfd、socket等）
- 可以一次传递多个fd
5.实际应用场景
场景1：Wayland compositor 和 客户端
// Wayland compositor (exporter)intdmabuf_fd=create_dmabuf_for_scanout();wl_buffer_send_dmabuf_fd(client,dmabuf_fd);// 内部使用 sendmsg + SCM_RIGHTS// Wayland client (importer)intreceived_fd=wl_buffer_receive_dmabuf_fd();// 内部使用 recvmsg// 将 fd 传给 GPU 驱动做纹理导入场景2：Android GraphicBuffer 共享
// SurfaceFlinger (exporter)intion_fd=ion_alloc(...);// 或 dma_heap_alloc()android::Parcel parcel;parcel.writeDupFileDescriptor(ion_fd);// 内部通过 binder + SCM_RIGHTSsend_parcel_to_app(parcel);// App (importer)intfd=parcel.readFileDescriptor();// 映射或传给GPU使用场景3：多媒体Pipeline（Camera -> GPU -> Display）
Camera驱动 (V4L2) │ ├─ dma_buf_export() → fd1 │ └──> [UNIX socket + SCM_RIGHTS] ──> GPU进程 │ ├─ dma_buf_get(fd1) ├─ 渲染到另一个 dma-buf → fd2 │ └──> [SCM_RIGHTS] ──> Display进程 │ └─ dma_buf_get(fd2) drm_mode_addfb2(fd2)6. 注意事项
fd的生命周期：
- 发送fd后，发送方应该
close(fd)自己的副本（如果不再需要） - 接收方负责
close()接收到的fd - 内核会正确管理底层file对象的引用计数
- 发送fd后，发送方应该
权限检查：
- 发送方必须对fd有访问权限
- SELinux/AppArmor 可能施加额外限制
限制：
- 每次
sendmsg可传递的fd数量有限制（通常是SCM_MAX_FD = 253） - socket缓冲区大小限制可能影响大量fd的传递
- 每次
错误处理：
- 如果接收方未能及时处理接收到的fd，可能导致资源泄漏
- 需要有超时和清理机制
7. 内核视角的完整流程
发送进程 内核 接收进程 │ │ │ ├─ sendmsg(fd=5) │ │ │ │ │ │ │ └─────────────────>├─ scm_send() │ │ │ └─ scm_fp_copy() │ │ │ ├─ fcheck(5) → file │ │ │ ├─ get_file(file) │ │ │ └─ 存储 file* │ │ │ │ │ ├─ socket buffer 中传递 │ │ │ │ │ │ [时间流逝] │ │ │ │ │ │<─────────────── recvmsg() ├─ │ │ │ │ ├─ scm_detach_fds() │ │ │ ├─ get_unused_fd() → 7 │ │ │ └─ fd_install(7, file) │ │ │ │ │ │──────────────────────────>├─ 得到 fd=7 │ │ │ (指向同一file) │ │ │现在接收进程的fd 7和发送进程的fd 5指向内核中的同一个struct file对象，而该file的private_data指向struct dma_buf，从而实现了dma-buf的共享。
8. 小结
fd的传递是dma-buf跨进程共享的关键环节。通过UNIX domain socket的SCM_RIGHTS机制：
- Exporter导出dma-buf为fd，通过socket发送
- Importer接收fd，在内核中获取到同一个dma-buf对象
- 内核确保引用计数正确、访问安全
这种设计优雅地解决了跨进程共享内核对象的问题，是Linux IPC的重要组成部分，不仅用于dma-buf，也广泛应用于eventfd、pidfd、bpf fd等现代内核特性中。
