linux-kernel - Re: [PATCH v3 00/38] x86/resctrl: Move the resctrl filesystem code to /fs/resctrl

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: <87bk33d1xg.fsf@rasp.cworth.amperemail.amperecomputing.com>
Date: Thu, 11 Jul 2024 15:00:27 -0700
From: Carl Worth <carl@...amperecomputing.com>
To: James Morse <james.morse@....com>, x86@...nel.org,
 linux-kernel@...r.kernel.org
Cc: Fenghua Yu <fenghua.yu@...el.com>, Reinette Chatre
 <reinette.chatre@...el.com>, Thomas Gleixner <tglx@...utronix.de>, Ingo
 Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, H Peter Anvin
 <hpa@...or.com>, Babu Moger <Babu.Moger@....com>, James Morse
 <james.morse@....com>, shameerali.kolothum.thodi@...wei.com, D Scott
 Phillips OS <scott@...amperecomputing.com>, lcherian@...vell.com,
 bobo.shaobowang@...wei.com, tan.shaopeng@...itsu.com,
 baolin.wang@...ux.alibaba.com, Jamie Iles <quic_jiles@...cinc.com>, Xin
 Hao <xhao@...ux.alibaba.com>, peternewman@...gle.com,
 dfustini@...libre.com, amitsinght@...vell.com, David Hildenbrand
 <david@...hat.com>, Rex Nie <rex.nie@...uarmicro.com>, Dave Martin
 <dave.martin@....com>
Subject: Re: [PATCH v3 00/38] x86/resctrl: Move the resctrl filesystem code
 to /fs/resctrl

James Morse <james.morse@....com> writes:
> This is the final series that allows other architectures to implement resctrl.
> The final patch to move the code has been ommited, but can be generated using
> the python script at the end of the series.
> The final move is a bit of a monster. I don't expect that to get merged as part
> of this series - we should wait for it to make less impact on other
> series.

Thanks, again, James.

As with previous versions, I've tested this code (along with additional
MPAM code from you and other code we've written), to test MPAM
functionality on an Ampere implementation.

I replied to the in the series which introduces
CONFIG_RESCTRL_FS_PSEUDO_LOCK to point out how that commit will actually
break compilation if that option is not selected, (and I described the
minor change needed to fix that).

With that fixed, for the series:

Tested-by: Carl Worth <carl@...amperecomputing.com> # arm64

-Carl