From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 8A52B4E1B3 for ; Wed, 21 Feb 2024 12:06:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708517213; cv=none; b=nneFwTO0Nrj+OkI2B9i9XwOmYqU9R80hZIeO/sPRrBv7DKaO7P61lj5vNz4e6VEpkzYi52Ju2qTcMWIQFdXHGItIHcn6o55easyqxNJdig4uP3JdjveDqV8f6+SC+RxYLvK41HQUI4UJHRsQu7fJrIRFVA5vKVILlffUE1HM84o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708517213; c=relaxed/simple; bh=TbXTSyKoJMZy0xDnmGuwLUxJ+iI+gkmKCkVN0X/w7UE=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=IAB83B4+V95+YbAiD3kzPlLh4RGGcwRWb/8gvqwychvqBgfnG9MgTnDVJdaYYoLZjGl0GffwbYwdqwBt0Rzc40ss6ygGlEbvmoGIWs14uE9370N1HcU4rD+HduXTsIXpq5MonM7OFCFYTUPlQwsy64sQJXiGqCeRuB8wiHpYteo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 603DD1007; Wed, 21 Feb 2024 04:07:29 -0800 (PST) Received: from [10.1.197.60] (eglon.cambridge.arm.com [10.1.197.60]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id CBBD13F762; Wed, 21 Feb 2024 04:06:47 -0800 (PST) Message-ID: <88097441-534d-4b81-9801-680334092ab8@arm.com> Date: Wed, 21 Feb 2024 12:06:46 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/resctrl: Fix WARN in get_domain_from_cpu() Content-Language: en-GB To: Tony Luck , "Chatre, Reinette" , Thomas Gleixner Cc: Borislav Petkov , "x86@kernel.org" , "linux-kernel@vger.kernel.org" , "Yu, Fenghua" , Ingo Molnar , H Peter Anvin , Babu Moger , "shameerali.kolothum.thodi@huawei.com" , D Scott Phillips OS , "carl@os.amperecomputing.com" , "lcherian@marvell.com" , "bobo.shaobowang@huawei.com" , "tan.shaopeng@fujitsu.com" , "baolin.wang@linux.alibaba.com" , Jamie Iles , Xin Hao , "peternewman@google.com" , "dfustini@baylibre.com" , "amitsinght@marvell.com" , David Hildenbrand References: <20240213184438.16675-1-james.morse@arm.com> <20240217105543.GAZdCQr_nosDP4tGuO@fat_crate.local> <87zfvwieli.ffs@tglx> From: James Morse In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 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