linux-stable.git/arch/arc/include, branch v3.18.76

Make asm/word-at-a-time.h available on all architectures

2017-08-11T16:30:13+00:00

commit a6e2f029ae34f41adb6ae3812c32c5d326e1abd2 upstream.

Added the x86 implementation of word-at-a-time to the
generic version, which previously only supported big-endian.

Omitted the x86-specific load_unaligned_zeropad(), which in
any case is also not present for the existing BE-only
implementation of a word-at-a-time, and is only used under
CONFIG_DCACHE_WORD_ACCESS.

Added as a "generic-y" to the Kbuilds of all architectures
that didn't previously have it.

Signed-off-by: Chris Metcalf 
Signed-off-by: Greg Kroah-Hartman

ARC: uaccess: get_user to zero out dest in cause of fault

2016-10-06T02:40:20+00:00

[ Upstream commit 05d9d0b96e53c52a113fd783c0c97c830c8dc7af ]

Al reported potential issue with ARC get_user() as it wasn't clearing
out destination pointer in case of fault due to bad address etc.

Verified using following

| {
|  	u32 bogus1 = 0xdeadbeef;
|	u64 bogus2 = 0xdead;
|	int rc1, rc2;
|
|  	pr_info("Orig values %x %llx\n", bogus1, bogus2);
|	rc1 = get_user(bogus1, (u32 __user *)0x40000000);
|	rc2 = get_user(bogus2, (u64 __user *)0x50000000);
|	pr_info("access %d %d, new values %x %llx\n",
|		rc1, rc2, bogus1, bogus2);
| }

| [ARCLinux]# insmod /mnt/kernel-module/qtn.ko
| Orig values deadbeef dead
| access -14 -14, new values 0 0

Reported-by: Al Viro 
Cc: Linus Torvalds 
Cc: linux-snps-arc@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org
Signed-off-by: Vineet Gupta 
Signed-off-by: Al Viro 
Signed-off-by: Sasha Levin

Revert "ARC: mm: don't loose PTE_SPECIAL in pte_modify()"

2016-09-15T22:55:24+00:00

This reverts commit 77c6ffdbce68688492a31702f67c7dbc4eeedd62.

Signed-off-by: Sasha Levin

ARC: Support syscall ABI v4

2016-09-01T02:05:44+00:00

[ Upstream commit 840c054fd0efb048df6fceb0c46385ec5b66dfe6 ]

The syscall ABI includes the gcc functional calling ABI since a syscall
implies userland caller and kernel callee.

The current gcc ABI (v3) for ARCv2 ISA required 64-bit data be passed in
even-odd register pairs, (potentially punching reg holes when passing such
values as args). This was partly driven by the fact that the double-word
LDD/STD instructions in ARCv2 expect the register alignment and thus gcc
forcing this avoids extra MOV at the cost of a few unused register (which we
have plenty anyways).

This however was rejected as part of upstreaming gcc port to HS. So the new
ABI v4 doesn't enforce the even-odd reg restriction.

Do note that for ARCompact ISA builds v3 and v4 are practically the same in
terms of gcc code generation.

In terms of change management, we infer the new ABI if gcc 6.x onwards
is used for building the kernel.

This also needs a stable backport to enable older kernels to work with
new tools/user-space

Cc: 
Signed-off-by: Vineet Gupta 
Signed-off-by: Sasha Levin

ARC: use correct offset in pt_regs for saving/restoring user mode r25

2016-09-01T02:05:44+00:00

[ Upstream commit 86147e3cfa5e118b61e78f4f0bf29e920dcbd477 ]

User mode callee regs are explicitly collected before signal delivery or
breakpoint trap. r25 is special for kernel as it serves as task pointer,
so user mode value is clobbered very early. It is saved in pt_regs where
generally only scratch (aka caller saved) regs are saved.

The code to access the corresponding pt_regs location had a subtle bug as
it was using load/store with scaling of offset, whereas the offset was already
byte wise correct. So fix this by replacing LD.AS with a standard LD

Cc: 
Signed-off-by: Liav Rehana 
Reviewed-by: Alexey Brodkin 
[vgupta: rewrote title and commit log]
Signed-off-by: Vineet Gupta 

Signed-off-by: Sasha Levin

ARCv2: STAR 9000808988: signals involving Delay Slot

2016-09-01T02:05:44+00:00

[ Upstream commit 0d7b8855a05c099a5c65a8d49a1e604198021f56 ]

Reported by Anton as LTP:munmap01 failing with Illegal Instruction
Exception.

   --------------------->8--------------------------------------
   mmap2(NULL, 24576, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0) = 0x200d2000
   munmap(0x200d2000, 24576)               = 0
   --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x200d2000}
   ---
   potentially unexpected fatal signal 4.
   Path: /munmap01
   CPU: 0 PID: 61 Comm: munmap01 Not tainted 3.13.0-g5d5c46d9a556 #8
   task: 9f1a8000 ti: 9f154000 task.ti: 9f154000

   [ECR   ]: 0x00020100 => Illegal Insn
   [EFA   ]: 0x0001354c
   [BLINK ]: 0x200515d4
   [ERET  ]: 0x1354c
       @off 0x1354c in [/munmap01]
       VMA: 0x00010000 to 0x00018000
   [STAT32]: 0x800802c0
   ...
   --------------------->8--------------------------------------

The issue was
1. munmap01 accessed unmapped memory (on purpose) with signal handler
   installed for SIGSEGV

2. The faulting instruction happened to be in Delay Slot
   00011864 :
      11908:	bl.d       13284 
      1190c:	stb        r16,[r2]

