linux-kernel - Re: [PATCH v8 08/24] x86/resctrl: Track the number of dirty RMID a CLOSID has

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: <CALPaoCi_3aPQ1cebtJLtnNEGjiAX8WjJcHP008wAOh0h+O=trQ@mail.gmail.com>
Date: Thu, 4 Jan 2024 11:13:35 -0800
From: Peter Newman <peternewman@...gle.com>
To: James Morse <james.morse@....com>
Cc: x86@...nel.org, linux-kernel@...r.kernel.org, 
	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>, 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>, dfustini@...libre.com, amitsinght@...vell.com
Subject: Re: [PATCH v8 08/24] x86/resctrl: Track the number of dirty RMID a
 CLOSID has

Hi James,

On Fri, Dec 15, 2023 at 9:44 AM James Morse <james.morse@....com> wrote:
>  void free_rmid(u32 closid, u32 rmid)
> @@ -792,13 +813,33 @@ void mbm_setup_overflow_handler(struct rdt_domain *dom, unsigned long delay_ms)
>  static int dom_data_init(struct rdt_resource *r)
>  {
>         u32 idx_limit = resctrl_arch_system_num_rmid_idx();
> +       u32 num_closid = resctrl_arch_get_num_closid(r);

Which resource is this again? Surely the one with the smallest number
of CLOSIDs?

It's not much harm if the array is bigger than it needs to be, but
I've become curious about how The Monitoring Resource is used in the
code when there are later changes[1] which would cause this function
to be called on RDT_RESOURCE_L3, RDT_RESOURCE_MBA, or both.

Given that we have hardware with event counters residing at different
levels of the topology and possibly being associated with different
rdt_resources, more attention needs to be paid to how these parameters
are used in code related to monitoring.

-Peter

[1] https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git/commit/drivers/platform/mpam/mpam_resctrl.c?h=mpam/snapshot/v6.7-rc2&id=a0ab3a6c26002