Linux4.15下kthread_run设置CLONE_FILES未共享文件描述符表疑问

你观测到的现象和copy_files的代码逻辑并不冲突，核心差异来自于观测时机和内核线程的后续初始化流程：

• 刚调用kernel_thread完成fork操作的时间点，CLONE_FILES标志确实生效，此时新创建的内核线程task_struct的files指针和父线程完全相同，files_struct的引用计数也会按代码逻辑加1，这一步完全符合你梳理的fork流程逻辑。
• 你打印current->files时已经处于内核线程的业务代码执行阶段，而内核线程的公共入口函数kthread在执行用户传入的自定义线程函数前，会完成内核线程的上下文隔离操作，其中就包括主动调用set_files_struct替换掉刚继承的共享files_struct，替换为内核线程独立的文件描述符表，避免和父线程共享上下文引发意料之外的资源泄漏或竞争。
• 内核线程创建时传入CLONE_FILES只是fork阶段的临时优化，减少fork时的资源拷贝开销，后续的强制替换操作才是为了符合内核线程无用户进程上下文、不共享文件描述符表的设计规范。

内容的提问来源于stack exchange，提问作者Ajay Brahmakshatriya