x86, microcode fixes for 3.2

GIT PULL Borislav Petkov 3 participants 9 messages Nov 28, 2011 – Mar 26, 2012 x86

lore

Share & tools

lore

Borislav Petkov

author

2011-11-28 20:43 UTC #0 lore raw

Hi Ingo,

please pull the following two fixes for the microcode machinery.

Thanks.

The following changes since commit caca6a03d365883564885f2c1da3e88dcf65d139:

Linux 3.2-rc3 (2011-11-23 20:20:28 -0800)

are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git ucode

Borislav Petkov (1):
x86, microcode, AMD: Restrict microcode reporting

Srivatsa S. Bhat (1):
x86, microcode: Fix the failure path of microcode update driver init code

 arch/x86/kernel/cpu/amd.c        |    3 ++-
 arch/x86/kernel/microcode_core.c |   19 +++++++++++--------
 2 files changed, 13 insertions(+), 9 deletions(-)

Signature · 8 lines

Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551

Borislav Petkov

author

2011-12-02 19:47 UTC #1 lore raw

Quoted 10 lines · Borislav Petkov

Hi Ingo,
please pull the following two fixes for the microcode machinery.
Thanks.
The following changes since commit caca6a03d365883564885f2c1da3e88dcf65d139:
Linux 3.2-rc3 (2011-11-23 20:20:28 -0800)

Quoted 8 lines

are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git ucode
Borislav Petkov (1):
x86, microcode, AMD: Restrict microcode reporting
Srivatsa S. Bhat (1):
x86, microcode: Fix the failure path of microcode update driver init code

Since you haven't pulled yet, I've updated this one with the better version below, branch above has been updated too:

--
From: "Srivatsa S. Bhat" <[email protected]>
Date: Mon, 7 Nov 2011 18:05:32 +0530
Subject: [PATCH] x86, microcode: Fix the failure path of microcode update
driver init code

The microcode update driver's initialization code does not handle failures correctly. This patch fixes this issue.

Signed-off-by Jan Beulich <[email protected]>

Signed-off-by Srivatsa S. Bhat <[email protected]>

Link http://lkml.kernel.org/r/[email protected] open here

Signed-off-by Borislav Petkov <[email protected]>

---
 arch/x86/kernel/microcode_core.c |   28 +++++++++++++++++++---------
 1 files changed, 19 insertions(+), 9 deletions(-)

arch/x86/kernel/microcode_core.c +19 -9

index f2d2a66..9d46f5e 100644
@@ -256,7 +256,7 @@ static int __init microcode_dev_init(void)
 	return 0;
 }
 
-static void microcode_dev_exit(void)
+static void __exit microcode_dev_exit(void)
 {
 	misc_deregister(&microcode_dev);
 }

@@ -519,10 +519,8 @@ static int __init microcode_init(void)
 
 	microcode_pdev = platform_device_register_simple("microcode", -1,
 							 NULL, 0);
-	if (IS_ERR(microcode_pdev)) {
-		microcode_dev_exit();
+	if (IS_ERR(microcode_pdev))
 		return PTR_ERR(microcode_pdev);
-	}
 
 	get_online_cpus();
 	mutex_lock(&microcode_mutex);

@@ -532,14 +530,12 @@ static int __init microcode_init(void)
 	mutex_unlock(&microcode_mutex);
 	put_online_cpus();
 
-	if (error) {
-		platform_device_unregister(microcode_pdev);
-		return error;
-	}
+	if (error)
+		goto out_pdev;
 
 	error = microcode_dev_init();
 	if (error)
-		return error;
+		goto out_sysdev_driver;
 
 	register_syscore_ops(&mc_syscore_ops);
 	register_hotcpu_notifier(&mc_cpu_notifier);

@@ -548,6 +544,20 @@ static int __init microcode_init(void)
 		" <[email protected]>, Peter Oruba\n");
 
 	return 0;
+
+out_sysdev_driver:
+	get_online_cpus();
+	mutex_lock(&microcode_mutex);
+
+	sysdev_driver_unregister(&cpu_sysdev_class, &mc_sysdev_driver);
+
+	mutex_unlock(&microcode_mutex);
+	put_online_cpus();
+
+out_pdev:
+	platform_device_unregister(microcode_pdev);
+	return error;
+
 }
 module_init(microcode_init);

Signature · 11 lines

1.7.8.rc0

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551

Ingo Molnar

2011-12-05 09:28 UTC #2 lore raw

Quoted 32 lines · Borislav Petkov

Quoted 10 lines · Borislav Petkov
Hi Ingo,
please pull the following two fixes for the microcode machinery.
Thanks.
The following changes since commit caca6a03d365883564885f2c1da3e88dcf65d139:
Linux 3.2-rc3 (2011-11-23 20:20:28 -0800)
Quoted 8 lines
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git ucode
Borislav Petkov (1):
x86, microcode, AMD: Restrict microcode reporting
Srivatsa S. Bhat (1):
x86, microcode: Fix the failure path of microcode update driver init code
Since you haven't pulled yet, I've updated this one with the better version below, branch above has been updated too:
--
From: "Srivatsa S. Bhat" <[email protected]>
Date: Mon, 7 Nov 2011 18:05:32 +0530
Subject: [PATCH] x86, microcode: Fix the failure path of microcode update
driver init code
The microcode update driver's initialization code does not handle failures correctly. This patch fixes this issue.

Quoted 6 lines

Signed-off-by Jan Beulich <[email protected]>
Signed-off-by Srivatsa S. Bhat <[email protected]>
Link http://lkml.kernel.org/r/[email protected] open here
Link http://lkml.kernel.org/r/[email protected] open here
Signed-off-by Borislav Petkov <[email protected]>
---

