Re: [patch] Real-Time Preemption, -RT-2.6.12-rc4-V0.7.47-06

[Ingo Molnar <mingo@elte.hu>]

* Michal Schmidt <xschmi00@stud.feec.vutbr.cz> wrote:

> I wrote:
> >I'm attaching a patch which changes a semaphore in cpufreq into a 
> >completion. With this patch, my system runs OK even with cpufreqd.
> >
> 
> Although the patch worked for me, it was probably bogus.

no, it was quite fine i think.

> The real reason why cpufreq caused problems was that it does:
>   init_MUTEX_LOCKED(&policy->lock);
> and later:
>   up(&policy->lock);
> where policy->lock is declared as:
>   struct semaphore        lock;
> 
> In PREEMPT_RT, the init_MUTEX_LOCKED is defined in include/linux/rt_lock.h :
>   /*
>    * No locked initialization for RT semaphores:
>    */
>   #define init_MUTEX_LOCKED(sem) compat_init_MUTEX_LOCKED(sem)
> (BTW, I don't understand why we have init_MUTEX but no init_MUTEX_LOCKED 
> for RT semaphores).

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')

> So the fix is to change the lock type into compat_semaphore. I'm 
> attaching the patch. It works for me with 2.6.12-rc5-RT-V0.7.47-12.

it would be nice to get the conversion to completions upstream. It is a 
perfectly fine solution. The compat_semaphore thing is another, easier 
solution.

	Ingo