参考
- https://stackoverflow.com/questions/28003921/sending-file-descriptor-by-linux-socket
- Linux高级进程编程———在任意两个进程间传递文件描述符：使用 sendmsg 和 recvmsg 实现
- linux进程间描述符的传递（sendmsg和recvmsg）
- qemu和vhost user app的消息传递,guest memory 和vhos-user app的共享，guest和vhost-user app的通知机制
刚才在学习vhost-user时，发现qemu进程跟dpdk进程之间会通过unix套接字来发送文件描述符，进而实现内存共享的功能。那么linux是如何实现这一技术的呢？
上面的参考文章中利用UNIX本地套接字实现了在不同的进程之间传递文件描述符，下面大致分析一下linux内核是如何实现的。
正文
用户态主要接口
首先看一下用户态用到的主要代码（代码做了简化）：
发送端
// 创建UNIX套接字 cli_fd = socket(AF_UNIX, SOCK_STREAM, 0); // 连接接收端 connect(cli_fd, (struct sockaddr *)&server_addr, sizeof(server_addr)); // 打开一个要发送的文件，获取文件描述符 fd = open(OPEN_FILE, O_CREAT | O_RDWR, 0777); // 设置socket_msg ctrl_msg = CMSG_FIRSTHDR(&socket_msg); ctrl_msg->cmsg_len = CMSG_LEN(sizeof(cli_fd)); ctrl_msg->cmsg_level = SOL_SOCKET; ctrl_msg->cmsg_type = SCM_RIGHTS; *((int *)CMSG_DATA(ctrl_msg)) = fd; // 发送 sendmsg(cli_fd, &socket_msg, 0);
接收端
// 创建UNIX套接字 listen_fd = socket(AF_UNIX, SOCK_STREAM, 0); // 等待连接 cli_fd= accept(listen_fd, (struct sockaddr *)&client_addr, &cli_len); // 接受数据 recvmsg(cli_fd, &socket_msg, 0); // 解析fd ctrl_msg = CMSG_FIRSTHDR(&socket_msg); rev_fd = *((int *)CMSG_DATA(ctrl_msg));
内核实现
发送端
这里主要分析sendmsg的实现：
文件：net\socket.c
SYSCALL_DEFINE3(sendmsg, int, fd, struct user_msghdr __user *, msg, unsigned int, flags) { return __sys_sendmsg(fd, msg, flags, true); }
然后从__sys_sendmsg一路往下调用：
__sys_sendmsg -> sockfd_lookup_light -> ___sys_sendmsg(sock, msg, &msg_sys, flags, NULL, 0) -> ____sys_sendmsg -> sock_sendmsg -> sock_sendmsg_nosec -> unix_stream_sendmsg -> scm_send(sock, msg, &scm, false); -> __scm_send -> scm_fp_copy(cmsg, &p->fp) -> fpl = kmalloc(sizeof(struct scm_fp_list), GFP_KERNEL) -> fpp = &fpl->fp[fpl->count] -> file = fget_raw(CMSG_DATA(cmsg)) -> *fpp++ = file -> unix_scm_to_skb(&scm, skb, !fds_sent) -> unix_attach_fds -> scm_fp_dup -> new_fpl = kmemdup(fpl, offsetof(struct scm_fp_list, fp[fpl->count]) -> get_file(fpl->fp[i]); -> return new_fpl
在scm_fp_copy中会分配一块内存fpl，用户要发送的文件描述符fd存放在CMSG_DATA(cmsg)中，调用fget_raw获取fd对应的struct file指针，最后将file指针存放到fpl指向的内存中。
在scm_fp_dup中将fpl拷贝一份返回，并且增加file结构体的引用计数。
接收端
这里主要分析recvmsg的实现：
文件：net\socket.c
SYSCALL_DEFINE3(recvmsg, int, fd, struct user_msghdr __user *, msg, unsigned int, flags) { return __sys_recvmsg(fd, msg, flags, true); }
然后从__sys_recvmsg一路往下调用：
__sys_recvmsg -> sockfd_lookup_light -> ___sys_recvmsg -> ____sys_recvmsg -> sock_recvmsg -> unix_stream_recvmsg -> unix_stream_read_generic -> unix_detach_fds(&scm, skb); -> scm_recv -> scm_detach_fds -> struct file **fp = scm->fp->fp -> new_fd = get_unused_fd_flags -> put_user(new_fd, CMSG_DATA(cm)) -> fd_install(new_fd, get_file(fp[i])) -> __scm_destroy(scm) -> fput(fpl->fp[i])
从skb中构造scm，其中包含发送过来的fp，然后从中将file指针提取出来，接着调用get_unused_fd_flags从当前进程中分配一个空闲的new_fd，最后调用fd_install装载到当前进程的files_struct中。此外，还需要将new_fd设置到CMSG_DATA(cm)中，这样上层应用就可以获得属于自己的文件描述符。
小结
对于引用计数的管理，在发送的时候会调用get_file增加引用计数，防止发送过程中发送端关闭这个文件时file结构体被销毁，在接收端接收的时候也会调用get_file增加引用计数，最后在__scm_destroy中会将file结构体的引用计数减1，这样在整个发送和接收过程中file结构体的引用计数实际增加了1，增加的1是给接收端用的，这样只有当发送端和接收端都关闭这个文件时，对应的file结构体才会被销毁。
通过上面的分析可以知道，发送端和接收端实际是通过增加引用计数的方式共享了同一个file结构体，但是这个file结构体在发送端和接收端对应的fd文件描述符不一定相同，盗用一幅《UNIX环境高级编程》中的图片来描述场景：
同时也正因为是共享了同一个数据结构，所以只能在同一台机器上通过UNIX域套接字实现发送文件描述符的功能。
