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

Ingo Molnar
2005-05-28T05:58:13Z

* 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