Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1538012 > unrolled thread

Re: [PATCH v8 8/8] cpufreq: intel_pstate: Use CPPC to get max performance

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v8 8/8] cpufreq: intel_pstate: Use CPPC to get max  performance Sebastian Andrzej Siewior <bigeasy@linutronix.de> - 2016-12-07 20:10 +0100
    Re: [PATCH v8 8/8] cpufreq: intel_pstate: Use CPPC to get max  performance Tim Chen <tim.c.chen@linux.intel.com> - 2016-12-08 00:20 +0100
      Re: [PATCH v8 8/8] cpufreq: intel_pstate: Use CPPC to get max performance "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-12-08 00:40 +0100
        Re: [PATCH v8 8/8] cpufreq: intel_pstate: Use CPPC to get max  performance Sebastian Andrzej Siewior <bigeasy@linutronix.de> - 2016-12-09 15:50 +0100
          Re: [PATCH v8 8/8] cpufreq: intel_pstate: Use CPPC to get max performance "Rafael J. Wysocki" <rafael@kernel.org> - 2016-12-09 16:10 +0100
            [PATCH] ACPI / CPPC: Fix per-CPU pointers management "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-12-10 01:00 +0100
              Re: [PATCH] ACPI / CPPC: Fix per-CPU pointers management Sebastian Andrzej Siewior <bigeasy@linutronix.de> - 2016-12-10 20:00 +0100
                Re: [PATCH] ACPI / CPPC: Fix per-CPU pointers management "Rafael J. Wysocki" <rafael@kernel.org> - 2016-12-12 02:10 +0100
              Re: [PATCH] ACPI / CPPC: Fix per-CPU pointers management "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-12-14 03:40 +0100

#1538012 — Re: [PATCH v8 8/8] cpufreq: intel_pstate: Use CPPC to get max performance

On 2016-11-22 12:24:00 [-0800], Tim Chen wrote:
> From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
> 
> This change uses acpi cppc_lib interface to get CPPC performance limits
> and calls scheduler interface to update per cpu highest priority. If
> there is a difference in highest performance of each CPUs, call scheduler
> interface to enable ITMT feature for only one time.
> 
> Here sched_set_itmt_core_prio() is called to set priorities and
> sched_set_itmt_support() is called to enable ITMT feature.

