linux-stable.git, branch v4.1.4

Linux 4.1.4

2015-08-03T16:30:08+00:00

x86/mpx: Do not set ->vm_ops on MPX VMAs

2015-08-03T16:29:19+00:00

commit a89652769470d12cd484ee3d3f7bde0742be8d96 upstream.

MPX setups private anonymous mapping, but uses vma->vm_ops too.
This can confuse core VM, as it relies on vm->vm_ops to
distinguish file VMAs from anonymous.

As result we will get SIGBUS, because handle_pte_fault() thinks
it's file VMA without vm_ops->fault and it doesn't know how to
handle the situation properly.

Let's fix that by not setting ->vm_ops.

We don't really need ->vm_ops here: MPX VMA can be detected with
VM_MPX flag. And vma_merge() will not merge MPX VMA with non-MPX
VMA, because ->vm_flags won't match.

The only thing left is name of VMA. I'm not sure if it's part of
ABI, or we can just drop it. The patch keep it by providing
arch_vma_name() on x86.

Signed-off-by: Kirill A. Shutemov 
Signed-off-by: Dave Hansen 
Cc: Andy Lutomirski 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: dave@sr71.net
Link: http://lkml.kernel.org/r/20150720212958.305CC3E9@viggo.jf.intel.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

mm: avoid setting up anonymous pages into file mapping

2015-08-03T16:29:19+00:00

commit 6b7339f4c31ad69c8e9c0b2859276e22cf72176d upstream.

Reading page fault handler code I've noticed that under right
circumstances kernel would map anonymous pages into file mappings: if
the VMA doesn't have vm_ops->fault() and the VMA wasn't fully populated
on ->mmap(), kernel would handle page fault to not populated pte with
do_anonymous_page().

Let's change page fault handler to use do_anonymous_page() only on
anonymous VMA (->vm_ops == NULL) and make sure that the VMA is not
shared.

For file mappings without vm_ops->fault() or shred VMA without vm_ops,
page fault on pte_none() entry would lead to SIGBUS.

Signed-off-by: Kirill A. Shutemov 
Acked-by: Oleg Nesterov 
Cc: Andrew Morton 
Cc: Willy Tarreau 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

Fix firmware loader uevent buffer NULL pointer dereference

2015-08-03T16:29:19+00:00

commit 6f957724b94cb19f5c1c97efd01dd4df8ced323c upstream.

The firmware class uevent function accessed the "fw_priv->buf" buffer
without the proper locking and testing for NULL.  This is an old bug
(looks like it goes back to 2012 and commit 1244691c73b2: "firmware
loader: introduce firmware_buf"), but for some reason it's triggering
only now in 4.2-rc1.

Shuah Khan is trying to bisect what it is that causes this to trigger
more easily, but in the meantime let's just fix the bug since others are
hitting it too (at least Ingo reports having seen it as well).

Reported-and-tested-by: Shuah Khan 
Acked-by: Ming Lei 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

hpfs: hpfs_error: Remove static buffer, use vsprintf extension %pV instead

2015-08-03T16:29:19+00:00

commit a28e4b2b18ccb90df402da3f21e1a83c9d4f8ec1 upstream.

Removing unnecessary static buffers is good.
Use the vsprintf %pV extension instead.

Signed-off-by: Joe Perches 
Signed-off-by: Mikulas Patocka 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

hpfs: kstrdup() out of memory handling

2015-08-03T16:29:19+00:00

commit ce657611baf902f14ae559ce4e0787ead6712067 upstream.

There is a possibility of nothing being allocated to the new_opts in
case of memory pressure, therefore return ENOMEM for such case.

Signed-off-by: Sanidhya Kashyap 
Signed-off-by: Mikulas Patocka 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

ARM: 8397/1: fix vdsomunge not to depend on glibc specific error.h

2015-08-03T16:29:19+00:00

commit 13ee9fdba96577eb1583dcd7b15767ef623fae12 upstream.

If the host toolchain is not glibc based then the arm kernel build
fails with

 arch/arm/vdso/vdsomunge.c:53:19: fatal error: error.h: No such file or directory

error.h is a glibc only header (ie not available in musl, newlib and
bsd libcs).  Changed the error reporting to standard conforming code
to avoid depending on specific C implementations.

Signed-off-by: Szabolcs Nagy 
Acked-by: Will Deacon 
Fixes: 8512287a8165 ("ARM: 8330/1: add VDSO user-space code")
Signed-off-by: Nathan Lynch 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: 8393/1: smp: Fix suspicious RCU usage with ipi tracepoints

2015-08-03T16:29:19+00:00

commit 398f74569cebbf06bc6b069442bcd0e9616ca465 upstream.

John Stultz reports an RCU splat on boot with ARM ipi trace
events enabled.

===============================
[ INFO: suspicious RCU usage. ]
4.1.0-rc7-00033-gb5bed2f #153 Not tainted
-------------------------------
include/trace/events/ipi.h:68 suspicious rcu_dereference_check() usage!

other info that might help us debug this:

RCU used illegally from idle CPU!
rcu_scheduler_active = 1, debug_locks = 0
RCU used illegally from extended quiescent state!
no locks held by swapper/0/0.

stack backtrace:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.1.0-rc7-00033-gb5bed2f #153
Hardware name: Qualcomm (Flattened Device Tree)
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0x70/0xbc)
[] (dump_stack) from [] (handle_IPI+0x428/0x604)
[] (handle_IPI) from [] (gic_handle_irq+0x54/0x5c)
[] (gic_handle_irq) from [] (__irq_svc+0x44/0x7c)
Exception stack(0xc09f3f48 to 0xc09f3f90)
3f40:                   00000001 00000001 00000000 c09f73b8 c09f4528 c0a5de9c
3f60: c076b4f0 00000000 00000000 c09ef108 c0a5cec1 00000001 00000000 c09f3f90
3f80: c026bf60 c0210ab8 20000113 ffffffff
[] (__irq_svc) from [] (arch_cpu_idle+0x20/0x3c)
[] (arch_cpu_idle) from [] (cpu_startup_entry+0x2c0/0x5dc)
[] (cpu_startup_entry) from [] (start_kernel+0x358/0x3c4)
[] (start_kernel) from [<8020807c>] (0x8020807c)

