Skip to contentSkip to conversation

acpi-cpufreq: Fix an acpi perf unregister issue

PATCH In review Pan Xinhui 3 participants 3 messages Jul 10, 2015 – Jul 16, 2015 CPU frequency scaling framework

lore
Share & tools
lore

Pan Xinhui

author
#0 lore raw

PATCH v2 1/1 acpi-cpufreq: Fix an acpi perf unregister issue

As policy->cpu may not be same in acpi_cpufreq_cpu_init and acpi_cpufreq_cpu_exit. There is a risk that we use different *cpu* to un/register acpi performance. So acpi_processor_unregister_performance may not be able to do the cleanup work. That causes a memory leak. And if there will be another acpi_processor_register_performance call, it may also fail thanks to the internal check of pr->performace.

So we add a field *acpi_perf_cpu* to fix this issue.

Signed-off-by Pan Xinhui <[email protected]>

---
Change from V1:
comments update

---
 drivers/cpufreq/acpi-cpufreq.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/cpufreq/acpi-cpufreq.c +3 -1
index 314a19e..8cad583 100644
@@ -69,6 +69,7 @@ struct acpi_cpufreq_data {
 	struct cpufreq_frequency_table *freq_table;
 	unsigned int resume;
 	unsigned int cpu_feature;
+	unsigned int acpi_perf_cpu;
 	cpumask_var_t freqdomain_cpus;
 };
 

@@ -677,6 +678,7 @@ static int acpi_cpufreq_cpu_init(struct cpufreq_policy *policy)
 	}
 
 	data->acpi_data = per_cpu_ptr(acpi_perf_data, cpu);
+	data->acpi_perf_cpu = cpu;
 	policy->driver_data = data;
 
 	if (cpu_has(c, X86_FEATURE_CONSTANT_TSC))

@@ -861,7 +863,7 @@ static int acpi_cpufreq_cpu_exit(struct cpufreq_policy *policy)
 	if (data) {
 		policy->driver_data = NULL;
 		acpi_processor_unregister_performance(data->acpi_data,
-						      policy->cpu);
+						      data->acpi_perf_cpu);
 		free_cpumask_var(data->freqdomain_cpus);
 		kfree(data->freq_table);
 		kfree(data);
Signature · 1 line
1.9.1
maintainer Acked-by on v2 1/1
#1 lore raw
Quoted 10 lines · Pan Xinhui

As policy->cpu may not be same in acpi_cpufreq_cpu_init and acpi_cpufreq_cpu_exit. There is a risk that we use different *cpu* to un/register acpi performance. So acpi_processor_unregister_performance may not be able to do the cleanup work. That causes a memory leak. And if there will be another acpi_processor_register_performance call, it may also fail thanks to the internal check of pr->performace.

So we add a field *acpi_perf_cpu* to fix this issue.

Quoted 7 lines
Signed-off-by Pan Xinhui <[email protected]>

---
Change from V1:
comments update

---
 drivers/cpufreq/acpi-cpufreq.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
Acked-by Viresh Kumar <[email protected]>
#2 lore raw
Quoted 19 lines · Viresh Kumar
Quoted 10 lines · Pan Xinhui

As policy->cpu may not be same in acpi_cpufreq_cpu_init and acpi_cpufreq_cpu_exit. There is a risk that we use different *cpu* to un/register acpi performance. So acpi_processor_unregister_performance may not be able to do the cleanup work. That causes a memory leak. And if there will be another acpi_processor_register_performance call, it may also fail thanks to the internal check of pr->performace.

So we add a field *acpi_perf_cpu* to fix this issue.

Quoted 7 lines
Signed-off-by Pan Xinhui <[email protected]>

---
Change from V1:
comments update

---
 drivers/cpufreq/acpi-cpufreq.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
Quoted 1 line
Acked-by Viresh Kumar <[email protected]>

Patch queued up for 4.3, thanks!

Signature · 2 lines
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.