From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752730AbdIVQsJ (ORCPT ); Fri, 22 Sep 2017 12:48:09 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:50112 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752430AbdIVQsF (ORCPT ); Fri, 22 Sep 2017 12:48:05 -0400 Date: Fri, 22 Sep 2017 09:47:52 -0700 From: Ram Pai To: Balbir Singh Cc: mpe@ellerman.id.au, 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, arnd@arndb.de, akpm@linux-foundation.org, corbet@lwn.net, mingo@redhat.com, benh@kernel.crashing.org, paulus@samba.org, khandual@linux.vnet.ibm.com, aneesh.kumar@linux.vnet.ibm.com, hbabu@us.ibm.com, mhocko@kernel.org, bauerman@linux.vnet.ibm.com, ebiederm@xmission.com, dave.hansen@intel.com Subject: Re: [PATCH 4/6] mm/mprotect, powerpc/mm/pkeys, x86/mm/pkeys: Add sysfs interface Reply-To: Ram Pai References: <1505524870-4783-1-git-send-email-linuxram@us.ibm.com> <1505524870-4783-5-git-send-email-linuxram@us.ibm.com> <20170922160019.0d6d1eae@firefly.ozlabs.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170922160019.0d6d1eae@firefly.ozlabs.ibm.com> User-Agent: Mutt/1.5.20 (2009-12-10) X-TM-AS-GCONF: 00 x-cbid: 17092216-0020-0000-0000-00000CBFA80C X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00007778; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000231; SDB=6.00920790; UDB=6.00462713; IPR=6.00701011; BA=6.00005601; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00017249; XFM=3.00000015; UTC=2017-09-22 16:48:03 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17092216-0021-0000-0000-00005E3C5DBD Message-Id: <20170922164752.GQ5698@ram.oc3035372033.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-09-22_06:,, 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-1707230000 definitions=main-1709220236 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 22, 2017 at 04:00:19PM +1000, Balbir Singh wrote: > On Fri, 15 Sep 2017 18:21:08 -0700 > Ram Pai wrote: > > > From: Thiago Jung Bauermann > > > > Expose useful information for programs using memory protection keys. > > Provide implementation for powerpc and x86. > > > > On a powerpc system with pkeys support, here is what is shown: > > > > $ head /sys/kernel/mm/protection_keys/* > > ==> /sys/kernel/mm/protection_keys/disable_access_supported <== > > true > > > > ==> /sys/kernel/mm/protection_keys/disable_execute_supported <== > > true > > > > ==> /sys/kernel/mm/protection_keys/disable_write_supported <== > > true > > > > ==> /sys/kernel/mm/protection_keys/total_keys <== > > 32 > > > > ==> /sys/kernel/mm/protection_keys/usable_keys <== > > 29 > > > > And on an x86 without pkeys support: > > > > $ head /sys/kernel/mm/protection_keys/* > > ==> /sys/kernel/mm/protection_keys/disable_access_supported <== > > false > > > > ==> /sys/kernel/mm/protection_keys/disable_execute_supported <== > > false > > > > ==> /sys/kernel/mm/protection_keys/disable_write_supported <== > > false > > > > ==> /sys/kernel/mm/protection_keys/total_keys <== > > 1 > > > > ==> /sys/kernel/mm/protection_keys/usable_keys <== > > 0 > > > > Signed-off-by: Ram Pai > > Signed-off-by: Thiago Jung Bauermann > > --- > > Just curious, how do you see this being used? > For debugging or will applications parse these properties and use them? Its upto the application to determine the best way to fully exploit all the keys. But that cannot happen if the application has no easy way to determine the number of available keys. > It's hard for an application to partition its address space > among keys at runtime, would you agree? Why would it be hard? Because the application may not know; in advance, the range of its address space? Well that is true. But that may not be the best strategy. It should not be based on how large its address space range is, rather it should be based on how many unique access-domains it will need. It can associate a key with each domain and it can associate address-ranges to the appropriate domains. The more the number of keys the more the number of access-domains and finer the control. > > Balbir Singh. -- Ram Pai