Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751238AbdGMIEH (ORCPT ); Thu, 13 Jul 2017 04:04:07 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:37315 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750854AbdGMIEF (ORCPT ); Thu, 13 Jul 2017 04:04:05 -0400 Date: Thu, 13 Jul 2017 01:03:48 -0700 From: Ram Pai To: Dave Hansen Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, x86@kernel.org, linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org, benh@kernel.crashing.org, paulus@samba.org, mpe@ellerman.id.au, khandual@linux.vnet.ibm.com, aneesh.kumar@linux.vnet.ibm.com, bsingharora@gmail.com, hbabu@us.ibm.com, arnd@arndb.de, akpm@linux-foundation.org, corbet@lwn.net, mingo@redhat.com Subject: Re: [RFC v5 34/38] procfs: display the protection-key number associated with a vma Reply-To: Ram Pai References: <1499289735-14220-1-git-send-email-linuxram@us.ibm.com> <1499289735-14220-35-git-send-email-linuxram@us.ibm.com> <8b0827c9-9fc9-c2d5-d1a5-52d9eef8965e@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8b0827c9-9fc9-c2d5-d1a5-52d9eef8965e@intel.com> User-Agent: Mutt/1.5.20 (2009-12-10) X-TM-AS-GCONF: 00 x-cbid: 17071308-0044-0000-0000-0000036D006C X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00007359; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000214; SDB=6.00886880; UDB=6.00442746; IPR=6.00667026; BA=6.00005469; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00016209; XFM=3.00000015; UTC=2017-07-13 08:04:02 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17071308-0045-0000-0000-0000079B04E3 Message-Id: <20170713080348.GH5525@ram.oc3035372033.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-07-13_03:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707130125 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 912 Lines: 25 On Tue, Jul 11, 2017 at 11:13:56AM -0700, Dave Hansen wrote: > On 07/05/2017 02:22 PM, Ram Pai wrote: > > +#ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS > > +void arch_show_smap(struct seq_file *m, struct vm_area_struct *vma) > > +{ > > + seq_printf(m, "ProtectionKey: %8u\n", vma_pkey(vma)); > > +} > > +#endif /* CONFIG_PPC64_MEMORY_PROTECTION_KEYS */ > > This seems like kinda silly unnecessary duplication. Could we just put > this in the fs/proc/ code and #ifdef it on ARCH_HAS_PKEYS? Well x86 predicates it based on availability of X86_FEATURE_OSPKE. powerpc doesn't need that check or any similar check. So trying to generalize the code does not save much IMHO. maybe have a seperate inline function that does seq_printf(m, "ProtectionKey: %8u\n", vma_pkey(vma)); and is called from x86 and powerpc's arch_show_smap()? At least will keep the string format captured in one single place. thoughts? RP