linux-toradex.git/arch/arm/include/asm/mmu_context.h, branch v4.9.35

ARM: Hide finish_arch_post_lock_switch() from modules

2016-05-13T14:12:53+00:00

The introduction of switch_mm_irqs_off() brought back an old bug
regarding the use of preempt_enable_no_resched:

As part of:

  62b94a08da1b ("sched/preempt: Take away preempt_enable_no_resched() from modules")

the definition of preempt_enable_no_resched() is only available in
built-in code, not in loadable modules, so we can't generally use
it from header files.

However, the ARM version of finish_arch_post_lock_switch()
calls preempt_enable_no_resched() and is defined as a static
inline function in asm/mmu_context.h. This in turn means we cannot
include asm/mmu_context.h from modules.

With today's tip tree, asm/mmu_context.h gets included from
linux/mmu_context.h, which is normally the exact pattern one would
expect, but unfortunately, linux/mmu_context.h can be included from
the vhost driver that is a loadable module, now causing this compile
time error with modular configs:

  In file included from ../include/linux/mmu_context.h:4:0,
                   from ../drivers/vhost/vhost.c:18:
  ../arch/arm/include/asm/mmu_context.h: In function 'finish_arch_post_lock_switch':
  ../arch/arm/include/asm/mmu_context.h:88:3: error: implicit declaration of function 'preempt_enable_no_resched' [-Werror=implicit-function-declaration]
     preempt_enable_no_resched();

Andy already tried to fix the bug by including linux/preempt.h
from asm/mmu_context.h, but that didn't help. Arnd suggested reordering
the header files, which wasn't popular, so let's use this
workaround instead:

The finish_arch_post_lock_switch() definition is now also hidden
inside of #ifdef MODULE, so we don't see anything referencing
preempt_enable_no_resched() from a header file. I've built a
few hundred randconfig kernels with this, and did not see any
new problems.

Tested-by: Guenter Roeck 
Signed-off-by: Steven Rostedt 
Signed-off-by: Arnd Bergmann 
Acked-by: Russell King 
Cc: Alexander Shishkin 
Cc: Andy Lutomirski 
Cc: Andy Lutomirski 
Cc: Ard Biesheuvel 
Cc: Arnaldo Carvalho de Melo 
Cc: Borislav Petkov 
Cc: Frederic Weisbecker 
Cc: Jiri Olsa 
Cc: Linus Torvalds 
Cc: Mel Gorman 
Cc: Peter Zijlstra 
Cc: Russell King - ARM Linux 
Cc: Stephane Eranian 
Cc: Thomas Gleixner 
Cc: Vince Weaver 
Cc: linux-arm-kernel@lists.infradead.org
Fixes: f98db6013c55 ("sched/core: Add switch_mm_irqs_off() and use it in the scheduler")
Link: http://lkml.kernel.org/r/1463146234-161304-1-git-send-email-arnd@arndb.de
Signed-off-by: Ingo Molnar

sched/core, ARM: Include linux/preempt.h from asm/mmu_context.h

2016-04-28T09:08:41+00:00

arm's mmu_context.h uses preempt_enable_no_resched and but doesn't
include anything that would pull in the declaration.

If I start including  from 
without this, the build breaks.

Signed-off-by: Andy Lutomirski 
Reviewed-by: Borislav Petkov 
Cc: Borislav Petkov 
Cc: Catalin Marinas 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Russell King 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/5b95730a70f2dafe12d4fbf38d20eb7330d67ba3.1461688545.git.luto@kernel.org
Signed-off-by: Ingo Molnar

ARM: 8531/1: turn init_new_context into an inline function

2016-02-22T16:55:42+00:00

Almost all architectures define init_new_context() as a function,
but on ARM, it's a macro and that causes a compiler warning when
its return code is not used:

drivers/firmware/efi/arm-runtime.c: In function 'efi_virtmap_init':
arch/arm/include/asm/mmu_context.h:88:34: warning: statement with no effect [-Wunused-value]
 #define init_new_context(tsk,mm) 0
