linux-toradex.git/arch/x86/kernel/cpu/mcheck, branch v3.4.68

x86/mce: Fix siginfo_t->si_addr value for non-recoverable memory faults

2012-08-09T15:31:29+00:00

commit 6751ed65dc6642af64f7b8a440a75563c8aab7ae upstream.

In commit dad1743e5993f1 ("x86/mce: Only restart instruction after machine
check recovery if it is safe") we fixed mce_notify_process() to force a
signal to the current process if it was not restartable (RIPV bit not
set in MCG_STATUS). But doing it here means that the process doesn't
get told the virtual address of the fault via siginfo_t->si_addr. This
would prevent application level recovery from the fault.

Make a new MF_MUST_KILL flag bit for memory_failure() et al. to use so
that we will provide the right information with the signal.

Signed-off-by: Tony Luck 
Acked-by: Borislav Petkov 
Signed-off-by: Greg Kroah-Hartman

x86, MCE, AMD: Make APIC LVT thresholding interrupt optional

2012-06-17T18:21:23+00:00

commit f227d4306cf30e1d5b6f231e8ef9006c34f3d186 upstream.

Currently, the APIC LVT interrupt for error thresholding is implicitly
enabled. However, there are models in the F15h range which do not enable
it. Make the code machinery which sets up the APIC interrupt support
an optional setting and add an ->interrupt_capable member to the bank
representation mirroring that capability and enable the interrupt offset
programming only if it is true.

Simplify code and fixup comment style while at it.

Signed-off-by: Borislav Petkov 
Cc: Robert Richter 
Signed-off-by: Greg Kroah-Hartman

MCE: Fix vm86 handling for 32bit mce handler

2012-06-01T07:18:28+00:00

commit a129a7c84582629741e5fa6f40026efcd7a65bd4 upstream.

When running on 32bit the mce handler could misinterpret
vm86 mode as ring 0. This can affect whether it does recovery
or not; it was possible to panic when recovery was actually
possible.

Fix this by always forcing vm86 to look like ring 3.

Signed-off-by: Andi Kleen 
Signed-off-by: Tony Luck 
Signed-off-by: Greg Kroah-Hartman

x86/mce: Fix check for processor context when machine check was taken.

2012-06-01T07:18:26+00:00

commit 875e26648cf9b6db9d8dc07b7959d7c61fb3f49c upstream.

Linus pointed out that there was no value is checking whether m->ip
was zero - because zero is a legimate value.  If we have a reliable
(or faked in the VM86 case) "m->cs" we can use it to tell whether we
were in user mode or kernelwhen the machine check hit.

Reported-by: Linus Torvalds 
Signed-off-by: Tony Luck 
Signed-off-by: Greg Kroah-Hartman

x86/mce: Only restart instruction after machine check recovery if it is safe

2012-05-14T22:07:48+00:00

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 
Signed-off-by: Tony Luck

Disintegrate asm/system.h for X86

2012-03-28T17:11:12+00:00

Disintegrate asm/system.h for X86.

Signed-off-by: David Howells 
Acked-by: H. Peter Anvin 
cc: x86@kernel.org

Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2012-03-22T16:44:50+00:00

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

Merge tag 'mce-for-tip' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras into x86/mce

2012-03-14T06:44:48+00:00

Apply two miscellaneous MCE fixes.

Signed-off-by: Ingo Molnar

Merge tag 'v3.3-rc7' into x86/mce

2012-03-14T06:44:11+00:00

Merge reason: Update from an ancient -rc1 base to an almost-final stable kernel.

Signed-off-by: Ingo Molnar

x86, mce: Fix rcu splat in drain_mce_log_buffer()

2012-03-07T10:44:29+00:00

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:  (&__lockdep_no_validate__){......}, at: [] __driver_attach+0x53/0xa0
[   21.725020]  #1:
[   21.725323] ioatdma: Intel(R) QuickData Technology Driver 4.00
[   21.733206]  (&__lockdep_no_validate__){......}, at: [] __driver_attach+0x61/0xa0
[   21.743015]  #2:  (i7core_edac_lock){+.+.+.}, at: [] 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]  [] lockdep_rcu_suspicious+0xcd/0x100
[   21.777366]  [] drain_mcelog_buffer+0x191/0x1b0
[   21.783715]  [] mce_register_decode_chain+0x18/0x20
[   21.790430]  [] i7core_register_mci+0x2fb/0x3e4 [i7core_edac]
[   21.798003]  [] i7core_probe+0xd4/0x5c0 [i7core_edac]
[   21.804809]  [] local_pci_probe+0x5b/0xe0
[   21.810631]  [] __pci_device_probe+0xd9/0xe0
[   21.816650]  [] ? get_device+0x14/0x20
[   21.822178]  [] pci_device_probe+0x36/0x60
[   21.828061]  [] really_probe+0x7a/0x2b0
[   21.833676]  [] driver_probe_device+0x63/0xc0
[   21.839868]  [] __driver_attach+0x9b/0xa0
[   21.845718]  [] ? driver_probe_device+0xc0/0xc0
[   21.852027]  [] bus_for_each_dev+0x68/0x90
[   21.857876]  [] driver_attach+0x1c/0x20
[   21.863462]  [] bus_add_driver+0x16d/0x2b0
[   21.869377]  [] driver_register+0x7c/0x160
[   21.875220]  [] __pci_register_driver+0x6a/0xf0
[   21.881494]  [] ? 0xffffffffa01fdfff
[   21.886846]  [] i7core_init+0x47/0x1000 [i7core_edac]
[   21.893737]  [] do_one_initcall+0x3e/0x180
[   21.899670]  [] sys_init_module+0xc5/0x220
[   21.905542]  [] 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
->finished field, ACCESS_ONCE() should work just fine. An rcu_dereference
is unnecessary here.

Signed-off-by: Srivatsa S. Bhat 
Suggested-by: Paul E. McKenney 
Cc: Tony Luck 
Signed-off-by: Borislav Petkov