On 11/11/2014 05:07 AM, Viresh Kumar wrote:
On 11 November 2014 17:45, Prarit Bhargava wrote:
the deadlock in commit 955ef4833574636819cd269cfbae12f79cbde63a
[ 75.471265]CPU0CPU1
[ 75.476327]
[ 75.481385] lock(>rwsem);
[
On 11/11/2014 05:07 AM, Viresh Kumar wrote:
On 11 November 2014 17:45, Prarit Bhargava pra...@redhat.com wrote:
the deadlock in commit 955ef4833574636819cd269cfbae12f79cbde63a
[ 75.471265]CPU0CPU1
[ 75.476327]
[ 75.481385]
On 11 November 2014 17:45, Prarit Bhargava wrote:
> the deadlock in commit 955ef4833574636819cd269cfbae12f79cbde63a
>
> [ 75.471265]CPU0CPU1
> [ 75.476327]
> [ 75.481385] lock(>rwsem);
> [ 75.485307]
On 11/10/2014 10:37 PM, Viresh Kumar wrote:
> On 10 November 2014 17:56, Prarit Bhargava wrote:
>
>>> I still fail to understand why ? What will the _trylock() change ?
>>
>> viresh, afaict read_trylock will return 0 when busy with write:
>
> Yes..
>
>> static inline int
On 11/10/2014 10:37 PM, Viresh Kumar wrote:
On 10 November 2014 17:56, Prarit Bhargava pra...@redhat.com wrote:
I still fail to understand why ? What will the _trylock() change ?
viresh, afaict read_trylock will return 0 when busy with write:
Yes..
static inline int
On 11 November 2014 17:45, Prarit Bhargava pra...@redhat.com wrote:
the deadlock in commit 955ef4833574636819cd269cfbae12f79cbde63a
[ 75.471265]CPU0CPU1
[ 75.476327]
[ 75.481385] lock(policy-rwsem);
[ 75.485307]
On 10 November 2014 17:56, Prarit Bhargava wrote:
>> I still fail to understand why ? What will the _trylock() change ?
>
> viresh, afaict read_trylock will return 0 when busy with write:
Yes..
> static inline int queue_read_trylock(struct qrwlock *lock)
> {
> u32 cnts;
>
>
On 11/10/2014 05:44 AM, Viresh Kumar wrote:
> On 5 November 2014 20:23, Prarit Bhargava wrote:
>> commit 955ef4833574636819cd269cfbae12f79cbde63a (" cpufreq: Drop rwsem
>> lock around CPUFREQ_GOV_POLICY_EXIT") opens up a hole in the locking
>> scheme for cpufreq.
>>
>> Simple tests such as
On 5 November 2014 20:23, Prarit Bhargava wrote:
> commit 955ef4833574636819cd269cfbae12f79cbde63a (" cpufreq: Drop rwsem
> lock around CPUFREQ_GOV_POLICY_EXIT") opens up a hole in the locking
> scheme for cpufreq.
>
> Simple tests such as rapidly switching the governor between ondemand and
>
On 5 November 2014 20:23, Prarit Bhargava pra...@redhat.com wrote:
commit 955ef4833574636819cd269cfbae12f79cbde63a ( cpufreq: Drop rwsem
lock around CPUFREQ_GOV_POLICY_EXIT) opens up a hole in the locking
scheme for cpufreq.
Simple tests such as rapidly switching the governor between ondemand
On 11/10/2014 05:44 AM, Viresh Kumar wrote:
On 5 November 2014 20:23, Prarit Bhargava pra...@redhat.com wrote:
commit 955ef4833574636819cd269cfbae12f79cbde63a ( cpufreq: Drop rwsem
lock around CPUFREQ_GOV_POLICY_EXIT) opens up a hole in the locking
scheme for cpufreq.
Simple tests such as
On 10 November 2014 17:56, Prarit Bhargava pra...@redhat.com wrote:
I still fail to understand why ? What will the _trylock() change ?
viresh, afaict read_trylock will return 0 when busy with write:
Yes..
static inline int queue_read_trylock(struct qrwlock *lock)
{
u32 cnts;
commit 955ef4833574636819cd269cfbae12f79cbde63a (" cpufreq: Drop rwsem
lock around CPUFREQ_GOV_POLICY_EXIT") opens up a hole in the locking
scheme for cpufreq.
Simple tests such as rapidly switching the governor between ondemand and
performance or attempting to read policy values while a governor
commit 955ef4833574636819cd269cfbae12f79cbde63a ( cpufreq: Drop rwsem
lock around CPUFREQ_GOV_POLICY_EXIT) opens up a hole in the locking
scheme for cpufreq.
Simple tests such as rapidly switching the governor between ondemand and
performance or attempting to read policy values while a governor
14 matches
Mail list logo
