ARM: 7658/1: mm: fix race updating mm->context.id on ASID rollover

If a thread triggers an ASID rollover, other threads of the same process
must be made to wait until the mm->context.id for the shared mm_struct
has been updated to new generation and associated book-keeping (e.g.
TLB invalidation) has ben performed.

However, there is a *tiny* window where both mm->context.id and the
relevant active_asids entry are updated to the new generation, but the
TLB flush has not been performed, which could allow another thread to
return to userspace with a dirty TLB, potentially leading to data
corruption. In reality this will never occur because one CPU would need
to perform a context-switch in the time it takes another to do a couple
of atomic test/set operations but we should plug the race anyway.

This patch moves the active_asids update until after the potential TLB
flush on context-switch.

Cc: <stable@vger.kernel.org> # 3.8
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: 7659/1: mm: make mm->context.id an atomic64_t variable

mm->context.id is updated under asid_lock when a new ASID is allocated
to an mm_struct. However, it is also read without the lock when a task
is being scheduled and checking whether or not the current ASID
generation is up-to-date.

If two threads of the same process are being scheduled in parallel and
the bottom bits of the generation in their mm->context.id match the
current generation (that is, the mm_struct has not been used for ~2^24
rollovers) then the non-atomic, lockless access to mm->context.id may
yield the incorrect ASID.

This patch fixes this issue by making mm->context.id and atomic64_t,
ensuring that the generation is always read consistently. For code that
only requires access to the ASID bits (e.g. TLB flushing by mm), then
the value is accessed directly, which GCC converts to an ldrb.

Cc: <stable@vger.kernel.org> # 3.8
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: 7661/1: mm: perform explicit branch predictor maintenance when required

The ARM ARM requires branch predictor maintenance if, for a given ASID,
the instructions at a specific virtual address appear to change.

From the kernel's point of view, that means:

	- Changing the kernel's view of memory (e.g. switching to the
	  identity map)
	- ASID rollover (since ASIDs will be re-allocated to new tasks)

This patch adds explicit branch predictor maintenance when either of the
two conditions above are met.

Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: 7684/1: errata: Workaround for Cortex-A15 erratum 798181 (TLBI/DSB operations)

On Cortex-A15 (r0p0..r3p2) the TLBI/DSB are not adequately shooting down
all use of the old entries. This patch implements the erratum workaround
which consists of:

1. Dummy TLBIMVAIS and DSB on the CPU doing the TLBI operation.
2. Send IPI to the CPUs that are running the same mm (and ASID) as the
   one being invalidated (or all the online CPUs for global pages).
3. CPU receiving the IPI executes a DMB and CLREX (part of the exception
   return code already).

Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Config update.
ARM: entry: prefetch/data abort helpers: convert to macros

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: entry: prefetch/data abort helpers: avoid corrupting r4

Replace r4 with ip for calling abort helpers - ip is allowed to be
corrupted by called functions in the ABI, so it makes more sense to
use such a register.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: entry: no need to increase preempt count for IRQ handlers

irq_enter() and irq_exit() already take care of the preempt_count
handling for interrupts, which increment and decrement the hardirq
bits of the preempt count.  So we can remove the preempt count handing
in our IRQ entry/exit assembly, like x86 did some 9 years ago.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: entry: no need to check parent IRQ mask in IRQ handler return

There's no point checking to see whether IRQs were masked in the parent
context when returning from IRQ handling - the fact that we're handling
an IRQ means that the parent context must have had IRQs unmasked.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: entry: rejig register allocation in exception entry handlers

This allows us to avoid moving registers twice to work around the
clobbered registers when we add calls to trace_hardirqs_{on,off}.

Ensure that all SVC handlers return with SPSR in r5 for consistency.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: entry: prefetch abort helper: pass aborted pc in r4 rather than r0

This avoids unnecessary instructions for CPUs which implement the IFAR
(instruction fault address register).

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: entry: avoid enabling interrupts in prefetch/data abort handlers

Avoid enabling interrupts if the parent context had interrupts enabled
in the abort handler assembly code, and move this into the breakpoint/
page/alignment fault handlers instead.

