Linux套接字与虚拟文件系统（2）：操作和销毁

今天药忘吃喽~ 2022-08-09 14:44 21阅读 0赞

转载自：http://www.cppblog.com/qinqing1984/archive/2015/05/03/210522.html

[Linux套接字与虚拟文件系统（2）：操作和销毁][Linux_2]

接上篇 [初始化与创建][Link 1] ，本篇阐述Socket操作和 [销毁][Link 2] 两部分的实现。  
  
Socket操作

--------------------

系统调用read(v)、write(v)是用户空间读写socket的一种方法，为了弄清楚它们是怎么通过VFS将请求转发到特定协议的实现，下面以read为例（write同理），并假定文件描述符对应的是IPv4 TCP类型的socket，来跟踪它的执行流程。首先来看下sys\_read的代码，定义在fs/read\_write.c中。

1 ![None.gif][] SYSCALL\_DEFINE3( **read** , unsigned  int , fd,  char  \_\_user  \* , buf, size\_t, count)  
  2 ![ExpandedBlockStart.gif][] \{  
 3![InBlock.gif][]struct file \*file;  
 4![InBlock.gif][] ssize\_t ret =\-EBADF;  
 5![InBlock.gif][]int fput\_needed;  
 6![InBlock.gif][]  
 7![InBlock.gif][] file = fget\_light(fd, &fput\_needed);  
 8![ExpandedSubBlockStart.gif][]if (file) \{  
 9![InBlock.gif][] loff\_t pos = file\_pos\_read(file);  
10![InBlock.gif][]ret =vfs\_read(file, buf, count, &pos);  
11![InBlock.gif][] ![dot.gif][]  
12![ExpandedSubBlockEnd.gif][] \}  
13![InBlock.gif][]  
14![InBlock.gif][]return ret;  
15![ExpandedBlockEnd.gif][]\}

先调用fget\_light得到fd对应的file，再调用vfs\_read。接着跟踪vfs\_read的代码，定义在fs/read\_write.c中。

1 ![None.gif][] ssize\_t  **vfs\_read** ( struct  file  \* file,  char  \_\_user  \* buf, size\_t count, loff\_t  \* pos)  
  2 ![ExpandedBlockStart.gif][] \{  
 3![InBlock.gif][] ssize\_t ret;  
 4![InBlock.gif][] ![dot.gif][]  
 5![InBlock.gif][] ret = rw\_verify\_area(READ, file, pos, count);  
 6![ExpandedSubBlockStart.gif][]if (ret >=0) \{  
 7![InBlock.gif][] count = ret;  
 8![InBlock.gif][]if (file\->f\_op\->read)  
 9![InBlock.gif][] ret = file\->f\_op\->read(file, buf, count, pos);  
10![InBlock.gif][]else  
11![InBlock.gif][] ret =do\_sync\_read(file, buf, count, pos);  
12![InBlock.gif][] ![dot.gif][]  
13![ExpandedSubBlockEnd.gif][] \}  
14![InBlock.gif][]  
15![InBlock.gif][]return ret;  
16![ExpandedBlockEnd.gif][]\}

在 [上篇Socket创建一节][Socket] 已知，因为sockfs\_file\_ops没有定义read（即read指针为空），所以这儿实际调用了do\_sync\_read，继续跟踪它的代码，定义在fs/read\_write.c中。

1 ![None.gif][] ssize\_t  **d** **o\_sync\_read** ( struct  file  \* filp,  char  \_\_user  \* buf, size\_t len, loff\_t  \* ppos)  
  2 ![ExpandedBlockStart.gif][] \{  
 3![ExpandedSubBlockStart.gif][]struct iovec iov =\{ .iov\_base = buf, .iov\_len = len \};  
 4![InBlock.gif][]struct kiocb kiocb;  
 5![InBlock.gif][] ssize\_t ret;  
 6![InBlock.gif][]  
 7![InBlock.gif][] ![dot.gif][]  
 8![ExpandedSubBlockStart.gif][]for (;;) \{  
 9![InBlock.gif][] ret = filp\->f\_op\->aio\_read(&kiocb, &iov, 1, kiocb.ki\_pos);  
10![InBlock.gif][]if (ret !=\-EIOCBRETRY)  
11![InBlock.gif][]break;  
12![InBlock.gif][] wait\_on\_retry\_sync\_kiocb(&kiocb);  
13![ExpandedSubBlockEnd.gif][] \}  
14![InBlock.gif][]  
15![InBlock.gif][]if (\-EIOCBQUEUED == ret)  
16![InBlock.gif][] ret = wait\_on\_sync\_kiocb(&kiocb);  
17![InBlock.gif][]\*ppos = kiocb.ki\_pos;  
18![InBlock.gif][]return ret;  
19![ExpandedBlockEnd.gif][]\}

