linux/arch, branch v3.12

Merge branch 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus

2013-11-03T19:36:41Z

Pull MIPS fixes from Ralf Baechle: "Three fixes across arch/mips with the most complex one being the GIC interrupt fix - at nine lines still not monster. I'm confident this are the final MIPS patches even if there should go for an rc8" * 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus: MIPS: ralink: fix return value check in rt_timer_probe() MIPS: malta: Fix GIC interrupt offsets MIPS: Perf: Fix 74K cache map

ARC: Incorrect mm reference used in vmalloc fault handler

2013-11-02T17:27:04Z

A vmalloc fault needs to sync up PGD/PTE entry from init_mm to current task's "active_mm". ARC vmalloc fault handler however was using mm. A vmalloc fault for non user task context (actually pre-userland, from init thread's open for /dev/console) caused the handler to deref NULL mm (for mm->pgd) The reasons it worked so far is amazing: 1. By default (!SMP), vmalloc fault handler uses a cached value of PGD. In SMP that MMU register is repurposed hence need for mm pointer deref. 2. In pre-3.12 SMP kernel, the problem triggering vmalloc didn't exist in pre-userland code path - it was introduced with commit 20bafb3d23d108bc "n_tty: Move buffers into n_tty_data" Signed-off-by: Vineet Gupta Cc: Gilad Ben-Yossef Cc: Noam Camus Cc: stable@vger.kernel.org #3.10 and 3.11 Cc: Peter Hurley Signed-off-by: Linus Torvalds

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

2013-11-01T19:54:51Z

Pull perf fixes from Ingo Molnar: "Two fixes: - Fix 'NMI handler took too long to run' false positives [ Genuine NMI overhead speedups will come for v3.13, this commit only fixes a measurement bug ] - Fix perf ring-buffer missed barrier causing (rare) ring-buffer data corruption on ppc64" * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf/x86: Fix NMI measurements perf: Fix perf ring buffer memory ordering

MIPS: ralink: fix return value check in rt_timer_probe()

2013-10-31T11:38:34Z

In case of error, the function devm_request_and_ioremap() returns NULL pointer not ERR_PTR(). Fix it by using devm_ioremap_resource() instead of devm_request_and_ioremap(). Signed-off-by: Wei Yongjun Acked-by: John Crispin Cc: grant.likely@linaro.org Cc: rob.herring@calxeda.com Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/6098/ Signed-off-by: Ralf Baechle

Merge branch 'akpm' (fixes from Andrew Morton)

2013-10-30T21:27:10Z

Merge three fixes from Andrew Morton. * emailed patches from Andrew Morton : memcg: use __this_cpu_sub() to dec stats to avoid incorrect subtrahend casting percpu: fix this_cpu_sub() subtrahend casting for unsigneds mm/pagewalk.c: fix walk_page_range() access of wrong PTEs

percpu: fix this_cpu_sub() subtrahend casting for unsigneds

2013-10-30T21:27:03Z

this_cpu_sub() is implemented as negation and addition. This patch casts the adjustment to the counter type before negation to sign extend the adjustment. This helps in cases where the counter type is wider than an unsigned adjustment. An alternative to this patch is to declare such operations unsupported, but it seemed useful to avoid surprises. This patch specifically helps the following example: unsigned int delta = 1 preempt_disable() this_cpu_write(long_counter, 0) this_cpu_sub(long_counter, delta) preempt_enable() Before this change long_counter on a 64 bit machine ends with value 0xffffffff, rather than 0xffffffffffffffff. This is because this_cpu_sub(pcp, delta) boils down to this_cpu_add(pcp, -delta), which is basically: long_counter = 0 + 0xffffffff Also apply the same cast to: __this_cpu_sub() __this_cpu_sub_return() this_cpu_sub_return() All percpu_test.ko passes, especially the following cases which previously failed: l -= ui_one; __this_cpu_sub(long_counter, ui_one); CHECK(l, long_counter, -1); l -= ui_one; this_cpu_sub(long_counter, ui_one); CHECK(l, long_counter, -1); CHECK(l, long_counter, 0xffffffffffffffff); ul -= ui_one; __this_cpu_sub(ulong_counter, ui_one); CHECK(ul, ulong_counter, -1); CHECK(ul, ulong_counter, 0xffffffffffffffff); ul = this_cpu_sub_return(ulong_counter, ui_one); CHECK(ul, ulong_counter, 2); ul = __this_cpu_sub_return(ulong_counter, ui_one); CHECK(ul, ulong_counter, 1); Signed-off-by: Greg Thelen Acked-by: Tejun Heo Acked-by: Johannes Weiner Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm

