linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Viresh Kumar <viresh.kumar@linaro.org>
To: Preeti U Murthy <preeti@linux.vnet.ibm.com>
Cc: Rafael Wysocki <rjw@rjwysocki.net>,
	ke.wang@spreadtrum.com, linaro-kernel@lists.linaro.org,
	linux-pm@vger.kernel.org, ego@linux.vnet.ibm.com,
	paulus@samba.org, shilpa.bhat@linux.vnet.ibm.com,
	prarit@redhat.com, robert.schoene@tu-dresden.de,
	skannan@codeaurora.org
Subject: Re: [PATCH 06/12] cpufreq: governor: Keep single copy of information common to policy->cpus
Date: Mon, 15 Jun 2015 12:16:24 +0530	[thread overview]
Message-ID: <20150615064624.GK30078@linux> (raw)
In-Reply-To: <557E6D6E.1070200@linux.vnet.ibm.com>

On 15-06-15, 11:45, Preeti U Murthy wrote:
> On 06/11/2015 04:21 PM, Viresh Kumar wrote:
> > @@ -320,6 +363,7 @@ static void cpufreq_governor_exit(struct cpufreq_policy *policy,
> >  		}
> > 
> >  		cdata->exit(dbs_data, policy->governor->initialized == 1);
> > +		free_ccdbs(policy, cdata);
> 
> This is a per-policy data structure, so why free it only when all the
> users of the governor are gone ? We should be freeing it when a policy
> is asked to exit, which is independent of references to this governor by
> other policy cpus. This would mean freeing it outside this if condition.

Right.