显而易见，这儿调用到了f\_op->aio\_read，使用异步读来实现同步读，若异步读没有完成，则调用wait\_on\_sync\_kiocb等待。由 [上篇Socket创建一节][Socket] 可知sockfs\_file\_ops的aio\_read设为sock\_aio\_read函数，定义在net/socket.c中，至此sys\_read的实现完成了前一半(操作对象是file)而进入后一半（操作对象是socket），即socket层的实现。  
 在socket层跟踪sock\_aio\_read，可以得到最后调用的是sock->ops->recvmsg，由于socket类型为IPv4 TCP，因此sock->ops在socket创建过程中被设为inet\_stream\_ops，定义在net/ipv4/af\_inet.c中。

1 ![ExpandedBlockStart.gif][] const  struct  proto\_ops  **inet\_stream\_ops**  =  \{  
2![InBlock.gif][] .family = PF\_INET,  
3![InBlock.gif][] ![dot.gif][]  
4![InBlock.gif][] .release=inet\_release,  
5![InBlock.gif][] ![dot.gif][]  
6![InBlock.gif][] .recvmsg=sock\_common\_recvmsg,  
7![InBlock.gif][] ![dot.gif][]  
8![ExpandedBlockEnd.gif][]\} ;

从上可知recvmsg设为sock\_common\_recvmsg，跟踪它的代码，定义在net/core/sock.c中。

1 ![None.gif][] int  **sock\_common\_recvmsg** ( struct  kiocb  \* iocb,  struct  socket  \* sock,  struct  msghdr  \* msg, size\_t size,  int  flags)  
  2 ![ExpandedBlockStart.gif][] \{  
 3![InBlock.gif][]struct sock \*sk = sock\->sk;  
 4![InBlock.gif][]int addr\_len =0;  
 5![InBlock.gif][]int err;  
 6![InBlock.gif][]  
 7![InBlock.gif][] err = sk\->sk\_prot\->recvmsg(iocb, sk, msg, size, flags & MSG\_DONTWAIT,flags &~MSG\_DONTWAIT, &addr\_len);  
 8![InBlock.gif][] ![dot.gif][]  
 9![InBlock.gif][]return err;  
10![ExpandedBlockEnd.gif][]\}

struct sock表示套接字的网络接口层，它的成员sk\_prot表示网络协议块，在这它对应tcp\_prot结构，定义在net/ipv4/tcp\_ipv4.c中，由此可见进入到特定协议的实现。

1 ![ExpandedBlockStart.gif][] struct  proto  **tcp\_prot**  =  \{  
2![InBlock.gif][] .name ="TCP",  
3![InBlock.gif][] ![dot.gif][]  
4![InBlock.gif][] .close=tcp\_close,  
5![InBlock.gif][] ![dot.gif][]  
6![InBlock.gif][] .recvmsg=tcp\_recvmsg,  
7![InBlock.gif][] ![dot.gif][]  
8![ExpandedBlockEnd.gif][]\} ;

recvmsg设为tcp\_recvmsg，至此跟踪结束。对于sys\_readv的实现，调用的是vfs\_readv，后面的过程和sys\_read相同，总结核心调用链如下图：

![sockfs_sock_op_callchain.png][]

由此可知，sockfs\_file\_ops只须实现aio\_read，就能支持普通和聚集两种方式的读操作。为了对比，这里也给出Berkeley Sockets API中recv的核心调用链如下图：

