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 9AE913CF66B for ; Mon, 16 Mar 2026 17:02:08 +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=1773680529; cv=none; b=dOzWBMtvmTucXmcgaSdYEd1yQ8rW0wPg/OWb67OoG9cEHS3ZBy3dg09xTKfA6kGpYJ/ZA3PnlpvKNGKKJgiw1hJsKkUrLg+TiM0wJ877y5EsgZxq/tR+mqZJs59wpzOzvNeRq9KV5oYEPfDELrN03sjXWwq2HyR6a5edZ9AmkiY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773680529; c=relaxed/simple; bh=BKFoDvBMZcnIYtx2cdcRS23HlI4NP+2ufIMPHLG7YJQ=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Kt5q0Mot08MXLZ9BFgr5Jxm30cDaOI/eT/JiVQzpQROOkNXzIC6iLbXjMoKqqssue1JEWzUmZMyU9ohplvGI/k3JXzv5HvsfdEwDgryF7I84fgoJeILNDnNardhW5zgIo+0BXRyuIlEe5DiDFMFRsVXxEPcn7YF9R0OwibyKY20= 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 D890A1477; Mon, 16 Mar 2026 10:02:01 -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 1A6073F73B; Mon, 16 Mar 2026 10:02:05 -0700 (PDT) Message-ID: <359217bc-59d1-4abf-89b1-77f5821b2a6f@arm.com> Date: Mon, 16 Mar 2026 17:02:04 +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: "Luck, Tony" Cc: "linux-kernel@vger.kernel.org" , "Chatre, Reinette" , "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> Content-Language: en-US From: Ben Horgan In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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. Thanks, Ben