> > @@ -348,11 +393,13 @@ static int cpufreq_governor_start(struct cpufreq_policy *policy,
> >  		io_busy = od_tuners->io_is_busy;
> >  	}
> > 
> > +	ccdbs->time_stamp = ktime_get();
> > +	mutex_init(&ccdbs->timer_mutex);
> > +
> >  	for_each_cpu(j, policy->cpus) {
> >  		struct cpu_dbs_info *j_cdbs = cdata->get_cpu_cdbs(j);
> >  		unsigned int prev_load;
> > 
> > -		j_cdbs->policy = policy;
> 
> This is not convincing. INIT and EXIT should be typically used to
> initiate and free 'governor' specific data structures. START and STOP
> should be used for 'policy wide/cpu wide' initialization and making
> NULL. Atleast thats how the current code appears to be designed.
> 
> Now, ccdbs is a policy wide data structure. We can perhaps allocate and
> free ccdbs during INIT and EXIT, but initiating the values and making
> them NULL must be done in START and STOP respectively. You initiate the
> time_stamp and timer_mutex in START, why not initialize policy also
> here? This will help maintain consistency in code too.

I don't think it was done to use it early and so moving it to
START/STOP should be fine.
 
> > @@ -406,10 +452,7 @@ static void cpufreq_governor_stop(struct cpufreq_policy *policy,
> >  		cs_dbs_info->enable = 0;
> >  	}
> > 
> > -	gov_cancel_work(dbs_data, policy);
> > -
> > -	mutex_destroy(&cdbs->timer_mutex);
> > -	cdbs->policy = NULL;
> 
> Same here. For the same reason as above, the value for policy must be
> nullified in STOP. Besides, policy is initiated a value explicitly in
> INIT, but invalidated in EXIT by freeing ccdbs in this patch. There is
> lack of consistency.
> 
> There is another consequence. Freeing a data structure does not
> necessarily mean setting it to NULL. It can be some random address. This
> will break places which check for NULL policy.

If we are freeing ccdbs, then using ccdbs->policy isn't valid anymore.
And so while freeing ccdbs, we don't really need to set its fields to
NULL.

> > +	mutex_destroy(&ccdbs->timer_mutex);
> 
> Another point which you may have taken care of in the subsequent
> patches. I will mention here nevertheless.
> 
> The timer_mutex is destroyed, but the cdbs->policy is not NULL until we
> call EXIT. So when cpufreq_governor_limits() is called, it checks for
> the existence of ccdbs, which succeeds. But when it tries to take the
> timer_mutex it dereferences NULL.

Hmm, so I should keep checking for cdbs->ccdbs->policy instead and
make it NULL in STOP..

Nice work Preeti. Thanks.

-- 
viresh

  reply	other threads:[~2015-06-15  6:46 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-11 10:51 [PATCH 00/12] cpufreq: Fix governor races - part 2 Viresh Kumar
2015-06-11 10:51 ` [PATCH 01/12] cpufreq: governor: Name delayed-work as dwork Viresh Kumar
2015-06-15  3:01   ` Preeti U Murthy
2015-06-11 10:51 ` [PATCH 02/12] cpufreq: governor: Drop unused field 'cpu' Viresh Kumar
2015-06-15  3:12   ` Preeti U Murthy
2015-06-11 10:51 ` [PATCH 03/12] cpufreq: governor: Rename 'cpu_dbs_common_info' to 'cpu_dbs_info' Viresh Kumar
2015-06-18  6:52   ` Preeti U Murthy
2015-06-11 10:51 ` [PATCH 04/12] cpufreq: governor: name pointer to cpu_dbs_info as 'cdbs' Viresh Kumar
2015-06-15  4:22   ` Preeti U Murthy
2015-06-11 10:51 ` [PATCH 05/12] cpufreq: governor: rename cur_policy as policy Viresh Kumar
2015-06-15  4:24   ` Preeti U Murthy
2015-06-11 10:51 ` [PATCH 06/12] cpufreq: governor: Keep single copy of information common to policy->cpus Viresh Kumar
2015-06-15  6:15   ` Preeti U Murthy
2015-06-15  6:46     ` Viresh Kumar [this message]
2015-06-18  5:59     ` Viresh Kumar
2015-06-19  4:13       ` Preeti U Murthy
2015-06-11 10:51 ` [PATCH 07/12] cpufreq: governor: split out common part of {cs|od}_dbs_timer() Viresh Kumar
2015-06-15  7:03   ` Preeti U Murthy
2015-06-11 10:51 ` [PATCH 08/12] cpufreq: governor: synchronize work-handler with governor callbacks Viresh Kumar
2015-06-15  8:23   ` Preeti U Murthy
2015-06-15  8:31     ` Viresh Kumar
2015-06-11 10:51 ` [PATCH 09/12] cpufreq: governor: Avoid invalid states with additional checks Viresh Kumar
2015-06-15  8:59   ` Preeti U Murthy
2015-06-15  9:12     ` Viresh Kumar
2015-06-11 10:51 ` [PATCH 10/12] cpufreq: governor: Don't WARN on invalid states Viresh Kumar
2015-06-15  9:52   ` Preeti U Murthy
2015-06-11 10:51 ` [PATCH 11/12] cpufreq: propagate errors returned from __cpufreq_governor() Viresh Kumar
2015-06-15 10:30   ` Preeti U Murthy
2015-06-11 10:51 ` [PATCH 12/12] cpufreq: conservative: remove 'enable' field Viresh Kumar
2015-06-15 10:40   ` Preeti U Murthy
2015-06-15  4:49 ` [PATCH 00/12] cpufreq: Fix governor races - part 2 Preeti U Murthy
2015-06-15  5:45   ` Viresh Kumar
2015-06-15 23:29 ` Rafael J. Wysocki
2015-06-16  2:10   ` Viresh Kumar
2015-06-18  5:19   ` Viresh Kumar

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=20150615064624.GK30078@linux \
    --to=viresh.kumar@linaro.org \
    --cc=ego@linux.vnet.ibm.com \
    --cc=ke.wang@spreadtrum.com \
    --cc=linaro-kernel@lists.linaro.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=paulus@samba.org \
    --cc=prarit@redhat.com \
    --cc=preeti@linux.vnet.ibm.com \
    --cc=rjw@rjwysocki.net \
    --cc=robert.schoene@tu-dresden.de \
    --cc=shilpa.bhat@linux.vnet.ibm.com \
    --cc=skannan@codeaurora.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).