headers
Jiri Slaby | 1 Mar 2011 17:41
Picon
Gravatar

[PATCH 1/1] CPUFREQ: fix BUG on cpufreq policy init failure

cpufreq_register_driver sets cpufreq_driver to a structure owned (and
placed) in the caller's memory. If cpufreq policy fails in its ->init
function, sysdev_driver_register returns nonzero in
cpufreq_register_driver. Now, cpufreq_register_driver returns an error
without setting cpufreq_driver back to NULL.

Usually cpufreq policy modules are unloaded because they propagate the
error to the module init function and return that.

So a later access to any member of cpufreq_driver causes bugs like:
BUG: unable to handle kernel paging request at ffffffffa00270a0
IP: [<ffffffff8145eca3>] cpufreq_cpu_get+0x53/0xe0
PGD 1805067 PUD 1809063 PMD 1c3f90067 PTE 0
Oops: 0000 [#1] SMP
last sysfs file: /sys/devices/virtual/net/tun0/statistics/collisions
CPU 0
Modules linked in: ...
Pid: 5677, comm: thunderbird-bin Tainted: G        W   2.6.38-rc4-mm1_64+ #1389 To be filled by O.E.M./To Be
Filled By O.E.M.
RIP: 0010:[<ffffffff8145eca3>]  [<ffffffff8145eca3>] cpufreq_cpu_get+0x53/0xe0
RSP: 0018:ffff8801aec37d98  EFLAGS: 00010086
RAX: 0000000000000202 RBX: 0000000000000000 RCX: 0000000000000001
RDX: ffffffffa00270a0 RSI: 0000000000001000 RDI: ffffffff8199ece8
...
Call Trace:
 [<ffffffff8145f490>] cpufreq_quick_get+0x10/0x30
 [<ffffffff8103f12b>] show_cpuinfo+0x2ab/0x300
 [<ffffffff81136292>] seq_read+0xf2/0x3f0
 [<ffffffff8126c5d3>] ? __strncpy_from_user+0x33/0x60
 [<ffffffff8116850d>] proc_reg_read+0x6d/0xa0
(Continue reading)

Permalink | Reply | 2 comments |
headers
Fredrik Rambris | 1 Mar 2011 22:25
Gravatar

p4-clockmod: Unknown CPU

Hi

I'm running Ubuntu something something (moms laptop) 2.6.35-25-generic
#44-Ubuntu SMP Fri Jan 21 17:40:44 UTC 2011 x86_64 GNU/Linux
This is a Compaq Presario CQ71 and the fans are running top speed all
the time. I therefor tried to run cpufreqd but the kernel does not
recognize the CPU.

processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 23
model name	: Celeron(R) Dual-Core CPU       T3000   <at>  1.80GHz
stepping	: 10
cpu MHz		: 1795.493
cache size	: 1024 KB
physical id	: 0
siblings	: 2
core id		: 0
cpu cores	: 2
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64
monitor ds_cpl tm2 ssse3 cx16 xtpr pdcm xsave lahf_lm dts
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thomas Renninger | 1 Mar 2011 22:32
Picon

Re: [PATCH 1/1] CPUFREQ: fix BUG on cpufreq policy init failure

On Tuesday 01 March 2011 17:41:10 Jiri Slaby wrote:
> cpufreq_register_driver sets cpufreq_driver to a structure owned (and
> placed) in the caller's memory. If cpufreq policy fails in its ->init
> function, sysdev_driver_register returns nonzero in
> cpufreq_register_driver. Now, cpufreq_register_driver returns an error
> without setting cpufreq_driver back to NULL.
> 
> Usually cpufreq policy modules are unloaded because they propagate the
> error to the module init function and return that.

Looks pretty sane and makes the code much nicer.

Will you pick it up Dave?

       Thomas
--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 1 comment |
headers
Dave Jones | 1 Mar 2011 23:39
Picon
Favicon

Re: [PATCH 1/1] CPUFREQ: fix BUG on cpufreq policy init failure

On Tue, Mar 01, 2011 at 10:32:00PM +0100, Thomas Renninger wrote:
 > On Tuesday 01 March 2011 17:41:10 Jiri Slaby wrote:
 > > cpufreq_register_driver sets cpufreq_driver to a structure owned (and
 > > placed) in the caller's memory. If cpufreq policy fails in its ->init
 > > function, sysdev_driver_register returns nonzero in
 > > cpufreq_register_driver. Now, cpufreq_register_driver returns an error
 > > without setting cpufreq_driver back to NULL.
 > > 
 > > Usually cpufreq policy modules are unloaded because they propagate the
 > > error to the module init function and return that.
 > 
 > Looks pretty sane and makes the code much nicer.
 > 
 > Will you pick it up Dave?

yep, got it.

thanks,
	Dave

--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Daniel J Blueman | 2 Mar 2011 06:52
Picon

[2.6.38-rc7, patch] cpuinfo_cur_freq unreadable by non-root

I failed to find why
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq is only readable
by root; the cost of reading it isn't sufficient to cause memory or
scheduling denial, but may have been in the past.

Thus, allow non-root users read permission, consistent with other
attributes, allowing it to be monitored.

Signed-off-by: Daniel J Blueman <daniel.blueman <at> gmail.com>

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 1109f68..0f491fe 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
 <at>  <at>  -664,7 +664,7  <at>  <at>  static ssize_t show_bios_limit(struct
cpufreq_policy *policy, char *buf)
 	return sprintf(buf, "%u\n", policy->cpuinfo.max_freq);
 }

