* 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/
[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]