linux-kernel - Re: [PATCH v1 00/31] 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: <edd100ce-dac6-4075-81cb-820e57282bc6@arm.com>
Date: Fri, 14 Jun 2024 14:59:29 +0100
From: James Morse <james.morse@....com>
To: Reinette Chatre <reinette.chatre@...el.com>, x86@...nel.org,
 linux-kernel@...r.kernel.org
Cc: Fenghua Yu <fenghua.yu@...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>,
 shameerali.kolothum.thodi@...wei.com,
 D Scott Phillips OS <scott@...amperecomputing.com>,
 carl@...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 v1 00/31] x86/resctrl: Move the resctrl filesystem code to
 /fs/resctrl

Hi Reinette,

On 09/04/2024 04:13, Reinette Chatre wrote:
> Please consider the file movements as captured in the diffstat below:
> 
> On 3/21/2024 9:50 AM, James Morse wrote:
>>  MAINTAINERS                               |    2 +
>>  arch/Kconfig                              |    8 +
>>  arch/x86/Kconfig                          |    5 +-
>>  arch/x86/include/asm/resctrl.h            |   45 +-
>>  arch/x86/kernel/cpu/resctrl/Makefile      |    5 +-
>>  arch/x86/kernel/cpu/resctrl/core.c        |  119 +-
>>  arch/x86/kernel/cpu/resctrl/ctrlmondata.c |  506 +--
>>  arch/x86/kernel/cpu/resctrl/internal.h    |  433 +--
>>  arch/x86/kernel/cpu/resctrl/monitor.c     |  813 +----
>>  arch/x86/kernel/cpu/resctrl/pseudo_lock.c | 1126 +-----
>>  arch/x86/kernel/cpu/resctrl/rdtgroup.c    | 3929 +-------------------
>>  arch/x86/kernel/process_32.c              |    2 +-
>>  arch/x86/kernel/process_64.c              |    2 +-
>>  fs/Kconfig                                |    1 +
>>  fs/Makefile                               |    1 +
>>  fs/resctrl/Kconfig                        |   23 +
>>  fs/resctrl/Makefile                       |    3 +
>>  fs/resctrl/ctrlmondata.c                  |  527 +++
>>  fs/resctrl/internal.h                     |  340 ++
>>  fs/resctrl/monitor.c                      |  843 +++++
>>  fs/resctrl/psuedo_lock.c                  | 1122 ++++++
> 
> (sidenote: James, please note typo in psuedo_lock.c)

Yeah - I still can't spell that...


>>  fs/resctrl/rdtgroup.c                     | 4013 +++++++++++++++++++++
>>  include/linux/resctrl.h                   |  153 +-
>>  include/linux/resctrl_types.h             |   98 +
>>  24 files changed, 7244 insertions(+), 6875 deletions(-)
>>  create mode 100644 fs/resctrl/Kconfig
>>  create mode 100644 fs/resctrl/Makefile
>>  create mode 100644 fs/resctrl/ctrlmondata.c
>>  create mode 100644 fs/resctrl/internal.h
>>  create mode 100644 fs/resctrl/monitor.c
>>  create mode 100644 fs/resctrl/psuedo_lock.c
>>  create mode 100644 fs/resctrl/rdtgroup.c
>>  create mode 100644 include/linux/resctrl_types.h

> I would like to check in on the sentiments regarding maintaining the resctrl
> contributions after this work is merged. Considering that resctrl will 
> be split between fs/resctrl and arch/x86, would it still be acceptable for
> resctrl code to both areas (filesystem as well as arch) to flow via the tip tree with
> help from x86 maintainers?

I think it makes sense for all that to be funnelled via tip.


> How will Arm patches flow?

No preference. If it makes the most sense for them to go via tip, then lets do that.

There will be the occasional dependency on arm64, but that should be manageable.
e.g. The first merge of the MPAM driver comes with some arm64 code for context-switch.
That will need co-ordinating with Will+Catalin.


> James, are you planning a separate MAINTAINERS entry for the Arm specific code?
> I would like to propose that you add yourself as a reviewer to the existing resctrl
> MAINTAINERS entry to learn when any changes are submitted that may impact Arm. 

I'll add a patch doing that to the end of the MPAM tree.


Thanks,

James