Re: [PATCH 1/12] cpufreq: governor: Close dbs_data update race condition

2016-02-18 Thread Viresh Kumar
On 18-02-16, 02:19, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > It is possible for a dbs_data object to be updated after its > usage counter has become 0. That may happen if governor_store() > runs (via a govenor tunable sysfs attribute write) in parallel > with cpufreq_governor_exit(

Re: [PATCH 1/12] cpufreq: governor: Close dbs_data update race condition

2016-02-18 Thread Rafael J. Wysocki
On Fri, Feb 19, 2016 at 3:27 AM, Viresh Kumar wrote: > On 18-02-16, 17:20, Rafael J. Wysocki wrote: >> On Thu, Feb 18, 2016 at 6:24 AM, Viresh Kumar >> wrote: >> > On 18-02-16, 02:19, Rafael J. Wysocki wrote: > >> >> @@ -112,7 +112,7 @@ static ssize_t governor_store(struct kob >> >> >> >>

Re: [PATCH 1/12] cpufreq: governor: Close dbs_data update race condition

2016-02-18 Thread Viresh Kumar
On 18-02-16, 17:20, Rafael J. Wysocki wrote: > On Thu, Feb 18, 2016 at 6:24 AM, Viresh Kumar wrote: > > On 18-02-16, 02:19, Rafael J. Wysocki wrote: > >> @@ -112,7 +112,7 @@ static ssize_t governor_store(struct kob > >> > >> mutex_lock(&dbs_data->mutex); > >> > >> - if (gattr->store) >

Re: [PATCH 1/12] cpufreq: governor: Close dbs_data update race condition

2016-02-18 Thread Rafael J. Wysocki
On Thu, Feb 18, 2016 at 6:24 AM, Viresh Kumar wrote: > On 18-02-16, 02:19, Rafael J. Wysocki wrote: >> From: Rafael J. Wysocki >> >> It is possible for a dbs_data object to be updated after its >> usage counter has become 0. That may happen if governor_store() >> runs (via a govenor tunable sysf

Re: [PATCH 1/12] cpufreq: governor: Close dbs_data update race condition

2016-02-17 Thread Viresh Kumar
On 18-02-16, 02:19, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > It is possible for a dbs_data object to be updated after its > usage counter has become 0. That may happen if governor_store() > runs (via a govenor tunable sysfs attribute write) in parallel > with cpufreq_governor_exit(