Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp1893192pxk; Tue, 1 Sep 2020 10:10:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzumn38u1i1aMClNaTQmcUPd1X04uzOXYBiMxqdzUKcJzTxFgyHRKIUdpehJPPfOpu2m3wq X-Received: by 2002:a17:906:b154:: with SMTP id bt20mr2615891ejb.272.1598980251152; Tue, 01 Sep 2020 10:10:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598980251; cv=none; d=google.com; s=arc-20160816; b=or7PIHO8gTrKgKBwPawFtAgHjU++MXPLkxwg0meh17GE3kXzasff6gzCX7dToBFSSy IDzH909L9hv9WLhmiAkJZItEDXEPhlJoZ9Tm2u8+vv/4NAT1odAjGPpbOOuA+1E+ZeAz YO/C4psp6jR+aMy1udn7Dd/xsSe1veZJx8tjY60USIH8xDz2jVbo1SeeTce9iMyKGRBc Dl3BgmZcLbHaKEYeZAVpig5a+fE47ETPT2lHOLsCsS/t5UDXnsybUtoGUJnUew/1iwZc RXV2K4Z9qd5ermviuEnZPa6YIBVSkyhNrCV2tqzlB56i6sVfMzYpTuTZFjNaX+fUQqoR IRzw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=1nSJyhOf9cs+31l4jJtgacxRzuK/hxmLmLZTmG1QkOo=; b=I8XvvVMoHo9KuUr/4Ik8QBw9drcHcIXvpgAXzUqfTzyri3CJAjJnU/8PVA9XYMqcOT Z29KVQQpJOT0yWgACY+hPBY1SChfEyIQGJTuGp9eoZot0zm1/sB5F9BuISoQ3znECabC oo+LZ45MoIGkqK2QIFblw+S5bRfSpziOzoXt4DrnnCqTX5YoXm6DVbgZPtAZRSv36OcO LgojHNGWHJ2QaOjnos8hvoUDn8cEpl95ErFYAIad7v6uQDreOSakF+k8VLJfMMKqwstV nH9tZ4q2VwBgJY9S8z+cH9fEOwhoTnRyxD2GqeX8kmOGcoKIUvOzybpW+OVPaqMA9s5l WRgw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=LLfD2o9q; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k1si962013ejp.718.2020.09.01.10.10.27; Tue, 01 Sep 2020 10:10:51 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=LLfD2o9q; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731917AbgIARJU (ORCPT + 99 others); Tue, 1 Sep 2020 13:09:20 -0400 Received: from mail.kernel.org ([198.145.29.99]:35308 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729041AbgIAPRn (ORCPT ); Tue, 1 Sep 2020 11:17:43 -0400 Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) (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 4D080206EB; Tue, 1 Sep 2020 15:17:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598973462; bh=Ltr/3vGVaMTyXTjP45tQiAyg7242z7/wrBrsLCFjBBQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=LLfD2o9qn696nn5u+5wMYPFyDhetbC2RIv/Du2AIqzxAIrZF5tU+IbmmyfCIS1Rra eLXYvS68Dhv9xfflSMiF/izqTzvSXWZ/UrTVFt2ecaD8cWlQdFr8IqNN8Y9Znc2tr6 FaWIOTnrcSsrhzplBfPrp900TgRJ+xFkeLxqFZws= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Michael Ellerman , Alistair Popple , Thadeu Lima de Souza Cascardo Subject: [PATCH 4.14 01/91] powerpc/64s: Dont init FSCR_DSCR in __init_FSCR() Date: Tue, 1 Sep 2020 17:09:35 +0200 Message-Id: <20200901150928.189143079@linuxfoundation.org> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20200901150928.096174795@linuxfoundation.org> References: <20200901150928.096174795@linuxfoundation.org> User-Agent: quilt/0.66 X-stable: review X-Patchwork-Hint: ignore 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: Michael Ellerman commit 0828137e8f16721842468e33df0460044a0c588b upstream. __init_FSCR() was added originally in commit 2468dcf641e4 ("powerpc: Add support for context switching the TAR register") (Feb 2013), and only set FSCR_TAR. At that point FSCR (Facility Status and Control Register) was not context switched, so the setting was permanent after boot. Later we added initialisation of FSCR_DSCR to __init_FSCR(), in commit 54c9b2253d34 ("powerpc: Set DSCR bit in FSCR setup") (Mar 2013), again that was permanent after boot. Then commit 2517617e0de6 ("powerpc: Fix context switch DSCR on POWER8") (Aug 2013) added a limited context switch of FSCR, just the FSCR_DSCR bit was context switched based on thread.dscr_inherit. That commit said "This clears the H/FSCR DSCR bit initially", but it didn't, it left the initialisation of FSCR_DSCR in __init_FSCR(). However the initial context switch from init_task to pid 1 would clear FSCR_DSCR because thread.dscr_inherit was 0. That commit also introduced the requirement that FSCR_DSCR be clear for user processes, so that we can take the facility unavailable interrupt in order to manage dscr_inherit. Then in commit 152d523e6307 ("powerpc: Create context switch helpers save_sprs() and restore_sprs()") (Dec 2015) FSCR was added to thread_struct. However it still wasn't fully context switched, we just took the existing value and set FSCR_DSCR if the new thread had dscr_inherit set. FSCR was still initialised at boot to FSCR_DSCR | FSCR_TAR, but that value was not propagated into the thread_struct, so the initial context switch set FSCR_DSCR back to 0. Finally commit b57bd2de8c6c ("powerpc: Improve FSCR init and context switching") (Jun 2016) added a full context switch of the FSCR, and added an initialisation of init_task.thread.fscr to FSCR_TAR | FSCR_EBB, but omitted FSCR_DSCR. The end result is that swapper runs with FSCR_DSCR set because of the initialisation in __init_FSCR(), but no other processes do, they use the value from init_task.thread.fscr. Having FSCR_DSCR set for swapper allows it to access SPR 3 from userspace, but swapper never runs userspace, so it has no useful effect. It's also confusing to have the value initialised in two places to two different values. So remove FSCR_DSCR from __init_FSCR(), this at least gets us to the point where there's a single value of FSCR, even if it's still set in two places. Signed-off-by: Michael Ellerman Tested-by: Alistair Popple Link: https://lore.kernel.org/r/20200527145843.2761782-1-mpe@ellerman.id.au Cc: Thadeu Lima de Souza Cascardo Signed-off-by: Greg Kroah-Hartman --- arch/powerpc/kernel/cpu_setup_power.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/powerpc/kernel/cpu_setup_power.S +++ b/arch/powerpc/kernel/cpu_setup_power.S @@ -189,7 +189,7 @@ __init_LPCR_ISA300: __init_FSCR: mfspr r3,SPRN_FSCR - ori r3,r3,FSCR_TAR|FSCR_DSCR|FSCR_EBB + ori r3,r3,FSCR_TAR|FSCR_EBB mtspr SPRN_FSCR,r3 blr