-cpufreq_freq_attr_ro_perm(cpuinfo_cur_freq, 0400);
+cpufreq_freq_attr_ro(cpuinfo_cur_freq);
 cpufreq_freq_attr_ro(cpuinfo_min_freq);
 cpufreq_freq_attr_ro(cpuinfo_max_freq);
 cpufreq_freq_attr_ro(cpuinfo_transition_latency);
--

-- 
Daniel J Blueman
--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 2 comments |
headers
Thomas Renninger | 2 Mar 2011 10:27
Picon

Re: [2.6.38-rc7, patch] cpuinfo_cur_freq unreadable by non-root

Hi,

<resend, because my stupid mailer added a strange content-type header
preventing the mail to be sent to the cpufreq list (hope it works now)>

On Wednesday, March 02, 2011 06:52:05 AM Daniel J Blueman wrote:
> I failed to find why
> /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq is only readable
> by root; the cost of reading it isn't sufficient to cause memory or
> scheduling denial, but may have been in the past.
> 
> Thus, allow non-root users read permission, consistent with other
> attributes, allowing it to be monitored.
> 
> Signed-off-by: Daniel J Blueman <daniel.blueman <at> gmail.com>
> 
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 1109f68..0f491fe 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
>  <at>  <at>  -664,7 +664,7  <at>  <at>  static ssize_t show_bios_limit(struct
> cpufreq_policy *policy, char *buf)
>  	return sprintf(buf, "%u\n", policy->cpuinfo.max_freq);
>  }
> 
> -cpufreq_freq_attr_ro_perm(cpuinfo_cur_freq, 0400);
> +cpufreq_freq_attr_ro(cpuinfo_cur_freq);
>  cpufreq_freq_attr_ro(cpuinfo_min_freq);
Having this read only for root goes back to the beginning
of git history of this file in 2005...
(Continue reading)

Permalink | Reply | 1 comment |
headers
Daniel J Blueman | 2 Mar 2011 10:33
Picon

[2.6.38-rc7, patch v2] cpuinfo_cur_freq unreadable by non-root

On 2 March 2011 16:59, Thomas Renninger <trenn <at> suse.de> wrote:
> On Wednesday, March 02, 2011 06:52:05 AM Daniel J Blueman wrote:
>
>> I failed to find why
>> /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq is only readable
>> by root; the cost of reading it isn't sufficient to cause memory or
>> scheduling denial, but may have been in the past.
>>
>> Thus, allow non-root users read permission, consistent with other
>> attributes, allowing it to be monitored.
>>
>> Signed-off-by: Daniel J Blueman <daniel.blueman <at> gmail.com>
>>
>> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
>> index 1109f68..0f491fe 100644
>> --- a/drivers/cpufreq/cpufreq.c
>> +++ b/drivers/cpufreq/cpufreq.c
>>  <at>  <at>  -664,7 +664,7  <at>  <at>  static ssize_t show_bios_limit(struct
>> cpufreq_policy *policy, char *buf)
>> return sprintf(buf, "%u\n", policy->cpuinfo.max_freq);
>> }
>>
>> -cpufreq_freq_attr_ro_perm(cpuinfo_cur_freq, 0400);
>> +cpufreq_freq_attr_ro(cpuinfo_cur_freq);
>
> Having this read only for root goes back to the beginning
> of git history of this file in 2005...
> It looks like this is done on purpose, but I do not see why
> this should not be readable for others.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dominik Brodowski | 2 Mar 2011 11:30

Re: [2.6.38-rc7, patch] cpuinfo_cur_freq unreadable by non-root

Hey,

On Wed, Mar 02, 2011 at 10:27:38AM +0100, Thomas Renninger wrote:
> > -cpufreq_freq_attr_ro_perm(cpuinfo_cur_freq, 0400);
> > +cpufreq_freq_attr_ro(cpuinfo_cur_freq);
> >  cpufreq_freq_attr_ro(cpuinfo_min_freq);
> Having this read only for root goes back to the beginning
> of git history of this file in 2005...
> It looks like this is done on purpose, but I do not see why
> this should not be readable for others.
> 
> Maybe Dominik or Dave have an idea.

This talks to hardware, and might (in some implementations) talk to the
BIOS, causing it to do nasty things, such as executing things in SMM. That
shouldn't be available to the world. However, as ACPI still does not provide
a ->get() method, making this attribute world readable _might_ not cause too
much harm, but it isn't worth the hassle IMO. Especially as everyone may
read out scaling_cur_freq, and scaling_cur_freq differs from
cpuinfo_cur_freq _only_ if something is broken.

Best,
	Dominik
--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 3 Mar 2011 02:11

[Bug 16489] kmemleak after suspend2ram in cpufreq driver

https://bugzilla.kernel.org/show_bug.cgi?id=16489

Len Brown <lenb <at> kernel.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED
                 CC|                            |lenb <at> kernel.org

--

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 3 Mar 2011 02:12

[Bug 12948] No Cool'n'Quiet on Asrock A770Crossfire

https://bugzilla.kernel.org/show_bug.cgi?id=12948

Len Brown <lenb <at> kernel.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED
                 CC|                            |lenb <at> kernel.org

--

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |

Gmane