linux-kernel - Re: [PATCH] x86/resctrl: Fix WARN in get_domain_from

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]

Date: Wed, 21 Feb 2024 12:06:46 +0000
From: James Morse <james.morse@....com>
To: Tony Luck <tony.luck@...el.com>,
 "Chatre, Reinette" <reinette.chatre@...el.com>,
 Thomas Gleixner <tglx@...utronix.de>
Cc: Borislav Petkov <bp@...en8.de>, "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] x86/resctrl: Fix WARN in get_domain_from_cpu()

Hi Tony,

On 21/02/2024 00:34, Tony Luck wrote:
> reset_all_ctrls() and resctrl_arch_update_domains() use
> on_each_cpu_mask() to call rdt_ctrl_update() on potentially
> one CPU from each domain.
> 
> But this means rdt_ctrl_update() needs to figure out which domain
> to apply changes to. Doing so requires a search of all domains
> in a resource, which can only be done safely if cpus_lock is
> held. Both callers do hold this lock, but there isn't a way
> for a function called on another CPU via IPI to verify this.
> 
> Fix by adding the target domain to the msr_param structure and
> calling for each domain separately using smp_call_function_single()

Cunning - this trades the memory allocation for multiple IPI. I think this is much better
for the case where only the local domains configuration is modified.

With the double-IPI when both CDP configurations are changed fixed:
Reviewed-by: James Morse <james.morse@....com>

I think we should rip out the false positive check, I'll post a patch to do that.
I'll double check this was the only IPI path, if so its safe again after this patch and we
can add lockdep_assert_cpus_held(). If anyone ever hits this during a bisect its should be
clear(er).


Thanks,

James