3. kernel sets up the reg file for signal handler and correctly clears
   the DE bit in pt_regs->status32 placeholder

4. However RESTORE_CALLEE_SAVED_USER macro is not adjusted for ARCv2,
   and it over-writes the above with orig/stale value of status32

5. After RTIE, userspace signal handler executes a non branch
   instruction with DE bit set, triggering Illegal Instruction Exception.

Reported-by: Anton Kolesov 
Signed-off-by: Vineet Gupta 
Signed-off-by: Sasha Levin

ARC: Call trace_hardirqs_on() before enabling irqs

2016-09-01T02:05:44+00:00

[ Upstream commit 18b43e89d295cc65151c505c643c98fb2c320e59 ]

trace_hardirqs_on_caller() in lockdep.c expects to be called before, not
after interrupts are actually enabled.

The following comment in kernel/locking/lockdep.c substantiates this
claim:

"
/*
 * We're enabling irqs and according to our state above irqs weren't
 * already enabled, yet we find the hardware thinks they are in fact
 * enabled.. someone messed up their IRQ state tracing.
 */
"

An example can be found in include/linux/irqflags.h:

	do { trace_hardirqs_on(); raw_local_irq_enable(); } while (0)

Without this change, we hit the following DEBUG_LOCKS_WARN_ON.

[    7.760000] ------------[ cut here ]------------
[    7.760000] WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:2711 resume_user_mode_begin+0x48/0xf0
[    7.770000] DEBUG_LOCKS_WARN_ON(!irqs_disabled())
[    7.780000] Modules linked in:
[    7.780000] CPU: 0 PID: 1 Comm: init Not tainted 4.7.0-00003-gc668bb9-dirty #366
[    7.790000]
[    7.790000] Stack Trace:
[    7.790000]   arc_unwind_core.constprop.1+0xa4/0x118
[    7.800000]   warn_slowpath_fmt+0x72/0x158
[    7.800000]   resume_user_mode_begin+0x48/0xf0
[    7.810000] ---[ end trace 6f6a7a8fae20d2f0 ]---

Signed-off-by: Daniel Mentz 
Cc: 
Signed-off-by: Vineet Gupta 
Signed-off-by: Sasha Levin

ARC: mm: don't loose PTE_SPECIAL in pte_modify()

2016-08-22T16:23:22+00:00

[ Upstream commit 3925a16ae980c79d1a8fd182d7f9487da1edd4dc ]

LTP madvise05 was generating mm splat

| [ARCLinux]# /sd/ltp/testcases/bin/madvise05
| BUG: Bad page map in process madvise05  pte:80e08211 pmd:9f7d4000
| page:9fdcfc90 count:1 mapcount:-1 mapping:  (null) index:0x0 flags: 0x404(referenced|reserved)
| page dumped because: bad pte
| addr:200b8000 vm_flags:00000070 anon_vma:  (null) mapping:  (null) index:1005c
| file:  (null) fault:  (null) mmap:  (null) readpage:  (null)
| CPU: 2 PID: 6707 Comm: madvise05

And for newer kernels, the system was rendered unusable afterwards.

The problem was mprotect->pte_modify() clearing PTE_SPECIAL (which is
set to identify the special zero page wired to the pte).
When pte was finally unmapped, special casing for zero page was not
done, and instead it was treated as a "normal" page, tripping on the
map counts etc.

This fixes ARC STAR 9001053308

Cc: 
Signed-off-by: Vineet Gupta 
Signed-off-by: Sasha Levin

ARC: add smp barriers around atomics per Documentation/atomic_ops.txt

2015-07-05T14:12:50+00:00

[ Upstream commit 2576c28e3f623ed401db7e6197241865328620ef ]

 - arch_spin_lock/unlock were lacking the ACQUIRE/RELEASE barriers
   Since ARCv2 only provides load/load, store/store and all/all, we need
   the full barrier

 - LLOCK/SCOND based atomics, bitops, cmpxchg, which return modified
   values were lacking the explicit smp barriers.

 - Non LLOCK/SCOND varaints don't need the explicit barriers since that
   is implicity provided by the spin locks used to implement the
   critical section (the spin lock barriers in turn are also fixed in
   this commit as explained above

Cc: Paul E. McKenney 
Cc: stable@vger.kernel.org
Acked-by: Peter Zijlstra (Intel) 
Signed-off-by: Vineet Gupta 
Signed-off-by: Sasha Levin

ARC: add compiler barrier to LLSC based cmpxchg

2015-07-05T14:12:50+00:00

[ Upstream commit d57f727264f1425a94689bafc7e99e502cb135b5 ]

When auditing cmpxchg call sites, Chuck noted that gcc was optimizing
away some of the desired LDs.

|	do {
|		new = old = *ipi_data_ptr;
|		new |= 1U << msg;
|	} while (cmpxchg(ipi_data_ptr, old, new) != old);

was generating to below

| 8015cef8:	ld         r2,[r4,0]  <-- First LD
| 8015cefc:	bset       r1,r2,r1
|
| 8015cf00:	llock      r3,[r4]  <-- atomic op
| 8015cf04:	brne       r3,r2,8015cf10
| 8015cf08:	scond      r1,[r4]
| 8015cf0c:	bnz        8015cf00
|
| 8015cf10:	brne       r3,r2,8015cf00  <-- Branch doesn't go to orig LD

Although this was fixed by adding a ACCESS_ONCE in this call site, it
seems safer (for now at least) to add compiler barrier to LLSC based
cmpxchg

Reported-by: Chuck Jordan 
Cc: 
Acked-by: Peter Zijlstra (Intel) 
Signed-off-by: Vineet Gupta 
Signed-off-by: Sasha Levin