我有一个守护进程，我不断启动并在循环中执行'kill -9'以便对特定用例进行压力测试。该守护进程加载一个共享库，该库又打开一个fd。 （打开/关闭fd是在内核中处理的另一个共享库代码）。我观察到在内核库中清理操作时，它会在清理之前检查来自task_structs（tgid）的PID值。 现在我的观察：我有时看到当守护进程被杀死时，我没有看到相关的tgid值，而是看到一个奇怪的进程ID值，即'binder process'。因此，我在内核代码中的清理操作不会对juts被'kill -9'杀死的进程ID生效
任何人都知道为什么current-＆gt; tgid值是绑定进程的值而不是被杀死的守护进程的值。请注意，我的守护程序确实链接到'libbinder'。不确定这是否会产生影响。如果我从我的守护进程中删除链接到'libbinder'及其相关代码，一切似乎都很好
有任何建议/想法吗？
答案 0 :(得分：0)
如果您的用户空间进程打开一个文件，然后分叉另一个进程，那么打开的文件将在分叉进程中重复（看起来这个libbinder可能正在分离另一个进程）。
只有在放置 last 对文件的引用时，才会调用内核中file_operations结构的close方法。如果两个进程在同一时间内死亡，那么最终调用close方法的进程将是第二个进程中的任何一个。
您的内核代码应该不键入tgid。它应该将清理操作所需的数据附加到struct file，不到task_struct。