mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Tony Luck <tony.luck@intel.com>
To: Fenghua Yu <fenghuay@nvidia.com>,
	Reinette Chatre <reinette.chatre@intel.com>,
	Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>,
	Peter Newman <peternewman@google.com>,
	James Morse <james.morse@arm.com>,
	Babu Moger <babu.moger@amd.com>,
	Drew Fustini <dfustini@baylibre.com>,
	Dave Martin <Dave.Martin@arm.com>, Chen Yu <yu.c.chen@intel.com>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
	patches@lists.linux.dev, Tony Luck <tony.luck@intel.com>,
	Sashiko <sashiko-bot@kernel.org>
Subject: [PATCH] fs/resctrl: Ensure default group reports tasks on monitor-only systems
Date: Thu,  8 Oct 2026 16:43:11 -0700	[thread overview]
Message-ID: <20261008234311.17702-1-tony.luck@intel.com> (raw)

resctrl can be mounted with monitoring support only, with no allocation
support. In that configuration every task that has not been explicitly
moved to a MON group remains in the default group, and CTRL_MON group
membership is decided purely by comparing a task's CLOSID against the
group's closid.

is_closid_match() also requires resctrl_arch_alloc_capable() to be true.
On a monitor-only system that is never the case, so the check breaks the
default group: it unconditionally returns false for all tasks, and
is_rmid_match() also returns false because the default group has type
RDTCTRL_GROUP rather than RDTMON_GROUP. Reading the root tasks file then
shows no tasks at all, even though every unmoved task belongs there.

Drop the resctrl_arch_alloc_capable() test from is_closid_match(). A
CTRL_MON group other than the default group can only be created when
allocation is supported, so for those groups the test is redundant. But
the default group always has closid == RESCTRL_RESERVED_CLOSID and is
present even without allocation support, so the test is wrong for it:
it is exactly the case this patch fixes.

Fixes: e6b2fac36fcc ("x86/resctrl: Use is_closid_match() in more places")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/20260831174421.13921-1-tony.luck%40intel.com?part=9
Signed-off-by: Tony Luck <tony.luck@intel.com>
Assisted-by: LLM
---

I fed your AI review to Claude and asked it to rewrite the changelog to
address all the issues your AI raised. Here's the summary Claude
provided:

   1. Opens with context (monitor-only mounts, default group, CLOSID-based membership) before
      describing the bug.
   2. States the problem/symptom concisely (one paragraph, not three restatements).
   3. Uses an imperative fix sentence ("Drop the resctrl_arch_alloc_capable() test...").
   4. Correctly scopes the safety claim: redundant for other CTRL_MON groups, but wrong for the
      default group - the actual bug.
   5. Drops the reviewer-facing "pre-existing issue" aside and "actively breaks" wording.
   6. Uses CTRL_MON/MON terminology from: Documentation/filesystems/resctrl.rst.
   7. Keeps tag order and includes: Assisted-by: LLM per coding-assistants.rst.

Claude put the "Assisted-by:" tag after my sign-off. The tip maintainer
documentation hasn't been updated to provide explicit guidance on where
this should appear. Looking at upstream commits people have picked
different spots, but immediately after the author sign-off seems common.

---
 fs/resctrl/rdtgroup.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/resctrl/rdtgroup.c b/fs/resctrl/rdtgroup.c
index 68be9b903ac6..57ab090072c2 100644
--- a/fs/resctrl/rdtgroup.c
+++ b/fs/resctrl/rdtgroup.c
@@ -685,7 +685,7 @@ static int __rdtgroup_move_task(struct task_struct *tsk,
 
 static bool is_closid_match(struct task_struct *t, struct rdtgroup *r)
 {
-	return (resctrl_arch_alloc_capable() && (r->type == RDTCTRL_GROUP) &&
+	return (r->type == RDTCTRL_GROUP &&
 		resctrl_arch_match_closid(t, r->closid));
 }
 
-- 
2.56.0


             reply	other threads:[~2026-10-08 23:43 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-08 23:43 Tony Luck [this message]
2026-10-09  5:02 ` Reinette Chatre

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261008234311.17702-1-tony.luck@intel.com \
    --to=tony.luck@intel.com \
    --cc=Dave.Martin@arm.com \
    --cc=babu.moger@amd.com \
    --cc=dfustini@baylibre.com \
    --cc=fenghuay@nvidia.com \
    --cc=james.morse@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maciej.wieczor-retman@intel.com \
    --cc=patches@lists.linux.dev \
    --cc=peternewman@google.com \
    --cc=reinette.chatre@intel.com \
    --cc=sashiko-bot@kernel.org \
    --cc=x86@kernel.org \
    --cc=yu.c.chen@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®