<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/arch/x86/kernel/cpu/mcheck, branch v3.4</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>x86/mce: Only restart instruction after machine check recovery if it is safe</title>
<updated>2012-05-14T22:07:48+00:00</updated>
<author>
<name>Tony Luck</name>
<email>tony.luck@intel.com</email>
</author>
<published>2012-05-14T22:07:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=dad1743e5993f19b3d7e7bd0fb35dc45b5326626'/>
<id>dad1743e5993f19b3d7e7bd0fb35dc45b5326626</id>
<content type='text'>
Section 15.3.1.2 of the software developer manual has this to say about the
RIPV bit in the IA32_MCG_STATUS register:

  RIPV (restart IP valid) flag, bit 0 — Indicates (when set) that program
  execution can be restarted reliably at the instruction pointed to by the
  instruction pointer pushed on the stack when the machine-check exception
  is generated.  When clear, the program cannot be reliably restarted at
  the pushed instruction pointer.

We need to save the state of this bit in do_machine_check() and use it
in mce_notify_process() to force a signal; even if memory_failure() says
it made a complete recovery ... e.g. replaced a clean LRU page.

Acked-by: Borislav Petkov &lt;bp@amd64.org&gt;
Signed-off-by: Tony Luck &lt;tony.luck@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Section 15.3.1.2 of the software developer manual has this to say about the
RIPV bit in the IA32_MCG_STATUS register:

  RIPV (restart IP valid) flag, bit 0 — Indicates (when set) that program
  execution can be restarted reliably at the instruction pointed to by the
  instruction pointer pushed on the stack when the machine-check exception
  is generated.  When clear, the program cannot be reliably restarted at
  the pushed instruction pointer.

We need to save the state of this bit in do_machine_check() and use it
in mce_notify_process() to force a signal; even if memory_failure() says
it made a complete recovery ... e.g. replaced a clean LRU page.

Acked-by: Borislav Petkov &lt;bp@amd64.org&gt;
Signed-off-by: Tony Luck &lt;tony.luck@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Disintegrate asm/system.h for X86</title>
<updated>2012-03-28T17:11:12+00:00</updated>
<author>
<name>David Howells</name>
<email>dhowells@redhat.com</email>
</author>
<published>2012-03-28T17:11:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f05e798ad4c09255f590f5b2c00a7ca6c172f983'/>
<id>f05e798ad4c09255f590f5b2c00a7ca6c172f983</id>
<content type='text'>
Disintegrate asm/system.h for X86.

Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Acked-by: H. Peter Anvin &lt;hpa@zytor.com&gt;
cc: x86@kernel.org
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Disintegrate asm/system.h for X86.

Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Acked-by: H. Peter Anvin &lt;hpa@zytor.com&gt;
cc: x86@kernel.org
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip</title>
<updated>2012-03-22T16:44:50+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2012-03-22T16:44:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=28f23d1f3b6a6078312b6e9585e583cc7326fe22'/>
<id>28f23d1f3b6a6078312b6e9585e583cc7326fe22</id>
<content type='text'>
Pull x86 "urgent" leftovers from Ingo Molnar:
 "Pending x86/urgent bits that were not high prio enough to warrant
  -rc-less v3.3-final inclusion."

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86, efi: Fix pointer math issue in handle_ramdisks()
  x86/ioapic: Add register level checks to detect bogus io-apic entries
  x86, mce: Fix rcu splat in drain_mce_log_buffer()
  x86, memblock: Move mem_hole_size() to .init
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull x86 "urgent" leftovers from Ingo Molnar:
 "Pending x86/urgent bits that were not high prio enough to warrant
  -rc-less v3.3-final inclusion."

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86, efi: Fix pointer math issue in handle_ramdisks()
  x86/ioapic: Add register level checks to detect bogus io-apic entries
  x86, mce: Fix rcu splat in drain_mce_log_buffer()
  x86, memblock: Move mem_hole_size() to .init
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'mce-for-tip' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras into x86/mce</title>
<updated>2012-03-14T06:44:48+00:00</updated>
<author>
<name>Ingo Molnar</name>
<email>mingo@elte.hu</email>
</author>
<published>2012-03-14T06:44:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ea281a9ebaba3287130dbe15bb0aad6f798bb06b'/>
<id>ea281a9ebaba3287130dbe15bb0aad6f798bb06b</id>
<content type='text'>
Apply two miscellaneous MCE fixes.

Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Apply two miscellaneous MCE fixes.

Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'v3.3-rc7' into x86/mce</title>
<updated>2012-03-14T06:44:11+00:00</updated>
<author>
<name>Ingo Molnar</name>
<email>mingo@elte.hu</email>
</author>
<published>2012-03-14T06:44:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=cd593accdcc27ccbe6498d9ad1c2b6cc8e1d830d'/>
<id>cd593accdcc27ccbe6498d9ad1c2b6cc8e1d830d</id>
<content type='text'>
Merge reason: Update from an ancient -rc1 base to an almost-final stable kernel.

Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Merge reason: Update from an ancient -rc1 base to an almost-final stable kernel.

Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>x86, mce: Fix rcu splat in drain_mce_log_buffer()</title>
<updated>2012-03-07T10:44:29+00:00</updated>
<author>
<name>Srivatsa S. Bhat</name>
<email>srivatsa.bhat@linux.vnet.ibm.com</email>
</author>
<published>2012-03-07T10:44:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b11e3d782b9c065b3b2fb543bfb0d97801822dc0'/>
<id>b11e3d782b9c065b3b2fb543bfb0d97801822dc0</id>
<content type='text'>
While booting, the following message is seen:

