All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dirk Brandewie <dirk.brandewie@gmail.com>
To: sedat.dilek@gmail.com
Cc: Viresh Kumar <viresh.kumar@linaro.org>,
	Dirk Brandewie <dirk.brandewie@gmail.com>,
	"Rafael J. Wysocki" <rjw@sisk.pl>,
	Dirk Brandewie <dirk.j.brandewie@intel.com>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
	cpufreq@vger.kernel.org, Linux PM list <linux-pm@vger.kernel.org>,
	Lists linaro-kernel <linaro-kernel@lists.linaro.org>,
	Nathan Zimmer <nzimmer@sgi.com>
Subject: Re: linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref]
Date: Mon, 15 Apr 2013 11:01:26 -0700	[thread overview]
Message-ID: <516C4076.7070605@gmail.com> (raw)
In-Reply-To: <CA+icZUVk1_Dw5Kb8uWwk7xjrgx6jPOfP8BZdFXQ9bqgmdckHuQ@mail.gmail.com>

On 04/15/2013 10:51 AM, Sedat Dilek wrote:
> On Mon, Apr 15, 2013 at 7:22 PM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
>> On 15 April 2013 21:37, Dirk Brandewie <dirk.brandewie@gmail.com> wrote:
>>> If the intel_pstate driver is being used __cpufreq_governor() should NOT be
>>> called intel_pstate does not implement the target() callback.
>>>
>>> Nathan's commit 5800043b2 changed the fence around the call to
>>> __cpufreq_governor() in __cpufreq_remove_dev() here is the relevant hunk.
>>
>> No it isn't.
>>
>>> +       if (has_target)
>>>                  __cpufreq_governor(data, CPUFREQ_GOV_STOP);
>>
>> As it has taken care of this limitation.
>>
>> BUT some of my earlier patches haven't. :(
>> Here is the fix (Sedat please try this and give your tested-by, use the attached
>> patch as gmail might break what i am copying in mail)..
>>
>> Sorry for being late in fixing this issue, i am still down with Tonsil infection
>> and fever.. Today only i got some power to fix it after seeing Dirk's mail.
>>
>> Your tested-by may help me to recover quickly :)
>>
>
> Hehe.
> Me myself and I was today chez-mon-docteur... Let's see the results on Thursday.
> Again, get well soon.
>
> Tested against...
>
>   "BROKEN" Linux-Next (next-20130411) with attached patchset (incl.
> your cpufreq-next-fixes).
>
> Test-Case...
>
> CONFIG_X86_INTEL_PSTATE=y
>
> root# echo 0 > /sys/devices/system/cpu/cpu3/online
>
> Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
>
> ...did not test on-reboot-case.
>
> ( Dirk promised to test as well... )
>

Tested with:
  while true
  do
  echo 0 > online
  echo 1 > online
  done
For several minutes and rebooting several times seems to have fixed the
issue.

Nathan, Sorry for calling out your patch erroneously I should have paid closer
attention.

Viresh you can add my Tested-by:

