@
julyclyde 你真的是.....那我来给你讲讲代码吧...
首先,你讲的/proc/pid/mounts 是 pid 这个进程所在的命名空间里挂载的所有文件系统列表,跟题主的问题没有任何关系,题主没有涉及 namespace 的切换,主进程和 sdk (子进程之类的)处于同一个 namespace 。
其次,让我们看一下 vfs 层的代码,
path_lookupat 函数负责解析路径分量,path_init 负责初始化路径分量的解析起点,对于 ls . 这个命令来讲,我们把起点设定为 fs->pwd ,也就是/proc/pid/cwd 的值。放在题主的环境里起点就是 workdir 这个父目录
然后函数进入 link_path_walk 开始正式解析路径分量,由于我们的入参 name=".",所以此函数一个循环直接结束,不会进一步进入 walk_component 函数了。link_path_walk 返回 0 ,此时入参 nd 直接把父目录 workdir 带回了。上层函数 path_lookupat 直接调用 lookup_last 把父目录相关的 dentry 和 inode 准备好,然后层层返回,路径查找结束。
那么再来看看 ls /tmp/workdir 的情况,路径分量解析起点是/,即父文件系统的根目录。然后 name="/tmp/workdir"被 link_path_walk 逐段解析,由于/后是 tmp 字符串,所以调用 walk_component 首先解析 tmp ,这个环节无事发生,再然后使用 walk_component 继续进入 workdir 这个子目录,此时发现 workdir 的 dentry 上有个标志位 DCACHE_MOUNTED(mount 系统调用是给 workdir 这个挂载点设置的,参见函数 d_set_mounted),这说明了什么?说明这是个挂载点,于是 lookup_mnt 被调用,路径查找流程开始“下降”到子文件系统,所以我们要解析的下一个分量不再是父文件系统的 workdir 目录,而是子文件系统的根目录。于是我们就看到了新的内容。
对比以上两个过程,我们会发现当 ls . 的时候,由于. 是个特殊的分量,内核会特殊的处理,所以不会走 walk_component ,也就没机会检测到当前目录上的 DCACHE_MOUNTED 标志。
而我们 ls 一个/tmp/workdir 的时候,迫使内核重新走一遍路径分量解析,它就能发现 DCACHE_MOUNTED 标志。
这就是为什么 ls . 永远看到旧内容,而 ls ../workdir 或者 ls /tmp/workdir 却可以看到新内容