linux-stable.git/arch/arc, branch v4.4.19

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

2016-08-20T16:09:20+00:00

commit 3925a16ae980c79d1a8fd182d7f9487da1edd4dc upstream.

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

Signed-off-by: Vineet Gupta 
Signed-off-by: Greg Kroah-Hartman

ARC: unwind: ensure that .debug_frame is generated (vs. .eh_frame)

2016-08-10T09:49:25+00:00

commit f52e126cc7476196f44f3c313b7d9f0699a881fc upstream.

With recent binutils update to support dwarf CFI pseudo-ops in gas, we
now get .eh_frame vs. .debug_frame. Although the call frame info is
exactly the same in both, the CIE differs, which the current kernel
unwinder can't cope with.

This broke both the kernel unwinder as well as loadable modules (latter
because of a new unhandled relo R_ARC_32_PCREL from .rela.eh_frame in
the module loader)

The ideal solution would be to switch unwinder to .eh_frame.
For now however we can make do by just ensureing .debug_frame is
generated by removing -fasynchronous-unwind-tables

 .eh_frame    generated with -gdwarf-2 -fasynchronous-unwind-tables
 .debug_frame generated with -gdwarf-2

Fixes STAR 9001058196

Signed-off-by: Vineet Gupta 
Signed-off-by: Greg Kroah-Hartman

arc: unwind: warn only once if DW2_UNWIND is disabled

2016-08-10T09:49:25+00:00

commit 9bd54517ee86cb164c734f72ea95aeba4804f10b upstream.

If CONFIG_ARC_DW2_UNWIND is disabled every time arc_unwind_core()
gets called following message gets printed in debug console:
----------------->8---------------
CONFIG_ARC_DW2_UNWIND needs to be enabled
----------------->8---------------

That message makes sense if user indeed wants to see a backtrace or
get nice function call-graphs in perf but what if user disabled
unwinder for the purpose? Why pollute his debug console?

So instead we'll warn user about possibly missing feature once and
let him decide if that was what he or she really wanted.

Signed-off-by: Alexey Brodkin 
Signed-off-by: Vineet Gupta 
Signed-off-by: Greg Kroah-Hartman

ARCv2: LLSC: software backoff is NOT needed starting HS2.1c

2016-07-27T16:47:31+00:00

commit b31ac42697bef4a3aa5d0aa42375a55657f57174 upstream.

Signed-off-by: Vineet Gupta 
Signed-off-by: Greg Kroah-Hartman

ARCv2: Check for LL-SC livelock only if LLSC is enabled

2016-07-27T16:47:31+00:00

commit 4d0cb15fccd1db9dac0c964b2ccf10874e69f5b8 upstream.

Signed-off-by: Vineet Gupta 
Signed-off-by: Greg Kroah-Hartman

ARC: Add missing io barriers to io{read,write}{16,32}be()

2016-05-11T09:21:20+00:00

commit e5bc0478ab6cf565619224536d75ecb2aedca43b upstream.

While reviewing a different change to asm-generic/io.h Arnd spotted that
ARC ioread32 and ioread32be both of which come from asm-generic versions
are not symmetrical in terms of calling the io barriers.

generic ioread32   -> ARC readl()                  [ has barriers]
generic ioread32be -> __be32_to_cpu(__raw_readl()) [ lacks barriers]

While generic ioread32be is being remediated to call readl(), that involves
a swab32(), causing double swaps on ioread32be() on Big Endian systems.

So provide our versions of big endian IO accessors to ensure io barrier
calls while also keeping them optimal

Suggested-by: Arnd Bergmann 
Acked-by: Arnd Bergmann 
Signed-off-by: Vineet Gupta 
Signed-off-by: Greg Kroah-Hartman

ARC: bitops: Remove non relevant comments

2016-04-12T16:08:56+00:00

commit 2a41b6dc28dc71c1a3f1622612a26edc58f7561e upstream.

commit 80f420842ff42 removed the ARC bitops microoptimization but failed
to prune the comments to same effect

