linux-stable.git/arch/x86/kernel, branch v4.2

x86/apic: Fix fallout from x2apic cleanup

2015-08-22T15:01:48+00:00

In the recent x2apic cleanup I got two things really wrong:
1) The safety check in __disable_x2apic which allows the function to
   be called unconditionally is backwards. The check is there to
   prevent access to the apic MSR in case that the machine has no
   apic. Though right now it returns if the machine has an apic and
   therefor the disabling of x2apic is never invoked.

2) x2apic_disable() sets x2apic_mode to 0 after registering the local
   apic. That's wrong, because register_lapic_address() checks x2apic
   mode and therefor takes the wrong code path.

This results in boot failures on machines with x2apic preenabled by
BIOS and can also lead to an fatal MSR access on machines without
apic.

The solutions are simple:
1) Correct the sanity check for apic availability
2) Clear x2apic_mode _before_ calling register_lapic_address()

Fixes: 659006bf3ae3 'x86/x2apic: Split enable and setup function'
Reported-and-tested-by: Javier Monteagudo 
Signed-off-by: Thomas Gleixner 
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1224764
Cc: stable@vger.kernel.org # 4.0+
Cc: Laura Abbott 
Cc: Jiang Liu 
Cc: Joerg Roedel 
Cc: Tony Luck 
Cc: Borislav Petkov

x86/fpu/math-emu: Fix crash in fork()

2015-08-22T08:23:03+00:00

During later stages of math-emu bootup the following crash triggers:

	 math_emulate: 0060:c100d0a8
	 Kernel panic - not syncing: Math emulation needed in kernel
	 CPU: 0 PID: 1511 Comm: login Not tainted 4.2.0-rc7+ #1012
	 [...]
	 Call Trace:
	  [] dump_stack+0x41/0x52
	  [] panic+0x77/0x189
	  [] ? math_error+0x140/0x140
	  [] math_emulate+0xba7/0xbd0
	  [] ? fpu__copy+0x138/0x1c0
	  [] ? __alloc_pages_nodemask+0x12c/0x870
	  [] ? proc_clear_tty+0x40/0x70
	  [] ? session_clear_tty+0x1e/0x30
	  [] ? math_error+0x140/0x140
	  [] do_device_not_available+0x45/0x70
	  [] ? fpu__copy+0x138/0x1c0
	  [] error_code+0x5a/0x60
	  [] ? math_error+0x140/0x140
	  [] ? fpu__copy+0x138/0x1c0
	  [] arch_dup_task_struct+0x25/0x30
	  [] copy_process.part.51+0xea/0x1480
	  [] ? dput+0x175/0x200
	  [] ? no_tty+0x30/0x30
	  [] ? do_vfs_ioctl+0x322/0x540
	  [] _do_fork+0xca/0x340
	  [] ? SyS_rt_sigaction+0x66/0x90
	  [] SyS_clone+0x27/0x30
	  [] sysenter_do_call+0x12/0x12

The reason is the incorrect assumption in fpu_copy(), that FNSAVE
can be executed from math-emu kernels as well.

Don't try to copy the registers, the soft state will be copied
by fork anyway, so the child task inherits the parent task's
soft math state.

With this fix applied math-emu kernels boot up fine on modern
hardware and the 'no387 nofxsr' boot options.

Cc: Andy Lutomirski 
Cc: Bobby Powers 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Dave Hansen 
Cc: Denys Vlasenko 
Cc: Fenghua Yu 
Cc: H. Peter Anvin 
Cc: Linus Torvalds 
Cc: Oleg Nesterov 
Cc: Peter Zijlstra 
Cc: Quentin Casasnovas 
Cc: Thomas Gleixner 
Signed-off-by: Ingo Molnar

x86/fpu/math-emu: Fix math-emu boot crash

2015-08-22T08:02:04+00:00

