Re: FAILED: patch "[PATCH] s390/smp,vdso: fix ASCE handling" failed to apply to 4.19-stable tree

[Sasha Levin <sashal@kernel.org>]

On Mon, Dec 16, 2019 at 02:10:23PM +0100, gregkh@linuxfoundation.org wrote:
>
>The patch below does not apply to the 4.19-stable tree.
>If someone wants it applied there, or to any other stable or longterm
>tree, then please email the backport, including the original git commit
>id to <stable@vger.kernel.org>.
>
>thanks,
>
>greg k-h
>
>------------------ original commit in Linus's tree ------------------
>
>From a2308c11ecbc3471ebb7435ee8075815b1502ef0 Mon Sep 17 00:00:00 2001
>From: Heiko Carstens <heiko.carstens@de.ibm.com>
>Date: Mon, 18 Nov 2019 13:09:52 +0100
>Subject: [PATCH] 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: 0aaba41b58bc ("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>

Adjusted context for missing ce3dc447493f ("s390: add support for
virtually mapped kernel stacks") in 4.19 and queued up.

-- 
Thanks,
Sasha