linux-stable.git/arch, branch v3.18.34

parisc: fix a bug when syscall number of tracee is __NR_Linux_syscalls

2016-05-18T01:48:06+00:00

[ Upstream commit f0b22d1bb2a37a665a969e95785c75a4f49d1499 ]

Do not load one entry beyond the end of the syscall table when the
syscall number of a traced process equals to __NR_Linux_syscalls.
Similar bug with regular processes was fixed by commit 3bb457af4fa8
("[PARISC] Fix bug when syscall nr is __NR_Linux_syscalls").

This bug was found by strace test suite.

Cc: stable@vger.kernel.org
Signed-off-by: Dmitry V. Levin 
Acked-by: Helge Deller 
Signed-off-by: Helge Deller 
Signed-off-by: Sasha Levin

parisc: Fix ptrace syscall number and return value modification

2016-05-18T01:47:58+00:00

[ Upstream commit 98e8b6c9ac9d1b1e9d1122dfa6783d5d566bb8f7 ]

Mike Frysinger reported that his ptrace testcase showed strange
behaviour on parisc: It was not possible to avoid a syscall and the
return value of a syscall couldn't be changed.

To modify a syscall number, we were missing to save the new syscall
number to gr20 which is then picked up later in assembly again.

The effect that the return value couldn't be changed is a side-effect of
another bug in the assembly code. When a process is ptraced, userspace
expects each syscall to report entrance and exit of a syscall.  If a
syscall number was given which doesn't exist, we jumped to the normal
syscall exit code instead of informing userspace that the (non-existant)
syscall exits. This unexpected behaviour confuses userspace and thus the
bug was misinterpreted as if we can't change the return value.

This patch fixes both problems and was tested on 64bit kernel with
32bit userspace.

Signed-off-by: Helge Deller 
Cc: Mike Frysinger 
Cc: stable@vger.kernel.org  # v4.0+
Tested-by: Mike Frysinger 
Signed-off-by: Sasha Levin

x86/tsc: Read all ratio bits from MSR_PLATFORM_INFO

2016-05-18T00:11:13+00:00

[ Upstream commit 886123fb3a8656699dff40afa0573df359abeb18 ]

Currently we read the tsc radio: ratio = (MSR_PLATFORM_INFO >> 8) & 0x1f;

Thus we get bit 8-12 of MSR_PLATFORM_INFO, however according to the SDM
(35.5), the ratio bits are bit 8-15.

Ignoring the upper bits can result in an incorrect tsc ratio, which causes the
TSC calibration and the Local APIC timer frequency to be incorrect.

Fix this problem by masking 0xff instead.

[ tglx: Massaged changelog ]

Fixes: 7da7c1561366 "x86, tsc: Add static (MSR) TSC calibration on Intel Atom SoCs"
Signed-off-by: Chen Yu 
Cc: "Rafael J. Wysocki" 
Cc: stable@vger.kernel.org
Cc: Bin Gao 
Cc: Len Brown 
Link: http://lkml.kernel.org/r/1462505619-5516-1-git-send-email-yu.c.chen@intel.com
Signed-off-by: Thomas Gleixner 
Signed-off-by: Sasha Levin

x86/sysfb_efi: Fix valid BAR address range check

2016-05-17T21:30:26+00:00

[ Upstream commit c10fcb14c7afd6688c7b197a814358fecf244222 ]

The code for checking whether a BAR address range is valid will break
out of the loop when a start address of 0x0 is encountered.

This behaviour is wrong since by breaking out of the loop we may miss
the BAR that describes the EFI frame buffer in a later iteration.

Because of this bug I can't use video=efifb: boot parameter to get
efifb on my new ThinkPad E550 for my old linux system hard disk with
3.10 kernel. In 3.10, efifb is the only choice due to DRM/I915 not
supporting the GPU.

This patch also add a trivial optimization to break out after we find
the frame buffer address range without testing later BARs.

Signed-off-by: Wang YanQing 
[ Rewrote changelog. ]
Signed-off-by: Matt Fleming 
Reviewed-by: Peter Jones 
Cc: 
Cc: Ard Biesheuvel 
Cc: David Herrmann 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Tomi Valkeinen 
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/1462454061-21561-2-git-send-email-matt@codeblueprint.co.uk
Signed-off-by: Ingo Molnar 

Signed-off-by: Sasha Levin

powerpc: Fix bad inline asm constraint in create_zero_mask()

2016-05-17T21:29:45+00:00

[ Upstream commit b4c112114aab9aff5ed4568ca5e662bb02cdfe74 ]

In create_zero_mask() we have:

	addi	%1,%2,-1
	andc	%1,%1,%2
	popcntd	%0,%1

using the "r" constraint for %2. r0 is a valid register in the "r" set,
but addi X,r0,X turns it into an li:

	li	r7,-1
	andc	r7,r7,r0
	popcntd	r4,r7

Fix this by using the "b" constraint, for which r0 is not a valid
register.

This was found with a kernel build using gcc trunk, narrowed down to
when -frename-registers was enabled at -O2. It is just luck however
that we aren't seeing this on older toolchains.

Thanks to Segher for working with me to find this issue.

Cc: stable@vger.kernel.org
Fixes: d0cebfa650a0 ("powerpc: word-at-a-time optimization for 64-bit Little Endian")
Signed-off-by: Anton Blanchard 
Signed-off-by: Michael Ellerman 
Signed-off-by: Sasha Levin

ARM: SoCFPGA: Fix secondary CPU startup in thumb2 kernel

2016-05-17T18:51:37+00:00

[ Upstream commit 5616f36713ea77f57ae908bf2fef641364403c9f ]

The secondary CPU starts up in ARM mode. When the kernel is compiled in
thumb2 mode we have to explicitly compile the secondary startup
trampoline in ARM mode, otherwise the CPU will go to Nirvana.