2013-10-30T19:25:15Z

Pull KVM fixes from Paolo Bonzini: "Fixes for the 3.12 debugfs problem - removing the duplicate directory name, and using a better the error code" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: KVM: use a more sensible error number when debugfs directory creation fails KVM: Fix modprobe failure for kvm_intel/kvm_amd

uml: check length in exitcode_proc_write()

2013-10-30T19:24:49Z

We don't cap the size of buffer from the user so we could write past the end of the array here. Only root can write to this file. Reported-by: Nico Golde Reported-by: Fabian Yamaguchi Signed-off-by: Dan Carpenter Cc: stable@kernel.org Signed-off-by: Linus Torvalds

MIPS: malta: Fix GIC interrupt offsets

2013-10-30T14:43:18Z

The GIC interrupt offsets are calculated based on the value of NR_CPUS. However, this is wrong because NR_CPUS may or may not contain the real number of the actual cpus present in the system. We fix that by using the 'nr_cpu_ids' variable which contains the real number of cpus in the system. Previously, an MT core (eg with 8 VPEs) will fail to boot if NR_CPUS was > 8 with the following errors: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at kernel/irq/chip.c:670 __irq_set_handler+0x15c/0x164() Modules linked in: CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 3.12.0-rc5-00087-gced5633 5 Stack : 00000006 00000004 00000000 00000000 00000000 00000000 807a4f36 00000053 807a0000 00000000 80173218 80565aa8 00000000 00000000 00000000 0000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0000000 00000000 00000000 00000000 8054fd00 8054fd94 80500514 805657a7 8016eb4 807a0000 80500514 00000000 00000000 80565aa8 8079a5d8 80565766 8054fd0 ... Call Trace: [<801098c0>] show_stack+0x64/0x7c [<8049c6b0>] dump_stack+0x64/0x84 [<8012efc4>] warn_slowpath_common+0x84/0xb4 [<8012f00c>] warn_slowpath_null+0x18/0x24 [<80173218>] __irq_set_handler+0x15c/0x164 [<80587cf4>] arch_init_ipiirq+0x2c/0x3c [<805880c8>] arch_init_irq+0x3c4/0x4bc [<80588e28>] init_IRQ+0x3c/0x50 [<805847e8>] start_kernel+0x230/0x3d8 ---[ end trace 4eaa2a86a8e2da26 ]--- This is now fixed and the Malta board can boot with any NR_CPUS value which also helps supporting more processors in a single kernel binary. Signed-off-by: Markos Chandras Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/6091/ Signed-off-by: Ralf Baechle

KVM: Fix modprobe failure for kvm_intel/kvm_amd

2013-10-30T11:10:42Z

The x86 specific kvm init creates a new conflicting debugfs directory which causes modprobe issues with kvm_intel and kvm_amd. For example, sudo modprobe kvm_amd modprobe: ERROR: could not insert 'kvm_amd': Bad address The simplest fix is to just rename the directory. The following KVM config options are set: CONFIG_KVM_GUEST=y CONFIG_KVM_DEBUG_FS=y CONFIG_HAVE_KVM=y CONFIG_HAVE_KVM_IRQCHIP=y CONFIG_HAVE_KVM_IRQ_ROUTING=y CONFIG_HAVE_KVM_EVENTFD=y CONFIG_KVM_APIC_ARCHITECTURE=y CONFIG_KVM_MMIO=y CONFIG_KVM_ASYNC_PF=y CONFIG_HAVE_KVM_MSI=y CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT=y CONFIG_KVM=m CONFIG_KVM_INTEL=m CONFIG_KVM_AMD=m CONFIG_KVM_DEVICE_ASSIGNMENT=y Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: Gleb Natapov Cc: Raghavendra K T Cc: Marcelo Tosatti Signed-off-by: Tim Gardner [Change debugfs directory name. - Paolo] Signed-off-by: Paolo Bonzini