Thanks
--Dirk
> - Sedat -
>
>> @Rafael: I will probably be down for one more week and so not doing any
>> reviews for now... I do check important mails sent directly to me though.
>>
>> ------------x----------------------x------------------
>>
>> From: Viresh Kumar <viresh.kumar@linaro.org>
>> Date: Mon, 15 Apr 2013 22:43:57 +0530
>> Subject: [PATCH] cpufreq: Don't call __cpufreq_governor() for drivers without
>>   target()
>>
>> Some cpufreq drivers implement their own governor and so don't need us to call
>> generic governors interface via __cpufreq_governor(). Few recent commits haven't
>> obeyed this law well and we saw some regressions.
>>
>> This patch tries to fix this issue.
>>
>> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
>> ---
>>   drivers/cpufreq/cpufreq.c | 18 +++++++++++++-----
>>   1 file changed, 13 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
>> index 3564947..a6f6595 100644
>> --- a/drivers/cpufreq/cpufreq.c
>> +++ b/drivers/cpufreq/cpufreq.c
>> @@ -858,13 +858,18 @@ static int cpufreq_add_policy_cpu(unsigned int
>> cpu, unsigned int sibling,
>>                                    struct device *dev)
>>   {
>>          struct cpufreq_policy *policy;
>> -       int ret = 0;
>> +       int ret = 0, has_target = 0;
>>          unsigned long flags;
>>
>>          policy = cpufreq_cpu_get(sibling);
>>          WARN_ON(!policy);
>>
>> -       __cpufreq_governor(policy, CPUFREQ_GOV_STOP);
>> +       rcu_read_lock();
>> +       has_target = !!rcu_dereference(cpufreq_driver)->target;
>> +       rcu_read_unlock();
>> +
>> +       if (has_target)
>> +               __cpufreq_governor(policy, CPUFREQ_GOV_STOP);
>>
>>          lock_policy_rwsem_write(sibling);
>>
>> @@ -877,8 +882,10 @@ static int cpufreq_add_policy_cpu(unsigned int
>> cpu, unsigned int sibling,
>>
>>          unlock_policy_rwsem_write(sibling);
>>
>> -       __cpufreq_governor(policy, CPUFREQ_GOV_START);
>> -       __cpufreq_governor(policy, CPUFREQ_GOV_LIMITS);
>> +       if (has_target) {
>> +               __cpufreq_governor(policy, CPUFREQ_GOV_START);
>> +               __cpufreq_governor(policy, CPUFREQ_GOV_LIMITS);
>> +       }
>>
>>          ret = sysfs_create_link(&dev->kobj, &policy->kobj, "cpufreq");
>>          if (ret) {
>> @@ -1146,7 +1153,8 @@ static int __cpufreq_remove_dev(struct device
>> *dev, struct subsys_interface *sif
>>
>>          /* If cpu is last user of policy, free policy */
>>          if (cpus == 1) {
>> -               __cpufreq_governor(data, CPUFREQ_GOV_POLICY_EXIT);
>> +               if (has_target)
>> +                       __cpufreq_governor(data, CPUFREQ_GOV_POLICY_EXIT);
>>
>>                  lock_policy_rwsem_read(cpu);
>>                  kobj = &data->kobj;

  parent reply	other threads:[~2013-04-15 18:01 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CA+icZUU_K9PiFMqMsOEk1+c2DX8LrUojZptPiRVarv4dcB2qFA@mail.gmail.com>
2013-04-09 14:03 ` linux-next: Tree for Apr 9 [cpufreq: NULL pointer deref] Rafael J. Wysocki
2013-04-09 14:03   ` Rafael J. Wysocki
2013-04-09 14:04   ` Sedat Dilek
2013-04-09 14:56     ` Viresh Kumar
2013-04-09 14:59       ` Sedat Dilek
2013-04-09 16:08       ` Sedat Dilek
2013-04-09 16:51         ` Viresh Kumar
2013-04-09 16:57           ` Sedat Dilek
2013-04-09 18:26           ` Sedat Dilek
2013-04-09 18:29             ` Sedat Dilek
2013-04-09 18:39               ` Sedat Dilek
2013-04-09 20:26                 ` Sedat Dilek
2013-04-10  5:41           ` Sedat Dilek
2013-04-10  5:53             ` Sedat Dilek
2013-04-10  6:14               ` Sedat Dilek
2013-04-12  8:23                 ` Viresh Kumar
2013-04-12 14:24                   ` Sedat Dilek
2013-04-12 15:45                     ` Sedat Dilek
2013-04-12 16:27                       ` Sedat Dilek
2013-04-12 21:08                         ` Sedat Dilek
2013-04-12 22:51                           ` Rafael J. Wysocki
2013-04-13  9:55                             ` Sedat Dilek
2013-04-15 16:07                               ` Dirk Brandewie
2013-04-15 16:13                                 ` Sedat Dilek
2013-04-15 17:22                                 ` Viresh Kumar
2013-04-15 17:51                                   ` Sedat Dilek
2013-04-15 17:57                                     ` Sedat Dilek
2013-04-15 18:07                                       ` Sedat Dilek
2013-04-15 18:01                                     ` Dirk Brandewie [this message]
2013-04-17 14:04                                   ` Sedat Dilek
2013-04-17 16:14                                     ` Rafael J. Wysocki
2013-04-21 23:30                                   ` Rafael J. Wysocki
2013-04-22  3:14                                     ` Viresh Kumar
2013-04-22 12:00                                       ` Rafael J. Wysocki
2013-04-15 17:27                                 ` Nathan Zimmer
2013-04-15 17:27                                   ` Nathan Zimmer
2013-04-15 17:42                                   ` Dirk Brandewie
2013-04-15 18:05                                     ` Nathan Zimmer
2013-04-15 18:05                                       ` Nathan Zimmer
2013-04-09 14:59   ` 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=516C4076.7070605@gmail.com \
    --to=dirk.brandewie@gmail.com \
    --cc=cpufreq@vger.kernel.org \
    --cc=dirk.j.brandewie@intel.com \
    --cc=linaro-kernel@lists.linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=nzimmer@sgi.com \
    --cc=rjw@sisk.pl \
    --cc=sedat.dilek@gmail.com \
    --cc=sfr@canb.auug.org.au \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.