From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752795AbaILUdG (ORCPT ); Fri, 12 Sep 2014 16:33:06 -0400 Received: from mga02.intel.com ([134.134.136.20]:35098 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752001AbaILUdE (ORCPT ); Fri, 12 Sep 2014 16:33:04 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.04,515,1406617200"; d="scan'208";a="572476577" Message-ID: <5413587E.4000303@intel.com> Date: Fri, 12 Sep 2014 13:33:02 -0700 From: Dave Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Thomas Gleixner CC: Qiaowei Ren , "H. Peter Anvin" , Ingo Molnar , x86@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v8 08/10] x86, mpx: add prctl commands PR_MPX_REGISTER, PR_MPX_UNREGISTER References: <1410425210-24789-1-git-send-email-qiaowei.ren@intel.com> <1410425210-24789-9-git-send-email-qiaowei.ren@intel.com> <541239F1.2000508@intel.com> <54130F9A.3000406@intel.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/12/2014 10:42 AM, Thomas Gleixner wrote: > On Fri, 12 Sep 2014, Dave Hansen wrote: >> The prctl(register) is meant to be a signal from userspace to the kernel >> to say, "I would like your help in managing these bounds tables". >> prctl(unregister) is the opposite, meaning "I don't want your help any >> more". > > Fine, but that's a totally different story. I can see the usefulness > of this, but then it's a complete misnomer. It should be: > > prctl(EN/DISABLE_MPX_BT_MANAGEMENT) Agreed. Those are much better names. > So this wants to be a boolean value and not some random user space > address collected at some random point and then ignored until you do > the magic cleanup. See the other reply. I know at this point you think the kernel can not or should not keep a copy of the bounds directory location around. I understand that. Bear with me for a moment, and please just assume for a moment that we need it. It's far from a random userspace address. When you make a syscall, we put the arguments in registers. The register we're putting it in here just happens to be used by the hardware. Right now, we do (ignoring the actual xsave/xrstr): bndcfgu = bnd_dir_ptr | ENABLE_BIT; prctl(ENABLE_MPX_BT_MANAGEMENT); // kernel grabs from xsave buf We could pass it explicitly in %rdi as a syscall argument and not have the prctl() code fetch it from the xsave buffer. I'm just not sure what this buys us: bndcfgu = bnd_dir_ptr | ENABLE_BIT; prctl(ENABLE_MPX_BT_MANAGEMENT, bndcfgu); Also, the "random cleanup" just happens to correspond with memory deallocation, which is something we want to go fast. I'd _prefer_ to keep xsaves out of the unmap path if possible. It's not a strict requirement, but it does seem prudent as an xsave eats a dozen or so cachelines. It's also not "sampled". I can't imagine a situation where the register will change values during the execution of any sane program. It really is essentially fixed. It's probably one of the reasons it is so expensive to access: there's *no* reason to do it frequently. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) by kanga.kvack.org (Postfix) with ESMTP id 5DDB86B003C for ; Fri, 12 Sep 2014 16:33:05 -0400 (EDT) Received: by mail-pa0-f53.google.com with SMTP id rd3so2030767pab.12 for ; Fri, 12 Sep 2014 13:33:04 -0700 (PDT) Received: from mga02.intel.com (mga02.intel.com. [134.134.136.20]) by mx.google.com with ESMTP id gp10si10118635pbd.32.2014.09.12.13.33.03 for ; Fri, 12 Sep 2014 13:33:04 -0700 (PDT) Message-ID: <5413587E.4000303@intel.com> Date: Fri, 12 Sep 2014 13:33:02 -0700 From: Dave Hansen MIME-Version: 1.0 Subject: Re: [PATCH v8 08/10] x86, mpx: add prctl commands PR_MPX_REGISTER, PR_MPX_UNREGISTER References: <1410425210-24789-1-git-send-email-qiaowei.ren@intel.com> <1410425210-24789-9-git-send-email-qiaowei.ren@intel.com> <541239F1.2000508@intel.com> <54130F9A.3000406@intel.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Thomas Gleixner Cc: Qiaowei Ren , "H. Peter Anvin" , Ingo Molnar , x86@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org On 09/12/2014 10:42 AM, Thomas Gleixner wrote: > On Fri, 12 Sep 2014, Dave Hansen wrote: >> The prctl(register) is meant to be a signal from userspace to the kernel >> to say, "I would like your help in managing these bounds tables". >> prctl(unregister) is the opposite, meaning "I don't want your help any >> more". > > Fine, but that's a totally different story. I can see the usefulness > of this, but then it's a complete misnomer. It should be: > > prctl(EN/DISABLE_MPX_BT_MANAGEMENT) Agreed. Those are much better names. > So this wants to be a boolean value and not some random user space > address collected at some random point and then ignored until you do > the magic cleanup. See the other reply. I know at this point you think the kernel can not or should not keep a copy of the bounds directory location around. I understand that. Bear with me for a moment, and please just assume for a moment that we need it. It's far from a random userspace address. When you make a syscall, we put the arguments in registers. The register we're putting it in here just happens to be used by the hardware. Right now, we do (ignoring the actual xsave/xrstr): bndcfgu = bnd_dir_ptr | ENABLE_BIT; prctl(ENABLE_MPX_BT_MANAGEMENT); // kernel grabs from xsave buf We could pass it explicitly in %rdi as a syscall argument and not have the prctl() code fetch it from the xsave buffer. I'm just not sure what this buys us: bndcfgu = bnd_dir_ptr | ENABLE_BIT; prctl(ENABLE_MPX_BT_MANAGEMENT, bndcfgu); Also, the "random cleanup" just happens to correspond with memory deallocation, which is something we want to go fast. I'd _prefer_ to keep xsaves out of the unmap path if possible. It's not a strict requirement, but it does seem prudent as an xsave eats a dozen or so cachelines. It's also not "sampled". I can't imagine a situation where the register will change values during the execution of any sane program. It really is essentially fixed. It's probably one of the reasons it is so expensive to access: there's *no* reason to do it frequently. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org