linux-kernel - Re: [PATCH v5 00/10] x86/resctrl: Misc cleanup

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <dbe46982-29b6-cea8-af22-8c808ac4a8cb@intel.com>
Date:   Thu, 23 Jul 2020 13:31:37 -0700
From:   Reinette Chatre <reinette.chatre@...el.com>
To:     James Morse <james.morse@....com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Borislav Petkov <bp@...en8.de>
Cc:     x86@...nel.org, linux-kernel@...r.kernel.org,
        Fenghua Yu <fenghua.yu@...el.com>,
        Ingo Molnar <mingo@...hat.com>, H Peter Anvin <hpa@...or.com>,
        Babu Moger <Babu.Moger@....com>
Subject: Re: [PATCH v5 00/10] x86/resctrl: Misc cleanup

Hi James, Borislav, and Thomas,

On 7/23/2020 11:31 AM, James Morse wrote:
> Hi Reinette,
> 
> On 08/07/2020 17:39, James Morse wrote:
>> These are the miscellaneous cleanup patches that floated to the top of
>> the MPAM tree.
> 
> Is there anything else I should do with this series?
> (Does patch 10 need an ACK from anyone else?)

James: From my perspective the series is ready for consideration by the
x86 maintainers and you already included the appropriate mailing list
and cc for this series to be queued for their consideration. My
"Reviewed-by" for patch 10 should have included a "#for resctrl". It
indeed needs more reviews for the cacheinfo.h changes but I expect that
to happen during review by x86 maintainers.

> 
> Would a branch or pull request make anyone's life easier?

Borislav and Thomas: Would this perhaps help you?

>> The only interesting thing are the patches to make the AMD/Intel
>> differences something resctrl understands, instead of just 'happening'
>> because of the different function pointers.
>> This will become more important once MPAM support is added. parse_bw()
>> and friends are what enforces resctrl's ABI. Allowing an
>> architecture/platform to provide a subtly different function here would
>> be bad for user-space.
>>
>> MPAM would set arch_has_sparse_bitmaps and arch_has_empty_bitmap, but
>> not arch_needs_linear.
> 
>> Nothing in this series should change any behaviour.

Thank you very much

Reinette