Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755768AbdLTRuh (ORCPT ); Wed, 20 Dec 2017 12:50:37 -0500 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:36466 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1755495AbdLTRuf (ORCPT ); Wed, 20 Dec 2017 12:50:35 -0500 Date: Wed, 20 Dec 2017 09:50:22 -0800 From: Ram Pai To: Benjamin Herrenschmidt Cc: Dave Hansen , 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, 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 29/51] mm/mprotect, powerpc/mm/pkeys, x86/mm/pkeys: Add sysfs interface Reply-To: Ram Pai References: <1509958663-18737-1-git-send-email-linuxram@us.ibm.com> <1509958663-18737-30-git-send-email-linuxram@us.ibm.com> <20171218221850.GD5461@ram.oc3035372033.ibm.com> <1513719296.2743.12.camel@kernel.crashing.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1513719296.2743.12.camel@kernel.crashing.org> User-Agent: Mutt/1.5.20 (2009-12-10) X-TM-AS-GCONF: 00 x-cbid: 17122017-0016-0000-0000-00000800B101 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00008234; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000244; SDB=6.00963055; UDB=6.00487179; IPR=6.00743047; BA=6.00005752; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00018644; XFM=3.00000015; UTC=2017-12-20 17:50:33 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17122017-0017-0000-0000-00003CB8EC9E Message-Id: <20171220175022.GB5619@ram.oc3035372033.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-12-20_07:,, 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-1709140000 definitions=main-1712200254 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1903 Lines: 48 On Wed, Dec 20, 2017 at 08:34:56AM +1100, Benjamin Herrenschmidt wrote: > On Mon, 2017-12-18 at 14:28 -0800, Dave Hansen wrote: > > > We do not have generic support for something like that on ppc. > > > The kernel looks at the device tree to determine what hardware features > > > are available. But does not have mechanism to tell the hardware to track > > > which of its features are currently enabled/used by the kernel; atleast > > > not for the memory-key feature. > > > > Bummer. You're missing out. > > > > But, you could still do this with a syscall. "Hey, kernel, do you > > support this feature?" > > I'm not sure I understand Ram's original (quoted) point, but informing > userspace of CPU features is what AT_HWCAP's are about. Ben, my original point was -- we developed this patch to satisfy a concern you raised back on July 11th; cut-n-pasted below. ------------------------------------------------------------------- That leads to the question... How do you tell userspace. (apologies if I missed that in an existing patch in the series) How do we inform userspace of the key capabilities ? There are at least two things userspace may want to know already: - What protection bits are supported for a key - How many keys exist - Which keys are available for use by userspace. On PowerPC, the kernel can reserve some keys for itself, so can the hypervisor. In fact, they do. -------------------------------------------------------------------- The argument against this patch is -- it should not be baked into the ABI as yet, since we do not have clarity on what applications need. As it stands today the only way to figure out the information from userspace is by probing the kernel through calls to sys_pkey_alloc(). AT_HWCAP can be used, but that will certainly not be capable of providing all the information that userspace might expect. Your thoughts? RP