Mind respinning this once more against latest -git? There's a new conflict due to:

8e8da023f5af: x86: Fix boot failures on older AMD CPU's

Thanks,

Ingo

Borislav Petkov

author

2011-12-05 15:10 UTC #3 lore raw

Quoted 4 lines · Ingo Molnar

Mind respinning this once more against latest -git? There's a new conflict due to:
8e8da023f5af: x86: Fix boot failures on older AMD CPU's

Branch is updated, it also contains the following patch:

--
From: Borislav Petkov <[email protected]>
Date: Mon, 5 Dec 2011 14:28:37 +0100
Subject: [PATCH] x86: Document rdmsr_safe restrictions

Recently, I got bitten by using rdmsr_safe too early in the boot process. Document its shortcomings for future reference.

Link http://lkml.kernel.org/r/[email protected] open here

Signed-off-by Borislav Petkov <[email protected]>

---
 arch/x86/include/asm/msr.h |    9 ++++++++-
 1 files changed, 8 insertions(+), 1 deletions(-)

arch/x86/include/asm/msr.h +8 -1

index 084ef95..95203d4 100644
@@ -169,7 +169,14 @@ static inline int wrmsr_safe(unsigned msr, unsigned low, unsigned high)
 	return native_write_msr_safe(msr, low, high);
 }
 
-/* rdmsr with exception handling */
+/*
+ * rdmsr with exception handling.
+ *
+ * Please note that the exception handling works only after we've
+ * switched to the "smart" #GP handler in trap_init() which knows about
+ * exception tables - using this macro earlier than that causes machine
+ * hangs on boxes which do not implement the @msr in the first argument.
+ */
 #define rdmsr_safe(msr, p1, p2)					\
 ({								\
 	int __err;						\

Signature · 13 lines

1.7.8.rc0

Thanks.

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551

H. Peter Anvin

reviewer

2012-03-25 19:27 UTC #4 lore raw

Quoted 11 lines · Borislav Petkov

arch/x86/include/asm/msr.h +1 -1

index 084ef95..95203d4 100644
@@ -169,7 +169,14 @@ static inline int wrmsr_safe(unsigned msr, unsigned low, unsigned high)
 	return native_write_msr_safe(msr, low, high);
 }
 
-/* rdmsr with exception handling */
+/*

arch/x86/include/asm/msr.h static inline int wrmsr_safe(unsigned msr, unsigned low, unsigned high) · line 182

Quoted 10 lines

arch/x86/include/asm/msr.h +7 -0

+ * rdmsr with exception handling.
+ *
+ * Please note that the exception handling works only after we've
+ * switched to the "smart" #GP handler in trap_init() which knows about
+ * exception tables - using this macro earlier than that causes machine
+ * hangs on boxes which do not implement the @msr in the first argument.
+ */
 #define rdmsr_safe(msr, p1, p2)					\
 ({								\
 	int __err;						\

I keep wondering if we couldn't have the early-static trap handlers be aware of exception tables, too; they wouldn't have to worry about modules and so it would be reasonably easy.

-hpa

Borislav Petkov

author

2012-03-26 08:48 UTC #5 lore raw

Quoted 3 lines · H. Peter Anvin

I keep wondering if we couldn't have the early-static trap handlers be aware of exception tables, too; they wouldn't have to worry about modules and so it would be reasonably easy.

Well, we talked about this recently and then we decided we needed the extable-sorting-at-build-time patches before we make those static trap handlers aware of extables. What happened to those patches, btw? See thread at http://marc.info/?l=linux-kernel&m=132196692827070

Signature · 8 lines

Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551

H. Peter Anvin

reviewer

2012-03-26 14:53 UTC #6 lore raw

Quoted 10 lines · Borislav Petkov

Quoted 3 lines · H. Peter Anvin
I keep wondering if we couldn't have the early-static trap handlers be aware of exception tables, too; they wouldn't have to worry about modules and so it would be reasonably easy.
Well, we talked about this recently and then we decided we needed the extable-sorting-at-build-time patches before we make those static trap handlers aware of extables. What happened to those patches, btw? See thread at http://marc.info/?l=linux-kernel&m=132196692827070

Hm... I hope that didn't stall out because of me... the amount of overload I have been under lately is a bit scary.

I was going to dredge out the perfect hash stuff that I had, but the sorting stuff could be done without that.

-hpa

Signature · 2 lines

H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Borislav Petkov

author

2012-03-26 15:25 UTC #7 lore raw

Quoted 12 lines · H. Peter Anvin

Quoted 10 lines · Borislav Petkov
Quoted 3 lines · H. Peter Anvin
I keep wondering if we couldn't have the early-static trap handlers be aware of exception tables, too; they wouldn't have to worry about modules and so it would be reasonably easy.
Well, we talked about this recently and then we decided we needed the extable-sorting-at-build-time patches before we make those static trap handlers aware of extables. What happened to those patches, btw? See thread at http://marc.info/?l=linux-kernel&m=132196692827070

Quoted 5 lines

Hm... I hope that didn't stall out because of me... the amount of overload I have been under lately is a bit scary.
I was going to dredge out the perfect hash stuff that I had, but the sorting stuff could be done without that.

Ok, let me scratch up something in the coming days.

Signature · 8 lines

Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551

H. Peter Anvin

reviewer

2012-03-26 17:56 UTC #8 lore raw

Here is a version of the automatic hash generator written in Perl:

http://www.zytor.com/~hpa/phash/

There is another one based on code written by Bob Jenkins, in C, and based on a different algorithm included with libucd:

git://git.kernel.org/pub/scm/libs/libucd/libucd.git

It is *much* slower to converge, but probably generates at least marginally faster lookup code.

-hpa