A different approach to module races

A different approach to module races

Posted Jul 31, 2003 21:30 UTC (Thu) by rankincj (subscriber, #4865)
In reply to: A different approach to module races by cpeterso
Parent article: A different approach to module races

There has been a lot of core-kernel help for module references. Most of the important kernel structures have an "owner" field that is (or should be) initialised to THIS_MODULE. In theory, the kernel can then increment and decrement the modules' usage counters when it knows that it is safe to do so.

Part of the problem has been that a lot of structures that needed owner fields didn't have them. The USB subsystem only gained an owner field in 2.4.20, and this created a maintenance problem for out-of-kernel drivers supporting earlier versions. The 2.4 serial layer doesn't have one at all, although I think the 2.6 layer might. And the locking requirements for stacks of related modules aren't always obvious, either. I suppose the simplest way of looking at the problem is that only the core-kernel or a locked module should modify another module's usage counter, although I'm sure that people can think of various exceptions to this, or cases when it cannot be achieved for some reason...

As for module garbage collection, I have that already in the form of a cron job that runs "rmmod -a" once an hour. However, the problem is to know which modules can be unloaded in the first place.

---

(Log in to post comments)