Fixes: 80f420842ff42 ("ARC: Make ARC bitops "safer" (add anti-optimization)")
Signed-off-by: Vineet Gupta 
Signed-off-by: Greg Kroah-Hartman

ARC: [BE] readl()/writel() to work in Big Endian CPU configuration

2016-04-12T16:08:56+00:00

commit f778cc65717687a3d3f26dd21bef62cd059f1b8b upstream.

read{l,w}() write{l,w}() primitives should use le{16,32}_to_cpu() and
cpu_to_le{16,32}() respectively to ensure device registers are read
correctly in Big Endian CPU configuration.

Per Arnd Bergmann
| Most drivers using readl() or readl_relaxed() expect those to perform byte
| swaps on big-endian architectures, as the registers tend to be fixed endian

This was needed for getting UART to work correctly on a Big Endian ARC.

The ARC accessors originally were fine, and the bug got introduced
inadventently by commit b8a033023994 ("ARCv2: barriers")

Fixes: b8a033023994 ("ARCv2: barriers")
Link: http://lkml.kernel.org/r/201603100845.30602.arnd@arndb.de
Cc: Alexey Brodkin 
Cc: Arnd Bergmann 
Signed-off-by: Lada Trimasova 
[vgupta: beefed up changelog, added Fixes/stable tags]
Signed-off-by: Vineet Gupta 
Signed-off-by: Greg Kroah-Hartman

ARCv2: SMP: Emulate IPI to self using software triggered interrupt

2016-03-03T23:07:28+00:00

commit bb143f814ea488769ca2e79e0b376139cb5f134b upstream.

ARConnect/MCIP Inter-Core-Interrupt module can't send interrupt to
local core. So use core intc capability to trigger software
interrupt to self, using an unsued IRQ #21.

This showed up as csd deadlock with LTP trace_sched on a dual core
system. This test acts as scheduler fuzzer, triggering all sorts of
schedulting activity. Trouble starts with IPI to self, which doesn't get
delivered (effectively lost due to H/w capability), but the msg intended
to be sent remain enqueued in per-cpu @ipi_data.

All subsequent IPIs to this core from other cores get elided due to the
IPI coalescing optimization in ipi_send_msg_one() where a pending msg
implies an IPI already sent and assumes other core is yet to ack it.
After the elided IPI, other core simply goes into csd_lock_wait()
but never comes out as this core never sees the interrupt.

Fixes STAR 9001008624

Cc: Peter Zijlstra 
Signed-off-by: Vineet Gupta 
Signed-off-by: Greg Kroah-Hartman

ARCv2: STAR 9000950267: Handle return from intr to Delay Slot #2

2016-03-03T23:07:28+00:00

commit cbfe74a753e877b49dc54e9b04d5d42230ca0aed upstream.

Returning to delay slot, riding an interrupti, had one loose end.
AUX_USER_SP used for restoring user mode SP upon RTIE was not being
setup from orig task's saved value, causing task to use wrong SP,
leading to ProtV errors.

The reason being:
 - INTERRUPT_EPILOGUE returns to a kernel trampoline, thus not expected to restore it
 - EXCEPTION_EPILOGUE is not used at all

Fix that by restoring AUX_USER_SP explicitly in the trampoline.

This was broken in the original workaround, but the error scenarios got
reduced considerably since v3.14 due to following:

 1. The Linuxthreads.old based userspace at the time caused many more
    exceptions in delay slot than the current NPTL based one.
    Infact with current userspace the error doesn't happen at all.

 2. Return from interrupt (delay slot or otherwise) doesn't get exercised much
    after commit 4de0e52867d8 ("Really Re-enable interrupts to avoid deadlocks")
    since IRQ_ACTIVE.active being clear means most returns are as if from pure
    kernel (even for active interrupts)

Infact the issue only happened in an experimental branch where I was tinkering with
reverted 4de0e52867d8

Fixes: 4255b07f2c9c ("ARCv2: STAR 9000793984: Handle return from intr to Delay Slot")
Signed-off-by: Vineet Gupta 
Signed-off-by: Greg Kroah-Hartman