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

ARC: Elide redundant setup of DMA callbacks

2016-09-07T06:34:52+00:00

commit 45c3b08a117e2232fc8d7b9e849ead36386f4f96 upstream.

For resources shared by all cores such as SLC and IOC, only the master
core needs to do any setups / enabling / disabling etc.

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

ARC: Call trace_hardirqs_on() before enabling irqs

2016-09-07T06:34:51+00:00

commit 18b43e89d295cc65151c505c643c98fb2c320e59 upstream.

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 
Signed-off-by: Vineet Gupta 
Signed-off-by: Greg Kroah-Hartman

ARC: mm: fix build breakage with STRICT_MM_TYPECHECKS

2016-09-07T06:34:51+00:00

commit 1c3c909303924d30145601f47b6c058fdd2cbc2e upstream.

|  CC      mm/memory.o
| In file included from ../mm/memory.c:53:0:
| ../include/linux/pfn_t.h: In function ‘pfn_t_pte’:
| ../include/linux/pfn_t.h:78:2: error: conversion to non-scalar type requested
|  return pfn_pte(pfn_t_to_pfn(pfn), pgprot);

With STRICT_MM_TYPECHECKS pte_t is a struct and the offending code
forces a cast which ends up shifting a struct and hence the gcc warning.

Note that in recent past some of the arches (aarch64, s390) made
STRICT_MM_TYPECHECKS default, but we don't for ARC as this leads to slightly
worse generated code, given ARC ABI definition of returning structs
(which pte_t would become)

Quoting from ARC ABI...

  "Results of type struct are returned in a caller-supplied temporary
  variable whose address is passed in r0.
  For such functions, the arguments are shifted so that they are
  passed in r1 and up."

So
 - struct to be returned would be allocated on stack requiring extra
   code at call sites
 - callee updates stack memory to facilitate the return (vs. simple
   MOV into return reg r0)

Hence STRICT_MM_TYPECHECKS is not enabled by default for ARC

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

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

2016-09-07T06:34:51+00:00

commit 86147e3cfa5e118b61e78f4f0bf29e920dcbd477 upstream.

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

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

ARC: dma: fix address translation in arc_dma_free

2016-08-20T16:10:54+00:00

commit b4dff2874006e54b60ce4f4dbcfec9ab81c6aff4 upstream.

page should be calculated using physical address.
If platform uses non-trivial dma-to-phys memory translation,
dma_handle should be converted to physicval address before
calculation of page.

Failing to do so results in struct page * pointing to
wrong or non-existent memory.

Fixes: f2e3d55397ff ("ARC: dma: reintroduce platform specific dma<->phys")
Signed-off-by: Vladimir Kondratiev 
Signed-off-by: Vineet Gupta 
Signed-off-by: Greg Kroah-Hartman

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

2016-08-20T16:10:54+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

Merge tag 'arc-4.7-rc6-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc

2016-06-30T16:53:43+00:00

Pull ARC fix from Vineet Gupta:
 "Reinstate dwarf unwinder/loadable-modules with new gnu tools"

* tag 'arc-4.7-rc6-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc:
  arc: unwind: warn only once if DW2_UNWIND is disabled
  ARC: unwind: ensure that .debug_frame is generated (vs. .eh_frame)

arc: unwind: warn only once if DW2_UNWIND is disabled

2016-06-28T05:41:44+00:00

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 
Cc: stable@vger.kernel.org
Signed-off-by: Vineet Gupta

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

2016-06-28T04:12:28+00:00

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

Cc: stable@vger.kernel.org
Signed-off-by: Vineet Gupta

arc: get rid of superfluous __GFP_REPEAT

2016-06-25T00:23:52+00:00

__GFP_REPEAT has a rather weak semantic but since it has been introduced
around 2.6.12 it has been ignored for low order allocations.

pte_alloc_one_kernel uses __get_order_pte but this is obviously always
zero because BITS_FOR_PTE is not larger than 9 yet the page size is
always larger than 4K.  This means that this flag has never been
actually useful here because it has always been used only for
PAGE_ALLOC_COSTLY requests.

Link: http://lkml.kernel.org/r/1464599699-30131-7-git-send-email-mhocko@kernel.org
Signed-off-by: Michal Hocko 
Acked-by: Vineet Gupta 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds