Messages in this thread | | | Date | Sat, 28 May 2005 07:53:22 +0200 | From | Ingo Molnar <> | Subject | Re: [patch] Real-Time Preemption, -RT-2.6.12-rc4-V0.7.47-06 |
| |
* 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |