linux-kernel - RE: [PATCH v9 00/24] x86/resctrl: monitored closid+rmid together, separate arch/fs locking

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: <SJ1PR11MB6083A759748EAF62EDF21D0FFC502@SJ1PR11MB6083.namprd11.prod.outlook.com>
Date: Tue, 20 Feb 2024 23:25:42 +0000
From: "Luck, Tony" <tony.luck@...el.com>
To: "Chatre, Reinette" <reinette.chatre@...el.com>, Thomas Gleixner
	<tglx@...utronix.de>
CC: Borislav Petkov <bp@...en8.de>, James Morse <james.morse@....com>,
	"x86@...nel.org" <x86@...nel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "Yu, Fenghua" <fenghua.yu@...el.com>, "Ingo
 Molnar" <mingo@...hat.com>, H Peter Anvin <hpa@...or.com>, Babu Moger
	<Babu.Moger@....com>, "shameerali.kolothum.thodi@...wei.com"
	<shameerali.kolothum.thodi@...wei.com>, D Scott Phillips OS
	<scott@...amperecomputing.com>, "carl@...amperecomputing.com"
	<carl@...amperecomputing.com>, "lcherian@...vell.com" <lcherian@...vell.com>,
	"bobo.shaobowang@...wei.com" <bobo.shaobowang@...wei.com>,
	"tan.shaopeng@...itsu.com" <tan.shaopeng@...itsu.com>,
	"baolin.wang@...ux.alibaba.com" <baolin.wang@...ux.alibaba.com>, Jamie Iles
	<quic_jiles@...cinc.com>, Xin Hao <xhao@...ux.alibaba.com>,
	"peternewman@...gle.com" <peternewman@...gle.com>, "dfustini@...libre.com"
	<dfustini@...libre.com>, "amitsinght@...vell.com" <amitsinght@...vell.com>,
	David Hildenbrand <david@...hat.com>
Subject: RE: [PATCH v9 00/24] x86/resctrl: monitored closid+rmid together,
 separate arch/fs locking

> So even though it is confirmed via lockdep_assert_cpus_held() that
> resctrl_arch_update_domains() holds cpu_hotplug_lock, it does not seem possible
> to have a similar lockdep check in the function called by it (resctrl_arch_update_domains())
> via IPI. It thus does not look like that lockdep checking within
> get_domain_from_cpu() can be accurate and I cannot see what it can be replaced with
> to make it accurate. Any guidance will be appreciated. Perhaps we should just drop (but
> with detailed context comments remaining) the lockdep check in get_domain_from_cpu()? 

Reinette

Both the places where this has problems (reset_all_ctrls() and
resctrl_arch_update_domains()) have similar structure:


	 list_for_each_entry(d, &r->domains, list) {
		add some bits to a cpumask
	}

	on_each_cpu_mask(cpu_mask, rdt_ctrl_update, &msr_param, 1);


Maybe instead of collecting all CPUs that need to do something, and then each
of them backtrack and search for the domain from a resource (that is passed
in the msr_param argument). The code could be restructured to pass the domain
to the target function. Like this:


	list_for_each_entry(d, &r->domains, list) {
		msr_param.dom = d;
		smp_call_function_single(somecpu, rdt_ctrl_update, &msr_param, 1);
	}

I'll try coding this up to see if it works.

-Tony