From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: ACJfBou3WfUL5n3/c/AKFvIotTGH/oK5gqNavshw4oG/rVV3G7GnAr/bCmsLTehY6p3BA9ifh+ak ARC-Seal: i=1; a=rsa-sha256; t=1516380677; cv=none; d=google.com; s=arc-20160816; b=pbdaGXpdV41bAAGQ7DGv/McaaX4+QTj/IBZdSid13+QMvvgBteDFnT2WZmKuX+TUIo vq1tb9OLziOi2JGeFBUTaZ1bDaH6vHcazXVcgN9yq9KmJKewTXPO0ejAXzrkavALXr3B gtLb1CXVsm7C8VYNbdksZ2WyfAypuKlx9p7oTflg1KILPlGNU2iQWLHTIdOlqSmGJa9G c14uaX3WK/QZAmL3iyUO8oNzl3EpIHyuDKRWheXqyBfD4mGgE9Bb74y/0AIiHIP0586V 1twTJwVxKxMsk8HVUsdJ0P2oSdnvyi2cR7WWHS9sHlp2xKQ2TvDJksihblui5Vh9MG3U TDSg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:user-agent:in-reply-to :content-disposition:mime-version:references:reply-to:subject:cc:to :from:date:arc-authentication-results; bh=rK+ntsbjJIF7pRhnCniqtWJHuQEuIBpTfjh+yLxWPsk=; b=VRMGQv0L0IqyaMKVrOxBfkFtGqoArSmyjDai6D6NuUTSxxIzstqH8PGPjhtAqualVP +QpfvhkPGk5orq/rDn9CoQAgQRkh+6SAw3DHepWOOIm5o3tKpDNCKcy/Y4HmkK1YrCWB rfwCBmcDfFoMI+3OorcuaH6gd5IeZoynCQ/XucvbnETibV6MmfQJHsos5z9SSjSSZVEn i/pddn5TH4YUX47XDrhhe/zi+wfyGajIg5XxVx1Trzjs/hTqwihLiWtseNPG2FpPBDdV dL8w0K9wvn5Z4o3BBmmHpmBZmbtaURHFDMo8OWCmoxznMLSyU+7JYUqlBS96v8m3XzLY ewFA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kselftest-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kselftest-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ibm.com Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kselftest-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kselftest-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ibm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755775AbeASQvQ (ORCPT ); Fri, 19 Jan 2018 11:51:16 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:41400 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756071AbeASQvP (ORCPT ); Fri, 19 Jan 2018 11:51:15 -0500 Date: Fri, 19 Jan 2018 08:50:50 -0800 From: Ram Pai To: "Eric W. Biederman" Cc: mpe@ellerman.id.au, mingo@redhat.com, akpm@linux-foundation.org, corbet@lwn.net, arnd@arndb.de, 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 Subject: Re: [PATCH v10 27/27] mm: display pkey in smaps if arch_pkeys_enabled() is true Reply-To: Ram Pai References: <1516326648-22775-1-git-send-email-linuxram@us.ibm.com> <1516326648-22775-28-git-send-email-linuxram@us.ibm.com> <87shb1de4a.fsf@xmission.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87shb1de4a.fsf@xmission.com> User-Agent: Mutt/1.5.20 (2009-12-10) X-TM-AS-GCONF: 00 x-cbid: 18011916-0012-0000-0000-000005A5AB74 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18011916-0013-0000-0000-000019212AAB Message-Id: <20180119165050.GK5612@ram.oc3035372033.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-01-19_06:,, 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=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1801190220 Sender: linux-kselftest-owner@vger.kernel.org X-Mailing-List: linux-kselftest@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1589983964716042571?= X-GMAIL-MSGID: =?utf-8?q?1590040385083475489?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On Fri, Jan 19, 2018 at 10:09:41AM -0600, Eric W. Biederman wrote: > Ram Pai writes: > > > Currently the architecture specific code is expected to > > display the protection keys in smap for a given vma. > > This can lead to redundant code and possibly to divergent > > formats in which the key gets displayed. > > > > This patch changes the implementation. It displays the > > pkey only if the architecture support pkeys. > > > > x86 arch_show_smap() function is not needed anymore. > > Delete it. > > > > Signed-off-by: Ram Pai > > --- > > arch/x86/kernel/setup.c | 8 -------- > > fs/proc/task_mmu.c | 11 ++++++----- > > 2 files changed, 6 insertions(+), 13 deletions(-) > > > > diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c > > index 8af2e8d..ddf945a 100644 > > --- a/arch/x86/kernel/setup.c > > +++ b/arch/x86/kernel/setup.c > > @@ -1326,11 +1326,3 @@ static int __init register_kernel_offset_dumper(void) > > return 0; > > } > > __initcall(register_kernel_offset_dumper); > > - > > -void arch_show_smap(struct seq_file *m, struct vm_area_struct *vma) > > -{ > > - if (!boot_cpu_has(X86_FEATURE_OSPKE)) > > - return; > > - > > - seq_printf(m, "ProtectionKey: %8u\n", vma_pkey(vma)); > > -} > > diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c > > index 0edd4da..4b39a94 100644 > > --- a/fs/proc/task_mmu.c > > +++ b/fs/proc/task_mmu.c > > @@ -18,6 +18,7 @@ > > #include > > #include > > #include > > +#include > > > > #include > > #include > > @@ -728,10 +729,6 @@ static int smaps_hugetlb_range(pte_t *pte, unsigned long hmask, > > } > > #endif /* HUGETLB_PAGE */ > > > > -void __weak arch_show_smap(struct seq_file *m, struct vm_area_struct *vma) > > -{ > > -} > > - > > static int show_smap(struct seq_file *m, void *v, int is_pid) > > { > > struct proc_maps_private *priv = m->private; > > @@ -851,9 +848,13 @@ static int show_smap(struct seq_file *m, void *v, int is_pid) > > (unsigned long)(mss->pss >> (10 + PSS_SHIFT))); > > > > if (!rollup_mode) { > > - arch_show_smap(m, vma); > > +#ifdef CONFIG_ARCH_HAS_PKEYS > > + if (arch_pkeys_enabled()) > > + seq_printf(m, "ProtectionKey: %8u\n", vma_pkey(vma)); > > +#endif > > Would it be worth it making vma_pkey a noop on architectures that don't > support protection keys so that we don't need the #ifdef here? You mean something like this? #define vma_pkey(vma) It will lead to compilation error. I can make it #define vma_pkey(vma) 0 and that will work and get rid of the #ifdef RP