drivers/firmware/efi/arm-runtime.c:47:2: note: in expansion of macro 'init_new_context'
  init_new_context(NULL, &efi_mm);

This changes the definition into an inline function, which gcc does
not warn about.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Russell King

ARM: wire up UEFI init and runtime support

2015-12-13T18:18:30+00:00

This adds support to the kernel proper for booting via UEFI. It shares
most of the code with arm64, so this patch mostly just wires it up for
use with ARM.

Note that this does not include the EFI stub, it is added in a subsequent
patch.

Tested-by: Ryan Harkin 
Reviewed-by: Matt Fleming 
Signed-off-by: Ard Biesheuvel

ARM: 7790/1: Fix deferred mm switch on VIVT processors

2013-07-26T11:02:09+00:00

As of commit b9d4d42ad9 (ARM: Remove __ARCH_WANT_INTERRUPTS_ON_CTXSW on
pre-ARMv6 CPUs), the mm switching on VIVT processors is done in the
finish_arch_post_lock_switch() function to avoid whole cache flushing
with interrupts disabled. The need for deferred mm switch is stored as a
thread flag (TIF_SWITCH_MM). However, with preemption enabled, we can
have another thread switch before finish_arch_post_lock_switch(). If the
new thread has the same mm as the previous 'next' thread, the scheduler
will not call switch_mm() and the TIF_SWITCH_MM flag won't be set for
the new thread.

This patch moves the switch pending flag to the mm_context_t structure
since this is specific to the mm rather than thread.

Signed-off-by: Catalin Marinas 
Reported-by: Marc Kleine-Budde 
Tested-by: Marc Kleine-Budde 
Cc:  # 3.5+
Signed-off-by: Russell King

ARM: 7769/1: Cortex-A15: fix erratum 798181 implementation

2013-06-24T14:27:35+00:00

Looking into the active_asids array is not enough, as we also need
to look into the reserved_asids array (they both represent processes
that are currently running).

Also, not holding the ASID allocator lock is racy, as another CPU
could schedule that process and trigger a rollover, making the erratum
workaround miss an IPI.

Exposing this outside of context.c is a little ugly on the side, so
let's define a new entry point that the erratum workaround can call
to obtain the cpumask.

Cc:  # 3.9
Acked-by: Will Deacon 
Acked-by: Catalin Marinas 
Signed-off-by: Marc Zyngier 
Signed-off-by: Russell King

ARM: 7757/1: mm: don't flush icache in switch_mm with hardware broadcasting

2013-06-17T08:27:06+00:00

When scheduling an mm on a CPU where it hasn't previously been used, we
flush the icache on that CPU so that any code loaded previously on
a different core can be safely executed.

For cores with hardware broadcasting of cache maintenance operations,
this is clearly unnecessary, since the inner-shareable invalidation in
__sync_icache_dcache will affect all CPUs.

This patch conditionalises the icache flush in switch_mm based on
cache_ops_need_broadcast().

Acked-by: Catalin Marinas 
Reported-by: Albin Tonnerre 
Signed-off-by: Will Deacon 
Signed-off-by: Russell King

ARM: 7684/1: errata: Workaround for Cortex-A15 erratum 798181 (TLBI/DSB operations)

2013-04-03T15:45:49+00:00

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 
Signed-off-by: Russell King

ARM: 7659/1: mm: make mm->context.id an atomic64_t variable

2013-03-03T22:54:14+00:00

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:  # 3.8
Reviewed-by: Catalin Marinas 
Signed-off-by: Will Deacon 
Signed-off-by: Russell King

ARM: 7582/2: rename kvm_seq to vmalloc_seq so to avoid confusion with KVM

2012-11-26T12:23:53+00:00

The kvm_seq value has nothing to do what so ever with this other KVM.
Given that KVM support on ARM is imminent, it's best to rename kvm_seq
into something else to clearly identify what it is about i.e. a sequence
number for vmalloc section mappings.

Signed-off-by: Nicolas Pitre 
Signed-off-by: Russell King