From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754315AbdA0I1J (ORCPT ); Fri, 27 Jan 2017 03:27:09 -0500 Received: from mail-wm0-f66.google.com ([74.125.82.66]:36054 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754268AbdA0I1G (ORCPT ); Fri, 27 Jan 2017 03:27:06 -0500 Date: Fri, 27 Jan 2017 09:26:30 +0100 From: Ingo Molnar To: Dave Hansen Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, x86@kernel.org Subject: Re: [RFC][PATCH 1/4] x86, mpx: introduce per-mm MPX table size tracking Message-ID: <20170127082629.GB25162@gmail.com> References: <20170126224005.A6BBEF2C@viggo.jf.intel.com> <20170126224006.DED9C8D3@viggo.jf.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170126224006.DED9C8D3@viggo.jf.intel.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Dave Hansen wrote: > Larger address spaces mean larger MPX bounds table sizes. This > tracks which size tables we are using. > > "MAWA" is what the hardware documentation calls this feature: > MPX Address-Width Adjust. We will carry that nomenclature throughout > this series. > > The new field will be optimized and get packed into 'bd_addr' in a later > patch. But, leave it separate for now to make the series simpler. > > --- > > b/arch/x86/include/asm/mmu.h | 1 + > b/arch/x86/include/asm/mpx.h | 9 +++++++++ > 2 files changed, 10 insertions(+) > > diff -puN arch/x86/include/asm/mmu.h~mawa-020-mmu_context-mawa arch/x86/include/asm/mmu.h > --- a/arch/x86/include/asm/mmu.h~mawa-020-mmu_context-mawa 2017-01-26 14:31:32.643673297 -0800 > +++ b/arch/x86/include/asm/mmu.h 2017-01-26 14:31:32.647673476 -0800 > @@ -34,6 +34,7 @@ typedef struct { > #ifdef CONFIG_X86_INTEL_MPX > /* address of the bounds directory */ > void __user *bd_addr; > + int mpx_mawa; -ENOCOMMENT. Plus 'int' looks probably wrong, unless the hardware really wants signed shift values. (whatever 'mpx_mawa' is.) Plus, while Intel is free to use sucky acronyms such as MAWA, could we please name this and related functionality sensibly: mpx_table_size or mpx_table_shift or such? The data structure comment can point out that Intel calls this 'MAWA'. (Also, the changelog refers to a later change, which never happens in this series.) Thanks, Ingo