First I had crashed what I bisected down to de966cf4a4fa ("sched/x86: Change
CONFIG_SCHED_ITMT to CONFIG_SCHED_MC_PRIO") because it made SCHED_ITMT the
default.
Then I run another bisect round and got here with the same backtrace:
|BUG: unable to handle kernel NULL pointer dereference at           (null)
|IP: [<ffffffff812aab6e>] acpi_cppc_processor_exit+0x40/0x60
|PGD 0 [    0.577616]
|Oops: 0000 [#1] SMP
|Modules linked in:
|CPU: 3 PID: 1 Comm: swapper/0 Not tainted 4.9.0-rc6-00146-g17669006adf6 #51
|task: ffff88003f878000 task.stack: ffffc90000008000
|RIP: 0010:[<ffffffff812aab6e>]  [<ffffffff812aab6e>] acpi_cppc_processor_exit+0x40/0x60
|RSP: 0000:ffffc9000000bd48  EFLAGS: 00010296
|RAX: 00000000000137e0 RBX: 0000000000000000 RCX: 0000000000000001
|RDX: ffff88003fc00000 RSI: 0000000000000000 RDI: ffff88003fbca130
|RBP: ffffc9000000bd60 R08: 0000000000000514 R09: 0000000000000000
|R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000002
|R13: 0000000000000020 R14: ffffffff8167cb00 R15: 0000000000000000
|FS:  0000000000000000(0000) GS:ffff88003fcc0000(0000) knlGS:0000000000000000
|CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|CR2: 0000000000000000 CR3: 0000000001618000 CR4: 00000000000406e0
|Stack:
| ffff88003f939848 ffff88003fbca130 0000000000000001 ffffc9000000bd80
| ffffffff812a4ccb ffff88003fc0cee8 0000000000000000 ffffc9000000bdb8
| ffffffff812dc20d ffff88003fc0cee8 ffffffff8167cb00 ffff88003fc0cf48
|Call Trace:
| [<ffffffff812a4ccb>] acpi_processor_stop+0xb2/0xc5
| [<ffffffff812dc20d>] driver_probe_device+0x14d/0x2f0
| [<ffffffff812dc41e>] __driver_attach+0x6e/0x90
| [<ffffffff812da234>] bus_for_each_dev+0x54/0x90
| [<ffffffff812dbbf9>] driver_attach+0x19/0x20
| [<ffffffff812db6a6>] bus_add_driver+0xe6/0x200
| [<ffffffff812dcb23>] driver_register+0x83/0xc0
| [<ffffffff816f050a>] acpi_processor_driver_init+0x20/0x94
| [<ffffffff81000487>] do_one_initcall+0x97/0x180
| [<ffffffff816ccf5c>] kernel_init_freeable+0x112/0x1a6
| [<ffffffff813a0fc9>] kernel_init+0x9/0xf0
| [<ffffffff813acf35>] ret_from_fork+0x25/0x30
|Code: 02 00 00 00 48 8b 14 d5 e0 c3 55 81 48 8b 1c 02 4c 8d 6b 20 eb 15 49 8b 7d 00 48 85 ff 74 05 e8 39 8c d9 ff 41 ff c4 49 83 c5 20 <44> 3b 23 72 e6 48 8d bb a0 02 00 00 e8 b1 6f f9 ff 48 89 df e8
|RIP  [<ffffffff812aab6e>] acpi_cppc_processor_exit+0x40/0x60
| RSP <ffffc9000000bd48>
|CR2: 0000000000000000
|---[ end trace 917a625107b09711 ]---

The patch attached fixes it. Could someone who looked longer at the code
than I actually confirm that this fine or fix it differently? This makes
the crash on boot on a "default" kvm setup go away.

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
 drivers/acpi/cppc_acpi.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c
index d0d0504b7c89..93252e5374c5 100644
--- a/drivers/acpi/cppc_acpi.c
+++ b/drivers/acpi/cppc_acpi.c
@@ -803,6 +803,7 @@ int acpi_cppc_processor_probe(struct acpi_processor *pr)
 		if (addr)
 			iounmap(addr);
 	}
+	per_cpu(cpc_desc_ptr, pr->id) = NULL;
 	kfree(cpc_ptr);
 
 out_buf_free:
@@ -824,6 +825,8 @@ void acpi_cppc_processor_exit(struct acpi_processor *pr)
 	void __iomem *addr;
 
 	cpc_ptr = per_cpu(cpc_desc_ptr, pr->id);
+	if (!cpc_ptr)
+		return;
 
 	/* Free all the mapped sys mem areas for this CPU */
 	for (i = 2; i < cpc_ptr->num_entries; i++) {
-- 
2.11.0

[toc] | [next] | [standalone]

#1538166

On Wed, 2016-12-07 at 20:06 +0100, Sebastian Andrzej Siewior wrote:
> 
> 
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> ---
>  drivers/acpi/cppc_acpi.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c
> index d0d0504b7c89..93252e5374c5 100644
> --- a/drivers/acpi/cppc_acpi.c
> +++ b/drivers/acpi/cppc_acpi.c
> @@ -803,6 +803,7 @@ int acpi_cppc_processor_probe(struct acpi_processor *pr)
>  		if (addr)
>  			iounmap(addr);
>  	}
> +	per_cpu(cpc_desc_ptr, pr->id) = NULL;
>  	kfree(cpc_ptr);
>  
>  out_buf_free:
> @@ -824,6 +825,8 @@ void acpi_cppc_processor_exit(struct acpi_processor *pr)
>  	void __iomem *addr;
>  
>  	cpc_ptr = per_cpu(cpc_desc_ptr, pr->id);
> +	if (!cpc_ptr)
> +		return;

I agree that not handling null pointer here is a bug that should be fixed.
The cpc_ptr is checked at other places like acpi_get_psd_map.  
We could potentially have a null cpc_ptr say when
the parsing of CPC table failed. We should handle such cases gracefully.

Tim

[toc] | [prev] | [next] | [standalone]

#1538184 — Re: [PATCH v8 8/8] cpufreq: intel_pstate: Use CPPC to get max performance

On Wednesday, December 07, 2016 03:12:53 PM Tim Chen wrote:
> On Wed, 2016-12-07 at 20:06 +0100, Sebastian Andrzej Siewior wrote:
> > 
> > 
> > Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> > ---
> >  drivers/acpi/cppc_acpi.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c
> > index d0d0504b7c89..93252e5374c5 100644
> > --- a/drivers/acpi/cppc_acpi.c
> > +++ b/drivers/acpi/cppc_acpi.c
> > @@ -803,6 +803,7 @@ int acpi_cppc_processor_probe(struct acpi_processor *pr)
> >  		if (addr)
> >  			iounmap(addr);
> >  	}
> > +	per_cpu(cpc_desc_ptr, pr->id) = NULL;
> >  	kfree(cpc_ptr);
> >  
> >  out_buf_free:
> > @@ -824,6 +825,8 @@ void acpi_cppc_processor_exit(struct acpi_processor *pr)
> >  	void __iomem *addr;
> >  
> >  	cpc_ptr = per_cpu(cpc_desc_ptr, pr->id);
> > +	if (!cpc_ptr)
> > +		return;
> 
> I agree that not handling null pointer here is a bug that should be fixed.
> The cpc_ptr is checked at other places like acpi_get_psd_map.  
> We could potentially have a null cpc_ptr say when
> the parsing of CPC table failed. We should handle such cases gracefully.

