lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181123114102.GB130228@gmail.com>
Date:   Fri, 23 Nov 2018 12:41:02 +0100
From:   Ingo Molnar <mingo@...nel.org>
To:     Borislav Petkov <bp@...en8.de>
Cc:     "Moger, Babu" <Babu.Moger@....com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "corbet@....net" <corbet@....net>,
        "fenghua.yu@...el.com" <fenghua.yu@...el.com>,
        "reinette.chatre@...el.com" <reinette.chatre@...el.com>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "hpa@...or.com" <hpa@...or.com>, "x86@...nel.org" <x86@...nel.org>,
        "mchehab+samsung@...nel.org" <mchehab+samsung@...nel.org>,
        "arnd@...db.de" <arnd@...db.de>,
        "kstewart@...uxfoundation.org" <kstewart@...uxfoundation.org>,
        "pombredanne@...b.com" <pombredanne@...b.com>,
        "rafael@...nel.org" <rafael@...nel.org>,
        "kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
        "tony.luck@...el.com" <tony.luck@...el.com>,
        "qianyue.zj@...baba-inc.com" <qianyue.zj@...baba-inc.com>,
        "xiaochen.shen@...el.com" <xiaochen.shen@...el.com>,
        "pbonzini@...hat.com" <pbonzini@...hat.com>,
        "Singh, Brijesh" <brijesh.singh@....com>,
        "Hurwitz, Sherry" <sherry.hurwitz@....com>,
        "dwmw2@...radead.org" <dwmw2@...radead.org>,
        "Lendacky, Thomas" <Thomas.Lendacky@....com>,
        "luto@...nel.org" <luto@...nel.org>,
        "joro@...tes.org" <joro@...tes.org>,
        "jannh@...gle.com" <jannh@...gle.com>,
        "vkuznets@...hat.com" <vkuznets@...hat.com>,
        "rian@...m.mit.edu" <rian@...m.mit.edu>,
        "jpoimboe@...hat.com" <jpoimboe@...hat.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>
Subject: Re: [PATCH v9 01/13] x86/resctrl: Rename and move rdt files to new
 directory


* Borislav Petkov <bp@...en8.de> wrote:

> On Fri, Nov 23, 2018 at 09:41:17AM +0100, Ingo Molnar wrote:
> > Then at least make the directory name resource_control/, which is only 
> > marginally longer and a lot more readable.
> > 
> > We really don't have to fit directly names into the 8 character DOS limit 
> > anymore. ;-)
> 
> How about
> 
> resource_ctl
> 
> ?

The thing is, thinking about this as a 'CPU resource' is really a 
misnomer on the conceptual level, which is why it's bothering me: RDT is 
not really about 'CPU resources', because registers are CPU resources, 
ioports and iomem are CPU resources, APICs are CPU resources and PMU 
events are resources - none of which is part of RDT.

The key difference in RDT is that they are *shared* resources - caches 
really - where the ad-hoc cache sharing might be causing security and 
scalability problems so there's partitioning and throttling (bandwidth 
control) support in the hardware.

Is there any other resource handled than caches by RDT or by the AMD 
variant?

So how about "cache_control"? It's shorter and a lot closer to what the 
code actually does.

> resource_control/ is kinda long-ish and the other names we have there
> are nice and short, see below.
> 
> BTW, while we're talking renaming, I have a patch which renames the MCE
> pile and am planning to slap it in around -rc6 timeframe since we don't
> have a lot of RAS commits this time around, see also the end of this
> mail. It makes the naming there all nicely regular. :)

That's cool - these IMHO need to be done periodically to keep overall 
namespace complexity low enough. (As long as can be done without breaking 
any ABI that is.)

>  15 files changed, 14 insertions(+), 14 deletions(-)
>  rename arch/x86/kernel/cpu/{mcheck => mce}/Makefile (52%)
>  rename arch/x86/kernel/cpu/{mcheck/mce_amd.c => mce/amd.c} (99%)
>  rename arch/x86/kernel/cpu/{mcheck/mce-apei.c => mce/apei.c} (99%)
>  rename arch/x86/kernel/cpu/{mcheck/mce.c => mce/core.c} (99%)
>  rename arch/x86/kernel/cpu/{mcheck => mce}/dev-mcelog.c (99%)
>  rename arch/x86/kernel/cpu/{mcheck/mce-genpool.c => mce/genpool.c} (99%)
>  rename arch/x86/kernel/cpu/{mcheck/mce-inject.c => mce/inject.c} (99%)
>  rename arch/x86/kernel/cpu/{mcheck/mce_intel.c => mce/intel.c} (99%)
>  rename arch/x86/kernel/cpu/{mcheck/mce-internal.h => mce/internal.h} (100%)
>  rename arch/x86/kernel/cpu/{mcheck => mce}/p5.c (100%)
>  rename arch/x86/kernel/cpu/{mcheck/mce-severity.c => mce/severity.c} (99%)
>  rename arch/x86/kernel/cpu/{mcheck => mce}/therm_throt.c (100%)
>  rename arch/x86/kernel/cpu/{mcheck => mce}/threshold.c (100%)
>  rename arch/x86/kernel/cpu/{mcheck => mce}/winchip.c (100%)

Standardizing around 'MCE' sounds good to me!

Thanks,

	Ingo

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