[   21.665087] ===============================
[   21.669439] [ INFO: suspicious RCU usage. ]
[   21.673798] 3.2.0-0.0.0.28.36b5ec9-default #2 Not tainted
[   21.681353] -------------------------------
[   21.685864] arch/x86/kernel/cpu/mcheck/mce.c:194 suspicious rcu_dereference_index_check() usage!
[   21.695013]
[   21.695014] other info that might help us debug this:
[   21.695016]
[   21.703488]
[   21.703489] rcu_scheduler_active = 1, debug_locks = 1
[   21.710426] 3 locks held by modprobe/2139:
[   21.714754]  #0:  (&amp;__lockdep_no_validate__){......}, at: [&lt;ffffffff8133afd3&gt;] __driver_attach+0x53/0xa0
[   21.725020]  #1:
[   21.725323] ioatdma: Intel(R) QuickData Technology Driver 4.00
[   21.733206]  (&amp;__lockdep_no_validate__){......}, at: [&lt;ffffffff8133afe1&gt;] __driver_attach+0x61/0xa0
[   21.743015]  #2:  (i7core_edac_lock){+.+.+.}, at: [&lt;ffffffffa01cfa5f&gt;] i7core_probe+0x1f/0x5c0 [i7core_edac]
[   21.753708]
[   21.753709] stack backtrace:
[   21.758429] Pid: 2139, comm: modprobe Not tainted 3.2.0-0.0.0.28.36b5ec9-default #2
[   21.768253] Call Trace:
[   21.770838]  [&lt;ffffffff810977cd&gt;] lockdep_rcu_suspicious+0xcd/0x100
[   21.777366]  [&lt;ffffffff8101aa41&gt;] drain_mcelog_buffer+0x191/0x1b0
[   21.783715]  [&lt;ffffffff8101aa78&gt;] mce_register_decode_chain+0x18/0x20
[   21.790430]  [&lt;ffffffffa01cf8db&gt;] i7core_register_mci+0x2fb/0x3e4 [i7core_edac]
[   21.798003]  [&lt;ffffffffa01cfb14&gt;] i7core_probe+0xd4/0x5c0 [i7core_edac]
[   21.804809]  [&lt;ffffffff8129566b&gt;] local_pci_probe+0x5b/0xe0
[   21.810631]  [&lt;ffffffff812957c9&gt;] __pci_device_probe+0xd9/0xe0
[   21.816650]  [&lt;ffffffff813362e4&gt;] ? get_device+0x14/0x20
[   21.822178]  [&lt;ffffffff81296916&gt;] pci_device_probe+0x36/0x60
[   21.828061]  [&lt;ffffffff8133ac8a&gt;] really_probe+0x7a/0x2b0
[   21.833676]  [&lt;ffffffff8133af23&gt;] driver_probe_device+0x63/0xc0
[   21.839868]  [&lt;ffffffff8133b01b&gt;] __driver_attach+0x9b/0xa0
[   21.845718]  [&lt;ffffffff8133af80&gt;] ? driver_probe_device+0xc0/0xc0
[   21.852027]  [&lt;ffffffff81339168&gt;] bus_for_each_dev+0x68/0x90
[   21.857876]  [&lt;ffffffff8133aa3c&gt;] driver_attach+0x1c/0x20
[   21.863462]  [&lt;ffffffff8133a64d&gt;] bus_add_driver+0x16d/0x2b0
[   21.869377]  [&lt;ffffffff8133b6dc&gt;] driver_register+0x7c/0x160
[   21.875220]  [&lt;ffffffff81296bda&gt;] __pci_register_driver+0x6a/0xf0
[   21.881494]  [&lt;ffffffffa01fe000&gt;] ? 0xffffffffa01fdfff
[   21.886846]  [&lt;ffffffffa01fe047&gt;] i7core_init+0x47/0x1000 [i7core_edac]
[   21.893737]  [&lt;ffffffff810001ce&gt;] do_one_initcall+0x3e/0x180
[   21.899670]  [&lt;ffffffff810a9b95&gt;] sys_init_module+0xc5/0x220
[   21.905542]  [&lt;ffffffff8149bc39&gt;] system_call_fastpath+0x16/0x1b

