Messages in this thread | | | Date | Wed, 27 Apr 2011 13:59:22 +0200 | From | Jean Delvare <> | Subject | Re: [PATCH v2 3/3] thermal: Make THERMAL_HWMON implementation fully internal |
| |
Hi Guenter,
On Tue, 26 Apr 2011 14:00:31 -0700, Guenter Roeck wrote: > On Tue, 2011-04-26 at 15:39 -0400, Jean Delvare wrote: > > Sorry I realize I have been inaccurate. thermal_sys indeed depends on > > the processor module, and that's what prevents me from unloading it. > > It's the processor module which has a reference count of 1, and no > > dependency, so I have no idea how I could unload it. > > > You mean the ACPI processor driver ? This comment might explain it: > > /* > * We keep the driver loaded even when ACPI is not running. > * This is needed for the powernow-k8 driver, that works even without > * ACPI, but needs symbols from this driver > */
I doubt it. I don't have powernow-k8 loaded on the affected systems. And if I did, that would be a regular inter-module dependency that would be listed by lsmod.
> > (...) > > I'm not sure. I don't see any relevant call to try_module_get under > > drivers/acpi, and I'm not aware of any other way to increase the > > reference count. > > > What happens if the calling code (such as, in my case here, the acpi > video code) gets built into the kernel ? Would that force the module to > be and remain loaded ?
For regular inter-module dependencies, that's not even possible. You can't build into the kernel a driver which depends on a symbol exported by a driver which is built as a module. It will break at link time.
For reference counts increased by try_module_get(), it is possible, but that doesn't necessarily make a difference from the all-modules case: the reference count can be increased at any time, not only during driver initialization, so the corresponding module_put doesn't necessarily happen during module unloading (which indeed never happens for a built-in driver.)
I tried booting in initlevel 1, but it didn't help, the reference count of module processor is stuck to 1. So it's not user-space causing it... it's something in the kernel itself. But I really don't have the time to investigate this further, especially when I have no idea where to look next.
-- Jean Delvare
| |