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 74AD1204008 for ; Fri, 18 Oct 2024 17:07:27 +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=1729271249; cv=none; b=fjDAVDvkxyKXCeZsyUrR33twkd8d+OJoVJlTYhXVinpJRjz0f1tqJ1erDHSRTzcULhaUMiFxzmyCtkW9E78ZnO4cqjBFpoyLIjRLlUdQk+sjHc5XgxwhHbxdPUlORMV2x3p1C/bDuNnkn1MvOAc9EXXNlYceWx//7Qx0X7K+x8M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1729271249; c=relaxed/simple; bh=5AEdJkkdu7f7YcyRjgxgJ2/+GJhnxxrfLe0FK7Sgw0k=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=lXtXhN86S7VfPVFR5VKKts2PtLMDviGbGHKlHp257xVmQTS3WJuVlgKphIYg8o0AGIFAKLvhxYywM92ReBsmYBf9ZCF8MtHgwTUbIoIMfHWSXkyHJ0pHuJiOZz0xdexUeluHEjAa3trvJSrQyf8yynbMDamFpsBy1x89dE1zAgM= 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 72A8C1477; Fri, 18 Oct 2024 10:07:56 -0700 (PDT) Received: from [10.1.196.28] (eglon.cambridge.arm.com [10.1.196.28]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1080B3F917; Fri, 18 Oct 2024 10:07:21 -0700 (PDT) Message-ID: <94cfdf5c-cd52-41c1-b5c3-7ac6b2f84f23@arm.com> Date: Fri, 18 Oct 2024 18:07:18 +0100 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 v5 02/40] x86/resctrl: Add a helper to avoid reaching into the arch code resource list Content-Language: en-GB To: Tony Luck Cc: x86@kernel.org, linux-kernel@vger.kernel.org, Fenghua Yu , Reinette Chatre , Thomas Gleixner , Ingo Molnar , Borislav Petkov , 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 , Rex Nie , Dave Martin , Shaopeng Tan References: <20241004180347.19985-1-james.morse@arm.com> <20241004180347.19985-3-james.morse@arm.com> From: James Morse In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Tony, On 15/10/2024 23:57, Tony Luck wrote: > On Fri, Oct 04, 2024 at 06:03:09PM +0000, James Morse wrote: >> +struct rdt_resource *resctrl_arch_get_resource(enum resctrl_res_level l) >> +{ >> + if (l >= RDT_NUM_RESOURCES) >> + return NULL; >> + >> + return &rdt_resources_all[l].r_resctrl; >> +} > > Is this a bit fragile if someone adds a new item in enum resctrl_res_level > but doesn't add a new entry to struct rdt_hw_resource rdt_resources_all[] > in arch/x86/kernel/cpu/resctrl/core.c > > Any caller of resctrl_arch_get_resource(new item name) will get past > the check "if (l >= RDT_NUM_RESOURCES)" and then return a pointer past > the end of the rdt_resources_all[] array. > > Maybe make sure the array is padded out to the right size? > > struct rdt_hw_resource rdt_resources_all[RDT_NUM_RESOURCES - 1] = { > ... > }; Sure. I was planning to do away with the 'must not return NULL' behaviour before extra resources start appearing. It's done like this to avoid the churn when x86 supports 'all' the resources anyway, buy you're right it can be less-churn and safer at the same time! Thanks, James