On 17 September 2013 00:12, Jon Medhurst (Tixy) wrote:
> The commit log to that patch still mentions taking both locks.
Yeah, it was sent in hurry to just give you a working solution and I forgot
to see the log if it is still valid.
> The code itself fixes the lockdep errors I had, so
>
> Tested
On 17 September 2013 00:04, Rafael J. Wysocki wrote:
> Care to resend with a subject indicating that that's a patch update?
>
> Like [PATCH v2] etc. or similar?
Yeah.. I was waiting for Tixy to test it once..
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body o
On Mon, 2013-09-16 at 22:38 +0530, Viresh Kumar wrote:
> On 16 September 2013 21:57, Jon Medhurst (Tixy) wrote:
> > If I take mainline code and just change the line above to:
>
> You meant this line by above line?
>
> unlock_policy_rwsem_write(cpu);
Yes.
> >up_write(&per_cpu(cpu_p
On Monday, September 16, 2013 10:38:05 PM Viresh Kumar wrote:
> On 16 September 2013 21:57, Jon Medhurst (Tixy) wrote:
> > If I take mainline code and just change the line above to:
>
> You meant this line by above line?
>
> unlock_policy_rwsem_write(cpu);
>
> >up_write(&per_cpu(cp
On 16 September 2013 21:57, Jon Medhurst (Tixy) wrote:
> If I take mainline code and just change the line above to:
You meant this line by above line?
unlock_policy_rwsem_write(cpu);
>up_write(&per_cpu(cpu_policy_rwsem, (per_cpu(cpufreq_cpu_data,
> cpu))->last_cpu));
> then the big
On Mon, 2013-09-16 at 20:40 +0530, Viresh Kumar wrote:
> Current code looks like this:
>
> WARN_ON(lock_policy_rwsem_write(cpu));
> update_policy_cpu(policy, new_cpu);
> unlock_policy_rwsem_write(cpu);
>
> {lock|unlock}_policy_rwsem_write(cpu) takes/releases policy->cpu's
Current code looks like this:
WARN_ON(lock_policy_rwsem_write(cpu));
update_policy_cpu(policy, new_cpu);
unlock_policy_rwsem_write(cpu);
{lock|unlock}_policy_rwsem_write(cpu) takes/releases policy->cpu's rwsem.
Because cpu is changing with the call to update_policy_cpu(),
7 matches
Mail list logo
