From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id ED8E9C43603 for ; Mon, 16 Dec 2019 18:07:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C42C7206EC for ; Mon, 16 Dec 2019 18:07:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1576519638; bh=ANH0VcugweeincgOiV0mn2GBO2ma/dBvXSix39HMcKE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=uwNYC9BTU3upwTG7nXebkJguZ1jCXQMWEkXbMDSQsocqWI1dDSa/XAqcAnEcjz2EA Y0J4BdqG9CW3thz61ojDOyl03QB5Cy75Lic4Gu6oFCDFHnU/Z8O4Lw1Sh8cHuO38u0 9kadiBNNDJ8mrzicNsJ2SPDvI5X88+IPLZsss2oc= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729539AbfLPSHR (ORCPT ); Mon, 16 Dec 2019 13:07:17 -0500 Received: from mail.kernel.org ([198.145.29.99]:48144 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730123AbfLPSHQ (ORCPT ); Mon, 16 Dec 2019 13:07:16 -0500 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id CA0C0206EC; Mon, 16 Dec 2019 18:07:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1576519635; bh=ANH0VcugweeincgOiV0mn2GBO2ma/dBvXSix39HMcKE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=teIX5ryvZoFnQLVuaiPaJEBZKhEm674Y9y3fjTPZ7OrbUJEBMzSVreu8H7EHOVK0E Gjp5sO6FRnd3x3tKdQQfTV8ZmBQnQGi8osvIWV5BJgruFF2BMGcfo5xyO2/cNulbwz jEW3l+ta7ZKsyYvHJ21shRr0FTYNzFAx1rHHNTV0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Heiko Carstens , Vasily Gorbik , Sasha Levin Subject: [PATCH 4.19 140/140] s390/smp,vdso: fix ASCE handling Date: Mon, 16 Dec 2019 18:50:08 +0100 Message-Id: <20191216174829.844659796@linuxfoundation.org> X-Mailer: git-send-email 2.24.1 In-Reply-To: <20191216174747.111154704@linuxfoundation.org> References: <20191216174747.111154704@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Heiko Carstens [ Upstream commit a2308c11ecbc3471ebb7435ee8075815b1502ef0 ] 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 Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin --- arch/s390/kernel/smp.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/arch/s390/kernel/smp.c b/arch/s390/kernel/smp.c index da02f4087d61f..df2413f26a8f2 100644 --- a/arch/s390/kernel/smp.c +++ b/arch/s390/kernel/smp.c @@ -261,9 +261,12 @@ static void pcpu_prepare_secondary(struct pcpu *pcpu, int cpu) lc->spinlock_index = 0; lc->percpu_offset = __per_cpu_offset[cpu]; lc->kernel_asce = S390_lowcore.kernel_asce; + lc->user_asce = S390_lowcore.kernel_asce; lc->machine_flags = S390_lowcore.machine_flags; lc->user_timer = lc->system_timer = lc->steal_timer = 0; __ctl_store(lc->cregs_save_area, 0, 15); + lc->cregs_save_area[1] = lc->kernel_asce; + lc->cregs_save_area[7] = lc->vdso_asce; save_access_regs((unsigned int *) lc->access_regs_save_area); memcpy(lc->stfle_fac_list, S390_lowcore.stfle_fac_list, sizeof(lc->stfle_fac_list)); @@ -810,6 +813,8 @@ static void smp_start_secondary(void *cpuvoid) restore_access_regs(S390_lowcore.access_regs_save_area); __ctl_load(S390_lowcore.cregs_save_area, 0, 15); __load_psw_mask(PSW_KERNEL_BITS | PSW_MASK_DAT); + set_cpu_flag(CIF_ASCE_PRIMARY); + set_cpu_flag(CIF_ASCE_SECONDARY); cpu_init(); preempt_disable(); init_cpu_timer(); -- 2.20.1