linux.git/arch/arc, branch v4.5-rc2

dma-mapping: always provide the dma_map_ops based implementation

2016-01-21T01:09:18+00:00

Move the generic implementation to  now that all
architectures support it and remove the HAVE_DMA_ATTR Kconfig symbol now
that everyone supports them.

[valentinrothberg@gmail.com: remove leftovers in Kconfig]
Signed-off-by: Christoph Hellwig 
Cc: "David S. Miller" 
Cc: Aurelien Jacquiot 
Cc: Chris Metcalf 
Cc: David Howells 
Cc: Geert Uytterhoeven 
Cc: Haavard Skinnemoen 
Cc: Hans-Christian Egtvedt 
Cc: Helge Deller 
Cc: James Hogan 
Cc: Jesper Nilsson 
Cc: Koichi Yasutake 
Cc: Ley Foon Tan 
Cc: Mark Salter 
Cc: Mikael Starvik 
Cc: Steven Miao 
Cc: Vineet Gupta 
Cc: Christian Borntraeger 
Cc: Joerg Roedel 
Cc: Sebastian Ott 
Signed-off-by: Valentin Rothberg 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

arc: convert to dma_map_ops

2016-01-21T01:09:18+00:00

[vgupta@synopsys.com: ARC: dma mapping fixes #2]
Signed-off-by: Christoph Hellwig 
Cc: Vineet Gupta 
Cc: Christian Borntraeger 
Cc: Joerg Roedel 
Cc: Sebastian Ott 
Signed-off-by: Vineet Gupta 
Cc: Carlos Palminha 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Kconfig: remove HAVE_LATENCYTOP_SUPPORT

2016-01-16T19:17:23+00:00

As illustrated by commit a3afe70b83fd ("[S390] latencytop s390
support."), HAVE_LATENCYTOP_SUPPORT is defined by an architecture to
advertise an implementation of save_stack_trace_tsk.

However, as of 9212ddb5eada ("stacktrace: provide save_stack_trace_tsk()
weak alias") a dummy implementation is provided if STACKTRACE=y.  Given
that LATENCYTOP already depends on STACKTRACE_SUPPORT and selects
STACKTRACE, we can remove HAVE_LATENCYTOP_SUPPORT altogether.

Signed-off-by: Will Deacon 
Acked-by: Heiko Carstens 
Cc: Vineet Gupta 
Cc: Russell King 
Cc: James Hogan 
Cc: Michal Simek 
Cc: Helge Deller 
Acked-by: Michael Ellerman 
Cc: "David S. Miller" 
Cc: Guan Xuetao 
Cc: Ingo Molnar 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm: differentiate page_mapped() from page_mapcount() for compound pages

2016-01-16T01:56:32+00:00

Let's define page_mapped() to be true for compound pages if any
sub-pages of the compound page is mapped (with PMD or PTE).

On other hand page_mapcount() return mapcount for this particular small
page.

This will make cases like page_get_anon_vma() behave correctly once we
allow huge pages to be mapped with PTE.

Most users outside core-mm should use page_mapcount() instead of
page_mapped().

Signed-off-by: Kirill A. Shutemov 
Tested-by: Sasha Levin 
Tested-by: Aneesh Kumar K.V 
Acked-by: Jerome Marchand 
Cc: Vlastimil Babka 
Cc: Andrea Arcangeli 
Cc: Hugh Dickins 
Cc: Dave Hansen 
Cc: Mel Gorman 
Cc: Rik van Riel 
Cc: Naoya Horiguchi 
Cc: Steve Capper 
Cc: Johannes Weiner 
Cc: Michal Hocko 
Cc: Christoph Lameter 
Cc: David Rientjes 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/livepatching

2016-01-15T00:38:02+00:00

Pull livepatching updates from Jiri Kosina:

 - RO/NX attribute fixes for patch module relocations from Josh
   Poimboeuf.  As part of this effort, module.c has been cleaned up as
   well and livepatching is piggy-backing on this cleanup.  Rusty is OK
   with this whole lot going through livepatching tree.

 - symbol disambiguation support from Chris J Arges.  That series is
   also

        Reviewed-by: Miroslav Benes 

   but this came in only after I've alredy pushed out.  Didn't want to
   rebase because of that, hence I am mentioning it here.

 - symbol lookup fix from Miroslav Benes

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/livepatching:
  livepatch: Cleanup module page permission changes
  module: keep percpu symbols in module's symtab
  module: clean up RO/NX handling.
  module: use a structure to encapsulate layout.
  gcov: use within_module() helper.
  module: Use the same logic for setting and unsetting RO/NX
  livepatch: function,sympos scheme in livepatch sysfs directory
  livepatch: add sympos as disambiguator field to klp_reloc
  livepatch: add old_sympos as disambiguator field to klp_func

ARC: dw2 unwind: Catch Dwarf SNAFUs early

2015-12-21T08:31:49+00:00

Instead of seeing empty stack traces, let kernel fail early so dwarf
issues can be fixed sooner

Signed-off-by: Vineet Gupta

ARC: dw2 unwind: Don't bail for CIE.version != 1

2015-12-21T08:31:25+00:00

The rudimentary CIE.version == 3 handling is already present in code
(for return address register specification)

Signed-off-by: Vineet Gupta

Revert "ARC: dw2 unwind: Ignore CIE version !=1 gracefully instead of bailing"

2015-12-21T07:59:44+00:00

Blingly ignoring CIE.version != 1 was a bad idea.
It still leaves "desirability" when running perf with callgraphing where libgcc
symbols might show in hotspot.

More importantly, basic CIE.version == 3 support already exists in code:

|
|   retAddrReg = state.version <= 1 ? *ptr++ : get_uleb128(&ptr, end);
|

Next commit with simply add continue-not-bail for CIE.version != 1

This reverts commit 323f41f9e7d0cb5b1d1586aded6682855f1e646d.

ARC: Fix linking errors with CONFIG_MODULE + CONFIG_CC_OPTIMIZE_FOR_SIZE

2015-12-21T07:31:19+00:00

At -Os, ARC gcc generates millicode thunk for function prologue/epilogue,
which are served by libgcc.

Modules historically are NOT linked with libgcc to avoid code bloat, reducing
runtime relocation fixups etc. I even once tried doing that but got lost
in makefile intricacies.

This means modules at -Os don't get the millicode thunks, causing build
failures below:

| MODPOST 5 modules
| ERROR: "__ld_r13_to_r18" [crypto/sha256_generic.ko] undefined!
| ERROR: "__ld_r13_to_r18_ret" [crypto/sha256_generic.ko] undefined!
| ERROR: "__st_r13_to_r18" [crypto/sha256_generic.ko] undefined!
| ERROR: "__ld_r13_to_r17_ret" [crypto/sha256_generic.ko] undefined!
| ERROR: "__st_r13_to_r17" [crypto/sha256_generic.ko] undefined!
| ERROR: "__ld_r13_to_r16_ret" [crypto/sha256_generic.ko] undefined!
| ERROR: "__st_r13_to_r16" [crypto/sha256_generic.ko] undefined!
|....
|....

Workaround that by inhibiting millicode thunks for loadable modules

Fixes STAR 9000641864:
("Linux built with optimizations for size emits errors for modules")

Reported-by: Anton Kolesov 
Cc: Michal Marek 
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Vineet Gupta

ARC: mm: fix building for MMU v2

2015-12-21T06:40:40+00:00

ARC700 cores with MMU v2 don't have IC_PTAG AUX register and so we only
define ARC_REG_IC_PTAG for MMU versions >= 3.

But current implementation of cache_line_loop_vX() routines assumes
availability of all of them (v2, v3 and v4) simultaneously.

And given undefined ARC_REG_IC_PTAG if CONFIG_MMU_VER=2 we're seeing
compilation problem:
---------------------------------->8-------------------------------
  CC      arch/arc/mm/cache.o
arch/arc/mm/cache.c: In function '__cache_line_loop_v3':
arch/arc/mm/cache.c:270:13: error: 'ARC_REG_IC_PTAG' undeclared (first use in this function)
   aux_tag = ARC_REG_IC_PTAG;
             ^
arch/arc/mm/cache.c:270:13: note: each undeclared identifier is reported only once for each function it appears in
scripts/Makefile.build:258: recipe for target 'arch/arc/mm/cache.o' failed
---------------------------------->8-------------------------------

The simples fix is to have ARC_REG_IC_PTAG defined regardless MMU
version being used.

We don't use it in cache_line_loop_v2() anyways so who cares.

Signed-off-by: Alexey Brodkin 
Signed-off-by: Vineet Gupta