[PATCH v1 0/2] crash on reading cpufreq sysfs

[PATCH v1 0/2] crash on reading cpufreq sysfs

[Srinivas Pandruvada]

Fixes for crash on reading cpufreq sysfs for offline cpus

v1
Fix commit discription on Patch 1/2. Included Acks from Viresh.
It has both patches, even though only one patch has change.

v0
two patches: one for acp-cpufreq and one for cpufreq core

Srinivas Pandruvada (2):
  cpufreq: acpi_cpufreq: prevent crash on reading freqdomain_cpus
  cpufreq: prevent lockup on reading scaling_available_frequencies

 drivers/cpufreq/acpi-cpufreq.c | 3 +++
 drivers/cpufreq/cpufreq.c      | 4 +++-
 2 files changed, 6 insertions(+), 1 deletion(-)

-- 
1.9.3

[PATCH v1 1/2] cpufreq: acpi_cpufreq: prevent crash on reading freqdomain_cpus

[Srinivas Pandruvada]

When freqdomain_cpus attribute is read from an offlined cpu, it will
cause crash. This change prevents calling cpufreq_show_cpus when
policy driver_data is NULL.

Crash info:

[  170.814949] BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
[  170.814990] IP: [<ffffffff813b2490>] _find_next_bit.part.0+0x10/0x70
[  170.815021] PGD 227d30067 PUD 229e56067 PMD 0
[  170.815043] Oops: 0000 [#2] SMP
[  170.816022] CPU: 3 PID: 3121 Comm: cat Tainted: G      D    OE   4.3.0-rc3+ #33
...
...
[  170.816657] Call Trace:
[  170.816672]  [<ffffffff813b2505>] ? find_next_bit+0x15/0x20
[  170.816696]  [<ffffffff8160e47c>] cpufreq_show_cpus+0x5c/0xd0
[  170.816722]  [<ffffffffa031a409>] show_freqdomain_cpus+0x19/0x20 [acpi_cpufreq]
[  170.816749]  [<ffffffff8160e65b>] show+0x3b/0x60
[  170.816769]  [<ffffffff8129b31c>] sysfs_kf_seq_show+0xbc/0x130
[  170.816793]  [<ffffffff81299be3>] kernfs_seq_show+0x23/0x30
[  170.816816]  [<ffffffff81240f2c>] seq_read+0xec/0x390
[  170.816837]  [<ffffffff8129a64a>] kernfs_fop_read+0x10a/0x160
[  170.816861]  [<ffffffff8121d9b7>] __vfs_read+0x37/0x100
[  170.816883]  [<ffffffff813217c0>] ? security_file_permission+0xa0/0xc0
[  170.816909]  [<ffffffff8121e2e3>] vfs_read+0x83/0x130
[  170.816930]  [<ffffffff8121f035>] SyS_read+0x55/0xc0
...
...
[  170.817185] ---[ end trace bc6eadf82b2b965a ]---

Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
---
 drivers/cpufreq/acpi-cpufreq.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index 7982772..cec1ee2 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -149,6 +149,9 @@ static ssize_t show_freqdomain_cpus(struct cpufreq_policy *policy, char *buf)
 {
 	struct acpi_cpufreq_data *data = policy->driver_data;
 
+	if (unlikely(!data))
+		return -ENODEV;
+
 	return cpufreq_show_cpus(data->freqdomain_cpus, buf);
 }
 
-- 
1.9.3

[PATCH v1 2/2] cpufreq: prevent lockup on reading scaling_available_frequencies

[Srinivas Pandruvada]

When scaling_available_frequencies is read on an offlined cpu, then
either lockup or junk values are displayed. This is caused by
freed freq_table, which policy is using.

Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
---
 drivers/cpufreq/cpufreq.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index ef5ed94..25c4c15 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1436,8 +1436,10 @@ static void cpufreq_offline_finish(unsigned int cpu)
 	 * since this is a core component, and is essential for the
 	 * subsequent light-weight ->init() to succeed.
 	 */
-	if (cpufreq_driver->exit)
+	if (cpufreq_driver->exit) {
 		cpufreq_driver->exit(policy);
+		policy->freq_table = NULL;
+	}
 }
 
 /**
-- 
1.9.3

Re: [PATCH v1 0/2] crash on reading cpufreq sysfs

[Rafael J. Wysocki]

On Wednesday, October 07, 2015 01:50:42 PM Srinivas Pandruvada wrote:
> Fixes for crash on reading cpufreq sysfs for offline cpus
> 
> v1
> Fix commit discription on Patch 1/2. Included Acks from Viresh.
> It has both patches, even though only one patch has change.
> 
> v0
> two patches: one for acp-cpufreq and one for cpufreq core
> 
> Srinivas Pandruvada (2):
>   cpufreq: acpi_cpufreq: prevent crash on reading freqdomain_cpus
>   cpufreq: prevent lockup on reading scaling_available_frequencies

Both applied, but they look like -stable material to me.

What kernel versions are they applicable too (and in what kernels
are they needed)?

Thanks,
Rafael

Re: [PATCH v1 0/2] crash on reading cpufreq sysfs

[Srinivas Pandruvada]

On Thu, 2015-10-08 at 00:50 +0200, Rafael J. Wysocki wrote:
> On Wednesday, October 07, 2015 01:50:42 PM Srinivas Pandruvada wrote:
> > Fixes for crash on reading cpufreq sysfs for offline cpus
> > 
> > v1
> > Fix commit discription on Patch 1/2. Included Acks from Viresh.
> > It has both patches, even though only one patch has change.
> > 
> > v0
> > two patches: one for acp-cpufreq and one for cpufreq core
> > 
> > Srinivas Pandruvada (2):
> >   cpufreq: acpi_cpufreq: prevent crash on reading freqdomain_cpus
> >   cpufreq: prevent lockup on reading scaling_available_frequencies
> 
> Both applied, but they look like -stable material to me.
> 
I tested in 4.1 kernels, since on offline, cpufreq folder is not
available there is no issue.
For 4.2 kernels the I didn't see crash fixed by cpufreq core patch (cat
scaling_available_frequencies), but the "cat freqdomain_cpus" still
causes crash. So we need to apply cpufreq:acpi-cpufreq patch only. So
one patch is applicable for stable tree.

Thanks,
Srinivas


> What kernel versions are they applicable too (and in what kernels
> are they needed)?
> 
> Thanks,
> Rafael
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 0/2] crash on reading cpufreq sysfs

[Rafael J. Wysocki]

On Thu, Oct 8, 2015 at 1:50 AM, Srinivas Pandruvada
<srinivas.pandruvada@linux.intel.com> wrote:
> On Thu, 2015-10-08 at 00:50 +0200, Rafael J. Wysocki wrote:
>> On Wednesday, October 07, 2015 01:50:42 PM Srinivas Pandruvada wrote:
>> > Fixes for crash on reading cpufreq sysfs for offline cpus
>> >
>> > v1
>> > Fix commit discription on Patch 1/2. Included Acks from Viresh.
>> > It has both patches, even though only one patch has change.
>> >
>> > v0
>> > two patches: one for acp-cpufreq and one for cpufreq core
>> >
>> > Srinivas Pandruvada (2):
>> >   cpufreq: acpi_cpufreq: prevent crash on reading freqdomain_cpus
>> >   cpufreq: prevent lockup on reading scaling_available_frequencies
>>
>> Both applied, but they look like -stable material to me.
>>
> I tested in 4.1 kernels, since on offline, cpufreq folder is not
> available there is no issue.
> For 4.2 kernels the I didn't see crash fixed by cpufreq core patch (cat
> scaling_available_frequencies), but the "cat freqdomain_cpus" still
> causes crash. So we need to apply cpufreq:acpi-cpufreq patch only. So
> one patch is applicable for stable tree.

So [1/2] should go into 4.2.y and [2/2] fixes a regression introduced
in this cycle, right?

Thanks,
Rafael

Re: [PATCH v1 0/2] crash on reading cpufreq sysfs

[Srinivas Pandruvada]

On Thu, 2015-10-08 at 02:17 +0200, Rafael J. Wysocki wrote:
> On Thu, Oct 8, 2015 at 1:50 AM, Srinivas Pandruvada
> <srinivas.pandruvada@linux.intel.com> wrote:
> > On Thu, 2015-10-08 at 00:50 +0200, Rafael J. Wysocki wrote:
> > > On Wednesday, October 07, 2015 01:50:42 PM Srinivas Pandruvada
> > > wrote:
> > > > Fixes for crash on reading cpufreq sysfs for offline cpus
> > > > 
> > > > v1
> > > > Fix commit discription on Patch 1/2. Included Acks from Viresh.
> > > > It has both patches, even though only one patch has change.
> > > > 
> > > > v0
> > > > two patches: one for acp-cpufreq and one for cpufreq core
> > > > 
> > > > Srinivas Pandruvada (2):
> > > >   cpufreq: acpi_cpufreq: prevent crash on reading
> > > > freqdomain_cpus
> > > >   cpufreq: prevent lockup on reading
> > > > scaling_available_frequencies
> > > 
> > > Both applied, but they look like -stable material to me.
> > > 
> > I tested in 4.1 kernels, since on offline, cpufreq folder is not
> > available there is no issue.
> > For 4.2 kernels the I didn't see crash fixed by cpufreq core patch
> > (cat
> > scaling_available_frequencies), but the "cat freqdomain_cpus" still
> > causes crash. So we need to apply cpufreq:acpi-cpufreq patch only.
> > So
> > one patch is applicable for stable tree.
> 
> So [1/2] should go into 4.2.y and [2/2] fixes a regression introduced
> in this cycle, right?
Yes.

Thanks,
Srinivas
> 
> Thanks,
> Rafael

Re: [PATCH v1 0/2] crash on reading cpufreq sysfs

[Rafael J. Wysocki]

On Thursday, October 08, 2015 08:17:57 AM Srinivas Pandruvada wrote:
> On Thu, 2015-10-08 at 02:17 +0200, Rafael J. Wysocki wrote:
> > On Thu, Oct 8, 2015 at 1:50 AM, Srinivas Pandruvada
> > <srinivas.pandruvada@linux.intel.com> wrote:
> > > On Thu, 2015-10-08 at 00:50 +0200, Rafael J. Wysocki wrote:
> > > > On Wednesday, October 07, 2015 01:50:42 PM Srinivas Pandruvada
> > > > wrote:
> > > > > Fixes for crash on reading cpufreq sysfs for offline cpus
> > > > > 
> > > > > v1
> > > > > Fix commit discription on Patch 1/2. Included Acks from Viresh.
> > > > > It has both patches, even though only one patch has change.
> > > > > 
> > > > > v0
> > > > > two patches: one for acp-cpufreq and one for cpufreq core
> > > > > 
> > > > > Srinivas Pandruvada (2):
> > > > >   cpufreq: acpi_cpufreq: prevent crash on reading
> > > > > freqdomain_cpus
> > > > >   cpufreq: prevent lockup on reading
> > > > > scaling_available_frequencies
> > > > 
> > > > Both applied, but they look like -stable material to me.
> > > > 
> > > I tested in 4.1 kernels, since on offline, cpufreq folder is not
> > > available there is no issue.
> > > For 4.2 kernels the I didn't see crash fixed by cpufreq core patch
> > > (cat
> > > scaling_available_frequencies), but the "cat freqdomain_cpus" still
> > > causes crash. So we need to apply cpufreq:acpi-cpufreq patch only.
> > > So
> > > one patch is applicable for stable tree.
> > 
> > So [1/2] should go into 4.2.y and [2/2] fixes a regression introduced
> > in this cycle, right?
> Yes.

OK, thanks!

Rafael