linux-kernel - Re: Regression on cpufreq in v3.12-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACRpkdYBYdMJ6mTGUropOypx0ZVNn8eQMzV+eKocCSBZAu6xTA@mail.gmail.com>
Date:	Fri, 20 Sep 2013 10:33:22 +0200
From:	Linus Walleij <linus.walleij@...aro.org>
To:	"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>
Cc:	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Viresh Kumar <viresh.kumar@...aro.org>
Subject: Re: Regression on cpufreq in v3.12-rc1

On Thu, Sep 19, 2013 at 2:55 PM, Linus Walleij <linus.walleij@...aro.org> wrote:
> On Thu, Sep 19, 2013 at 2:46 PM, Srivatsa S. Bhat
> <srivatsa.bhat@...ux.vnet.ibm.com> wrote:
>
>> So I think we should first identify (bisect?) and understand what caused that
>> particular change and then we will be in a position to evaluate whether the
>> patch you proposed would be the right fix or not.
>
> I'll see if I can get a bisect going, the problem is that I upload the
> kernel over the serial port so this isn't a very quick procedure :-(

Well I did a bisect anyway, it seems the problem appears due
at this commit:

commit 6eed9404ab3c4baea54ce4c7e862e69df1d39f38
Author: Viresh Kumar <viresh.kumar@...aro.org>
Date:   Tue Aug 6 22:53:11 2013 +0530

    cpufreq: Use rwsem for protecting critical sections

    Critical sections of the cpufreq core are protected with the help of
    the driver module owner's refcount, which isn't the correct approach,
    because it causes rmmod to return an error when some routine has
    updated that refcount.

    Let's use rwsem for this purpose instead.  Only
    cpufreq_unregister_driver() will use write sem
    and everybody else will use read sem.

    [rjw: Subject & changelog]
    Signed-off-by: Viresh Kumar <viresh.kumar@...aro.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>

I suspect this hunk from the patch may be the cause:

+       if (cpufreq_driver) {
+               /* get the CPU */
+               policy = per_cpu(cpufreq_cpu_data, cpu);
+               if (policy)
+                       kobject_get(&policy->kobj);
+       }

-       /* get the CPU */
-       policy = per_cpu(cpufreq_cpu_data, cpu);

As you see we *always* set a policy pointer before this patch,
but after this patch we only do it if we have a cpufreq driver
registered!

It's not trivial to fix this for me though, it seems there are some
other suggestions in this thread...

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/