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 <[email protected]> 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 [email protected]
> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
