From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751465AbdKMAzH (ORCPT ); Sun, 12 Nov 2017 19:55:07 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:44210 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751020AbdKMAzF (ORCPT ); Sun, 12 Nov 2017 19:55:05 -0500 Date: Sun, 12 Nov 2017 16:54:51 -0800 From: Ram Pai To: mpe@ellerman.id.au, mingo@redhat.com, akpm@linux-foundation.org, corbet@lwn.net, arnd@arndb.de Cc: linuxppc-dev@lists.ozlabs.org, linux-mm@kvack.org, x86@kernel.org, linux-arch@vger.kernel.org, linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, dave.hansen@intel.com, benh@kernel.crashing.org, paulus@samba.org, khandual@linux.vnet.ibm.com, aneesh.kumar@linux.vnet.ibm.com, bsingharora@gmail.com, hbabu@us.ibm.com, mhocko@kernel.org, bauerman@linux.vnet.ibm.com, ebiederm@xmission.com Subject: Re: [PATCH v9 23/51] powerpc: Enable pkey subsystem Reply-To: Ram Pai References: <1509958663-18737-1-git-send-email-linuxram@us.ibm.com> <1509958663-18737-24-git-send-email-linuxram@us.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1509958663-18737-24-git-send-email-linuxram@us.ibm.com> User-Agent: Mutt/1.5.20 (2009-12-10) X-TM-AS-GCONF: 00 x-cbid: 17111300-8235-0000-0000-00000C8D7697 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00008059; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000239; SDB=6.00945016; UDB=6.00476892; IPR=6.00725313; BA=6.00005688; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00017984; XFM=3.00000015; UTC=2017-11-13 00:55:02 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17111300-8236-0000-0000-00003E6A8301 Message-Id: <20171113005451.GF5546@ram.oc3035372033.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-11-12_10:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711130010 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 06, 2017 at 12:57:15AM -0800, Ram Pai wrote: > PAPR defines 'ibm,processor-storage-keys' property. It exports two > values. The first value holds the number of data-access keys and the > second holds the number of instruction-access keys. Due to a bug in > the firmware, instruction-access keys is always reported as zero. > However any key can be configured to disable data-access and/or disable > execution-access. The inavailablity of the second value is not a > big handicap, though it could have been used to determine if the > platform supported disable-execution-access. > > Non PAPR platforms do not define this property in the device tree yet. > Here, we hardcode CPUs that support pkey by consulting > PowerISA3.0 > > This patch calculates the number of keys supported by the platform. > Alsi it determines the platform support for read/write/execution access > support for pkeys. > > Signed-off-by: Ram Pai > --- > ....snip... > +static inline bool pkey_mmu_enabled(void) > +{ > + if (firmware_has_feature(FW_FEATURE_LPAR)) > + return pkeys_total; > + else > + return cpu_has_feature(CPU_FTR_PKEY); > +} > + > void __init pkey_initialize(void) > { > int os_reserved, i; > @@ -46,14 +54,9 @@ void __init pkey_initialize(void) > __builtin_popcountl(ARCH_VM_PKEY_FLAGS >> VM_PKEY_SHIFT) > != (sizeof(u64) * BITS_PER_BYTE)); > > - /* > - * Disable the pkey system till everything is in place. A subsequent > - * patch will enable it. > - */ > - static_branch_enable(&pkey_disabled); > - > - /* Lets assume 32 keys */ > - pkeys_total = 32; vvvvvvvvvvvvvvvvvvvv > + /* Let's assume 32 keys if we are not told the number of pkeys. */ > + if (!pkeys_total) > + pkeys_total = 32; ^^^^^^^^^^^^^^^^^^^^ There is a small bug here. On a KVM guest or a LPAR, if the device tree does not expose pkeys, the pkey-subsystem must be disabled. Unfortunately, the code above blindly sets the pkeys_total to 32. This confuses pkey_mmu_enabled() into returning true. Because of this bug the guest errorneously enables pkey-subsystem. The fix is to delete the code marked above. > > /* > * Adjust the upper limit, based on the number of bits supported by > @@ -62,11 +65,19 @@ void __init pkey_initialize(void) > pkeys_total = min_t(int, pkeys_total, > (ARCH_VM_PKEY_FLAGS >> VM_PKEY_SHIFT)); > > + if (!pkey_mmu_enabled() || radix_enabled() || !pkeys_total) > + static_branch_enable(&pkey_disabled); > + else > + static_branch_disable(&pkey_disabled); > + RP