ARC: [TB10x] Remove redundant abilis,simple-pinctrl mechanism

The TB10x platform port includes a custom mechanism using to set up
default pin controller configurations using abilis,simple-default
pin configurations of nodes compatible with abilis,simple-pinctrl. This
mechanism is redundant with the Linux standard "default" pin
configuration, see commit ab78029ecc347debbd737f06688d788bd9d60c1d
"drivers/pinctrl: grab default handles from device core".
This patch removes the TB10x custom mechanism in favour of the Linux
standard.

Signed-off-by: Christian Ruppert <christian.ruppert@abilis.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
ARM: 7723/1: crypto: sha1-armv4-large.S: fix SP handling

Make the SHA1 asm code ABI conformant by making sure all stack
accesses occur above the stack pointer.

Origin:
http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=1a9d60d2

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Nicolas Pitre <nico@linaro.org>
Cc: stable@vger.kernel.org
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: 7727/1: remove the .vm_mm value from gate_vma

If one reads /proc/$PID/smaps, the mmap_sem belonging to the
address space of the task being examined is locked for reading.
All the pages of the vmas belonging to the task's address space
are then walked with this lock held.

If a gate_vma is present in the architecture, it too is examined
by the fs/proc/task_mmu.c code. As gate_vma doesn't belong to the
address space of the task though, its pages are not walked.

A recent cleanup (commit f6604efe) of the gate_vma initialisation
code set the vm_mm value to &init_mm. Unfortunately a non-NULL
vm_mm value in the gate_vma will cause the task_mmu code to attempt
to walk the pages of the gate_vma (with no mmap-sem lock held). If
one enables Transparent Huge Page support and vm debugging, this
will then cause OOPses as pmd_trans_huge_lock is called without
mmap_sem being locked.

This patch removes the .vm_mm value from gate_vma, restoring the
original behaviour of the task_mmu code.

Signed-off-by: Steve Capper <steve.capper@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: 7729/1: vfp: ensure VFP_arch is non-zero when VFP is not supported

Commit d3f79584a8b5 ("ARM: cleanup undefined instruction entry code")
improved the register scheduling when handling undefined instructions.
A side effect of this is that r5 is now used as a temporary, whilst the
VFP probing code relies on r5 containing a non-zero value when VFP is
not supported.

This patch fixes the VFP detection code so that we don't rely on the
contents of r5. Without this patch, Linux dies loudly on CPUs without
VFP support.

Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARC: [mm] Prevent stray dcache lines after__sync_icache_dcach()

Flush and INVALIDATE the dcache page.

This helper is only used for writeback of CODE pages to memory. So
there's no value in keeping the dcache lines around. Infact it is risky
as a writeback on natural eviction under pressure can cause un-needed
writeback with weird issues on aliasing dcache configurations.

Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
ARC: copy_(to|from)_user() to honor usermode-access permissions

This manifested as grep failing psuedo-randomly:

-------------->8---------------------
[ARCLinux]$ ip address show lo | grep inet
[ARCLinux]$ ip address show lo | grep inet
[ARCLinux]$ ip address show lo | grep inet
[ARCLinux]$
[ARCLinux]$ ip address show lo | grep inet
    inet 127.0.0.1/8 scope host lo
-------------->8---------------------

ARC700 MMU provides fully orthogonal permission bits per page:
Ur, Uw, Ux, Kr, Kw, Kx

The user mode page permission templates used to have all Kernel mode
access bits enabled.
This caused a tricky race condition observed with uClibc buffered file
read and UNIX pipes.

1. Read access to an anon mapped page in libc .bss: write-protected
   zero_page mapped: TLB Entry installed with Ur + K[rwx]

2. grep calls libc:getc() -> buffered read layer calls read(2) with the
   internal read buffer in same .bss page.
   The read() call is on STDIN which has been redirected to a pipe.
   read(2) => sys_read() => pipe_read() => copy_to_user()