![sockfs_sock_sys_recv_callchain.png][]

显而易见，recv内部实现调用的是sys\_recvfrom，它没有经过VFS，而是先调用sock\_lookup\_light从fd得到socket，再调用sock\_recvmsg，后面的流程和recv就是一样的了。  
  
Socket销毁

--------------------

Socket操作既可以调用文件IO，也可以调用Berkeley Sockets API。但销毁不同，系统调用close是用户空间销毁socket的唯一方法，它定义在fs/open.c中。

1 ![None.gif][] SYSCALL\_DEFINE1( **close** , unsigned  int , fd)  
  2 ![ExpandedBlockStart.gif][] \{  
 3![InBlock.gif][]struct file \* filp;  
 4![InBlock.gif][]struct files\_struct \*files = current\->files;  
 5![InBlock.gif][]struct fdtable \*fdt;  
 6![InBlock.gif][]int retval;  
 7![InBlock.gif][]  
 8![InBlock.gif][] spin\_lock(&files\->file\_lock);  
 9![InBlock.gif][] fdt = files\_fdtable(files);  
10![InBlock.gif][] ![dot.gif][]  
11![InBlock.gif][]filp = fdt\->fd\[fd\];  
12![InBlock.gif][] ![dot.gif][]  
13![InBlock.gif][] rcu\_assign\_pointer(fdt\->fd\[fd\], NULL);  
14![InBlock.gif][] FD\_CLR(fd, fdt\->close\_on\_exec);  
15![InBlock.gif][] \_\_put\_unused\_fd(files, fd);  
16![InBlock.gif][] spin\_unlock(&files\->file\_lock);  
17![InBlock.gif][] retval =filp\_close(filp, files);  
18![InBlock.gif][] ![dot.gif][]  
19![ExpandedBlockEnd.gif][]\}

首先从fd获取对应的file，若file非空则设置进程描述符数组对应项为空，并将fd从exec时关闭的文件描述符链表和打开的文件描述符链表中移除；最后调用filp\_close，跟踪它的代码，定义在fs/open.c中。

1 ![None.gif][] int  **filp\_close** ( struct  file  \* filp, fl\_owner\_t id)  
  2 ![ExpandedBlockStart.gif][] \{  
 3![InBlock.gif][]int retval =0;  
 4![InBlock.gif][]  
 5![ExpandedSubBlockStart.gif][]if (!file\_count(filp)) \{  
 6![InBlock.gif][] printk(KERN\_ERR "VFS: Close: file count is 0\\n");  
 7![InBlock.gif][]return0;  
 8![ExpandedSubBlockEnd.gif][] \}  
 9![InBlock.gif][]  
10![InBlock.gif][]if (filp\->f\_op && filp\->f\_op\->flush)  
11![InBlock.gif][] retval = filp\->f\_op\->flush(filp, id);  
12![InBlock.gif][]  
13![InBlock.gif][] dnotify\_flush(filp, id);  
14![InBlock.gif][] locks\_remove\_posix(filp, id);  
15![InBlock.gif][]fput(filp);  
16![InBlock.gif][]return retval;  
17![ExpandedBlockEnd.gif][]\}

首先判断file的引用计数，若为0则打印一个错误日志（说明这是一个bug，因为file已经被释放）并返回；由于sockfs\_file\_ops中的flush没有定义即为空，因此跳过；dnotify\_flush用于释放任何相关的dnotify（一种文件监控机制）资源，locks\_remove\_posix用于清除文件锁相关的资源，由于socket对应的inode没有使用文件锁，因此它什么也没做。最后调用fput来释放file，定义在fs/file\_table.c中。

1 ![None.gif][] void  **fput** ( struct  file  \* file)  
 2 ![ExpandedBlockStart.gif][] \{  
3![InBlock.gif][]if (atomic\_long\_dec\_and\_test(&file\->f\_count))  
4![InBlock.gif][] \_\_fput(file);  
5![ExpandedBlockEnd.gif][]\}

先递减引用计数，若为0则调用\_\_fput释放file，它会调用到sockfs\_file\_ops定义的release函数即sock\_close，它是sock\_release的包装函数，sock\_release定义在net/socket.c中。