At this point in the IPI handling path we haven't called
irq_enter() yet, so RCU doesn't know that we're about to exit
idle and properly warns that we're using RCU from an idle CPU.
Use trace_ipi_entry_rcuidle() instead of trace_ipi_entry() so
that RCU is informed about our exit from idle.

Fixes: 365ec7b17327 ("ARM: add IPI tracepoints")
Reported-by: John Stultz 
Tested-by: John Stultz 
Acked-by: Steven Rostedt 
Reviewed-by: Paul E. McKenney 
Signed-off-by: Stephen Boyd 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

perf bench numa: Fix to show proper convergence stats

2015-08-03T16:29:18+00:00

commit 2b42b09b88c831ba4da2d669581dde371c38c2af upstream.

With commit: e1e455f4f4d3 (perf tools: Work around lack of sched_getcpu
in glibc < 2.6), perf_bench numa mem with -c or -m option is not able to
correctly calculate convergence.

With the above commit, sched_getcpu always seems to return -1. The
intention of commit e1e455f was to add a sched_getcpu in glibc < 2.6.
Hence keep the sched_getcpu definition under an ifdef.

This regression happened occurred between v4.0 and v4.1

Signed-off-by: Srikar Dronamraju 
Acked-by: Ingo Molnar 
Cc: Jiri Olsa 
Cc: Masami Hiramatsu 
Cc: Namhyung Kim 
Cc: Vinson Lee 
Fixes:  e1e455f4f4d3 ("perf tools: Work around lack of sched_getcpu in glibc < 2.6")
Link: http://lkml.kernel.org/r/20150624111004.GA5220@linux.vnet.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Greg Kroah-Hartman

arm64: Don't report clear pmds and puds as huge

2015-08-03T16:29:18+00:00

commit fd28f5d439fca77348c129d5b73043a56f8a0296 upstream.

The current pmd_huge() and pud_huge() functions simply check if the table
bit is not set and reports the entries as huge in that case.  This is
counter-intuitive as a clear pmd/pud cannot also be a huge pmd/pud, and
it is inconsistent with at least arm and x86.

To prevent others from making the same mistake as me in looking at code
that calls these functions and to fix an issue with KVM on arm64 that
causes memory corruption due to incorrect page reference counting
resulting from this mistake, let's change the behavior.

Signed-off-by: Christoffer Dall 
Reviewed-by: Steve Capper 
Acked-by: Marc Zyngier 
Fixes: 084bd29810a5 ("ARM64: mm: HugeTLB support.")
Signed-off-by: Catalin Marinas 
Signed-off-by: Greg Kroah-Hartman