3. Since page has Kernel-write permission (despite being user-mode
   write-protected), copy_to_user() suceeds w/o taking a MMU TLB-Miss
   Exception (page-fault for ARC). core-MM is unaware that kernel
   erroneously wrote to the reserved read-only zero-page (BUG #1)

4. Control returns to userspace which now does a write to same .bss page
   Since Linux MM is not aware that page has been modified by kernel, it
   simply reassigns a new writable zero-init page to mapping, loosing the
   prior write by kernel - effectively zero'ing out the libc read buffer
   under the hood - hence grep doesn't see right data (BUG #2)

The fix is to make all kernel-mode access permissions mirror the
user-mode ones. Note that the kernel still has full access to pages,
when accessed directly (w/o MMU) - this fix ensures that kernel-mode
access in copy_to_from() path uses the same faulting access model as for
pure user accesses to keep MM fully aware of page state.

The issue is peudo-random because it only shows up if the TLB entry
installed in #1 is present at the time of #3. If it is evicted out, due
to TLB pressure or some-such, then copy_to_user() does take a TLB Miss
Exception, with a routine write-to-anon COW processing installing a
fresh page for kernel writes and also usable as it is in userspace.

Further the issue was dormant for so long as it depends on where the
libc internal read buffer (in .bss) is mapped at runtime.
If it happens to reside in file-backed data mapping of libc (in the
page-aligned slack space trailing the file backed data), loader zero
padding the slack space, does the early cow page replacement, setting
things up at the very beginning itself.

With gcc 4.8 based builds, the libc buffer got pushed out to a real
anon mapping which triggers the issue.

Reported-by: Anton Kolesov <akolesov@synopsys.com>
Cc: <stable@vger.kernel.org> # 3.9
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
ARC: Brown paper bag bug in macro for checking cache color

The VM_EXEC check in update_mmu_cache() was getting optimized away
because of a stupid error in definition of macro addr_not_cache_congruent()

The intention was to have the equivalent of following:

	if (a || (1 ? b : 0))

but we ended up with following:

	if (a || 1 ? b : 0)

And because precedence of '||' is more that that of '?', gcc was optimizing
away evaluation of <a>

Nasty Repercussions:
1. For non-aliasing configs it would mean some extraneous dcache flushes
   for non-code pages if U/K mappings were not congruent.
2. For aliasing config, some needed dcache flush for code pages might
   be missed if U/K mappings were congruent.

Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
ARC: Use enough bits for determining page's cache color

The current code uses 2 bits for determining page's dcache color, thus
sorting pages into 4 bins, whereas the aliasing dcache really has 2 bins
(8k page, 64k dcache - 4 way-set-assoc).
This can cause extraneous flushes - e.g. color 0 and 2.

Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
ARC: lazy dcache flush broke gdb in non-aliasing configs

gdbserver inserting a breakpoint ends up calling copy_user_page() for a
code page. The generic version of which (non-aliasing config) didn't set
the PG_arch_1 bit hence update_mmu_cache() didn't sync dcache/icache for
corresponding dynamic loader code page - causing garbade to be executed.

So now aliasing versions of copy_user_highpage()/clear_page() are made
default. There is no significant overhead since all of special alias
handling code is compiled out for non-aliasing build

Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Merge branch 'fixes' of git://git.linaro.org/people/rmk/linux-arm

Pull ARM fixes from Russell King:
 "Just three this time, all really quite small"

* 'fixes' of git://git.linaro.org/people/rmk/linux-arm:
  ARM: 7729/1: vfp: ensure VFP_arch is non-zero when VFP is not supported
  ARM: 7727/1: remove the .vm_mm value from gate_vma
  ARM: 7723/1: crypto: sha1-armv4-large.S: fix SP handling
Merge tag 'arc-v3.10-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc

Pull ARC fixes from Vineet Gupta:

 - Fallouts/wreckage of Cache Flush optimizations / aliasing dcache
   support

 - Fix for an interesting bug where piped input to grep was getting
   mysteriously clobbered

* tag 'arc-v3.10-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc:
  ARC: lazy dcache flush broke gdb in non-aliasing configs
  ARC: Use enough bits for determining page's cache color
  ARC: Brown paper bag bug in macro for checking cache color
  ARC: copy_(to|from)_user() to honor usermode-access permissions
  ARC: [mm] Prevent stray dcache lines after__sync_icache_dcach()
  ARC: [TB10x] Remove redundant abilis,simple-pinctrl mechanism
score: remove redundant kcore_list entries

kcore_vmalloc is in fs/proc/kcore.c and kcore_mem is unused across
the tree. Noticed while grepping the tree for some other kcore stuff.

(score looks pretty unmaintained to me.)

Signed-off-by: Kyle McMartin <kyle@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>