linux的fd传递实现

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] 是一对连接的socket

2. 发送端 (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时，内核做了以下关键操作：

1. 发送端处理(scm_send->scm_fp_copy)：

   • 检查发送进程是否有权访问该fd
   • 增加对应file结构的引用计数（get_file()）
   • 将file指针存储在socket缓冲区中

2. 接收端处理(scm_recv->scm_detach_fds)：

   • 在接收进程的文件描述符表中分配新的fd（get_unused_fd_flags()）
   • 将file结构安装到新fd上（fd_install()）
   • 接收进程现在拥有指向同一file对象的新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. 为什么需要这种机制？

1. 安全性：

   • fd不能被猜测或伪造
   • 只有通过显式传递才能共享
   • 发送方必须有对该fd的访问权限

2. 正确的引用计数：

   • 内核自动管理file对象的引用计数
   • 防止资源泄漏和悬空指针

3. 跨进程地址空间隔离：

   • 每个进程有自己的fd表和地址空间
   • 通过内核中介实现安全共享

4. 灵活性：

   • 支持任意类型的文件描述符（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. 注意事项

1. fd的生命周期：

   • 发送fd后，发送方应该close(fd)自己的副本（如果不再需要）
   • 接收方负责close()接收到的fd
   • 内核会正确管理底层file对象的引用计数

2. 权限检查：

   • 发送方必须对fd有访问权限
   • SELinux/AppArmor 可能施加额外限制

3. 限制：

   • 每次sendmsg可传递的fd数量有限制（通常是SCM_MAX_FD = 253）
   • socket缓冲区大小限制可能影响大量fd的传递

4. 错误处理：

   • 如果接收方未能及时处理接收到的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等现代内核特性中。