1 ![None.gif][] void  **sock\_release** ( struct  socket  \* sock)  
  2 ![ExpandedBlockStart.gif][] \{  
 3![ExpandedSubBlockStart.gif][]if (sock\->ops) \{  
 4![InBlock.gif][]struct module \*owner = sock\->ops\->owner;  
 5![InBlock.gif][]  
 6![InBlock.gif][] sock\->ops\->release(sock);  
 7![InBlock.gif][] sock\->ops = NULL;  
 8![InBlock.gif][] module\_put(owner);  
 9![ExpandedSubBlockEnd.gif][] \}  
10![InBlock.gif][]if (sock\->fasync\_list)  
11![InBlock.gif][] printk(KERN\_ERR "sock\_release: fasync list not empty!\\n");  
12![InBlock.gif][]  
13![InBlock.gif][] percpu\_sub(sockets\_in\_use, 1);  
14![ExpandedSubBlockStart.gif][]if (!sock\->file) \{  
15![InBlock.gif][]iput(SOCK\_INODE(sock));  
16![InBlock.gif][]return;  
17![ExpandedSubBlockEnd.gif][] \}  
18![InBlock.gif][] sock\->file = NULL;  
19![ExpandedBlockEnd.gif][]\}

先调用ops->release即特定协议的释放操作，对于IPv4 TCP，就是inet\_stream\_ops中定义的inet\_release函数，它又会调用到tcp\_prot中定义的close即tcp\_close；对于关联inode的释放，这里要分2种情况：如果sock->file为空，就调用iput释放，否则返回到\_\_fput中，会调用dput释放dentry，而dentry又关联着inode，最终调用iput释放inode；当最后一个iput被调用时，sockfs\_ops中定义的sock\_destroy\_inode就会被调用，归还由sock\_alloc\_inode分配的struct socket\_alloc对象到SALB缓存中。总结核心调用链如下图：

![sockfs_sock_destroy_calltree.PNG][]

在 [上篇初始化一节][Link 3] ，我们已知sockfs文件系统被装载，然而实际上没有卸载它的方式。由于TCP/IP协议栈和sockfs被静态编译到内核中，而不是一个内核模块。因此没必要提供一个卸载函数，sockfs伪文件系统在启动到关闭期间，总是被装载着的。

[Linux_2]: http://www.cppblog.com/qinqing1984/archive/2015/05/03/210522.html
[Link 1]: http://www.cppblog.com/qinqing1984/archive/2015/05/30/210521.html
[Link 2]: http://www.cppblog.com/qinqing1984/archive/2015/05/03/210522.html#sock_destroy
[None.gif]: /images/20220731/4b332094a7d04c2ebd8838f4809a3e98.png
[ExpandedBlockStart.gif]: /images/20220731/c56905df540a4b2cb40468cce2367c2d.png
[InBlock.gif]: /images/20220731/cc5c99f63806437395fda7c06058f13e.png
[ExpandedSubBlockStart.gif]: /images/20220731/cd7bc64d9d874b24bc5fe5c5d3dbea06.png
[dot.gif]: /images/20220731/769315c2a4c34388bdc96069f1cd3fda.png
[ExpandedSubBlockEnd.gif]: /images/20220731/65ee8cd749794858bc70c97361d71c3c.png
[ExpandedBlockEnd.gif]: /images/20220731/89add779275b43949d6c33348a605089.png
[Socket]: http://www.cppblog.com/qinqing1984/archive/2015/05/03/210521.html#sock_create
[sockfs_sock_op_callchain.png]: /images/20220731/bd56508f2ca34e8fbb266a898ffdd7d8.png
[sockfs_sock_sys_recv_callchain.png]: /images/20220731/9f6d3c5bba8e4587b3a92c79a6810d7d.png
[sockfs_sock_destroy_calltree.PNG]: /images/20220731/cd612e38fef44a2599102963555b8283.png
[Link 3]: http://www.cppblog.com/qinqing1984/archive/2015/05/03/210521.html#sockfs_init