linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Prarit Bhargava <prarit@redhat.com>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Rafael Wysocki <rjw@rjwysocki.net>,
	Lists linaro-kernel <linaro-kernel@lists.linaro.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>
Subject: Re: [PATCH 12/13] cpufreq: stats: Fix locking
Date: Tue, 23 Dec 2014 05:47:30 -0500	[thread overview]
Message-ID: <54994842.3000801@redhat.com> (raw)
In-Reply-To: <CAKohpok+7b3t3-82EO+9tpmBHavMxBT1r2ORhPcQbT3hT=p9mA@mail.gmail.com>



On 12/23/2014 01:06 AM, Viresh Kumar wrote:
> On 18 December 2014 at 17:30, Viresh Kumar <viresh.kumar@linaro.org> wrote:
>> Locking wasn't handled properly at places and this patch is an attempt to fix
>> it. Specially while creating/removing stat tables.
> 
> Because we were required to allocated memory from within locks, we had to
> use mutex here. So, just consider a mutex instead of spinlock everywhere in
> this file.

There is a subtle locking issue here that I want to make sure you're aware of
(mostly because it has bitten me in the past a few times).

> diff --git a/drivers/cpufreq/cpufreq_stats.c b/drivers/cpufreq/cpufreq_stats.c
> index 7701532b32c8..e18735816908 100644
> --- a/drivers/cpufreq/cpufreq_stats.c
> +++ b/drivers/cpufreq/cpufreq_stats.c
> @@ -149,10 +149,12 @@ static void __cpufreq_stats_free_table(struct cpufreq_policy *policy)
>  
>  	pr_debug("%s: Free stat table\n", __func__);
>  
> +	spin_lock(&cpufreq_stats_lock);
>  	sysfs_remove_group(&policy->kobj, &stats_attr_group);

^^^ this line is not guaranteed to have removed the group files by the time it
returns.  That is important in this code IMO, as we are adding and removing the
stats entries rapidly.  You may hit the dreaded "sysfs file already exists"
WARNING if this is done too fast, or if sysfs is locked for some other reason
and delays the removal of the group.  In the worst case, it is possible you hit
a NULL pointer due to stale data access (because you kfree and set to a NULL
pointer below).

I've never found a good method to block this sort of add/remove sysfs file race
from happening.  Perhaps someone else may have a suggestion.  In the past I've
thought about adding a usage count to the sysfs file handlers themselves but
that seems to lead to blocking on userspace access...

>  	kfree(stat->time_in_state);
>  	kfree(stat);
>  	policy->stats_data = NULL;
> +	spin_unlock(&cpufreq_stats_lock);
>  }

There may not be an easy way around this ...

P.

> 

  reply	other threads:[~2014-12-23 10:47 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-18 12:00 [PATCH 00/13] cpufreq: stats: cleanups Viresh Kumar
2014-12-18 12:00 ` [PATCH 01/13] cpufreq: stats: don't break strings into multiple lines Viresh Kumar
2014-12-18 12:00 ` [PATCH 02/13] cpufreq: stats: return -EEXIST when stats are already allocated Viresh Kumar
2014-12-18 12:00 ` [PATCH 03/13] cpufreq: stats: don't check for freq table while freeing stats Viresh Kumar
2014-12-18 12:00 ` [PATCH 04/13] cpufreq: stats: pass 'stat' to cpufreq_stats_update() Viresh Kumar
2014-12-18 12:00 ` [PATCH 05/13] cpufreq: stats: get rid of per-cpu cpufreq_stats_table Viresh Kumar
2014-12-18 12:00 ` [PATCH 06/13] cpufreq: Remove (now) unused 'last_cpu' from struct cpufreq_policy Viresh Kumar
2014-12-18 12:00 ` [PATCH 07/13] cpufreq: stats: remove cpufreq_stats_update_policy_cpu() Viresh Kumar
2014-12-18 12:00 ` [PATCH 08/13] cpufreq: remove CPUFREQ_UPDATE_POLICY_CPU notifications Viresh Kumar
2014-12-18 12:00 ` [PATCH 09/13] cpufreq: stats: create sysfs group once we are ready Viresh Kumar
2014-12-18 12:00 ` [PATCH 10/13] cpufreq: stats: don't update stats from show_trans_table() Viresh Kumar
2014-12-18 12:00 ` [PATCH 11/13] cpufreq: stats: don't update stats on false notifiers Viresh Kumar
2014-12-18 12:00 ` [PATCH 12/13] cpufreq: stats: Fix locking Viresh Kumar
2014-12-23  6:06   ` Viresh Kumar
2014-12-23 10:47     ` Prarit Bhargava [this message]
2014-12-23 10:55       ` Viresh Kumar
2014-12-24 19:01         ` Prarit Bhargava
2014-12-18 12:00 ` [PATCH 13/13] cpufreq: stats: call cpufreq_stats_update() with locks held Viresh Kumar
2014-12-19  2:15 ` [PATCH 00/13] cpufreq: stats: cleanups Rafael J. Wysocki
2014-12-29  4:41   ` Viresh Kumar
2014-12-30 14:56     ` Prarit Bhargava

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54994842.3000801@redhat.com \
    --to=prarit@redhat.com \
    --cc=linaro-kernel@lists.linaro.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=viresh.kumar@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).