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 429312DFF04 for ; Fri, 2 Jan 2026 11:07:11 +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=1767352032; cv=none; b=a8t/R9qOJwAXZUONd56kY6Hi4Ifu0Id7iBPyfrw6FN8KN0TL2FuqcuLhRs6MpyEx3uEbX3GddJetQG9EYVDvIrYw1A2XDciQTcRktL1EzZwaut61ZUu0qmN7t+O2Uoa6M/QWjJZ0bW6VQDkiQnBidDBuPRb/+6tkQbDX53XnQ1s= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767352032; c=relaxed/simple; bh=lMX/oAjE8+O5YEgAcD3yoU7udaLJJjOfE8NKqMit8Hg=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=SsQ8E1r0qQZaiLsQjV6BrxovkgNovkhR74Q3AldY9MFBPd1lPtvjmu4WdRoTZrrzG2pfmVL7FY6f1ISlHwQrzlKBok2nvJooDv2VsL9UrD5CYdnJBw+mBlZ2PifWXt/uuTovWd/geqRn9YF0kBkAaW03u7GuwYij/gqh65igZyQ= 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 B0074497; Fri, 2 Jan 2026 03:07:03 -0800 (PST) Received: from [10.1.196.46] (e134344.arm.com [10.1.196.46]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C22113F63F; Fri, 2 Jan 2026 03:07:06 -0800 (PST) Message-ID: <7ca41a6a-60c1-486f-a0f8-4af256fa1b4a@arm.com> Date: Fri, 2 Jan 2026 11:07:05 +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: [RFC PATCH 07/38] arm_mpam: resctrl: Add boilerplate cpuhp and domain allocation To: Jonathan Cameron Cc: James Morse , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, 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 , Dave Martin , Koba Ko , Shanker Donthineni , fenghuay@nvidia.com, baisheng.gao@unisoc.com, Gavin Shan , rohit.mathew@arm.com, reinette.chatre@intel.com, Punit Agrawal References: <20251205215901.17772-1-james.morse@arm.com> <20251205215901.17772-8-james.morse@arm.com> <20251218113014.00002691@huawei.com> <4495db3f-cfb8-4571-b83a-10a24f7b73a9@arm.com> <20251222114804.00005231@huawei.com> From: Ben Horgan Content-Language: en-US In-Reply-To: <20251222114804.00005231@huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Jonathan, On 12/22/25 11:48, Jonathan Cameron wrote: > >>>> +static struct mpam_resctrl_dom * >>>> +mpam_resctrl_get_domain_from_cpu(int cpu, struct mpam_resctrl_res *res) >>>> +{ >>>> + struct mpam_resctrl_dom *dom; >>>> + struct rdt_ctrl_domain *ctrl_d; >>>> + >>>> + lockdep_assert_cpus_held(); >>>> + >>>> + list_for_each_entry_rcu(ctrl_d, &res->resctrl_res.ctrl_domains, >>>> + hdr.list) { >>>> + dom = container_of(ctrl_d, struct mpam_resctrl_dom, >>>> + resctrl_ctrl_dom); >>> >>> I'm lazy so haven't checked for more code here in later patches, but >>> if not, why not iterate the list to access the domain directly rather >>> than jumping through the rdt_ctrl_domain? >>> >>> Something along lines of: >>> >>> list_for_each_entry_rcu(dom, &res->resctrl_res.ctrl_domains, >>> resctrl_ctrl_dom.hdr.list) { >>> } >>> >> >> Unless I've misunderstood I don't think this works because it's not what >> the fs/resctrl code expects. > > I think I explained this one badly. > > This should be functionally identical to the above so no visible side > effects outside of this code. All this change is meant to do is wrap the > container_of() in the list iterator. When using the _entry_ variants > it is wrapping container_of() anyway so just going one level further > up the hierarchy of nested structures. > > struct a { > struct b { > struct list_head l; > } > } > > It's actually a list of struct a as all elements on this list are > struct b instances within struct a, but you are treating it as a list > of struct b and then using a container_of() to get to struct a on > each one. > > The change is treat it as a list of struct a with the list_head happening > to be wrapped in struct b. Results in slightly simpler code and makes > the point these are always struct a instances. Thanks for the detailed explanation. This makes sense to me now and I'll make the change. > > Jonathan > > > >> >> >>>> + >>>> + if (cpumask_test_cpu(cpu, &dom->ctrl_comp->affinity)) >>>> + return dom; >>>> + } >>>> + >>>> + return NULL; >>>> +} >>>> + > > Thanks, Ben