On a math-emu bootup the following crash occurs:

	Initializing CPU#0
	------------[ cut here ]------------
	kernel BUG at arch/x86/kernel/traps.c:779!
	invalid opcode: 0000 [#1] SMP
	[...]
	EIP is at do_device_not_available+0xe/0x70
	[...]
	Call Trace:
	 [] error_code+0x5a/0x60
	 [] ? math_error+0x140/0x140
	 [] ? fpu__init_cpu+0x59/0xa0
	 [] cpu_init+0x202/0x330
	 [] ? __native_set_fixmap+0x1f/0x30
	 [] trap_init+0x305/0x346
	 [] start_kernel+0x1a5/0x35d
	 [] i386_start_kernel+0x82/0x86

The reason is that in the following commit:

  b1276c48e91b ("x86/fpu: Initialize fpregs in fpu__init_cpu_generic()")

I failed to consider math-emu's limitation that it cannot execute the
FNINIT instruction in kernel mode.

The long term fix might be to allow math-emu to execute (certain) kernel
mode FPU instructions, but for now apply the safe (albeit somewhat ugly)
fix: initialize the emulation state explicitly without trapping out to
the FPU emulator.

Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Dave Hansen 
Cc: Denys Vlasenko 
Cc: Fenghua Yu 
Cc: H. Peter Anvin 
Cc: Linus Torvalds 
Cc: Oleg Nesterov 
Cc: Peter Zijlstra 
Cc: Quentin Casasnovas 
Cc: Thomas Gleixner 
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar

x86/idle: Restore trace_cpu_idle to mwait_idle() calls

2015-08-20T19:37:45+00:00

Commit b253149b843f ("sched/idle/x86: Restore mwait_idle() to fix boot
hangs, to improve power savings and to improve performance") restores
mwait_idle(), but the trace_cpu_idle related calls are missing. This
causes powertop on my old desktop powered by Intel Core2 E6550 to
report zero wakeups and zero events.

Add them back to restore the proper behaviour.

Fixes: b253149b843f ("sched/idle/x86: Restore mwait_idle() to ...")
Signed-off-by: Jisheng Zhang 
Cc: 
Cc: stable@vger.kernel.org # 4.1
Link: http://lkml.kernel.org/r/1440046479-4262-1-git-send-email-jszhang@marvell.com
Signed-off-by: Thomas Gleixner

x86/irq: Build correct vector mapping for multiple MSI interrupts

2015-08-18T16:18:55+00:00

Alex Deucher, Mark Rustad and Alexander Holler reported a regression
with the latest v4.2-rc4 kernel, which breaks some SATA controllers.
With multi-MSI capable SATA controllers, only the first port works,
all other ports time out when executing SATA commands.

This happens because the first argument to assign_irq_vector_policy()
is always the base linux irq number of the multi MSI interrupt block,
so all subsequent vector assignments operate on the base linux irq
number, so all MSI irqs are handled as the first irq number. Therefor
the other MSI irqs of a device are never set up correctly and never
fire.

Add the loop iterator to the base irq number so all vectors are
assigned correctly.

Fixes: b5dc8e6c21e7 "x86/irq: Use hierarchical irqdomain to manage CPU interrupt vectors"
Reported-and-tested-by: Alex Deucher 
Reported-and-tested-by: Mark Rustad 
Reported-and-tested-by: Alexander Holler 
Signed-off-by: Jiang Liu 
Cc: Tony Luck 
Link: http://lkml.kernel.org/r/1439911228-9880-1-git-send-email-jiang.liu@linux.intel.com
Signed-off-by: Thomas Gleixner

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

2015-08-16T22:11:25+00:00

Merge x86 fixes from Ingo Molnar:
 "Two followup fixes related to the previous LDT fix"

Also applied a further FPU emulation fix from Andy Lutomirski to the
branch before actually merging it.

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
  x86/ldt: Further fix FPU emulation
  x86/ldt: Correct FPU emulation access to LDT
  x86/ldt: Correct LDT access in single stepping logic

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

2015-08-14T17:57:16+00:00

Pull perf fixes from Ingo Molnar:
 "Misc fixes: PMU driver corner cases, tooling fixes, and an 'AUX'
  (Intel PT) race related core fix"

* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  perf/x86/intel/cqm: Do not access cpu_data() from CPU_UP_PREPARE handler
  perf/x86/intel: Fix memory leak on hot-plug allocation fail
  perf: Fix PERF_EVENT_IOC_PERIOD migration race
  perf: Fix double-free of the AUX buffer
  perf: Fix fasync handling on inherited events
  perf tools: Fix test build error when bindir contains double slash
  perf stat: Fix transaction lenght metrics
  perf: Fix running time accounting

Revert x86 sigcontext cleanups

2015-08-13T19:42:22+00:00

This reverts commits 9a036b93a344 ("x86/signal/64: Remove 'fs' and 'gs'
from sigcontext") and c6f2062935c8 ("x86/signal/64: Fix SS handling for
signals delivered to 64-bit programs").

They were cleanups, but they break dosemu by changing the signal return
behavior (and removing 'fs' and 'gs' from the sigcontext struct - while
not actually changing any behavior - causes build problems).

Reported-and-tested-by: Stas Sergeev 
Acked-by: Andy Lutomirski 
Cc: Ingo Molnar 
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds

perf/x86/intel/cqm: Do not access cpu_data() from CPU_UP_PREPARE handler

2015-08-12T09:37:23+00:00

Tony reports that booting his 144-cpu machine with maxcpus=10 triggers
the following WARN_ON():

[   21.045727] WARNING: CPU: 8 PID: 647 at arch/x86/kernel/cpu/perf_event_intel_cqm.c:1267 intel_cqm_cpu_prepare+0x75/0x90()
[   21.045744] CPU: 8 PID: 647 Comm: systemd-udevd Not tainted 4.2.0-rc4 #1
[   21.045745] Hardware name: Intel Corporation BRICKLAND/BRICKLAND, BIOS BRHSXSD1.86B.0066.R00.1506021730 06/02/2015
[   21.045747]  0000000000000000 0000000082771b09 ffff880856333ba8 ffffffff81669b67
[   21.045748]  0000000000000000 0000000000000000 ffff880856333be8 ffffffff8107b02a
[   21.045750]  ffff88085b789800 ffff88085f68a020 ffffffff819e2470 000000000000000a
[   21.045750] Call Trace:
[   21.045757]  [] dump_stack+0x45/0x57
[   21.045759]  [] warn_slowpath_common+0x8a/0xc0
[   21.045761]  [] warn_slowpath_null+0x1a/0x20
[   21.045762]  [] intel_cqm_cpu_prepare+0x75/0x90
[   21.045764]  [] intel_cqm_cpu_notifier+0x42/0x160
[   21.045767]  [] notifier_call_chain+0x4d/0x80
[   21.045769]  [] __raw_notifier_call_chain+0xe/0x10
[   21.045770]  [] _cpu_up+0xe8/0x190
[   21.045771]  [] cpu_up+0x7a/0xa0
[   21.045774]  [] cpu_subsys_online+0x40/0x90
[   21.045777]  [] device_online+0x67/0x90
[   21.045778]  [] online_store+0x8a/0xa0
[   21.045782]  [] dev_attr_store+0x18/0x30
[   21.045785]  [] sysfs_kf_write+0x3a/0x50
[   21.045786]  [] kernfs_fop_write+0x120/0x170
[   21.045789]  [] __vfs_write+0x37/0x100
[   21.045791]  [] ? __sb_start_write+0x58/0x110
[   21.045795]  [] ? security_file_permission+0x3d/0xc0
[   21.045796]  [] vfs_write+0xa9/0x190
[   21.045797]  [] SyS_write+0x55/0xc0
[   21.045800]  [] ? do_page_fault+0x30/0x80
[   21.045804]  [] entry_SYSCALL_64_fastpath+0x12/0x71
[   21.045805] ---[ end trace fe228b836d8af405 ]---

The root cause is that CPU_UP_PREPARE is completely the wrong notifier
action from which to access cpu_data(), because smp_store_cpu_info()
won't have been executed by the target CPU at that point, which in turn
means that ->x86_cache_max_rmid and ->x86_cache_occ_scale haven't been
filled out.

Instead let's invoke our handler from CPU_STARTING and rename it
appropriately.

Reported-by: Tony Luck 
Signed-off-by: Matt Fleming 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: Ashok Raj 
Cc: Kanaka Juvva 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Vikas Shivappa 
Link: http://lkml.kernel.org/r/1438863163-14083-1-git-send-email-matt@codeblueprint.co.uk
Signed-off-by: Ingo Molnar

perf/x86/intel: Fix memory leak on hot-plug allocation fail

2015-08-12T09:37:22+00:00

We fail to free the shared_regs allocation if the constraint_list
allocation fails.

Cure this and be more consistent in NULL-ing the pointers after free.

Signed-off-by: Peter Zijlstra (Intel) 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Cc: Thomas Gleixner 
Signed-off-by: Ingo Molnar