linux_dsm_epyc7002/arch
Heiko Carstens a2308c11ec s390/smp,vdso: fix ASCE handling
When a secondary CPU is brought up it must initialize its control
registers. CPU A which triggers that a secondary CPU B is brought up
stores its control register contents into the lowcore of new CPU B,
which then loads these values on startup.

This is problematic in various ways: the control register which
contains the home space ASCE will correctly contain the kernel ASCE;
however control registers for primary and secondary ASCEs are
initialized with whatever values were present in CPU A.

Typically:
- the primary ASCE will contain the user process ASCE of the process
  that triggered onlining of CPU B.
- the secondary ASCE will contain the percpu VDSO ASCE of CPU A.

Due to lazy ASCE handling we may also end up with other combinations.

When then CPU B switches to a different process (!= idle) it will
fixup the primary ASCE. However the problem is that the (wrong) ASCE
from CPU A was loaded into control register 1: as soon as an ASCE is
attached (aka loaded) a CPU is free to generate TLB entries using that
address space.
Even though it is very unlikey that CPU B will actually generate such
entries, this could result in TLB entries of the address space of the
process that ran on CPU A. These entries shouldn't exist at all and
could cause problems later on.

Furthermore the secondary ASCE of CPU B will not be updated correctly.
This means that processes may see wrong results or even crash if they
access VDSO data on CPU B. The correct VDSO ASCE will eventually be
loaded on return to user space as soon as the kernel executed a call
to strnlen_user or an atomic futex operation on CPU B.

Fix both issues by intializing the to be loaded control register
contents with the correct ASCEs and also enforce (re-)loading of the
ASCEs upon first context switch and return to user space.

Fixes: 0aaba41b58 ("s390: remove all code using the access register mode")
Cc: stable@vger.kernel.org # v4.15+
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-11-30 10:52:44 +01:00
..
alpha mm: introduce MADV_PAGEOUT 2019-09-25 17:51:41 -07:00
arc ARC: perf: Accommodate big-endian CPU 2019-10-22 09:59:43 -07:00
arm arm64 updates for 5.5: 2019-11-25 15:39:19 -08:00
arm64 arm64 updates for 5.5: 2019-11-25 15:39:19 -08:00
c6x mm: consolidate pgtable_cache_init() and pgd_cache_init() 2019-09-24 15:54:09 -07:00
csky csky-for-linus-5.4-rc1: arch/csky patches for 5.4-rc1 2019-09-30 10:16:17 -07:00
h8300 mm: consolidate pgtable_cache_init() and pgd_cache_init() 2019-09-24 15:54:09 -07:00
hexagon mm: treewide: clarify pgtable_page_{ctor,dtor}() naming 2019-09-26 10:10:44 -07:00
ia64 Merge branch 'akpm' (patches from Andrew) 2019-09-24 16:10:23 -07:00
m68k mm: treewide: clarify pgtable_page_{ctor,dtor}() naming 2019-09-26 10:10:44 -07:00
microblaze Merge branch 'akpm' (patches from Andrew) 2019-09-24 16:10:23 -07:00
mips A fix & simplification for SGI IP27 exception handlers, and a small 2019-11-15 09:10:13 -08:00
nds32 mm: consolidate pgtable_cache_init() and pgd_cache_init() 2019-09-24 15:54:09 -07:00
nios2 nios2 update for v5.4-rc1 2019-09-27 13:02:19 -07:00
openrisc mm: treewide: clarify pgtable_page_{ctor,dtor}() naming 2019-09-26 10:10:44 -07:00
parisc arm64 updates for 5.5: 2019-11-25 15:39:19 -08:00
powerpc arm64 updates for 5.5: 2019-11-25 15:39:19 -08:00
riscv RISC-V: Add PCIe I/O BAR memory mapping 2019-10-28 10:43:32 -07:00
s390 s390/smp,vdso: fix ASCE handling 2019-11-30 10:52:44 +01:00
sh mm: treewide: clarify pgtable_page_{ctor,dtor}() naming 2019-09-26 10:10:44 -07:00
sparc sparc: vdso: fix build error of vdso32 2019-11-15 00:12:28 +09:00
um linux-kselftest-5.5-rc1-kunit 2019-11-25 15:01:30 -08:00
unicore32 mm: treewide: clarify pgtable_page_{ctor,dtor}() naming 2019-09-26 10:10:44 -07:00
x86 arm64 updates for 5.5: 2019-11-25 15:39:19 -08:00
xtensa xtensa: fix change_bit in exclusive access option 2019-10-16 00:14:33 -07:00
.gitignore
Kconfig arm64, mm: make randomization selected by generic topdown mmap layout 2019-09-24 15:54:11 -07:00