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

[Esben Nielsen]

Replace
 init_MUTEX_LOCKED(&policy->lock);
with
 init_MUTEX(&policy->lock);
 down(&policy->lock);

Compiles here... Would also work upstream.

init_MUTEX_LOCKED() isn't very nice :-(

Esben



On Sat, 28 May 2005, Ingo Molnar wrote:

> 
> * Michal Schmidt <xschmi00@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/