Fix this by using ACCESS_ONCE() instead of rcu_dereference_check_mce()
over mcelog.next. Since the access to each entry is controlled by the
-&gt;finished field, ACCESS_ONCE() should work just fine. An rcu_dereference
is unnecessary here.

Signed-off-by: Srivatsa S. Bhat &lt;srivatsa.bhat@linux.vnet.ibm.com&gt;
Suggested-by: Paul E. McKenney &lt;paulmck@linux.vnet.ibm.com&gt;
Cc: Tony Luck &lt;tony.luck@intel.com&gt;
Signed-off-by: Borislav Petkov &lt;borislav.petkov@amd.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
While booting, the following message is seen:

[   21.665087] ===============================
[   21.669439] [ INFO: suspicious RCU usage. ]
[   21.673798] 3.2.0-0.0.0.28.36b5ec9-default #2 Not tainted
[   21.681353] -------------------------------
[   21.685864] arch/x86/kernel/cpu/mcheck/mce.c:194 suspicious rcu_dereference_index_check() usage!
[   21.695013]
[   21.695014] other info that might help us debug this:
[   21.695016]
[   21.703488]
[   21.703489] rcu_scheduler_active = 1, debug_locks = 1
[   21.710426] 3 locks held by modprobe/2139:
[   21.714754]  #0:  (&amp;__lockdep_no_validate__){......}, at: [&lt;ffffffff8133afd3&gt;] __driver_attach+0x53/0xa0
[   21.725020]  #1:
[   21.725323] ioatdma: Intel(R) QuickData Technology Driver 4.00
[   21.733206]  (&amp;__lockdep_no_validate__){......}, at: [&lt;ffffffff8133afe1&gt;] __driver_attach+0x61/0xa0
[   21.743015]  #2:  (i7core_edac_lock){+.+.+.}, at: [&lt;ffffffffa01cfa5f&gt;] i7core_probe+0x1f/0x5c0 [i7core_edac]
[   21.753708]
[   21.753709] stack backtrace:
[   21.758429] Pid: 2139, comm: modprobe Not tainted 3.2.0-0.0.0.28.36b5ec9-default #2
[   21.768253] Call Trace:
[   21.770838]  [&lt;ffffffff810977cd&gt;] lockdep_rcu_suspicious+0xcd/0x100
[   21.777366]  [&lt;ffffffff8101aa41&gt;] drain_mcelog_buffer+0x191/0x1b0
[   21.783715]  [&lt;ffffffff8101aa78&gt;] mce_register_decode_chain+0x18/0x20
[   21.790430]  [&lt;ffffffffa01cf8db&gt;] i7core_register_mci+0x2fb/0x3e4 [i7core_edac]
[   21.798003]  [&lt;ffffffffa01cfb14&gt;] i7core_probe+0xd4/0x5c0 [i7core_edac]
[   21.804809]  [&lt;ffffffff8129566b&gt;] local_pci_probe+0x5b/0xe0
[   21.810631]  [&lt;ffffffff812957c9&gt;] __pci_device_probe+0xd9/0xe0
[   21.816650]  [&lt;ffffffff813362e4&gt;] ? get_device+0x14/0x20
[   21.822178]  [&lt;ffffffff81296916&gt;] pci_device_probe+0x36/0x60
[   21.828061]  [&lt;ffffffff8133ac8a&gt;] really_probe+0x7a/0x2b0
[   21.833676]  [&lt;ffffffff8133af23&gt;] driver_probe_device+0x63/0xc0
[   21.839868]  [&lt;ffffffff8133b01b&gt;] __driver_attach+0x9b/0xa0
[   21.845718]  [&lt;ffffffff8133af80&gt;] ? driver_probe_device+0xc0/0xc0
[   21.852027]  [&lt;ffffffff81339168&gt;] bus_for_each_dev+0x68/0x90
[   21.857876]  [&lt;ffffffff8133aa3c&gt;] driver_attach+0x1c/0x20
[   21.863462]  [&lt;ffffffff8133a64d&gt;] bus_add_driver+0x16d/0x2b0
[   21.869377]  [&lt;ffffffff8133b6dc&gt;] driver_register+0x7c/0x160
[   21.875220]  [&lt;ffffffff81296bda&gt;] __pci_register_driver+0x6a/0xf0
[   21.881494]  [&lt;ffffffffa01fe000&gt;] ? 0xffffffffa01fdfff
[   21.886846]  [&lt;ffffffffa01fe047&gt;] i7core_init+0x47/0x1000 [i7core_edac]
[   21.893737]  [&lt;ffffffff810001ce&gt;] do_one_initcall+0x3e/0x180
[   21.899670]  [&lt;ffffffff810a9b95&gt;] sys_init_module+0xc5/0x220
[   21.905542]  [&lt;ffffffff8149bc39&gt;] system_call_fastpath+0x16/0x1b

