From nobody Tue Mar 3 03:20:24 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E9E162DF12F for ; Mon, 2 Mar 2026 18:46:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.11 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772477189; cv=none; b=ZrrNlvhr1WEieSvVfxwWi4d4s8gJ8ySxZ5b2EU9Ppvih/Hj9a8u2tHWi+UddCADlPBQ7K/Epcej/bAuipSAEECYvFpM9UJeVJ5KHPL0d++AiuTxGAz8ND/PGxWI2j+tjiTHPmc9e9+53M1ssIngkip8dyKz5rVb6uf2CZttQkuk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772477189; c=relaxed/simple; bh=lPprbTGisbGA0s+d/uOwEM9KiYptDpYY2nJtKbgMbQQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=hZRV+ZM1vTKv9XHaMuefBphKj0K21lmCckvaPYzNkTpnvbdW4kyr4rT3nMz8Dyb5rPdU8PGQkBGoARZ+yvWE+eaX6VE29MlxEvd13SaU0aIAMTsU/hesrzjcuSE3WQJzM3Qc9QC+cxgq2VGC6nXB/or/jbPWekXBCwi/r5f3aTc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=MRNrB7/w; arc=none smtp.client-ip=192.198.163.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="MRNrB7/w" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1772477188; x=1804013188; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=lPprbTGisbGA0s+d/uOwEM9KiYptDpYY2nJtKbgMbQQ=; b=MRNrB7/wT3O7LWWbbhQZeh4Ybdb6JIZQoXtINcqO5oN2ieTuJuCNyl45 k2TG9IEQlkeD/yGl3kPan64HRKcwqGq5zRGoCrp4pW0/+79bdzr/aK384 RYBJYWT4H9UXuzdZXCYBiRe5CzxT0wK8EL1ABsylqLWTourAwDV0N0SUA +r428a1dsjfUiJDSmmL5J7AiCvH/FdzbWUOCkmbF+In/nmJg9l7oPk3dB yPzLQOTKGgJrKZRfAY5xcddSaSG7W7Uae4Kca8ZpDJBxaV/paRuZxRqsD wu8L/fWN1nGCW10KlvEQubdRyLJ7azk4S+7xTqV36cd221yGUAIEgA60V g==; X-CSE-ConnectionGUID: zU16xz+iQkWC/2TFZeibBg== X-CSE-MsgGUID: RH75krrZRRGrs+zBePkteA== X-IronPort-AV: E=McAfee;i="6800,10657,11717"; a="84135420" X-IronPort-AV: E=Sophos;i="6.21,320,1763452800"; d="scan'208";a="84135420" Received: from orviesa001.jf.intel.com ([10.64.159.141]) by fmvoesa105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Mar 2026 10:46:26 -0800 X-CSE-ConnectionGUID: JCQRu/dqQ8KB0ZBbsmdL4A== X-CSE-MsgGUID: SEJPw139QMm+4U2hSuKJcg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,320,1763452800"; d="scan'208";a="255604077" Received: from rchatre-desk1.jf.intel.com ([10.165.154.99]) by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Mar 2026 10:46:26 -0800 From: Reinette Chatre To: tony.luck@intel.com, james.morse@arm.com, Dave.Martin@arm.com, babu.moger@amd.com, bp@alien8.de, tglx@linutronix.de, dave.hansen@linux.intel.com Cc: x86@kernel.org, hpa@zytor.com, ben.horgan@arm.com, fustini@kernel.org, fenghuay@nvidia.com, peternewman@google.com, linux-kernel@vger.kernel.org, patches@lists.linux.dev, reinette.chatre@intel.com Subject: [PATCH 01/11] fs/resctrl: Add missing return value descriptions Date: Mon, 2 Mar 2026 10:46:07 -0800 Message-ID: X-Mailer: git-send-email 2.50.1 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Using the stricter "./tools/docs/kernel-doc -Wall -v" to verify proper formatting of documentation comments includes warnings related to return markup on functions that are omitted during the default verification checks. This stricter verification reports a couple of missing return descriptions in resctrl: Warning: .../fs/resctrl/rdtgroup.c:1536 No description found for return= value of 'rdtgroup_cbm_to_size' Warning: .../fs/resctrl/rdtgroup.c:3131 No description found for return= value of 'mon_get_kn_priv' Warning: .../fs/resctrl/rdtgroup.c:3523 No description found for return= value of 'cbm_ensure_valid' Warning: .../fs/resctrl/monitor.c:238 No description found for return v= alue of 'resctrl_find_cleanest_closid' Add the missing return descriptions. Signed-off-by: Reinette Chatre --- fs/resctrl/monitor.c | 2 ++ fs/resctrl/rdtgroup.c | 6 ++++++ 2 files changed, 8 insertions(+) diff --git a/fs/resctrl/monitor.c b/fs/resctrl/monitor.c index 0cd5476a483a..93db7c1cd7be 100644 --- a/fs/resctrl/monitor.c +++ b/fs/resctrl/monitor.c @@ -234,6 +234,8 @@ static struct rmid_entry *resctrl_find_free_rmid(u32 cl= osid) * * When the CLOSID and RMID are independent numbers, the first free CLOSID= will * be returned. + * + * Return: Free CLOSID on success, < 0 on failure. */ int resctrl_find_cleanest_closid(void) { diff --git a/fs/resctrl/rdtgroup.c b/fs/resctrl/rdtgroup.c index ba8d503551cd..3c9508fc558d 100644 --- a/fs/resctrl/rdtgroup.c +++ b/fs/resctrl/rdtgroup.c @@ -1519,6 +1519,8 @@ static ssize_t rdtgroup_mode_write(struct kernfs_open= _file *of, * * @cbm is unsigned long, even if only 32 bits are used to make the * bitmap functions work correctly. + * + * Return: size in bytes, 0 on failure. */ unsigned int rdtgroup_cbm_to_size(struct rdt_resource *r, struct rdt_ctrl_domain *d, unsigned long cbm) @@ -3102,6 +3104,8 @@ static void rmdir_all_sub(void) * @mevt: The type of event file being created. * @do_sum: Whether SNC summing monitors are being created. Only set * when @rid =3D=3D RDT_RESOURCE_L3. + * + * Return: Pointer to mon_data private data of the event, NULL on failure. */ static struct mon_data *mon_get_kn_priv(enum resctrl_res_level rid, int do= mid, struct mon_evt *mevt, @@ -3496,6 +3500,8 @@ static int mkdir_mondata_all(struct kernfs_node *pare= nt_kn, * resource group is initialized. The user can follow this with a * modification to the CBM if the default does not satisfy the * requirements. + * + * Return: A CBM that is valid for resource @r. */ static u32 cbm_ensure_valid(u32 _val, struct rdt_resource *r) { --=20 2.50.1 From nobody Tue Mar 3 03:20:24 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 30DA132FA14 for ; Mon, 2 Mar 2026 18:46:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.11 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772477190; cv=none; b=YI4Heh3EitxeO2DW27jgDfaXE8LBjCpquaAg/KIZWNyjthIkPbjk+eJb/ovLfCnlEr8ghKqupYDprq7RlGYzr7DbO46niDfBCTvKpApUUTYR05WIUYmK6feORX6wzBNU0zb5ZnLKcyaHZbPEAS+Fhh/VzYV6ZChh89Pt4rp1Ffs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772477190; c=relaxed/simple; bh=zWYgo2TYhNeEHB8V8WV2tR63dZU59nyuZTE5XHA2GX4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=C+coYHHo/aG6qSqKRfloSRpcz8vDzf56COz13KgGOyRKLjgrxNyfHBFc2JpENMEqPVBSwGcOZnJm1ieIfygA7mcGSQtvKaAeQ+YHxOIbzEBPGKthTo6+ihTzBSB3+M5YypuS3wstMfMl5B3Oln+4Wj1NhgZQ+SRtg6wJn0Tturk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=NnJmfJ2O; arc=none smtp.client-ip=192.198.163.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="NnJmfJ2O" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1772477188; x=1804013188; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=zWYgo2TYhNeEHB8V8WV2tR63dZU59nyuZTE5XHA2GX4=; b=NnJmfJ2O/X3Qe/TzThdlpHSZ8bIOGbfyAsN68/YrKQUuOiltrKCtG9Nv n1bjUAahSdx4nL5Z/9z/1/Z0dvaS46eFjun5dF7/GhwJV8u0+FfcFd5qu MWB8uumynP8ct2eYu+sYzJVKtrJ1I4Z+MscBBcx7F3eT8tdkgX30/P3MT jFSD/IrD6nXtp08ebtOs7laRlmIkFYxdQIV4tfPpbrxXmtHujYb1/2X3A EOO9Q9+p0iDRHb8t1/3aTg9ddIg0ne+tH+Tad+LAgy0K1196eV6YOIedw 0Ul8fQZwW2x8E+rX9jktLYe2V6qSjKTcO26lwrjMXFVPsy1cq06RJO8kz g==; X-CSE-ConnectionGUID: 5po15TpsQTSsBk4MYCb7AA== X-CSE-MsgGUID: Cqt757naRAOGE3dsa6Cu2Q== X-IronPort-AV: E=McAfee;i="6800,10657,11717"; a="84135434" X-IronPort-AV: E=Sophos;i="6.21,320,1763452800"; d="scan'208";a="84135434" Received: from orviesa001.jf.intel.com ([10.64.159.141]) by fmvoesa105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Mar 2026 10:46:26 -0800 X-CSE-ConnectionGUID: 1XwbRuMhS66K1jMpdPpFag== X-CSE-MsgGUID: N5b0hfajT3qS6OpKgAyjbQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,320,1763452800"; d="scan'208";a="255604080" Received: from rchatre-desk1.jf.intel.com ([10.165.154.99]) by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Mar 2026 10:46:26 -0800 From: Reinette Chatre To: tony.luck@intel.com, james.morse@arm.com, Dave.Martin@arm.com, babu.moger@amd.com, bp@alien8.de, tglx@linutronix.de, dave.hansen@linux.intel.com Cc: x86@kernel.org, hpa@zytor.com, ben.horgan@arm.com, fustini@kernel.org, fenghuay@nvidia.com, peternewman@google.com, linux-kernel@vger.kernel.org, patches@lists.linux.dev, reinette.chatre@intel.com Subject: [PATCH 02/11] fs/resctrl: Avoid "may be used uninitialized" warning Date: Mon, 2 Mar 2026 10:46:08 -0800 Message-ID: <71100a0c6f616bbb2da30d045dfeeaedf18bcd0f.1772476561.git.reinette.chatre@intel.com> X-Mailer: git-send-email 2.50.1 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Building resctrl with extra checks ("W=3D12") produces the following warnin= g: .../include/linux/ucopysize.h:22:17: warning: =E2=80=98buf=E2=80=99 may be= used uninitialized [-Wmaybe-uninitialized] 22 | __check_object_size(ptr, n, to_user); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .../include/linux/ucopysize.h: In function =E2=80=98pseudo_lock_measure_tr= igger=E2=80=99: .../include/linux/ucopysize.h:10:13: note: by argument 1 of type =E2=80=98= const void *=E2=80=99 to =E2=80=98__check_object_size=E2=80=99 declared here 10 | extern void __check_object_size(const void *ptr, unsigned long n, | ^~~~~~~~~~~~~~~~~~~ .../fs/resctrl/pseudo_lock.c:754:14: note: =E2=80=98buf=E2=80=99 declared = here 754 | char buf[32]; | ^~~ __check_object_size() ensures the provided buffer is within a valid location but does not read from the uninitialized buffer. Even so, initialize the buffer to silence the warning to help resctrl have a cleaner build. Signed-off-by: Reinette Chatre --- fs/resctrl/pseudo_lock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/resctrl/pseudo_lock.c b/fs/resctrl/pseudo_lock.c index e81d71abfe54..a857e51580e2 100644 --- a/fs/resctrl/pseudo_lock.c +++ b/fs/resctrl/pseudo_lock.c @@ -750,8 +750,8 @@ static ssize_t pseudo_lock_measure_trigger(struct file = *file, size_t count, loff_t *ppos) { struct rdtgroup *rdtgrp =3D file->private_data; + char buf[32] =3D {}; size_t buf_size; - char buf[32]; int ret; int sel; =20 --=20 2.50.1 From nobody Tue Mar 3 03:20:24 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3CE50355814 for ; Mon, 2 Mar 2026 18:46:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.11 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772477190; cv=none; b=ZpraQ29nYcEJ+mpJryAZw8mXSelJHnfQtiOoBScE1BBAf2TIofB7euHYFO6xEBR/jb7hAI+zsxORziVmMmxlnGGUadec6yQEHAfTShiW688+ZNCtvCbRsgiYSdZ15Jok5V7jr+DK9NNxqy1ZJj9SFQg4LsJU7/hNz220qRI4UhU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772477190; c=relaxed/simple; bh=CwrHQgPqOa0N4wtOACFz3iQnSLts6rYcN5/ddoUE6hY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=hfx1p3THMyoHM/80u+Cr4hNn4SiheOehFl55kUpH4RotTwuTXhGKfZox7ZRoePyz01ig1e3FnIqK+ccra9oqVgrQJzBl/uolEh9Zoe3X8K7rwKl8USVUclKc2U/K+RNK8vN+RcNpeNSVh9QP6qvRMPfrf7dllQhXrpiq3ZmnP4k= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=R6skcoYT; arc=none smtp.client-ip=192.198.163.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="R6skcoYT" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1772477189; x=1804013189; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=CwrHQgPqOa0N4wtOACFz3iQnSLts6rYcN5/ddoUE6hY=; b=R6skcoYTr2dUOJWFY5JX8n/RdvUYisJlUXmpUCtuqxiHt6rAV3bYsVb2 zp8lFqK2RRN0bU/DALDhQfy5kTvcxsKq2X4+k9AjJeEEP6BcogSR/4xQn R++1s1tGQKsX0nrv9kmiqr0losLn+LvPqYRPYAudKimY+S9uXgY+Ohc3K iu+CSIecxnwftzqsujoPtO5rvOVWudXdsa2xZ9BhcNkEwY/Ju24Qe9HPY seRY7i6bYmPaoKGXSmDUgeCpbxlTYbgtWWUpO7jkEpaO9DvzOo8jXhJtW cuftFryw1eUvneWtZn1Rj3p99GNAWYLtJA7M3hE7xtLOk2bzkjxF68Ms+ A==; X-CSE-ConnectionGUID: 8VszP1iXSDm8uNDeYspX1A== X-CSE-MsgGUID: kIa0/FbjSqueDRPYGelJww== X-IronPort-AV: E=McAfee;i="6800,10657,11717"; a="84135439" X-IronPort-AV: E=Sophos;i="6.21,320,1763452800"; d="scan'208";a="84135439" Received: from orviesa001.jf.intel.com ([10.64.159.141]) by fmvoesa105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Mar 2026 10:46:26 -0800 X-CSE-ConnectionGUID: ZOSBaofOTT2D/GqNz4h9qw== X-CSE-MsgGUID: MmJAruGuRCa+lDPCZdrUCw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,320,1763452800"; d="scan'208";a="255604083" Received: from rchatre-desk1.jf.intel.com ([10.165.154.99]) by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Mar 2026 10:46:26 -0800 From: Reinette Chatre To: tony.luck@intel.com, james.morse@arm.com, Dave.Martin@arm.com, babu.moger@amd.com, bp@alien8.de, tglx@linutronix.de, dave.hansen@linux.intel.com Cc: x86@kernel.org, hpa@zytor.com, ben.horgan@arm.com, fustini@kernel.org, fenghuay@nvidia.com, peternewman@google.com, linux-kernel@vger.kernel.org, patches@lists.linux.dev, reinette.chatre@intel.com Subject: [PATCH 03/11] fs/resctrl: Use correct format specifier for printing error pointers Date: Mon, 2 Mar 2026 10:46:09 -0800 Message-ID: X-Mailer: git-send-email 2.50.1 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Use correct format specifier for error pointer as coccinelle suggests: .../fs/resctrl/monitor.c:148:8-15: WARNING: Consider using %pe to print= PTR_ERR() .../fs/resctrl/monitor.c:760:9-16: WARNING: Consider using %pe to print= PTR_ERR() Signed-off-by: Reinette Chatre --- fs/resctrl/monitor.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/fs/resctrl/monitor.c b/fs/resctrl/monitor.c index 93db7c1cd7be..421c70f96426 100644 --- a/fs/resctrl/monitor.c +++ b/fs/resctrl/monitor.c @@ -144,8 +144,8 @@ void __check_limbo(struct rdt_l3_mon_domain *d, bool fo= rce_free) arch_priv =3D mon_event_all[QOS_L3_OCCUP_EVENT_ID].arch_priv; arch_mon_ctx =3D resctrl_arch_mon_ctx_alloc(r, QOS_L3_OCCUP_EVENT_ID); if (IS_ERR(arch_mon_ctx)) { - pr_warn_ratelimited("Failed to allocate monitor context: %ld", - PTR_ERR(arch_mon_ctx)); + pr_warn_ratelimited("Failed to allocate monitor context: %pe", + arch_mon_ctx); return; } =20 @@ -752,8 +752,8 @@ static void mbm_update_one_event(struct rdt_resource *r= , struct rdt_l3_mon_domai } else { rr.arch_mon_ctx =3D resctrl_arch_mon_ctx_alloc(rr.r, evtid); if (IS_ERR(rr.arch_mon_ctx)) { - pr_warn_ratelimited("Failed to allocate monitor context: %ld", - PTR_ERR(rr.arch_mon_ctx)); + pr_warn_ratelimited("Failed to allocate monitor context: %pe", + rr.arch_mon_ctx); return; } } --=20 2.50.1 From nobody Tue Mar 3 03:20:24 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 69CB42E8B83 for ; Mon, 2 Mar 2026 18:46:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.11 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772477191; cv=none; b=GoziaaBJg6CnsERIGfLevD1XQBmkn4aAAWWuFAtuN+m2T1Hz05fWYJ92ecvzZzaHQZkTBUliX6kEe/m+ME2AEdqR/+FK2HOr7c4F2UlV+KMXoingDHpBN7mg2wlnd2Diy7qWTK1EIGB8bI8/z3XKidk1H9vSKeIc91aejqyav60= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772477191; c=relaxed/simple; bh=XQbrDtV7kC3BagIoRNk2xRfz81oxluInULTjgTirvbA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=sEXAcgF0UMnxjCGqGBCcZbUuQuXmkn1tCkchO+M5tcoKD8HP0pAc5T2aKqSJFDz7zzniX7UMWXkNR3kGgB8pDTA9TeRgwl9FkMtLBWSmHqYceVYCTzLrsKneO9/zbSNUJcYYJLFfM2lqyWQIlL6AiVpirWVauDzzfbgAzahEC1Y= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=PX178H/t; arc=none smtp.client-ip=192.198.163.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="PX178H/t" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1772477190; x=1804013190; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=XQbrDtV7kC3BagIoRNk2xRfz81oxluInULTjgTirvbA=; b=PX178H/txyS0O95ZkDpHIB6ekxXFZwVSl+9k3lxnVukt8igbddXnsJBP TAa04J2lAoewwObWBy16QEJ+UfrDoxd1ZlGDHEkdm9p6jwospxKsy+FSW KoPb/TuJbTjY/vk0UQ1b62huyEmPdWaG8Vjhyb2IlrPpEBYPThQBiAm+j HGn1upH/QjORZqS50sXz2xiYIErlVz4PC5Zi4wn0BYEW6O9dczy6LtPOq qhAYXrYK2Xnuptu7O2N2P25Fs+OE5DhXgDP/8fnnMM0TrlET8ydn/yk/g dHUGPBGxtf45EQwU8zAkBQBaaGhIQDS5J//8UyKS0JJdCi/CK7OBdRHN0 Q==; X-CSE-ConnectionGUID: sHYDxSlcTTCn2tJ2yAJ6jQ== X-CSE-MsgGUID: vDVL/X28RCWcIJT+bmOMww== X-IronPort-AV: E=McAfee;i="6800,10657,11717"; a="84135454" X-IronPort-AV: E=Sophos;i="6.21,320,1763452800"; d="scan'208";a="84135454" Received: from orviesa001.jf.intel.com ([10.64.159.141]) by fmvoesa105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Mar 2026 10:46:26 -0800 X-CSE-ConnectionGUID: DgXG0t+RSA2FtlD8thqVmw== X-CSE-MsgGUID: dVCDayM6RgGTiMCd1ME1vQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,320,1763452800"; d="scan'208";a="255604086" Received: from rchatre-desk1.jf.intel.com ([10.165.154.99]) by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Mar 2026 10:46:26 -0800 From: Reinette Chatre To: tony.luck@intel.com, james.morse@arm.com, Dave.Martin@arm.com, babu.moger@amd.com, bp@alien8.de, tglx@linutronix.de, dave.hansen@linux.intel.com Cc: x86@kernel.org, hpa@zytor.com, ben.horgan@arm.com, fustini@kernel.org, fenghuay@nvidia.com, peternewman@google.com, linux-kernel@vger.kernel.org, patches@lists.linux.dev, reinette.chatre@intel.com Subject: [PATCH 04/11] x86/resctrl: Protect against bad shift Date: Mon, 2 Mar 2026 10:46:10 -0800 Message-ID: <36e7f922c6779ffccd007bd7be6b33e0e1b7f9f9.1772476561.git.reinette.chatre@intel.com> X-Mailer: git-send-email 2.50.1 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The size of the bandwidth specifier field is enumerated from AMD hardware. resctrl uses this field width to determine the maximum bandwidth supported that is stored in resctrl_membw::max_bw to which user space allocation requests are compared for validity. resctrl_membw::max_bw is of type u32 while the register containing the bandwidth specifier field, L3QOS_BW_CONTROL_n, is 64 bits. While not an issue with current hardware it is theoretically possible that enumeration of maximum bandwidth may trigger invalid behavior if a future system can use a bandwidth specifier field larger than 32 bits. Whether this could ever represent a reasonable bandwidth value is unknown but addressing the issue will appease static checkers. Ensure resctrl can accommodate the hardware's bandwidth specifier field width with an additional check. Switch to BIT() instead of open-coding the bitshift to avoid signed integer overflow if the number of bits is a valid 31. Signed-off-by: Reinette Chatre --- arch/x86/kernel/cpu/resctrl/core.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/cpu/resctrl/core.c b/arch/x86/kernel/cpu/resct= rl/core.c index 7667cf7c4e94..db787c4dee61 100644 --- a/arch/x86/kernel/cpu/resctrl/core.c +++ b/arch/x86/kernel/cpu/resctrl/core.c @@ -246,7 +246,9 @@ static __init bool __rdt_get_mem_config_amd(struct rdt_= resource *r) =20 cpuid_count(0x80000020, subleaf, &eax, &ebx, &ecx, &edx); hw_res->num_closid =3D edx + 1; - r->membw.max_bw =3D 1 << eax; + if (WARN_ON(BITS_PER_TYPE(r->membw.max_bw) <=3D eax)) + return false; + r->membw.max_bw =3D BIT(eax); =20 /* AMD does not use delay */ r->membw.delay_linear =3D false; --=20 2.50.1 From nobody Tue Mar 3 03:20:24 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 311A83431E6 for ; Mon, 2 Mar 2026 18:46:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.11 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772477191; cv=none; b=NUyO2uVBQeeRU3Le1aam3bEKGx2vpABWbf3D7yHMnLy4kue7vFKYmVa7TInFTggKvh1jy5BQnNrWcYJVt6fa7XedZAlc4721HuKodEkauE2SGwwSq84/kRivOn+i5FDUhZgSjIO3SNR89R44dFRiLPFr0A8GYnks4EmCOAZYqXs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772477191; c=relaxed/simple; bh=nwyQzMGADx/PfQKCWg0k2WacxbE7C0hQBCBBvvQeJ94=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=FmA65ZjlM3PE8+AZZBshYQaTBxHlH3P5LgXEI46JVtBoTru68RlU5gw5F2hyrH5qehZc5m61ug3J0OL2AfJEXjsDpNWCVgyRlrXCCwXcKwimzJEcPOO+UT7KlEhxGi6aEW207Cz3CJL+wzlHWjrGFoonrZRwq0w4GsvjlMesyPo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=EvQ8zz0H; arc=none smtp.client-ip=192.198.163.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="EvQ8zz0H" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1772477190; x=1804013190; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=nwyQzMGADx/PfQKCWg0k2WacxbE7C0hQBCBBvvQeJ94=; b=EvQ8zz0H5Z1Abdl6WVSR8baFbFlFMdKUvjGtHTJJ9dp7cKyKUsliL3FI uXMVHVgo5Co1Fxe4wkMC3ViQctT8gJCtx1m3KxZIGcsENBrg1rLRb0Dsj 87IAPab/RahPJDd9J6bUhogjnbnCqjdK1WBiVgbk7lkCfrRiXkSIGvDre kH27qCJLiMSgbksDR0TjLToT2ejl2WJtPqzmv5LPIY/CwCSbuAVtzInZD fYn+jojVM1lGVFBqqf1Gh721Xa2wDmf8Qf0aRW0s2jF+u7C7Njx1uZEIM PQtnPRIP8wmeFuGYKpODSo9+F2qb9c49GTi6PGOu92Adth3IeKWQij5v1 Q==; X-CSE-ConnectionGUID: GFMz4CB8RO+AfnPqv6rLrw== X-CSE-MsgGUID: QUQkJfoORYCl2ftFCBeE5w== X-IronPort-AV: E=McAfee;i="6800,10657,11717"; a="84135466" X-IronPort-AV: E=Sophos;i="6.21,320,1763452800"; d="scan'208";a="84135466" Received: from orviesa001.jf.intel.com ([10.64.159.141]) by fmvoesa105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Mar 2026 10:46:26 -0800 X-CSE-ConnectionGUID: FItd45U6T5GnrJ2dKM4YIw== X-CSE-MsgGUID: uVw9xmdBRKKfw9k9oeKV/A== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,320,1763452800"; d="scan'208";a="255604089" Received: from rchatre-desk1.jf.intel.com ([10.165.154.99]) by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Mar 2026 10:46:26 -0800 From: Reinette Chatre To: tony.luck@intel.com, james.morse@arm.com, Dave.Martin@arm.com, babu.moger@amd.com, bp@alien8.de, tglx@linutronix.de, dave.hansen@linux.intel.com Cc: x86@kernel.org, hpa@zytor.com, ben.horgan@arm.com, fustini@kernel.org, fenghuay@nvidia.com, peternewman@google.com, linux-kernel@vger.kernel.org, patches@lists.linux.dev, reinette.chatre@intel.com Subject: [PATCH 05/11] fs/resctrl: Use accurate type for rdt_resource::rid Date: Mon, 2 Mar 2026 10:46:11 -0800 Message-ID: <956a7f8c9ff85b873ec85159a66d5e3c8b468d70.1772476561.git.reinette.chatre@intel.com> X-Mailer: git-send-email 2.50.1 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Every resctrl resource has a unique ID described by enum resctrl_res_level. enum resctrl_res_level is used in all resource ID initializations and all resource ID comparisons. All functions consuming the resource ID expects an enum resctrl_res_level. Of the four structures that contain a resource ID (struct mon_data, struct mon_evt, struct rdt_domain_hdr, and struct rdt_resource) only struct rdt_resource does not use enum resctrl_res_level. Switch the type of rdt_resource::rid to be enum resctrl_res_level to make it obvious what values are valid, match the type everywhere this member is used, and obtain benefits from tools that can flag any enum misuse. Move define of RDT_NUM_RESOURCES outside the enum to enable tools to catch when a switch() on the resource ID does not handle all the resources and thus help flag which switch statements need an update when a new resource is added. Signed-off-by: Reinette Chatre --- include/linux/resctrl.h | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/include/linux/resctrl.h b/include/linux/resctrl.h index 006e57fd7ca5..48e95f273fb3 100644 --- a/include/linux/resctrl.h +++ b/include/linux/resctrl.h @@ -54,11 +54,11 @@ enum resctrl_res_level { RDT_RESOURCE_MBA, RDT_RESOURCE_SMBA, RDT_RESOURCE_PERF_PKG, - - /* Must be the last */ - RDT_NUM_RESOURCES, + /* Additions to enum need to update RDT_NUM_RESOURCES. */ }; =20 +#define RDT_NUM_RESOURCES (RDT_RESOURCE_PERF_PKG + 1) + /** * enum resctrl_conf_type - The type of configuration. * @CDP_NONE: No prioritisation, both code and data are controlled or moni= tored. @@ -319,7 +319,7 @@ struct resctrl_mon { * @cdp_capable: Is the CDP feature available on this resource */ struct rdt_resource { - int rid; + enum resctrl_res_level rid; bool alloc_capable; bool mon_capable; enum resctrl_scope ctrl_scope; --=20 2.50.1 From nobody Tue Mar 3 03:20:24 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A881E366DB7 for ; Mon, 2 Mar 2026 18:46:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.11 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772477194; cv=none; b=EZwUIrVF5t27jsr9ibKbYYJERmjKzHWC9i3W7uhbrFAspIe5Pg/Jt56pCN6F6woNkffc/64E6p3EnI4uPzlq2WEHMyYwpT9KirrZNjUnjz5YgwtH6dQKF2P+fz86OvzUuh+XXrQk5BepGYPAFM06UYioVr5+NXRqL2y5jf/pRX4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772477194; c=relaxed/simple; bh=dWQkMySV2jYd0tvpllHLWFB4pHJJvS5dZ9FwHlCFYDI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=T1Mie6YGVWubU6JdVzNAb74gFo5L1CcSPAF4EvItpRJ7caVALyK+R0N3HcK2gvB+3XFzxPRn3PzlFeqbK1KLcXKTCLOWvap5k8fvoGzu/fC/dzT/jAIFLL4+N+ad1bgyH/q7fR0klpxPOo0hgS6xC/NxHSIIGmS7bsK8ck/sBI4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=MeDWd75d; arc=none smtp.client-ip=192.198.163.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="MeDWd75d" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1772477191; x=1804013191; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=dWQkMySV2jYd0tvpllHLWFB4pHJJvS5dZ9FwHlCFYDI=; b=MeDWd75dkKvd9eWGoC/D2ZGnX40x6LRzCclFvDTWY3T148afpM6nU2SJ qN/QXKap3WeupXFAd/48kTCFF2OtoDBTnSwe1uD6efBxhvJ+ltNKR6R8X Nb5AOBeilDLv0CcQzgANI5+z30+MTU6wJgPsnbnNvWy4zc1T3GzKHv2NZ 0f8mbPOYWxzkCmiQM8XwglCLSkqXXHv0FbH4b8gai9E+v4WcU3Ufumj8O D8OFhshrydq7BEs7c2gGpLtEhxHpmAM31dN1fyEH3dSqRl1MIbNIA+YAF Jb37wZyf7nFkiVrT1J8Toi9wjS2gvVv1LKGt/1e1yDqHLHGPuT2cV/I2T Q==; X-CSE-ConnectionGUID: 1771VldMQIeZPBv/CRU3Lg== X-CSE-MsgGUID: DkclRhGBTme/cQO43pR0Tw== X-IronPort-AV: E=McAfee;i="6800,10657,11717"; a="84135476" X-IronPort-AV: E=Sophos;i="6.21,320,1763452800"; d="scan'208";a="84135476" Received: from orviesa001.jf.intel.com ([10.64.159.141]) by fmvoesa105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Mar 2026 10:46:26 -0800 X-CSE-ConnectionGUID: 64mwtmaoQHWPDdNYmebMbw== X-CSE-MsgGUID: r4CXWXiVRtuVf3SPHYe7Sw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,320,1763452800"; d="scan'208";a="255604092" Received: from rchatre-desk1.jf.intel.com ([10.165.154.99]) by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Mar 2026 10:46:26 -0800 From: Reinette Chatre To: tony.luck@intel.com, james.morse@arm.com, Dave.Martin@arm.com, babu.moger@amd.com, bp@alien8.de, tglx@linutronix.de, dave.hansen@linux.intel.com Cc: x86@kernel.org, hpa@zytor.com, ben.horgan@arm.com, fustini@kernel.org, fenghuay@nvidia.com, peternewman@google.com, linux-kernel@vger.kernel.org, patches@lists.linux.dev, reinette.chatre@intel.com Subject: [PATCH 06/11] fs/resctrl: Pass error reading event through to user space Date: Mon, 2 Mar 2026 10:46:12 -0800 Message-ID: <6ceb56817d137bee96a5e4508657bf9080cb4acf.1772476561.git.reinette.chatre@intel.com> X-Mailer: git-send-email 2.50.1 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Reading of event data is managed through populating a struct rmid_read with properties of event needing to be read. This data is dispatched to an appropriate CPU and upon completion any error can be found in rmid_read::er= r, or on success the event data will be in rmid_read::val. rmid_read::err is not updated in the unlikely scenario that the reading of the event was dispatched to a wrong CPU. If this ever occurs due to a bug in resctrl the user space read will return "success" but the data reported will be invalid. Ensure accurate error reporting so that if there may be an issue with how resctrl picks a CPU it could be learned with an error to user space instead of silent failure. Signed-off-by: Reinette Chatre --- fs/resctrl/monitor.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/fs/resctrl/monitor.c b/fs/resctrl/monitor.c index 421c70f96426..f1a08fdbdd61 100644 --- a/fs/resctrl/monitor.c +++ b/fs/resctrl/monitor.c @@ -453,8 +453,10 @@ static int __l3_mon_event_count(struct rdtgroup *rdtgr= p, struct rmid_read *rr) } =20 /* Reading a single domain, must be on a CPU in that domain. */ - if (!cpumask_test_cpu(cpu, &d->hdr.cpu_mask)) + if (!cpumask_test_cpu(cpu, &d->hdr.cpu_mask)) { + rr->err =3D -EIO; return -EINVAL; + } if (rr->is_mbm_cntr) rr->err =3D resctrl_arch_cntr_read(rr->r, d, closid, rmid, cntr_id, rr->evt->evtid, &tval); @@ -491,8 +493,10 @@ static int __l3_mon_event_count_sum(struct rdtgroup *r= dtgrp, struct rmid_read *r } =20 /* Summing domains that share a cache, must be on a CPU for that cache. */ - if (!cpumask_test_cpu(cpu, &rr->ci->shared_cpu_map)) + if (!cpumask_test_cpu(cpu, &rr->ci->shared_cpu_map)) { + rr->err =3D -EIO; return -EINVAL; + } =20 /* * Legacy files must report the sum of an event across all --=20 2.50.1 From nobody Tue Mar 3 03:20:24 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D6E13377034 for ; Mon, 2 Mar 2026 18:46:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.11 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772477194; cv=none; b=pbrgFu/O9EFkGcW8d6yZ8jFm7znowEwHVlrNQ7T+XQ0gMGZsV57Ah3M85BgxvNYGsJ7OUI0JjVIaq00AvhPu0RtcBjHtbEr9B7x9WH9FImou/Ra1HRVtl7tHhUkC9oVzzVCSkbHgSN1KMUv2gmxae4G4guqqcI9EKbPNsv+tJhg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772477194; c=relaxed/simple; bh=Qq52SRm9YMpEcB4HrMywHjfc+PUC4Z32uOPEJC9WLiA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=NAH3K5pAmG9uY26y3YBB4u5wiOCymnkGqvG1SMZ7/9SrIGeO46Z5X88Sj+7YRfJfmivxitLoCHkIc/tlY7RJd0BXh+qcdQvFuxm0yTrKXJYuSP9ZW1e0tm7KpR3GDHQHHAblQoTfF97/U0Kc9kQo01zmgpulYEI5jr5nnKCthqM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=cZlW+bBm; arc=none smtp.client-ip=192.198.163.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="cZlW+bBm" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1772477192; x=1804013192; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=Qq52SRm9YMpEcB4HrMywHjfc+PUC4Z32uOPEJC9WLiA=; b=cZlW+bBm2zg0Y6818LSLsjkl1QJ329Tw0vivpCEf9ElBYxDCcQih/WYm Mf0lCmhfPWby1C2swGbcH8hzsLDspFO+BossW1zWuywe6HO7aFdVStwBW DU5u9PpHP5kj4LKluAeEimjXvVe+Ll9PRjrLnVa0jKBge+oIAOd3KXYnA ciNYSwRKxTi81X+bo2QgVx6VtzkiWnfg5ljAzwMYKVdNB7B/HgbZYjqtS 7er8xBztxo7sgwzcDBhgjeAch//QjBawl5irTLQ5dt6dn1hCYTvEcE8g8 v+zL6+bK0iRtHR3TQLixmaLEXi5Qae9nFbTI0BUsNYKt3MCg/v5fWK5cw Q==; X-CSE-ConnectionGUID: dngXnuSnSbi/C9Mii/4SBg== X-CSE-MsgGUID: 9/Su64jzSHSEfYb0XaxVFA== X-IronPort-AV: E=McAfee;i="6800,10657,11717"; a="84135490" X-IronPort-AV: E=Sophos;i="6.21,320,1763452800"; d="scan'208";a="84135490" Received: from orviesa001.jf.intel.com ([10.64.159.141]) by fmvoesa105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Mar 2026 10:46:26 -0800 X-CSE-ConnectionGUID: W/NkPF9qTqq5HXxRFtBljQ== X-CSE-MsgGUID: 7XiSeI0aS4+rwi8TTKctNA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,320,1763452800"; d="scan'208";a="255604095" Received: from rchatre-desk1.jf.intel.com ([10.165.154.99]) by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Mar 2026 10:46:26 -0800 From: Reinette Chatre To: tony.luck@intel.com, james.morse@arm.com, Dave.Martin@arm.com, babu.moger@amd.com, bp@alien8.de, tglx@linutronix.de, dave.hansen@linux.intel.com Cc: x86@kernel.org, hpa@zytor.com, ben.horgan@arm.com, fustini@kernel.org, fenghuay@nvidia.com, peternewman@google.com, linux-kernel@vger.kernel.org, patches@lists.linux.dev, reinette.chatre@intel.com Subject: [PATCH 07/11] fs/resctrl: Add last_cmd_status support for writes to max_threshold_occupancy Date: Mon, 2 Mar 2026 10:46:13 -0800 Message-ID: X-Mailer: git-send-email 2.50.1 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" info/last_cmd_status is intended to contain more information if a write to any resctrl file fails. Writes to max_threshold_occupancy did not receive last_cmd_status support during initial last_cmd_status enabling. Add it now. Signed-off-by: Reinette Chatre --- fs/resctrl/rdtgroup.c | 21 ++++++++++++++++----- 1 file changed, 16 insertions(+), 5 deletions(-) diff --git a/fs/resctrl/rdtgroup.c b/fs/resctrl/rdtgroup.c index 3c9508fc558d..933f6ae26d59 100644 --- a/fs/resctrl/rdtgroup.c +++ b/fs/resctrl/rdtgroup.c @@ -1238,16 +1238,27 @@ static ssize_t max_threshold_occ_write(struct kernf= s_open_file *of, unsigned int bytes; int ret; =20 + mutex_lock(&rdtgroup_mutex); + rdt_last_cmd_clear(); + ret =3D kstrtouint(buf, 0, &bytes); - if (ret) - return ret; + if (ret) { + rdt_last_cmd_puts("Invalid input\n"); + goto out_unlock; + } =20 - if (bytes > resctrl_rmid_realloc_limit) - return -EINVAL; + if (bytes > resctrl_rmid_realloc_limit) { + rdt_last_cmd_printf("Exceeds limit (before adjustment) of %u bytes\n", + resctrl_rmid_realloc_limit); + ret =3D -EINVAL; + goto out_unlock; + } =20 resctrl_rmid_realloc_threshold =3D resctrl_arch_round_mon_val(bytes); =20 - return nbytes; +out_unlock: + mutex_unlock(&rdtgroup_mutex); + return ret ?: nbytes; } =20 /* --=20 2.50.1 From nobody Tue Mar 3 03:20:24 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CFC67377020 for ; Mon, 2 Mar 2026 18:46:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.11 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772477194; cv=none; b=fa+2Yy+8Mc7mdxB3lSphDn7o2iktJ/Z9oRGipMiZxylZkCEy5T7/MxgzSxvqEb8lVit89iDQmsIdfE+WyBKwM/n9QQfAUKlBXgrekY6Yq53IrAwiNZ1UmLdBOReireJxl1qsznOW821yF3aqMRua6JffTgQkrXYUasmGjKt4wh0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772477194; c=relaxed/simple; bh=WuOr17rmOeSXijSalpBw2VvgVcngOVpjuie0BTD4cHE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=SFGX8Df/1fzGW1RFLPaF2Ec5pphFW4uRdGhwZO/KlCTgqQQy3QjvdhodhJ1c+r7wJtb+6KmpE/hc1qb7y767uaFMeBgD816iAP+UxbAeumpRLCu1bArjwuwhFkeA6EbV5yl3rmAYojTj9/Nf/1YYZMfOQeMyXrEPI1MeTHq+9Bc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=Bf2Dob/O; arc=none smtp.client-ip=192.198.163.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="Bf2Dob/O" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1772477192; x=1804013192; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=WuOr17rmOeSXijSalpBw2VvgVcngOVpjuie0BTD4cHE=; b=Bf2Dob/OAgdPURMQjrOUWb6gcVvZI8R03A9rWQIh9etBO4YCdWDzQdEl z730QOWH2qfximAc06BEeuGtkz5pMGjOEjJqB4mkGFbPHYQ8XDv29XSwk QkbF5wTNbM4iJhQs55sMOohRp+8y8xuApES+bO9NB5+BOzmoXlx2j0RQ1 HMpIPNqHzhvZ+0AXNCk3REyO5LLtFLw4+nFv2TdzADHpBNvUVLKOxGJMS 7sR36Uxhl9qbsraWAZ65srtnSYqZH22hi1y2qel9Dc0qHf/8WYcIawbtU a0FEyTaGoxULkxvrKi/ytWZtdEY4WVvGuOaHKIXgDWUsAHzPeyy7FpzAt w==; X-CSE-ConnectionGUID: Iftm5w7dQZu774/hxphYQg== X-CSE-MsgGUID: NsGNRuGDQbeLUigN4b7Q6Q== X-IronPort-AV: E=McAfee;i="6800,10657,11717"; a="84135492" X-IronPort-AV: E=Sophos;i="6.21,320,1763452800"; d="scan'208";a="84135492" Received: from orviesa001.jf.intel.com ([10.64.159.141]) by fmvoesa105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Mar 2026 10:46:26 -0800 X-CSE-ConnectionGUID: P/TfXnQ8RGKa+2ORRT8PDw== X-CSE-MsgGUID: Olwv4Q0USdibrUg0kCqD2A== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,320,1763452800"; d="scan'208";a="255604098" Received: from rchatre-desk1.jf.intel.com ([10.165.154.99]) by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Mar 2026 10:46:26 -0800 From: Reinette Chatre To: tony.luck@intel.com, james.morse@arm.com, Dave.Martin@arm.com, babu.moger@amd.com, bp@alien8.de, tglx@linutronix.de, dave.hansen@linux.intel.com Cc: x86@kernel.org, hpa@zytor.com, ben.horgan@arm.com, fustini@kernel.org, fenghuay@nvidia.com, peternewman@google.com, linux-kernel@vger.kernel.org, patches@lists.linux.dev, reinette.chatre@intel.com Subject: [PATCH 08/11] fs/resctrl: Use accurate and symmetric exit flows Date: Mon, 2 Mar 2026 10:46:14 -0800 Message-ID: X-Mailer: git-send-email 2.50.1 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" During schemata file write handling there is one error exit path labeled "out" that handles all cleanup and unlocking needed on exit. The staged configs cleared during an error exit may not have been used at the time of exit making the clearing of the staged configs unnecessary. Access the exit code using two labels and only clear the staged configuration if it was in use at the time of exit. Doing so makes the code flow obvious and simplifies upcoming changes that improve the handling of failures during early input parsing. Signed-off-by: Reinette Chatre --- fs/resctrl/ctrlmondata.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/fs/resctrl/ctrlmondata.c b/fs/resctrl/ctrlmondata.c index cc4237c57cbe..a8e7cdcfec6e 100644 --- a/fs/resctrl/ctrlmondata.c +++ b/fs/resctrl/ctrlmondata.c @@ -331,7 +331,7 @@ ssize_t rdtgroup_schemata_write(struct kernfs_open_file= *of, if (rdtgrp->mode =3D=3D RDT_MODE_PSEUDO_LOCKED) { ret =3D -EINVAL; rdt_last_cmd_puts("Resource group is pseudo-locked\n"); - goto out; + goto out_unlock; } =20 rdt_staged_configs_clear(); @@ -341,16 +341,16 @@ ssize_t rdtgroup_schemata_write(struct kernfs_open_fi= le *of, if (!tok) { rdt_last_cmd_puts("Missing ':'\n"); ret =3D -EINVAL; - goto out; + goto out_clear_staged; } if (tok[0] =3D=3D '\0') { rdt_last_cmd_printf("Missing '%s' value\n", resname); ret =3D -EINVAL; - goto out; + goto out_clear_staged; } ret =3D rdtgroup_parse_resource(resname, tok, rdtgrp); if (ret) - goto out; + goto out_clear_staged; } =20 list_for_each_entry(s, &resctrl_schema_all, list) { @@ -365,7 +365,7 @@ ssize_t rdtgroup_schemata_write(struct kernfs_open_file= *of, =20 ret =3D resctrl_arch_update_domains(r, rdtgrp->closid); if (ret) - goto out; + goto out_clear_staged; } =20 if (rdtgrp->mode =3D=3D RDT_MODE_PSEUDO_LOCKSETUP) { @@ -378,8 +378,9 @@ ssize_t rdtgroup_schemata_write(struct kernfs_open_file= *of, ret =3D rdtgroup_pseudo_lock_create(rdtgrp); } =20 -out: +out_clear_staged: rdt_staged_configs_clear(); +out_unlock: rdtgroup_kn_unlock(of->kn); return ret ?: nbytes; } --=20 2.50.1 From nobody Tue Mar 3 03:20:24 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 65118383C74 for ; Mon, 2 Mar 2026 18:46:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.11 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772477195; cv=none; b=TFfqt2wQ6UKgCsblpPcsJ+D0k+bG4v9JOYx6bF07qxcvcHIPp6/5BtjV6Rl4hZu33RC/HkTmpdnB1pG3vo/zkiW0rWLKx6RCKXFTAYoLYxLGqWMkpaozCafqICROreONXCr5IvawD89IPWXwfy/FyP9LM0oV+ml3O09ZwGORdH4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772477195; c=relaxed/simple; bh=jmRYPBs4qnWxa2oEzq7iX9LJGBD9xCCVJOZk0JJE8co=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=M2lSzSU1hztbs1WjHheZUFNOCQqH4d3j6at9TfamqRjkbRIDQbAO2t/uHtRHotc3mAsJT1emeWajy2JVbyjWKAIRLVjJs0C6fIq50GIGxd/MWwQpjr13DZAyKua65eVHUkQyPHramxXY17o+aCl9KfQSrwt2CpJbttxaUECxYR8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=nMNkKC3j; arc=none smtp.client-ip=192.198.163.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="nMNkKC3j" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1772477195; x=1804013195; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=jmRYPBs4qnWxa2oEzq7iX9LJGBD9xCCVJOZk0JJE8co=; b=nMNkKC3jJIURCcTTS/ZlNt5TXBO8NbclOGbkjw+tgbtjrdr5JuC1U4Gy Krk55X0Qq74mxW2Ny7burWlVgDhf0mDS/Tq8VUrZbKhELPEMrntXx2KGc z60ipZtj5KrOhMJ5/nx7WZP+JqdnECQ63YaAOqZ2YWYXcS38D94MnHi5j KauGGHhyhSWT/kQe776s/5A9qfuxJ5XRmNFgK54f482GWKxhdZLsMEZ+I I3TONNFjWOH5kBOj9sK0fdjhWtRGrnvjKXNPSyhdofdQt2TUi7pvACsVO dyNPOdAhCHvxgGe6OuoFMjg5ZPTEhZ9Qt/SRxKuoHf3Ldeim3mT9HXFc5 A==; X-CSE-ConnectionGUID: 4Zj6h77gRSyCkL43I4ke6A== X-CSE-MsgGUID: OkAdd+ApQVmUe4qdWF2SJQ== X-IronPort-AV: E=McAfee;i="6800,10657,11717"; a="84135508" X-IronPort-AV: E=Sophos;i="6.21,320,1763452800"; d="scan'208";a="84135508" Received: from orviesa001.jf.intel.com ([10.64.159.141]) by fmvoesa105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Mar 2026 10:46:27 -0800 X-CSE-ConnectionGUID: U/uMiH4NQX6JTeOuEeL0aQ== X-CSE-MsgGUID: ZrK4N+3JSg+Vdk0zP48UFw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,320,1763452800"; d="scan'208";a="255604101" Received: from rchatre-desk1.jf.intel.com ([10.165.154.99]) by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Mar 2026 10:46:26 -0800 From: Reinette Chatre To: tony.luck@intel.com, james.morse@arm.com, Dave.Martin@arm.com, babu.moger@amd.com, bp@alien8.de, tglx@linutronix.de, dave.hansen@linux.intel.com Cc: x86@kernel.org, hpa@zytor.com, ben.horgan@arm.com, fustini@kernel.org, fenghuay@nvidia.com, peternewman@google.com, linux-kernel@vger.kernel.org, patches@lists.linux.dev, reinette.chatre@intel.com Subject: [PATCH 09/11] fs/resctrl: Use stricter checks on input to cpus/cpus_list file Date: Mon, 2 Mar 2026 10:46:15 -0800 Message-ID: X-Mailer: git-send-email 2.50.1 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Callbacks handling writes to resctrl files are called via kernfs_fop_write_iter() that ensures that the resctrl callback is never called with a NULL buffer. Even if user space issues a write() with a NULL buffer and zero count the resctrl callback receives a valid buffer terminated with '\0' and the number of bytes parameter set to zero. The NULL buffer check at the beginning of rdtgroup_cpus_write(), while making no assumptions about caller behavior, is not useful. An empty buffer is transformed into an empty cpumask that is passed through entire flow that results in no changes. Ensure that the user provided buffer contains some data before attempting to parse it using the same check as other resctrl files (the familiar "nbytes =3D=3D 0"). The custom is for resctrl file callbacks to fail on an empty buffer and this brings interactions with the cpus/cpus_list file in line with this custom. The risk is that if there exists a user space that uses empty writes to this specific file then those successful interactions will start failing. Exit right away if there was no failure yet no cpumask could be created from the input. It is of no use to pass an empty cpumask through the entire flow, just return with success to short-circuit the existing behavior. Signed-off-by: Reinette Chatre --- fs/resctrl/rdtgroup.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/fs/resctrl/rdtgroup.c b/fs/resctrl/rdtgroup.c index 933f6ae26d59..f33a50c545bc 100644 --- a/fs/resctrl/rdtgroup.c +++ b/fs/resctrl/rdtgroup.c @@ -515,7 +515,7 @@ static ssize_t rdtgroup_cpus_write(struct kernfs_open_f= ile *of, struct rdtgroup *rdtgrp; int ret; =20 - if (!buf) + if (!buf || nbytes =3D=3D 0) return -EINVAL; =20 if (!zalloc_cpumask_var(&tmpmask, GFP_KERNEL)) @@ -555,6 +555,9 @@ static ssize_t rdtgroup_cpus_write(struct kernfs_open_f= ile *of, goto unlock; } =20 + if (cpumask_empty(newmask)) + goto unlock; + /* check that user didn't specify any offline cpus */ cpumask_andnot(tmpmask, newmask, cpu_online_mask); if (!cpumask_empty(tmpmask)) { --=20 2.50.1 From nobody Tue Mar 3 03:20:24 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 855AA383C98 for ; Mon, 2 Mar 2026 18:46:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.11 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772477197; cv=none; b=d/YkoFjK/m1D/gHsDVjcbrbEWz7MafCHm8kBoJz1MihRA8QUYFNMrRMqjOpfV/t70zTnIR8iIk1FMHnajSiP8+n6GUohkgifW5vlKnNmfiXJuTWZ497V3WgSzR7XCz7/13JKMORtB0EHr73IHgNArXaNU3GQiGwSb+xLUZclMGg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772477197; c=relaxed/simple; bh=/jyQh8Q6R02r9eO1ihb6qt+lfOWNdbA214wN+6np2WQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=tVVhWb7pwMnGC/B0XsenIIJHgPxv582eVQi+amughqZyIMfyWAjKvDTAVJOL+FRhEB5I9Z4ZMMTYYkJG9HO5UQNGGMB1biouCPmA6/VGYw12t2vuvJui68JDCTHMoFjTXwVbLS71lHGXgVKWlAGBKynspgfTQrb9gW69g+wyyKY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=PoOiRm06; arc=none smtp.client-ip=192.198.163.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="PoOiRm06" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1772477195; x=1804013195; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=/jyQh8Q6R02r9eO1ihb6qt+lfOWNdbA214wN+6np2WQ=; b=PoOiRm06qRXWhUnmIyXboSD12glGAMQncYlzaTrVCf0COJeYblP73iSW e2ymDkVldkrTilqHw8Uq3YEMxncV1Ux1hlDvOD2gkyl9pYmq2KHCh9zqi 4RR/L0GkFRAhmURg5v+n0KnGNY4p9RA5Rj8bxm8oqEXHxgpi4/nJCpfgN 9q+fsbSFHbIihLGk100Jj2akG1rRrnWQ9fviTu6wnDqXsAn2Sjb4ppYUn XAleSt5vvkhLo/8FRP4BN+56zVlf/zD6y4N6ClNtyNHYH+Qn5rHIdin+h 1zi+qpU9kBsfAx4ka7qkEeyPIE6CK6/sDWRimFCReo+XDfzz5NEpOy387 Q==; X-CSE-ConnectionGUID: ZZi6vtWqS06OuXMer/3OcQ== X-CSE-MsgGUID: /f79CszOQJKU6YGKmyC0GA== X-IronPort-AV: E=McAfee;i="6800,10657,11717"; a="84135511" X-IronPort-AV: E=Sophos;i="6.21,320,1763452800"; d="scan'208";a="84135511" Received: from orviesa001.jf.intel.com ([10.64.159.141]) by fmvoesa105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Mar 2026 10:46:27 -0800 X-CSE-ConnectionGUID: vDWIpBknS/CUe0nF8kYEbQ== X-CSE-MsgGUID: sU+P8ZM3QV+OhxmiNSRsHA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,320,1763452800"; d="scan'208";a="255604104" Received: from rchatre-desk1.jf.intel.com ([10.165.154.99]) by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Mar 2026 10:46:26 -0800 From: Reinette Chatre To: tony.luck@intel.com, james.morse@arm.com, Dave.Martin@arm.com, babu.moger@amd.com, bp@alien8.de, tglx@linutronix.de, dave.hansen@linux.intel.com Cc: x86@kernel.org, hpa@zytor.com, ben.horgan@arm.com, fustini@kernel.org, fenghuay@nvidia.com, peternewman@google.com, linux-kernel@vger.kernel.org, patches@lists.linux.dev, reinette.chatre@intel.com Subject: [PATCH 10/11] fs/resctrl: Change last_cmd_status custom during input parsing Date: Mon, 2 Mar 2026 10:46:16 -0800 Message-ID: <021f736612186e9fd653d107b0642e8c1cf110d2.1772476561.git.reinette.chatre@intel.com> X-Mailer: git-send-email 2.50.1 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" A pattern of usage of last_cmd_status was introduced during its enabling in commit c377dcfbee80 ("x86/intel_rdt: Add diagnostics when writing the schemata fil= e") and since copied throughout resctrl to result in the following custom: ..._write() { /* Early parsing of input, exit on failure. */ /* Obtain rdtgroup_mutex */ rdt_last_cmd_clear(); /* Clear last_cmd_status buffer */ /* * Act on user command, failures result in detail * error message in last_cmd_status buffer via * rdt_last_cmd_puts()/rdt_last_cmd_printf(). */ /* Release rdtgroup_mutex */ } If resctrl exits with failure during early parsing of input there are two possible scenarios: - The last_cmd_status buffer is empty and a user's read of info/last_cmd_status returns "ok". - The last_cmd_status buffer contains details from an earlier ...write() failure and a user's read of info/last_cmd_status returns this outdated error description. Writing to a resctrl file is considered a "resctrl command" and the resctrl documentation states the following about the last_cmd_status file: "If the command failed, it will provide more information that can be conveyed in the error returns from file operations." Neither of the current scenarios is correct behavior. Move early input parsing to be done with rdtgroup_mutex held after the last_cmd_status buffer is cleared. Let info/last_cmd_status be accurate when an error is encountered during parsing of user command. Signed-off-by: Reinette Chatre --- fs/resctrl/ctrlmondata.c | 54 ++++++++++++++++---------- fs/resctrl/monitor.c | 60 ++++++++++++++++------------ fs/resctrl/rdtgroup.c | 84 +++++++++++++++++++++++----------------- 3 files changed, 118 insertions(+), 80 deletions(-) diff --git a/fs/resctrl/ctrlmondata.c b/fs/resctrl/ctrlmondata.c index a8e7cdcfec6e..7b90c36ff0a6 100644 --- a/fs/resctrl/ctrlmondata.c +++ b/fs/resctrl/ctrlmondata.c @@ -312,11 +312,6 @@ ssize_t rdtgroup_schemata_write(struct kernfs_open_fil= e *of, char *tok, *resname; int ret =3D 0; =20 - /* Valid input requires a trailing newline */ - if (nbytes =3D=3D 0 || buf[nbytes - 1] !=3D '\n') - return -EINVAL; - buf[nbytes - 1] =3D '\0'; - rdtgrp =3D rdtgroup_kn_lock_live(of->kn); if (!rdtgrp) { rdtgroup_kn_unlock(of->kn); @@ -324,6 +319,15 @@ ssize_t rdtgroup_schemata_write(struct kernfs_open_fil= e *of, } rdt_last_cmd_clear(); =20 + /* Valid input requires a trailing newline */ + if (nbytes =3D=3D 0 || buf[nbytes - 1] !=3D '\n') { + rdt_last_cmd_puts("Invalid input\n"); + ret =3D -EINVAL; + goto out_unlock; + } + + buf[nbytes - 1] =3D '\0'; + /* * No changes to pseudo-locked region allowed. It has to be removed * and re-created instead. @@ -466,11 +470,6 @@ ssize_t rdtgroup_mba_mbps_event_write(struct kernfs_op= en_file *of, struct rdtgroup *rdtgrp; int ret =3D 0; =20 - /* Valid input requires a trailing newline */ - if (nbytes =3D=3D 0 || buf[nbytes - 1] !=3D '\n') - return -EINVAL; - buf[nbytes - 1] =3D '\0'; - rdtgrp =3D rdtgroup_kn_lock_live(of->kn); if (!rdtgrp) { rdtgroup_kn_unlock(of->kn); @@ -478,6 +477,15 @@ ssize_t rdtgroup_mba_mbps_event_write(struct kernfs_op= en_file *of, } rdt_last_cmd_clear(); =20 + /* Valid input requires a trailing newline */ + if (nbytes =3D=3D 0 || buf[nbytes - 1] !=3D '\n') { + rdt_last_cmd_puts("Invalid input\n"); + ret =3D -EINVAL; + goto out_unlock; + } + + buf[nbytes - 1] =3D '\0'; + if (!strcmp(buf, "mbm_local_bytes")) { if (resctrl_is_mon_event_enabled(QOS_L3_MBM_LOCAL_EVENT_ID)) rdtgrp->mba_mbps_event =3D QOS_L3_MBM_LOCAL_EVENT_ID; @@ -495,6 +503,7 @@ ssize_t rdtgroup_mba_mbps_event_write(struct kernfs_ope= n_file *of, if (ret) rdt_last_cmd_printf("Unsupported event id '%s'\n", buf); =20 +out_unlock: rdtgroup_kn_unlock(of->kn); =20 return ret ?: nbytes; @@ -854,15 +863,17 @@ ssize_t resctrl_io_alloc_write(struct kernfs_open_fil= e *of, char *buf, bool enable; int ret; =20 - ret =3D kstrtobool(buf, &enable); - if (ret) - return ret; - cpus_read_lock(); mutex_lock(&rdtgroup_mutex); =20 rdt_last_cmd_clear(); =20 + ret =3D kstrtobool(buf, &enable); + if (ret) { + rdt_last_cmd_puts("Invalid input\n"); + goto out_unlock; + } + if (!r->cache.io_alloc_capable) { rdt_last_cmd_printf("io_alloc is not supported on %s\n", s->name); ret =3D -ENODEV; @@ -1004,16 +1015,19 @@ ssize_t resctrl_io_alloc_cbm_write(struct kernfs_op= en_file *of, char *buf, u32 io_alloc_closid; int ret =3D 0; =20 - /* Valid input requires a trailing newline */ - if (nbytes =3D=3D 0 || buf[nbytes - 1] !=3D '\n') - return -EINVAL; - - buf[nbytes - 1] =3D '\0'; - cpus_read_lock(); mutex_lock(&rdtgroup_mutex); rdt_last_cmd_clear(); =20 + /* Valid input requires a trailing newline */ + if (nbytes =3D=3D 0 || buf[nbytes - 1] !=3D '\n') { + rdt_last_cmd_puts("Invalid input\n"); + ret =3D -EINVAL; + goto out_unlock; + } + + buf[nbytes - 1] =3D '\0'; + if (!r->cache.io_alloc_capable) { rdt_last_cmd_printf("io_alloc is not supported on %s\n", s->name); ret =3D -ENODEV; diff --git a/fs/resctrl/monitor.c b/fs/resctrl/monitor.c index f1a08fdbdd61..6c499a0bd435 100644 --- a/fs/resctrl/monitor.c +++ b/fs/resctrl/monitor.c @@ -1112,13 +1112,15 @@ ssize_t resctrl_mbm_assign_on_mkdir_write(struct ke= rnfs_open_file *of, char *buf bool value; int ret; =20 - ret =3D kstrtobool(buf, &value); - if (ret) - return ret; - mutex_lock(&rdtgroup_mutex); rdt_last_cmd_clear(); =20 + ret =3D kstrtobool(buf, &value); + if (ret) { + rdt_last_cmd_puts("Invalid input\n"); + goto out_unlock; + } + if (!resctrl_arch_mbm_cntr_assign_enabled(r)) { rdt_last_cmd_puts("mbm_event counter assignment mode is not enabled\n"); ret =3D -EINVAL; @@ -1409,17 +1411,20 @@ ssize_t event_filter_write(struct kernfs_open_file = *of, char *buf, size_t nbytes u32 evt_cfg =3D 0; int ret =3D 0; =20 - /* Valid input requires a trailing newline */ - if (nbytes =3D=3D 0 || buf[nbytes - 1] !=3D '\n') - return -EINVAL; - - buf[nbytes - 1] =3D '\0'; - cpus_read_lock(); mutex_lock(&rdtgroup_mutex); =20 rdt_last_cmd_clear(); =20 + /* Valid input requires a trailing newline */ + if (nbytes =3D=3D 0 || buf[nbytes - 1] !=3D '\n') { + rdt_last_cmd_puts("Invalid input\n"); + ret =3D -EINVAL; + goto out_unlock; + } + + buf[nbytes - 1] =3D '\0'; + r =3D resctrl_arch_get_resource(mevt->rid); if (!resctrl_arch_mbm_cntr_assign_enabled(r)) { rdt_last_cmd_puts("mbm_event counter assignment mode is not enabled\n"); @@ -1478,17 +1483,20 @@ ssize_t resctrl_mbm_assign_mode_write(struct kernfs= _open_file *of, char *buf, int ret =3D 0; bool enable; =20 - /* Valid input requires a trailing newline */ - if (nbytes =3D=3D 0 || buf[nbytes - 1] !=3D '\n') - return -EINVAL; - - buf[nbytes - 1] =3D '\0'; - cpus_read_lock(); mutex_lock(&rdtgroup_mutex); =20 rdt_last_cmd_clear(); =20 + /* Valid input requires a trailing newline */ + if (nbytes =3D=3D 0 || buf[nbytes - 1] !=3D '\n') { + rdt_last_cmd_puts("Invalid input\n"); + ret =3D -EINVAL; + goto out_unlock; + } + + buf[nbytes - 1] =3D '\0'; + if (!strcmp(buf, "default")) { enable =3D 0; } else if (!strcmp(buf, "mbm_event")) { @@ -1759,12 +1767,6 @@ ssize_t mbm_L3_assignments_write(struct kernfs_open_= file *of, char *buf, char *token, *event; int ret =3D 0; =20 - /* Valid input requires a trailing newline */ - if (nbytes =3D=3D 0 || buf[nbytes - 1] !=3D '\n') - return -EINVAL; - - buf[nbytes - 1] =3D '\0'; - rdtgrp =3D rdtgroup_kn_lock_live(of->kn); if (!rdtgrp) { rdtgroup_kn_unlock(of->kn); @@ -1772,10 +1774,19 @@ ssize_t mbm_L3_assignments_write(struct kernfs_open= _file *of, char *buf, } rdt_last_cmd_clear(); =20 + /* Valid input requires a trailing newline */ + if (nbytes =3D=3D 0 || buf[nbytes - 1] !=3D '\n') { + rdt_last_cmd_puts("Invalid input\n"); + ret =3D -EINVAL; + goto out_unlock; + } + + buf[nbytes - 1] =3D '\0'; + if (!resctrl_arch_mbm_cntr_assign_enabled(r)) { rdt_last_cmd_puts("mbm_event mode is not enabled\n"); - rdtgroup_kn_unlock(of->kn); - return -EINVAL; + ret =3D -EINVAL; + goto out_unlock; } =20 while ((token =3D strsep(&buf, "\n")) !=3D NULL) { @@ -1791,6 +1802,7 @@ ssize_t mbm_L3_assignments_write(struct kernfs_open_f= ile *of, char *buf, break; } =20 +out_unlock: rdtgroup_kn_unlock(of->kn); =20 return ret ?: nbytes; diff --git a/fs/resctrl/rdtgroup.c b/fs/resctrl/rdtgroup.c index f33a50c545bc..3b3acc748d03 100644 --- a/fs/resctrl/rdtgroup.c +++ b/fs/resctrl/rdtgroup.c @@ -511,38 +511,38 @@ static int cpus_ctrl_write(struct rdtgroup *rdtgrp, c= pumask_var_t newmask, static ssize_t rdtgroup_cpus_write(struct kernfs_open_file *of, char *buf, size_t nbytes, loff_t off) { - cpumask_var_t tmpmask, newmask, tmpmask1; + cpumask_var_t tmpmask =3D CPUMASK_VAR_NULL, newmask =3D CPUMASK_VAR_NULL; + cpumask_var_t tmpmask1 =3D CPUMASK_VAR_NULL; struct rdtgroup *rdtgrp; int ret; =20 - if (!buf || nbytes =3D=3D 0) - return -EINVAL; - - if (!zalloc_cpumask_var(&tmpmask, GFP_KERNEL)) - return -ENOMEM; - if (!zalloc_cpumask_var(&newmask, GFP_KERNEL)) { - free_cpumask_var(tmpmask); - return -ENOMEM; - } - if (!zalloc_cpumask_var(&tmpmask1, GFP_KERNEL)) { - free_cpumask_var(tmpmask); - free_cpumask_var(newmask); - return -ENOMEM; - } - rdtgrp =3D rdtgroup_kn_lock_live(of->kn); if (!rdtgrp) { ret =3D -ENOENT; - goto unlock; + goto out_unlock; } =20 rdt_last_cmd_clear(); =20 + if (!buf || nbytes =3D=3D 0) { + rdt_last_cmd_puts("Invalid input\n"); + ret =3D -EINVAL; + goto out_unlock; + } + + if (!zalloc_cpumask_var(&tmpmask, GFP_KERNEL) || + !zalloc_cpumask_var(&newmask, GFP_KERNEL) || + !zalloc_cpumask_var(&tmpmask1, GFP_KERNEL)) { + rdt_last_cmd_puts("Kernel allocation failure\n"); + ret =3D -ENOMEM; + goto out_free; + } + if (rdtgrp->mode =3D=3D RDT_MODE_PSEUDO_LOCKED || rdtgrp->mode =3D=3D RDT_MODE_PSEUDO_LOCKSETUP) { ret =3D -EINVAL; rdt_last_cmd_puts("Pseudo-locking in progress\n"); - goto unlock; + goto out_free; } =20 if (is_cpu_list(of)) @@ -552,18 +552,18 @@ static ssize_t rdtgroup_cpus_write(struct kernfs_open= _file *of, =20 if (ret) { rdt_last_cmd_puts("Bad CPU list/mask\n"); - goto unlock; + goto out_free; } =20 if (cpumask_empty(newmask)) - goto unlock; + goto out_free; =20 /* check that user didn't specify any offline cpus */ cpumask_andnot(tmpmask, newmask, cpu_online_mask); if (!cpumask_empty(tmpmask)) { ret =3D -EINVAL; rdt_last_cmd_puts("Can only assign online CPUs\n"); - goto unlock; + goto out_free; } =20 if (rdtgrp->type =3D=3D RDTCTRL_GROUP) @@ -573,11 +573,12 @@ static ssize_t rdtgroup_cpus_write(struct kernfs_open= _file *of, else ret =3D -EINVAL; =20 -unlock: - rdtgroup_kn_unlock(of->kn); +out_free: free_cpumask_var(tmpmask); free_cpumask_var(newmask); free_cpumask_var(tmpmask1); +out_unlock: + rdtgroup_kn_unlock(of->kn); =20 return ret ?: nbytes; } @@ -1457,11 +1458,6 @@ static ssize_t rdtgroup_mode_write(struct kernfs_ope= n_file *of, enum rdtgrp_mode mode; int ret =3D 0; =20 - /* Valid input requires a trailing newline */ - if (nbytes =3D=3D 0 || buf[nbytes - 1] !=3D '\n') - return -EINVAL; - buf[nbytes - 1] =3D '\0'; - rdtgrp =3D rdtgroup_kn_lock_live(of->kn); if (!rdtgrp) { rdtgroup_kn_unlock(of->kn); @@ -1469,6 +1465,14 @@ static ssize_t rdtgroup_mode_write(struct kernfs_ope= n_file *of, } =20 rdt_last_cmd_clear(); + /* Valid input requires a trailing newline */ + if (nbytes =3D=3D 0 || buf[nbytes - 1] !=3D '\n') { + rdt_last_cmd_puts("Invalid input\n"); + ret =3D -EINVAL; + goto out; + } + + buf[nbytes - 1] =3D '\0'; =20 mode =3D rdtgrp->mode; =20 @@ -1794,19 +1798,23 @@ static ssize_t mbm_total_bytes_config_write(struct = kernfs_open_file *of, struct rdt_resource *r =3D rdt_kn_parent_priv(of->kn); int ret; =20 - /* Valid input requires a trailing newline */ - if (nbytes =3D=3D 0 || buf[nbytes - 1] !=3D '\n') - return -EINVAL; - cpus_read_lock(); mutex_lock(&rdtgroup_mutex); =20 rdt_last_cmd_clear(); =20 + /* Valid input requires a trailing newline */ + if (nbytes =3D=3D 0 || buf[nbytes - 1] !=3D '\n') { + rdt_last_cmd_puts("Invalid input\n"); + ret =3D -EINVAL; + goto out_unlock; + } + buf[nbytes - 1] =3D '\0'; =20 ret =3D mon_config_write(r, buf, QOS_L3_MBM_TOTAL_EVENT_ID); =20 +out_unlock: mutex_unlock(&rdtgroup_mutex); cpus_read_unlock(); =20 @@ -1820,19 +1828,23 @@ static ssize_t mbm_local_bytes_config_write(struct = kernfs_open_file *of, struct rdt_resource *r =3D rdt_kn_parent_priv(of->kn); int ret; =20 - /* Valid input requires a trailing newline */ - if (nbytes =3D=3D 0 || buf[nbytes - 1] !=3D '\n') - return -EINVAL; - cpus_read_lock(); mutex_lock(&rdtgroup_mutex); =20 rdt_last_cmd_clear(); =20 + /* Valid input requires a trailing newline */ + if (nbytes =3D=3D 0 || buf[nbytes - 1] !=3D '\n') { + rdt_last_cmd_puts("Invalid input\n"); + ret =3D -EINVAL; + goto out_unlock; + } + buf[nbytes - 1] =3D '\0'; =20 ret =3D mon_config_write(r, buf, QOS_L3_MBM_LOCAL_EVENT_ID); =20 +out_unlock: mutex_unlock(&rdtgroup_mutex); cpus_read_unlock(); =20 --=20 2.50.1 From nobody Tue Mar 3 03:20:24 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6AABC383C76 for ; Mon, 2 Mar 2026 18:46:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.11 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772477196; cv=none; b=sGS2B8Jet3WaUQHR7pmBBbzCMGTHKfMZh/lRfBdcGQGITOYwjW7N/qcvDDI0m+uKlQb6Ql8PzM9Fo8jxYR1cZwL5FZQ1DDRykkekW4OgWBGMBmLeqC0YpxO8L690VFxvoHultwtdZrIXTZbqal1ty3foDSP5WqNm1zojnfogPfY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772477196; c=relaxed/simple; bh=z+I4Oh28rTlzW4CAMClsLNIZcZbgb28hRpbqm0vRka4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=fS7KA003G8tCP/SCcY2nqQryavtDwg8uPH/IYdAiwinifqccfxz4jZAPGrHZ+WmJwlLSxH3Wf7Q3Yz1NmiTjKaZu2VGxUvC0xas3spNKqrEGkvGtBdb3tmMEOSPYCoo8xF2beA0mhyOCGWcYam2C1XyjvyZ1BeWVZclhUHZSfBU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=S4kbU/lb; arc=none smtp.client-ip=192.198.163.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="S4kbU/lb" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1772477195; x=1804013195; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=z+I4Oh28rTlzW4CAMClsLNIZcZbgb28hRpbqm0vRka4=; b=S4kbU/lb803+Q475Mu/kA2FvDsZyghCJoderwHuqWUmTFMiX3w8Rz5BB 0K/c2DVvdJqMoujqF69d1E92ajtvhKIIR8mauscT84wh2jxYIeGrnVxmf cYd2cW6z4VFnu9sjE69FPN4b2ZnsmRHfNbpXXNl7cGsJxRpF7kvzVQvQl mlP7Fl+SHA/7ZulIO2K1D7T5DEC8igZKxkvQ1Je36ZcbxIeNErl3B/qBc rzfPZVMBpWF8sUN/SSgTCStqhDG+b2tRdbcFyewBH+oKzrsXUxccpdxV9 Fit4eVIk42LIBxiRe3l1nVj2DX9edAPdQikndxV1H7xQZRrdXUCrmp2An w==; X-CSE-ConnectionGUID: JQVZvRuhQ2OCDM36PCyNFA== X-CSE-MsgGUID: xcPLe/++SvG07wr0XvKfPA== X-IronPort-AV: E=McAfee;i="6800,10657,11717"; a="84135523" X-IronPort-AV: E=Sophos;i="6.21,320,1763452800"; d="scan'208";a="84135523" Received: from orviesa001.jf.intel.com ([10.64.159.141]) by fmvoesa105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Mar 2026 10:46:27 -0800 X-CSE-ConnectionGUID: uGAxpUKASqiLqiHIjSHJtA== X-CSE-MsgGUID: PIXfq16aSIuuUlWyNKAmcw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,320,1763452800"; d="scan'208";a="255604107" Received: from rchatre-desk1.jf.intel.com ([10.165.154.99]) by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Mar 2026 10:46:26 -0800 From: Reinette Chatre To: tony.luck@intel.com, james.morse@arm.com, Dave.Martin@arm.com, babu.moger@amd.com, bp@alien8.de, tglx@linutronix.de, dave.hansen@linux.intel.com Cc: x86@kernel.org, hpa@zytor.com, ben.horgan@arm.com, fustini@kernel.org, fenghuay@nvidia.com, peternewman@google.com, linux-kernel@vger.kernel.org, patches@lists.linux.dev, reinette.chatre@intel.com Subject: [PATCH 11/11] fs/resctrl: Communicate resource group deleted error via last_cmd_status Date: Mon, 2 Mar 2026 10:46:17 -0800 Message-ID: X-Mailer: git-send-email 2.50.1 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" User space expects last_cmd_status to contain additional information if any resctrl command fails. A resctrl command may be blocked waiting on the rdtgroup_mutex waiting for another command to finish and find that once the mutex is available that the resource group has since been deleted. In this scenario the command will fail while last_cmd_status contains either "ok" if the last_cmd_status buffer is empty or an outdated error from a previous command failure if last_cmd_status buffer has content. Include clearing of last_cmd_status buffer as part of rdtgroup_kn_lock_live() that is used to obtain access and needed locking to a resource group before attempting a command on the group. With the last_cmd_status buffer ready, provide an appropriate message to user space if the resource group has been deleted. No last_cmd_status treatment is needed for the remaining failure of rdtgroup_kn_lock_live() encountering a non-existent resource group since that could only occur during an attempt to obtain a resource group lock on a file in info/ which is an invalid usage. Signed-off-by: Reinette Chatre --- fs/resctrl/ctrlmondata.c | 3 --- fs/resctrl/monitor.c | 2 -- fs/resctrl/rdtgroup.c | 14 +++++--------- 3 files changed, 5 insertions(+), 14 deletions(-) diff --git a/fs/resctrl/ctrlmondata.c b/fs/resctrl/ctrlmondata.c index 7b90c36ff0a6..9915f714e26a 100644 --- a/fs/resctrl/ctrlmondata.c +++ b/fs/resctrl/ctrlmondata.c @@ -317,7 +317,6 @@ ssize_t rdtgroup_schemata_write(struct kernfs_open_file= *of, rdtgroup_kn_unlock(of->kn); return -ENOENT; } - rdt_last_cmd_clear(); =20 /* Valid input requires a trailing newline */ if (nbytes =3D=3D 0 || buf[nbytes - 1] !=3D '\n') { @@ -434,7 +433,6 @@ int rdtgroup_schemata_show(struct kernfs_open_file *of, } } else if (rdtgrp->mode =3D=3D RDT_MODE_PSEUDO_LOCKED) { if (!rdtgrp->plr->d) { - rdt_last_cmd_clear(); rdt_last_cmd_puts("Cache domain offline\n"); ret =3D -ENODEV; } else { @@ -475,7 +473,6 @@ ssize_t rdtgroup_mba_mbps_event_write(struct kernfs_ope= n_file *of, rdtgroup_kn_unlock(of->kn); return -ENOENT; } - rdt_last_cmd_clear(); =20 /* Valid input requires a trailing newline */ if (nbytes =3D=3D 0 || buf[nbytes - 1] !=3D '\n') { diff --git a/fs/resctrl/monitor.c b/fs/resctrl/monitor.c index 6c499a0bd435..73893a7e14e0 100644 --- a/fs/resctrl/monitor.c +++ b/fs/resctrl/monitor.c @@ -1632,7 +1632,6 @@ int mbm_L3_assignments_show(struct kernfs_open_file *= of, struct seq_file *s, voi goto out_unlock; } =20 - rdt_last_cmd_clear(); if (!resctrl_arch_mbm_cntr_assign_enabled(r)) { rdt_last_cmd_puts("mbm_event counter assignment mode is not enabled\n"); ret =3D -EINVAL; @@ -1772,7 +1771,6 @@ ssize_t mbm_L3_assignments_write(struct kernfs_open_f= ile *of, char *buf, rdtgroup_kn_unlock(of->kn); return -ENOENT; } - rdt_last_cmd_clear(); =20 /* Valid input requires a trailing newline */ if (nbytes =3D=3D 0 || buf[nbytes - 1] !=3D '\n') { diff --git a/fs/resctrl/rdtgroup.c b/fs/resctrl/rdtgroup.c index 3b3acc748d03..09d688bee0a3 100644 --- a/fs/resctrl/rdtgroup.c +++ b/fs/resctrl/rdtgroup.c @@ -359,7 +359,6 @@ static int rdtgroup_cpus_show(struct kernfs_open_file *= of, if (rdtgrp) { if (rdtgrp->mode =3D=3D RDT_MODE_PSEUDO_LOCKED) { if (!rdtgrp->plr->d) { - rdt_last_cmd_clear(); rdt_last_cmd_puts("Cache domain offline\n"); ret =3D -ENODEV; } else { @@ -522,8 +521,6 @@ static ssize_t rdtgroup_cpus_write(struct kernfs_open_f= ile *of, goto out_unlock; } =20 - rdt_last_cmd_clear(); - if (!buf || nbytes =3D=3D 0) { rdt_last_cmd_puts("Invalid input\n"); ret =3D -EINVAL; @@ -783,7 +780,6 @@ static ssize_t rdtgroup_tasks_write(struct kernfs_open_= file *of, rdtgroup_kn_unlock(of->kn); return -ENOENT; } - rdt_last_cmd_clear(); =20 if (rdtgrp->mode =3D=3D RDT_MODE_PSEUDO_LOCKED || rdtgrp->mode =3D=3D RDT_MODE_PSEUDO_LOCKSETUP) { @@ -1464,7 +1460,6 @@ static ssize_t rdtgroup_mode_write(struct kernfs_open= _file *of, return -ENOENT; } =20 - rdt_last_cmd_clear(); /* Valid input requires a trailing newline */ if (nbytes =3D=3D 0 || buf[nbytes - 1] !=3D '\n') { rdt_last_cmd_puts("Invalid input\n"); @@ -1601,7 +1596,6 @@ static int rdtgroup_size_show(struct kernfs_open_file= *of, =20 if (rdtgrp->mode =3D=3D RDT_MODE_PSEUDO_LOCKED) { if (!rdtgrp->plr->d) { - rdt_last_cmd_clear(); rdt_last_cmd_puts("Cache domain offline\n"); ret =3D -ENODEV; } else { @@ -2639,10 +2633,14 @@ struct rdtgroup *rdtgroup_kn_lock_live(struct kernf= s_node *kn) =20 cpus_read_lock(); mutex_lock(&rdtgroup_mutex); + rdt_last_cmd_clear(); =20 /* Was this group deleted while we waited? */ - if (rdtgrp->flags & RDT_DELETED) + if (rdtgrp->flags & RDT_DELETED) { + rdt_last_cmd_printf("Resource group %s deleted. No commands possible.\n", + rdt_kn_name(rdtgrp->kn)); return NULL; + } =20 return rdtgrp; } @@ -3765,8 +3763,6 @@ static int mkdir_rdt_prepare(struct kernfs_node *pare= nt_kn, goto out_unlock; } =20 - rdt_last_cmd_clear(); - /* * Check that the parent directory for a monitor group is a "mon_groups" * directory. --=20 2.50.1