Agreed, but the bug fixed by the first hunk is real too.  I'd fix it a bit
differently, though:

Tentatively-signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

---
 drivers/acpi/cppc_acpi.c |   12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

Index: linux-pm/drivers/acpi/cppc_acpi.c
===================================================================
--- linux-pm.orig/drivers/acpi/cppc_acpi.c
+++ linux-pm/drivers/acpi/cppc_acpi.c
@@ -776,9 +776,6 @@ int acpi_cppc_processor_probe(struct acp
 		init_waitqueue_head(&pcc_data.pcc_write_wait_q);
 	}
 
-	/* Plug PSD data into this CPUs CPC descriptor. */
-	per_cpu(cpc_desc_ptr, pr->id) = cpc_ptr;
-
 	/* Everything looks okay */
 	pr_debug("Parsed CPC struct for CPU: %d\n", pr->id);
 
@@ -789,10 +786,15 @@ int acpi_cppc_processor_probe(struct acp
 		goto out_free;
 	}
 
+	/* Plug PSD data into this CPUs CPC descriptor. */
+	per_cpu(cpc_desc_ptr, pr->id) = cpc_ptr;
+
 	ret = kobject_init_and_add(&cpc_ptr->kobj, &cppc_ktype, &cpu_dev->kobj,
 			"acpi_cppc");
-	if (ret)
+	if (ret) {
+		per_cpu(cpc_desc_ptr, pr->id) = NULL;
 		goto out_free;
+	}
 
 	kfree(output.pointer);
 	return 0;
