Ingo Molnar wrote:
> RT semaphores have stricter semantics than Linux semaphores. One 
> property is that there always needs to be an owner of a semaphore. If a 
> semaphore gets initialized as init_MUTEX_LOCKED, it is a fair indication
> that the semaphore is really used as a completion object - with no
> stable owner.  (e.g. at insmod time when the init_MUTEX_LOCKED is done,
> the insmod thread will go away after some time, leaving the semaphore
> 'orphaned')

Thanks for the explanation. In that case calling init_MUTEX_LOCKED on an 
RT semaphore is obviously wrong.
However, it only produces a warning during the compilation and is 
guaranteed to BUG when run. It would be better if it obviously failed to 
compile. How about the attached patch?
That makes the compilation fail like this:

drivers/cpufreq/cpufreq.c: In function `cpufreq_add_dev':
drivers/cpufreq/cpufreq.c:608: error: 
`there_is_no_init_MUTEX_LOCKED_for_RT_semaphores' undeclared (first use 
in this function)
drivers/cpufreq/cpufreq.c:608: error: (Each undeclared identifier is 
reported only once
drivers/cpufreq/cpufreq.c:608: error: for each function it appears in.)
make[2]: *** [drivers/cpufreq/cpufreq.o] Error 1
make[1]: *** [drivers/cpufreq] Error 2
make: *** [drivers] Error 2

Michal