Signed-off-by: Sascha Hauer 
Reported-by: Steffen Trumtrar 
Suggested-by: Ard Biesheuvel 
Cc: stable@vger.kernel.org
Signed-off-by: Dinh Nguyen 
Signed-off-by: Kevin Hilman 
Signed-off-by: Sasha Levin

x86/mm/xen: Suppress hugetlbfs in PV guests

2016-05-10T16:20:19+00:00

[ Upstream commit 103f6112f253017d7062cd74d17f4a514ed4485c ]

Huge pages are not normally available to PV guests. Not suppressing
hugetlbfs use results in an endless loop of page faults when user mode
code tries to access a hugetlbfs mapped area (since the hypervisor
denies such PTEs to be created, but error indications can't be
propagated out of xen_set_pte_at(), just like for various of its
siblings), and - once killed in an oops like this:

  kernel BUG at .../fs/hugetlbfs/inode.c:428!
  invalid opcode: 0000 [#1] SMP
  ...
  RIP: e030:[]  [] remove_inode_hugepages+0x25b/0x320
  ...
  Call Trace:
   [] hugetlbfs_evict_inode+0x15/0x40
   [] evict+0xbd/0x1b0
   [] __dentry_kill+0x19a/0x1f0
   [] dput+0x1fe/0x220
   [] __fput+0x155/0x200
   [] task_work_run+0x60/0xa0
   [] do_exit+0x160/0x400
   [] do_group_exit+0x3b/0xa0
   [] get_signal+0x1ed/0x470
   [] do_signal+0x14/0x110
   [] prepare_exit_to_usermode+0xe9/0xf0
   [] retint_user+0x8/0x13

This is CVE-2016-3961 / XSA-174.

Reported-by: Vitaly Kuznetsov 
Signed-off-by: Jan Beulich 
Cc: Andrew Morton 
Cc: Andy Lutomirski 
Cc: Boris Ostrovsky 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: David Vrabel 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Juergen Gross 
Cc: Linus Torvalds 
Cc: Luis R. Rodriguez 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Toshi Kani 
Cc: stable@vger.kernel.org
Cc: xen-devel 
Link: http://lkml.kernel.org/r/57188ED802000078000E431C@prv-mh.provo.novell.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin

s390/hugetlb: add hugepages_supported define

2016-05-10T16:20:19+00:00

[ Upstream commit 7f9be77555bb2e52de84e9dddf7b4eb20cc6e171 ]

On s390 we only can enable hugepages if the underlying hardware/hypervisor
also does support this.  Common code now would assume this to be
signaled by setting HPAGE_SHIFT to 0.  But on s390, where we only
support one hugepage size, there is a link between HPAGE_SHIFT and
pageblock_order.

So instead of setting HPAGE_SHIFT to 0, we will implement the check for
the hardware capability.

Signed-off-by: Dominik Dingel 
Acked-by: Martin Schwidefsky 
Cc: Heiko Carstens 
Cc: Christian Borntraeger 
Cc: Michael Holzheu 
Cc: Gerald Schaefer 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

powerpc: Update cpu_user_features2 in scan_features()

2016-05-09T01:21:51+00:00

[ Upstream commit beff82374b259d726e2625ec6c518a5f2613f0ae ]

scan_features() updates cpu_user_features but not cpu_user_features2.

Amongst other things, cpu_user_features2 contains the user TM feature
bits which we must keep in sync with the kernel TM feature bit.

Signed-off-by: Anton Blanchard 
Cc: stable@vger.kernel.org
Signed-off-by: Michael Ellerman 
Signed-off-by: Sasha Levin

powerpc: scan_features() updates incorrect bits for REAL_LE

2016-05-09T01:21:51+00:00

[ Upstream commit 6997e57d693b07289694239e52a10d2f02c3a46f ]

The REAL_LE feature entry in the ibm_pa_feature struct is missing an MMU
feature value, meaning all the remaining elements initialise the wrong
values.

This means instead of checking for byte 5, bit 0, we check for byte 0,
bit 0, and then we incorrectly set the CPU feature bit as well as MMU
feature bit 1 and CPU user feature bits 0 and 2 (5).

Checking byte 0 bit 0 (IBM numbering), means we're looking at the
"Memory Management Unit (MMU)" feature - ie. does the CPU have an MMU.
In practice that bit is set on all platforms which have the property.

This means we set CPU_FTR_REAL_LE always. In practice that seems not to
matter because all the modern cpus which have this property also
implement REAL_LE, and we've never needed to disable it.

We're also incorrectly setting MMU feature bit 1, which is:

  #define MMU_FTR_TYPE_8xx		0x00000002

Luckily the only place that looks for MMU_FTR_TYPE_8xx is in Book3E
code, which can't run on the same cpus as scan_features(). So this also
doesn't matter in practice.

Finally in the CPU user feature mask, we're setting bits 0 and 2. Bit 2
is not currently used, and bit 0 is:

  #define PPC_FEATURE_PPC_LE		0x00000001

Which says the CPU supports the old style "PPC Little Endian" mode.
Again this should be harmless in practice as no 64-bit CPUs implement
that mode.

Fix the code by adding the missing initialisation of the MMU feature.

Also add a comment marking CPU user feature bit 2 (0x4) as reserved. It
would be unsafe to start using it as old kernels incorrectly set it.

Fixes: 44ae3ab3358e ("powerpc: Free up some CPU feature bits by moving out MMU-related features")
Signed-off-by: Anton Blanchard 
Cc: stable@vger.kernel.org
[mpe: Flesh out changelog, add comment reserving 0x4]
Signed-off-by: Michael Ellerman 

Signed-off-by: Sasha Levin