@@ -826,6 +828,8 @@ void acpi_cppc_processor_exit(struct acp
 	void __iomem *addr;
 
 	cpc_ptr = per_cpu(cpc_desc_ptr, pr->id);
+	if (!cpc_ptr)
+		return;
 
 	/* Free all the mapped sys mem areas for this CPU */
 	for (i = 2; i < cpc_ptr->num_entries; i++) {

[toc] | [prev] | [next] | [standalone]

#1539417

On 2016-12-08 00:29:29 [+0100], Rafael J. Wysocki wrote:
> Agreed, but the bug fixed by the first hunk is real too.  I'd fix it a bit
> differently, though:
> 
> Tentatively-signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Is there anything you want me to do here? The hunk in
acpi_cppc_processor_exit() is unchanged and is the one that led to the
crash. The other hunk I made (the one you changed) was something I
noticed while looking at the code - nothing that hit me directly.

Sebastian

[toc] | [prev] | [next] | [standalone]

#1539430 — Re: [PATCH v8 8/8] cpufreq: intel_pstate: Use CPPC to get max performance

On Fri, Dec 9, 2016 at 3:45 PM, Sebastian Andrzej Siewior
<bigeasy@linutronix.de> wrote:
> On 2016-12-08 00:29:29 [+0100], Rafael J. Wysocki wrote:
>> Agreed, but the bug fixed by the first hunk is real too.  I'd fix it a bit
>> differently, though:
>>
>> Tentatively-signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>
> Is there anything you want me to do here? The hunk in
> acpi_cppc_processor_exit() is unchanged and is the one that led to the
> crash. The other hunk I made (the one you changed) was something I
> noticed while looking at the code - nothing that hit me directly.

OK, thanks.

I'll add a changelog to the patch and resend it later today.

Thanks,
Rafael

[toc] | [prev] | [next] | [standalone]

#1539740 — [PATCH] ACPI / CPPC: Fix per-CPU pointers management

From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Enabling ACPI CPPC on x86 causes a NULL pointer dereference to occur
(on boot on a "default" KVM setup) in acpi_cppc_processor_exit() due
to a missing check against NULL in there:

|BUG: unable to handle kernel NULL pointer dereference at           (null)
|IP: [<ffffffff812aab6e>] acpi_cppc_processor_exit+0x40/0x60
|PGD 0 [    0.577616]
|Oops: 0000 [#1] SMP
|Modules linked in:
|CPU: 3 PID: 1 Comm: swapper/0 Not tainted 4.9.0-rc6-00146-g17669006adf6 #51
|task: ffff88003f878000 task.stack: ffffc90000008000
|RIP: 0010:[<ffffffff812aab6e>]  [<ffffffff812aab6e>] acpi_cppc_processor_exit+0x40/0x60
|RSP: 0000:ffffc9000000bd48  EFLAGS: 00010296
|RAX: 00000000000137e0 RBX: 0000000000000000 RCX: 0000000000000001
|RDX: ffff88003fc00000 RSI: 0000000000000000 RDI: ffff88003fbca130
|RBP: ffffc9000000bd60 R08: 0000000000000514 R09: 0000000000000000
|R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000002
|R13: 0000000000000020 R14: ffffffff8167cb00 R15: 0000000000000000
|FS:  0000000000000000(0000) GS:ffff88003fcc0000(0000) knlGS:0000000000000000
|CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|CR2: 0000000000000000 CR3: 0000000001618000 CR4: 00000000000406e0
|Stack:
| ffff88003f939848 ffff88003fbca130 0000000000000001 ffffc9000000bd80
| ffffffff812a4ccb ffff88003fc0cee8 0000000000000000 ffffc9000000bdb8
| ffffffff812dc20d ffff88003fc0cee8 ffffffff8167cb00 ffff88003fc0cf48
|Call Trace:
| [<ffffffff812a4ccb>] acpi_processor_stop+0xb2/0xc5
| [<ffffffff812dc20d>] driver_probe_device+0x14d/0x2f0
| [<ffffffff812dc41e>] __driver_attach+0x6e/0x90
| [<ffffffff812da234>] bus_for_each_dev+0x54/0x90
| [<ffffffff812dbbf9>] driver_attach+0x19/0x20
| [<ffffffff812db6a6>] bus_add_driver+0xe6/0x200
| [<ffffffff812dcb23>] driver_register+0x83/0xc0
| [<ffffffff816f050a>] acpi_processor_driver_init+0x20/0x94
| [<ffffffff81000487>] do_one_initcall+0x97/0x180
| [<ffffffff816ccf5c>] kernel_init_freeable+0x112/0x1a6
| [<ffffffff813a0fc9>] kernel_init+0x9/0xf0
| [<ffffffff813acf35>] ret_from_fork+0x25/0x30
|Code: 02 00 00 00 48 8b 14 d5 e0 c3 55 81 48 8b 1c 02 4c 8d 6b 20 eb 15 49 8b 7d 00 48 85 ff 74 05 e8 39 8c d9 ff 41 ff c4 49 83 c5 20 <44> 3b 23 72 e6 48 8d bb a0 02 00 00 e8 b1 6f f9 ff 48 89 df e8
|RIP  [<ffffffff812aab6e>] acpi_cppc_processor_exit+0x40/0x60
| RSP <ffffc9000000bd48>
|CR2: 0000000000000000

Fix that and while at it, fix a possible use-after-free scenario in
acpi_cppc_processor_probe() that can happen if the function returns
without cleaning up the per-CPU pointer set by it previously.

Reported-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Original-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---

Hi Thomas,

The crash fixed by this is exposed by the ITMT (asymmetric packing) series
(which involves using ACPI CPPC on x86), so IMO it would be good to route it
through tip along with that series.

Thanks,
Rafael

---
 drivers/acpi/cppc_acpi.c |   12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

Index: linux-pm/drivers/acpi/cppc_acpi.c
===================================================================
--- linux-pm.orig/drivers/acpi/cppc_acpi.c
+++ linux-pm/drivers/acpi/cppc_acpi.c
@@ -776,9 +776,6 @@ int acpi_cppc_processor_probe(struct acp
 		init_waitqueue_head(&pcc_data.pcc_write_wait_q);
 	}
 
-	/* Plug PSD data into this CPUs CPC descriptor. */
-	per_cpu(cpc_desc_ptr, pr->id) = cpc_ptr;
-
 	/* Everything looks okay */
 	pr_debug("Parsed CPC struct for CPU: %d\n", pr->id);
 
@@ -789,10 +786,15 @@ int acpi_cppc_processor_probe(struct acp
 		goto out_free;
 	}
 
+	/* Plug PSD data into this CPUs CPC descriptor. */
+	per_cpu(cpc_desc_ptr, pr->id) = cpc_ptr;
+
 	ret = kobject_init_and_add(&cpc_ptr->kobj, &cppc_ktype, &cpu_dev->kobj,
 			"acpi_cppc");
-	if (ret)
+	if (ret) {
+		per_cpu(cpc_desc_ptr, pr->id) = NULL;
 		goto out_free;
+	}
 
 	kfree(output.pointer);
 	return 0;
@@ -826,6 +828,8 @@ void acpi_cppc_processor_exit(struct acp
 	void __iomem *addr;
 
 	cpc_ptr = per_cpu(cpc_desc_ptr, pr->id);
+	if (!cpc_ptr)
+		return;
 
 	/* Free all the mapped sys mem areas for this CPU */
 	for (i = 2; i < cpc_ptr->num_entries; i++) {

[toc] | [prev] | [next] | [standalone]

#1539891 — Re: [PATCH] ACPI / CPPC: Fix per-CPU pointers management

On 2016-12-10 00:52:28 [+0100], Rafael J. Wysocki wrote:
> Hi Thomas,
> 
> The crash fixed by this is exposed by the ITMT (asymmetric packing) series
> (which involves using ACPI CPPC on x86), so IMO it would be good to route it
> through tip along with that series.

can we get this merged into the original patch please? This is default y
and breaks bisecting.

> Thanks,
> Rafael

Sebastian

[toc] | [prev] | [next] | [standalone]

#1540101 — Re: [PATCH] ACPI / CPPC: Fix per-CPU pointers management

On Sat, Dec 10, 2016 at 7:51 PM, Sebastian Andrzej Siewior
<bigeasy@linutronix.de> wrote:
> On 2016-12-10 00:52:28 [+0100], Rafael J. Wysocki wrote:
>> Hi Thomas,
>>
>> The crash fixed by this is exposed by the ITMT (asymmetric packing) series
>> (which involves using ACPI CPPC on x86), so IMO it would be good to route it
>> through tip along with that series.
>
> can we get this merged into the original patch please?

Functionally, that patch has a little to do with the fix, so I'd
rather not do that.

> This is default y  and breaks bisecting.

Instead, I would reorder the series to put the fix in front of that patch.

Thanks,
Rafael

[toc] | [prev] | [next] | [standalone]

#1541651 — Re: [PATCH] ACPI / CPPC: Fix per-CPU pointers management

On Saturday, December 10, 2016 12:52:28 AM Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> 
> Enabling ACPI CPPC on x86 causes a NULL pointer dereference to occur
> (on boot on a "default" KVM setup) in acpi_cppc_processor_exit() due
> to a missing check against NULL in there:
> 
> |BUG: unable to handle kernel NULL pointer dereference at           (null)
> |IP: [<ffffffff812aab6e>] acpi_cppc_processor_exit+0x40/0x60
> |PGD 0 [    0.577616]
> |Oops: 0000 [#1] SMP
> |Modules linked in:
> |CPU: 3 PID: 1 Comm: swapper/0 Not tainted 4.9.0-rc6-00146-g17669006adf6 #51
> |task: ffff88003f878000 task.stack: ffffc90000008000
> |RIP: 0010:[<ffffffff812aab6e>]  [<ffffffff812aab6e>] acpi_cppc_processor_exit+0x40/0x60
> |RSP: 0000:ffffc9000000bd48  EFLAGS: 00010296
> |RAX: 00000000000137e0 RBX: 0000000000000000 RCX: 0000000000000001
> |RDX: ffff88003fc00000 RSI: 0000000000000000 RDI: ffff88003fbca130
> |RBP: ffffc9000000bd60 R08: 0000000000000514 R09: 0000000000000000
> |R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000002
> |R13: 0000000000000020 R14: ffffffff8167cb00 R15: 0000000000000000
> |FS:  0000000000000000(0000) GS:ffff88003fcc0000(0000) knlGS:0000000000000000
> |CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> |CR2: 0000000000000000 CR3: 0000000001618000 CR4: 00000000000406e0
> |Stack:
> | ffff88003f939848 ffff88003fbca130 0000000000000001 ffffc9000000bd80
> | ffffffff812a4ccb ffff88003fc0cee8 0000000000000000 ffffc9000000bdb8
> | ffffffff812dc20d ffff88003fc0cee8 ffffffff8167cb00 ffff88003fc0cf48
> |Call Trace:
> | [<ffffffff812a4ccb>] acpi_processor_stop+0xb2/0xc5
> | [<ffffffff812dc20d>] driver_probe_device+0x14d/0x2f0
> | [<ffffffff812dc41e>] __driver_attach+0x6e/0x90
> | [<ffffffff812da234>] bus_for_each_dev+0x54/0x90
> | [<ffffffff812dbbf9>] driver_attach+0x19/0x20
> | [<ffffffff812db6a6>] bus_add_driver+0xe6/0x200
> | [<ffffffff812dcb23>] driver_register+0x83/0xc0
> | [<ffffffff816f050a>] acpi_processor_driver_init+0x20/0x94
> | [<ffffffff81000487>] do_one_initcall+0x97/0x180
> | [<ffffffff816ccf5c>] kernel_init_freeable+0x112/0x1a6
> | [<ffffffff813a0fc9>] kernel_init+0x9/0xf0
> | [<ffffffff813acf35>] ret_from_fork+0x25/0x30
> |Code: 02 00 00 00 48 8b 14 d5 e0 c3 55 81 48 8b 1c 02 4c 8d 6b 20 eb 15 49 8b 7d 00 48 85 ff 74 05 e8 39 8c d9 ff 41 ff c4 49 83 c5 20 <44> 3b 23 72 e6 48 8d bb a0 02 00 00 e8 b1 6f f9 ff 48 89 df e8
> |RIP  [<ffffffff812aab6e>] acpi_cppc_processor_exit+0x40/0x60
> | RSP <ffffc9000000bd48>
> |CR2: 0000000000000000
> 
> Fix that and while at it, fix a possible use-after-free scenario in
> acpi_cppc_processor_probe() that can happen if the function returns
> without cleaning up the per-CPU pointer set by it previously.
> 
> Reported-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> Original-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
> 
> Hi Thomas,
> 
> The crash fixed by this is exposed by the ITMT (asymmetric packing) series
> (which involves using ACPI CPPC on x86), so IMO it would be good to route it
> through tip along with that series.

The problematic commit has gone in already, so I'll route the fix through
the ACPI tree.

Thanks,
Rafael

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web