Fix this by using ACCESS_ONCE() instead of rcu_dereference_check_mce()
over mcelog.next. Since the access to each entry is controlled by the
-&gt;finished field, ACCESS_ONCE() should work just fine. An rcu_dereference
is unnecessary here.

Signed-off-by: Srivatsa S. Bhat &lt;srivatsa.bhat@linux.vnet.ibm.com&gt;
Suggested-by: Paul E. McKenney &lt;paulmck@linux.vnet.ibm.com&gt;
Cc: Tony Luck &lt;tony.luck@intel.com&gt;
Signed-off-by: Borislav Petkov &lt;borislav.petkov@amd.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'mce-recovery-for-tip' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras into x86/mce</title>
<updated>2012-02-24T15:26:39+00:00</updated>
<author>
<name>Ingo Molnar</name>
<email>mingo@elte.hu</email>
</author>
<published>2012-02-24T15:26:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=11b91d6fe7272452c999573bab33c15c2f03dc31'/>
<id>11b91d6fe7272452c999573bab33c15c2f03dc31</id>
<content type='text'>
Add symbolic defines for architectural MCACOD constants
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add symbolic defines for architectural MCACOD constants
</pre>
</div>
</content>
</entry>
<entry>
<title>x86/mce: Fix return value of mce_chrdev_read() when erst is disabled</title>
<updated>2012-02-22T21:14:16+00:00</updated>
<author>
<name>Naoya Horiguchi</name>
<email>n-horiguchi@ah.jp.nec.com</email>
</author>
<published>2012-01-23T20:54:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=fadd85f16a8ec3fee8af599e79a209682dc52348'/>
<id>fadd85f16a8ec3fee8af599e79a209682dc52348</id>
<content type='text'>
Current kernel MCE code reads ERST at the first reading of /dev/mcelog
(maybe in starting mcelogd,) even if the system does not support ERST,
which results in a fake "no such device" message (as described in [1].)
This problem is not critical, but can confuse system admins.
This patch fixes it by filtering the return value from lower (ACPI) layer.

 [1] http://thread.gmane.org/gmane.linux.kernel/1060250

Reported by: Jon Masters &lt;jonathan@jonmasters.org&gt;
Signed-off-by: Naoya Horiguchi &lt;n-horiguchi@ah.jp.nec.com&gt;
Cc: Andi Kleen &lt;andi@firstfloor.org&gt;
Cc: Huang Ying &lt;ying.huang@intel.com&gt;
Link: https://lkml.org/lkml/2012/1/23/299
Signed-off-by: Tony Luck &lt;tony.luck@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Current kernel MCE code reads ERST at the first reading of /dev/mcelog
(maybe in starting mcelogd,) even if the system does not support ERST,
which results in a fake "no such device" message (as described in [1].)
This problem is not critical, but can confuse system admins.
This patch fixes it by filtering the return value from lower (ACPI) layer.

 [1] http://thread.gmane.org/gmane.linux.kernel/1060250

