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 2BB863AE1A9 for ; Tue, 17 Mar 2026 12:05:09 +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=1773749111; cv=none; b=C0rWGyFCXpWrExrc1S7rDBOFSzKUzvQYozW8A1P80EFsXOyKhcQGxUEntnBMZ5GLFTZBFvn9UudK3W+yfy61jdkNv0C4kYKJXzWVh4Wfrmvx2qOAw6mqlDe4Uzc0g+nCRTFcDpzp/I4Se73jcmD1IC4gkiWJGDXQ4T8HuScX8bw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773749111; c=relaxed/simple; bh=SqB/oylkIAvOAejJMnH+yJS0eRRs2lwvPASudaaK8cM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=mV6/U+XtdoTV3yl+LyoJSOKGN7Zf5DFBt+RQV8Kb3WaA25ssSIqpmfPgTxO15hcgcisk+If+5PY+kiqa0RpUps+XBzm6xU2zROl5CMQOoTz7DdFpyw+/+MTa+KVMN96VwYDcLTj80dxmvSb63wOLgXPpC+7EN7Aa3X9oykmsOSs= 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 7EDFF1477; Tue, 17 Mar 2026 05:05:02 -0700 (PDT) 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 B24923F7BD; Tue, 17 Mar 2026 05:05:06 -0700 (PDT) Message-ID: <1957e92f-0a08-4811-bb25-8a8327f5cf53@arm.com> Date: Tue, 17 Mar 2026 12:05:05 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Thunderbird Daily Subject: Re: [PATCH v2 3/6] fs/resctrl: Make 'event_filter' files read only if they're not configurable To: Reinette Chatre , "Luck, Tony" Cc: "linux-kernel@vger.kernel.org" , "Dave.Martin@arm.com" , "james.morse@arm.com" , "babu.moger@amd.com" , "tglx@kernel.org" , "mingo@redhat.com" , "bp@alien8.de" , "dave.hansen@linux.intel.com" , "x86@kernel.org" , "hpa@zytor.com" , "fenghuay@nvidia.com" , "tan.shaopeng@fujitsu.com" References: <20260313174524.3482767-1-ben.horgan@arm.com> <20260313174524.3482767-4-ben.horgan@arm.com> <359217bc-59d1-4abf-89b1-77f5821b2a6f@arm.com> Content-Language: en-US From: Ben Horgan In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Reinette, On 3/16/26 17:29, Reinette Chatre wrote: > Hi Ben, > > On 3/16/26 10:02 AM, Ben Horgan wrote: >> Hi Tony, >> >> On 3/16/26 16:27, Luck, Tony wrote: >>>>> Instead of making the file writable, and then fixing the mode. Maybe >>>>> patch the mode in res_common_files[] before calling rdtgroup_add_files(): >>>> >>>> >>>> I initially rejected this idea because res_common_files[] is global and the >>>> read/write choice is per event type but we can safely save restore the mode as >>>> we're holding the rdtgroup mutex. How about this? >>> >>> That seems more complicated. Is there an expectation that event_filter >>> needs to be writable on the "total" event but not on the "local" one? >> >> No, at least not currently. For mpam only the total event is supported. >> >> Another way of doing it could be to patch the mode in res_common_files[] from >> resctrl_mkdir_event_configs() for both cases, 0444 and 0644, and change the >> starting value to something invalid, e.g. 0. > > "event_filter"'s mode could be initialized similar to its fflags. Please see > resctrl_l3_mon_resource_init(). Ok, this works if we shift to the rdt_resource::resctrl_mon::mbm_cntr_configurable property you suggest below as that is scoped to all mbm events. > > Stepping back, based on the v1 discussion I understand that BMEC does not > apply to MPAM so patching the BMEC specific resctrl_arch_is_evt_configurable() > in patch #1 to support MPAM does not look right. From what I can tell we need a > new "configurable" property that is specific to assignable counters. I understand > naming is not ideal here but forcing the two independent features together like this > just because resctrl_arch_is_evt_configurable() has a generically relevant name is > not right. Sure, we can consider them separately. > > Consider, for example, a new rdt_resource::resctrl_mon::mbm_cntr_configurable > property that arch can set. From resctrl fs side it would be a property that is > only considered if rdt_resource::resctrl_mon::mbm_cntr_assignable == true. > > res_common_files[] can initialize the default mode of "event_filter" to be > read-only and resctrl_l3_mon_resource_init() can be expanded to to make > "event_filter" writable if both rdt_resource::resctrl_mon::mbm_cntr_assignable == true > AND rdt_resource::resctrl_mon::mbm_cntr_configurable == true. Seems reasonable. I'll give this a go. > > Looking at this we do seem to have options between resctrl fs properties > and arch callbacks to do this and considering your earlier concern with > callbacks I wonder if resctrl fs properties would be better? > How about another new property, rdt_resource::resctrl_mon::mbm_cntr_assign_fixed > to replace resctrl_arch_mbm_cntr_assign_fixed()? As we've already got mbm_cntr_assignable and mbm_assign_on_mkdir in resctrl_mon it won't seem out of place. I'll update this too. > > Reinette Thanks, Ben