file_operations 结构体为什么没有处理 close 的函数

[fly4free]

对比 Windows 驱动，IRP_MJ_CLOSE 就相当于 release 吧 ？
可是怎么没有处理相当于 IRP_MJ_CLEANUP 的函数 ？

如下情况：
./prog1 与 ./prog2 都 open 了自写驱动的设备 /dev/xxxx 进行各种操作

当./prog1 仍旧运行时 ./prog2 程序遇到如下情况：
1.调用了close
2.调用close前崩溃
3.调用close前被结束掉了

按照结构体成员说明，只有两个程序都调用了 close 后(引用计数达到0，对象被销毁)才会调用 release（不知道两个程序在调用close之前都被结束掉这个情况下，是否也调用 release ，我没找到说明，且还未试验）。

而我需要响应其中一个程序在遇到前文描述的情况时所"产生的事件"，这可行吗？


我用的Linux内核版本是 2.6.36.4。

[fly4free]

没人知道吗？ （最后一顶。)

[北极星6号]

file_operation 每一次触发一次，执行一次。只有driver 中有共享数据时，才存在你说的问题。 demo_write() { unsigned buff printk('---------------\n"); } 你可以并发执行1W次。 char buf[64]; demo_write() { copy_from_user(); } 像这个就的考虑。Linux 90% Driver 都是这种。

[nswcfd]

2楼正解。 “事件”啥意思？ 基于引用计数的设计，一般都没法感知其它上下文的加/减操作吧，最多也就知道自己是不是最后一个引用计数?

[猪头三小队长]

如果用户态的程序出了问题，系统在强行关闭这个程序的时候，会清理它所占用的资源，包括打开的文件句柄，所以不用担心，系统会替你调用close。

[fly4free]

哈哈，感谢关注。 我的意思是： 如果用户态的进程每打开一个文件，我在内核态的驱动模块就 申请一块内存/资源与其关联。 那么我需要在这个用户进程被关闭时，清理这块内存/资源 kill进程时，系统自动清理了系统自己的资源，但我自己的资源没机会清理了啊，内存泄漏

[fly4free]

引用 4 楼 nswcfd 的回复:

2楼正解。 “事件”啥意思？ 基于引用计数的设计，一般都没法感知其它上下文的加/减操作吧，最多也就知道自己是不是最后一个引用计数?

引用 4 楼 nswcfd 的回复:

2楼正解。 “事件”啥意思？ 基于引用计数的设计，一般都没法感知其它上下文的加/减操作吧，最多也就知道自己是不是最后一个引用计数?

Windows 驱动的 IRP_MJ_CLEANUP 就是计数减少了才触发的啊

引用 5 楼 fly4free 的回复:

哈哈，感谢关注。 我的意思是： 如果用户态的进程每打开一个文件，我在内核态的驱动模块就 申请一块内存/资源与其关联。 那么我需要在这个用户进程被关闭时，清理这块内存/资源 kill进程时，系统自动清理了系统自己的资源，但我自己的资源没机会清理了啊，内存泄漏

最后一句说的有点问题，修正如下： 用户进程被kill掉后，打开的对象资源延迟到引用计数为0时销毁，只有这个时候，我才有机会销毁我创建的资源(这个“资源”包括这个对象的一次引用)。 但终究是延迟，还有可能被另外一个进程长期占用一个计数，那么程序重新启动后，再次访问同一对象时，又会创建相关资源与其对应。 那么此时，2个进程对其引用至少共2个计数，但是却存在了3份资源。。，只能等到彻底销毁时才能连带着一起销毁。。。

[fly4free]

卧槽，我发现我误解 IRP_MJ_CLEANUP 了。。。。 不过我说的问题，就更成为问题了。。。

[猪头三小队长]

一个正常的驱动里面至少要有几个层次的清理，release对应open（release函数就是在设备文件被关闭时调用的），remove对应probe，module_exit对应module_init，如此健壮的类unix系统不会在架构层面留下这个大的漏洞的。

[fly 100%]

应该先判断一下是不是空

[Wenxy1]

调试下，gdb. 内核，用printk.

[nswcfd]

这个取决于全局资源的访问策略吧，必要的时候在open里还得检查是否相同的资源已经存在。 拿共享内存做了例子，如果open的语义是O_CREAT的话（不存在就创建，否则打开）， 1） 第一个进程打开的时候创建资源，引用计数为1； 2）此进程fork子进程，引用计数为2； 3）进程意外退出，子进程还在，引用计数为1； 4）进程重新启动，重新open，这时的实现就有两个选择： 4.1）忽略之前的实例，重新分配新的资源，那么新资源引用计数为1，老资源引用计数为1； 4.2）不允许重复的资源，那么使用旧的资源，引用计数为2。

[fly4free]

引用 11 楼 nswcfd 的回复:

这个取决于全局资源的访问策略吧，必要的时候在open里还得检查是否相同的资源已经存在。 拿共享内存做了例子，如果open的语义是O_CREAT的话（不存在就创建，否则打开）， 1） 第一个进程打开的时候创建资源，引用计数为1； 2）此进程fork子进程，引用计数为2； 3）进程意外退出，子进程还在，引用计数为1； 4）进程重新启动，重新open，这时的实现就有两个选择： 4.1）忽略之前的实例，重新分配新的资源，那么新资源引用计数为1，老资源引用计数为1； 4.2）不允许重复的资源，那么使用旧的资源，引用计数为2。

麻烦请解释一下第3条，引用计数是如何从2减到1的？通过什么事件、回调（...等机制）能够得到通知？如果这个明白了，我帖子的问题就解开了

[nswcfd]

这里拿共享内存举例子，因为它是系统资源（由kernel分配），所以kernel会负责在进程退出（包括意外退出）的时候执行相关的清理工作。 不过好像不是所有的全局资源都有这种待遇，SYSv IPC的好像就不释放？？ 如果是自己写的驱动的话（典型的是实现char device），由于是基于file system实现的，在用户态fd关闭（包含意外退出）的时候，kernel会调用设备文件的release/close接口。 时间有点长了，跟不上原来帖子的上下文了，抱歉。

[sxh2016]

close表示关闭所有进程，如果进程多的话，有的进程不需要关闭，这时就不能用close，内核提供了引用计数来解决，关闭一个进程就减一，当进程为0的话，就自动放free了，