Reported by: Jon Masters &lt;jonathan@jonmasters.org&gt;
Signed-off-by: Naoya Horiguchi &lt;n-horiguchi@ah.jp.nec.com&gt;
Cc: Andi Kleen &lt;andi@firstfloor.org&gt;
Cc: Huang Ying &lt;ying.huang@intel.com&gt;
Link: https://lkml.org/lkml/2012/1/23/299
Signed-off-by: Tony Luck &lt;tony.luck@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>x86/mce: Convert static array of pointers to per-cpu variables</title>
<updated>2012-02-22T20:58:06+00:00</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@suse.de</email>
</author>
<published>2012-01-26T23:49:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d6126ef5f31ca54980cb067af659a360dfcca037'/>
<id>d6126ef5f31ca54980cb067af659a360dfcca037</id>
<content type='text'>
When I previously fixed up the mce_device code, I used a static array of
the pointers.  It was (rightfully) pointed out to me that I should be
using the per_cpu code instead.

This patch converts the code over to that structure, moving the variable
back into the per_cpu area, like it used to be for 3.2 and earlier.

Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
Reviewed-by: Srivatsa S. Bhat &lt;srivatsa.bhat@linux.vnet.ibm.com&gt;
Link: https://lkml.org/lkml/2012/1/27/165
Signed-off-by: Tony Luck &lt;tony.luck@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When I previously fixed up the mce_device code, I used a static array of
the pointers.  It was (rightfully) pointed out to me that I should be
using the per_cpu code instead.

This patch converts the code over to that structure, moving the variable
back into the per_cpu area, like it used to be for 3.2 and earlier.

Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
Reviewed-by: Srivatsa S. Bhat &lt;srivatsa.bhat@linux.vnet.ibm.com&gt;
Link: https://lkml.org/lkml/2012/1/27/165
Signed-off-by: Tony Luck &lt;tony.luck@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>x86/mce/AMD: Fix UP build error</title>
<updated>2012-02-22T12:36:30+00:00</updated>
<author>
<name>Borislav Petkov</name>
<email>bp@alien8.de</email>
</author>
<published>2012-02-03T19:18:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3f806e50981825fa56a7f1938f24c0680816be45'/>
<id>3f806e50981825fa56a7f1938f24c0680816be45</id>
<content type='text'>
141168c36cde ("x86: Simplify code by removing a !SMP #ifdefs
from 'struct cpuinfo_x86'") removed a bunch of CONFIG_SMP ifdefs
around code touching struct cpuinfo_x86 members but also caused
the following build error with Randy's randconfigs:

mce_amd.c:(.cpuinit.text+0x4723): undefined reference to `cpu_llc_shared_map'

Restore the #ifdef in threshold_create_bank() which creates
symlinks on the non-BSP CPUs.

There's a better patch series being worked on by Kevin Winchester
which will solve this in a cleaner fashion, but that series is
too ambitious for v3.3 merging - so we first queue up this trivial
fix and then do the rest for v3.4.

Signed-off-by: Borislav Petkov &lt;bp@alien8.de&gt;
Acked-by: Kevin Winchester &lt;kjwinchester@gmail.com&gt;
Cc: Randy Dunlap &lt;rdunlap@xenotime.net&gt;
Cc: Nick Bowler &lt;nbowler@elliptictech.com&gt;
Link: http://lkml.kernel.org/r/20120203191801.GA2846@x1.osrc.amd.com
Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
141168c36cde ("x86: Simplify code by removing a !SMP #ifdefs
from 'struct cpuinfo_x86'") removed a bunch of CONFIG_SMP ifdefs
around code touching struct cpuinfo_x86 members but also caused
the following build error with Randy's randconfigs:

mce_amd.c:(.cpuinit.text+0x4723): undefined reference to `cpu_llc_shared_map'

Restore the #ifdef in threshold_create_bank() which creates
symlinks on the non-BSP CPUs.

There's a better patch series being worked on by Kevin Winchester
which will solve this in a cleaner fashion, but that series is
too ambitious for v3.3 merging - so we first queue up this trivial
fix and then do the rest for v3.4.

Signed-off-by: Borislav Petkov &lt;bp@alien8.de&gt;
Acked-by: Kevin Winchester &lt;kjwinchester@gmail.com&gt;
Cc: Randy Dunlap &lt;rdunlap@xenotime.net&gt;
Cc: Nick Bowler &lt;nbowler@elliptictech.com&gt;
Link: http://lkml.kernel.org/r/20120203191801.GA2846@x1.osrc.amd.com
Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
</pre>
</div>
</content>
</entry>
</feed>