This gets rid of some special-casing for the breakpoint fault handlers
from the low level abort handler path.

Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: 7007/1: alignment: Prevent ignoring of faults with ARMv6 unaligned access model

Currently, it's possible to set the kernel to ignore alignment
faults when changing the alignment fault handling mode at runtime
via /proc/sys/alignment, even though this is undesirable on ARMv6
and above, where it can result in infinite spins where an un-fixed-
up instruction repeatedly faults.

In addition, the kernel clobbers any alignment mode specified on
the command-line if running on ARMv6 or above.

This patch factors out the necessary safety check into a couple of
new helper functions, and checks and modifies the fault handling
mode as appropriate on boot and on writes to /proc/cpu/alignment.

Prior to ARMv6, the behaviour is unchanged.

For ARMv6 and above, the behaviour changes as follows:

  * Attempting to ignore faults on ARMv6 results in the mode being
    forced to UM_FIXUP instead.  A warning is printed if this
    happened as a result of a write to /proc/cpu/alignment.  The
    user's UM_WARN bit (if present) is still honoured.

  * An alignment= argument from the kernel command-line is now
    honoured, except that the kernel will modify the specified mode
    as described above.  This is allows modes such as UM_SIGNAL and
    UM_WARN to be active immediately from boot, which is useful for
    debugging purposes.

Signed-off-by: Dave Martin <dave.martin@linaro.org>
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: 7008/1: alignment: Make SIGBUS sent to userspace POSIXly correct

With the UM_SIGNAL alignment fault mode, no siginfo structure is
passed to userspace.

POSIX specifies how siginfo_t should be populated for alignment
faults, so this patch does just that:

  * si_signo = SIGBUS
  * si_code = BUS_ADRALN
  * si_addr = misaligned data address at which access was attempted

Signed-off-by: Dave Martin <dave.martin@linaro.org>
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Acked-by: Kirill A. Shutemov <kirill@shutemov.name>
Reviewed-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: allow building alignment.c without PROC_FS

The two functions cpu_is_v6_unaligned and safe_usermode
are only defined when CONFIG_PROC_FS is enabled, but
are used outside of the #ifdef.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Dave Martin <dave.martin@linaro.org>
ARM: Fix build warning in arch/arm/mm/alignment.c

Fix this harmless build warning:

arch/arm/mm/alignment.c: In function 'do_alignment':
arch/arm/mm/alignment.c:749:21: warning: 'offset.un' may be used uninitialized in this function

This is caused by the compiler not being able to properly analyse the
code to prove that offset.un is assigned in every case.  The case it
struggles with is where we assign the handler from the Thumb parser -
do_alignment_t32_to_handler().  As this starts by zeroing this variable
via a pointer, move it into the calling function.  This fixes the
warning.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
 ARM: Fix another build warning in arch/arm/mm/alignment.c

One such warning was recently fixed in a761ceb "ARM: Fix build warning
in arch/arm/mm/alignment.c" but only for the thumb2 case, this fixes
the other half.

arch/arm/mm/alignment.c: In function 'do_alignment':
arch/arm/mm/alignment.c:327:15: error: 'offset.un' may be used uninitialized in this function
arch/arm/mm/alignment.c:748:21: note: 'offset.un' was declared here

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: 7569/1: mm: uninitialized warning corrections

The variables here are really not used uninitialized.

arch/arm/mm/alignment.c: In function 'do_alignment':
arch/arm/mm/alignment.c:327:15: warning: 'offset.un' may be used uninitialized in this function [-Wmaybe-uninitialized]
arch/arm/mm/alignment.c:748:21: note: 'offset.un' was declared here

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: make cr_alignment read-only #ifndef CONFIG_CPU_CP15

This makes cr_alignment a constant 0 to break code that tries to modify
the value as it's likely that it's built on wrong assumption when
CONFIG_CPU_CP15 isn't defined. For code that is only reading the value 0
is more or less a fine value to report.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Message-Id: 1358413196-5609-2-git-send-email-u.kleine-koenig@pengutronix.de (v8)
Small fix arch/arm/mm/alignment.c