Linux Documentation
 help / color / mirror / Atom feed
From: Reinette Chatre <reinette.chatre@intel.com>
To: Babu Moger <babu.moger@amd.com>, <corbet@lwn.net>,
	<tony.luck@intel.com>, <Dave.Martin@arm.com>,
	<james.morse@arm.com>, <tglx@kernel.org>, <bp@alien8.de>,
	<dave.hansen@linux.intel.com>
Cc: <skhan@linuxfoundation.org>, <x86@kernel.org>, <mingo@redhat.com>,
	<hpa@zytor.com>, <akpm@linux-foundation.org>,
	<rdunlap@infradead.org>, <pawan.kumar.gupta@linux.intel.com>,
	<feng.tang@linux.alibaba.com>, <dapeng1.mi@linux.intel.com>,
	<kees@kernel.org>, <elver@google.com>, <lirongqing@baidu.com>,
	<paulmck@kernel.org>, <bhelgaas@google.com>, <seanjc@google.com>,
	<alexandre.chartre@oracle.com>, <yazen.ghannam@amd.com>,
	<peterz@infradead.org>, <chang.seok.bae@intel.com>,
	<kim.phillips@amd.com>, <xin@zytor.com>, <naveen@kernel.org>,
	<thomas.lendacky@amd.com>, <linux-doc@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <eranian@google.com>,
	<peternewman@google.com>
Subject: Re: [PATCH v3 08/12] fs/resctrl: Make info/kernel_mode writable and identify the bound group
Date: Tue, 16 Jun 2026 16:42:12 -0700	[thread overview]
Message-ID: <57f6324b-6340-4633-b3a0-b40683a5ec12@intel.com> (raw)
In-Reply-To: <768d4b603542f3202ece4294c808dbbf1a8e3008.1777591497.git.babu.moger@amd.com>

Hi Babu,

On 4/30/26 4:24 PM, Babu Moger wrote:
> info/kernel_mode lists the kernel-mode CLOSID/RMID policies the kernel

(also here please drop the x86 specific details and consider the resctrl
fs changes to be valid from MPAM perspective also)

> supports and the one currently active, but user space has no way to
> switch policies or rebind to a different rdtgroup, and the file does
> not name the group that owns the kernel CLOSID/RMID.

This adds a new feature. No need to describe this change as a bugfix.

> 
> Make info/kernel_mode writable.  The format used by both read and
> write is one line per mode:

This sounds like multiple modes can be written to the file as long as they
are separated by newline? I do not think it should be needed to support
write of more than one mode at a time.

> 
>   inherit_ctrl_and_mon:group=none
>   [global_assign_ctrl_inherit_mon_per_cpu:group=g1//]
>   global_assign_ctrl_assign_mon_per_cpu:group=none
> 
> The active mode is wrapped in "[...]" and ":group=<ctrl>/<mon>/" names
> the bound rdtgroup ("//" for the default control group).  Inactive
> modes report ":group=none".  Documented in
> Documentation/filesystems/resctrl.rst.

Above describes the output of the file. This changelog can just focus on
what needs to be supported when user space writes to the file.

> 
> The write path strims input, strips the optional "[...]", validates

strims?

Wait, why support the brackets as input? This seems unnecessary.

> the mode against resctrl_kcfg.kmode, and resolves the optional
> ":group=" suffix via the new helper rdtgroup_by_kmode_path().  An
> omitted suffix or an INHERIT-mode write binds to the default group.
> On success, rdtgroup_config_kmode_clear() tears down the previous
> binding and rdtgroup_config_kmode() programs the new one before
> resctrl_kcfg.k_rdtgrp and resctrl_kcfg.kmode_cur are updated under
> rdtgroup_mutex.  Allocation failures in the helpers are propagated so
> the write fails atomically.

This also reads like it just describes the code.

> 
> Add struct rdtgroup fields kmode and kmode_cpu_mask to track the
> per-group binding.

Please do not just describe the code but *why* this change is needed and
what it means and how it is used.

> 
> Signed-off-by: Babu Moger <babu.moger@amd.com>
> ---
> v3: New patch to handle the changed interface file info/kernel_mode.
> ---
>  Documentation/filesystems/resctrl.rst |  51 ++++
>  fs/resctrl/internal.h                 |   6 +
>  fs/resctrl/rdtgroup.c                 | 375 +++++++++++++++++++++++++-
>  3 files changed, 431 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/filesystems/resctrl.rst b/Documentation/filesystems/resctrl.rst
> index b003bed339fd..89fbf8b4fb2a 100644
> --- a/Documentation/filesystems/resctrl.rst
> +++ b/Documentation/filesystems/resctrl.rst
> @@ -522,6 +522,57 @@ conveyed in the error returns from file operations. E.g.
>  	# cat info/last_cmd_status
>  	mask f7 has non-consecutive 1-bits
>  
> +"kernel_mode":

(dropping the documentation here since I believe earlier comments apply)

...

> diff --git a/fs/resctrl/internal.h b/fs/resctrl/internal.h
> index 1a9b29119f88..9435ce663f54 100644
> --- a/fs/resctrl/internal.h
> +++ b/fs/resctrl/internal.h
> @@ -216,6 +216,10 @@ struct mongroup {
>   * @mon:			mongroup related data
>   * @mode:			mode of resource group
>   * @mba_mbps_event:		input monitoring event id when mba_sc is enabled
> + * @kmode:			true if this group is currently bound as the kernel-mode
> + *				CLOSID/RMID owner (resctrl_kcfg.k_rdtgrp)

(drop CLOSID/RMID)

> + * @kmode_cpu_mask:		CPUs scoped for this group's kernel-mode binding;
> + *				when empty, all online CPUs are used

Why does "empty" signify "all online CPUs"? This complicates implementation and
creates different interface from existing CPUs interface of resource groups.

>   * @plr:			pseudo-locked region
>   */
>  struct rdtgroup {
> @@ -229,6 +233,8 @@ struct rdtgroup {
>  	struct mongroup			mon;
>  	enum rdtgrp_mode		mode;
>  	enum resctrl_event_id		mba_mbps_event;
> +	bool				kmode;
> +	struct cpumask			kmode_cpu_mask;
>  	struct pseudo_lock_region	*plr;
>  };
>  
> diff --git a/fs/resctrl/rdtgroup.c b/fs/resctrl/rdtgroup.c
> index 9cdcfa64c4a2..5383b4eb23ed 100644
> --- a/fs/resctrl/rdtgroup.c
> +++ b/fs/resctrl/rdtgroup.c
> @@ -1055,6 +1055,378 @@ static int resctrl_kernel_mode_show(struct kernfs_open_file *of,
>  	return 0;
>  }
>  
> +/**
> + * rdtgroup_config_kmode() - Push @rdtgrp's kernel CLOSID/RMID to hardware
> + * @rdtgrp:	Resctrl group whose CLOSID/RMID should be programmed.
> + *
> + * Derives CLOSID/RMID from @rdtgrp->type:
> + *   - RDTMON_GROUP: parent control group's CLOSID with the monitor group's RMID.

This seem unnecessary since when a monitor group is created it's closid is inherited
from it's control group?

> + *   - RDTCTRL_GROUP: the control group's own CLOSID and default RMID.
> + *
> + * Calls resctrl_arch_configure_kmode() with the kernel-mode binding enabled
> + * on the online subset of @rdtgrp->kmode_cpu_mask (or all online CPUs when
> + * that mask is empty), and disabled on the complementary online CPUs so
> + * stale enable bits from a previously bound group are cleared in the same
> + * reprogram step.  The caller (resctrl_kernel_mode_write()) is responsible
> + * for validating that the (kmode, group type) pair is permitted before
> + * invoking this helper.
> + *
> + * Context: Caller must hold rdtgroup_mutex.

Please use lockdep_assert_held(&rdtgroup_mutex) instead. See "Documenting locking requirements"
in Documentation/process/maintainer-tip.rst

> + *
> + * Return: 0 on success, -EINVAL for a pseudo-locked group, -ENOMEM if
> + * cpumask allocation fails.
> + */
> +static int rdtgroup_config_kmode(struct rdtgroup *rdtgrp)
> +{
> +	cpumask_var_t enable_mask, disable_mask;
> +	u32 closid, rmid;
> +	bool need_disable;

(needs reverse fir)

> +
> +	if (rdtgrp->mode == RDT_MODE_PSEUDO_LOCKED) {
> +		rdt_last_cmd_puts("Resource group is pseudo-locked\n");
> +		return -EINVAL;
> +	}
> +
> +	if (!zalloc_cpumask_var(&enable_mask, GFP_KERNEL))
> +		return -ENOMEM;
> +
> +	need_disable = !cpumask_empty(&rdtgrp->kmode_cpu_mask);

As I understand rdtgroup_config_kmode() is called when the kernel mode is switched.
Also, earlier patches made it explicit that "Default scope is all online CPUs".

It is not clear to me how kmode_cpu_mask is initialized here ... it almost seems as though
if a resource was associated with a mode at some point and received some CPU changes then
when the mode switches between some other resource groups and then back to the original
then the old cpu_mask will be used on the mode switch. Should the resource group's cpu_mask
not be re-initialized to all online CPUs? If done then all of this cpu_mask wrangling seems
unnecessary to me, just use all online CPUs?


> +	if (need_disable && !zalloc_cpumask_var(&disable_mask, GFP_KERNEL)) {
> +		free_cpumask_var(enable_mask);
> +		return -ENOMEM;
> +	}
> +
> +	if (rdtgrp->type == RDTMON_GROUP) {
> +		closid = rdtgrp->mon.parent->closid;
> +		rmid = rdtgrp->mon.rmid;
> +	} else {
> +		closid = rdtgrp->closid;
> +		rmid = rdtgrp->mon.rmid;
> +	}

Considering MON group inherits the CLOSID if its parent, can above be simplified
to just be?
	closid = rdtgrp->closid;
	rmid = rdtgrp->mon.rmid;


> +
> +	/*
> +	 * Empty kmode_cpu_mask: enable on every online CPU.  Otherwise enable
> +	 * only CPUs in the group mask and explicitly clear on other online CPUs
> +	 * so a previously bound group's enable bits don't linger.
> +	 */
> +	if (!need_disable) {
> +		cpumask_copy(enable_mask, cpu_online_mask);
> +	} else {
> +		cpumask_copy(enable_mask, &rdtgrp->kmode_cpu_mask);
> +		cpumask_andnot(disable_mask, cpu_online_mask, &rdtgrp->kmode_cpu_mask);
> +	}
> +
> +	if (!cpumask_empty(enable_mask))
> +		resctrl_arch_configure_kmode(enable_mask, closid, rmid, true);
> +
> +	if (need_disable && !cpumask_empty(disable_mask))
> +		resctrl_arch_configure_kmode(disable_mask, closid, rmid, false);
> +
> +	rdtgrp->kmode = true;
> +
> +	free_cpumask_var(enable_mask);
> +	if (need_disable)
> +		free_cpumask_var(disable_mask);
> +
> +	return 0;
> +}
> +
> +/**
> + * rdtgroup_config_kmode_clear() - Tear down the kernel-mode binding on @rdtgrp
> + * @rdtgrp:	Resctrl group whose kernel-mode binding is being released.
> + *		May be %NULL when no group is currently bound, in which case
> + *		this is a no-op.
> + * @kmode:	Kernel-mode policy currently active on @rdtgrp, as a
> + *		BIT(&enum resctrl_kernel_modes) value.  When this is
> + *		BIT(INHERIT_CTRL_AND_MON) the hardware tear-down is skipped
> + *		because no MSR was previously programmed.
> + *
> + * Disables the kernel-mode binding on the CPUs @rdtgrp covers (its
> + * @kmode_cpu_mask, or all online CPUs when that mask is empty) and resets
> + * the per-group bookkeeping (@kmode and @kmode_cpu_mask).  This is the
> + * disable counterpart of rdtgroup_config_kmode() and exists so that a write
> + * that transitions the active mode to BIT(INHERIT_CTRL_AND_MON) -- which
> + * skips rdtgroup_config_kmode() entirely -- still tears down the previously
> + * bound group instead of leaving stale enable bits behind.
> + *
> + * On allocation failure the function returns -ENOMEM and leaves both the
> + * hardware state and @rdtgrp's bookkeeping unchanged so the caller can fail
> + * the operation atomically and last_cmd_status reflects reality.
> + *
> + * Context: Caller must hold rdtgroup_mutex.
> + *
> + * Return: 0 on success (including the @rdtgrp == %NULL and INHERIT cases),
> + * -ENOMEM if cpumask allocation fails.
> + */
> +static int rdtgroup_config_kmode_clear(struct rdtgroup *rdtgrp, int kmode)
> +{
> +	cpumask_var_t disable_mask;
> +	u32 closid, rmid;
> +
> +	if (!rdtgrp)
> +		return 0;
> +
> +	if (kmode == BIT(INHERIT_CTRL_AND_MON))
> +		goto out_clear;
> +
> +	if (!zalloc_cpumask_var(&disable_mask, GFP_KERNEL))
> +		return -ENOMEM;
> +
> +	if (rdtgrp->type == RDTMON_GROUP) {
> +		closid = rdtgrp->mon.parent->closid;
> +		rmid = rdtgrp->mon.rmid;
> +	} else {
> +		closid = rdtgrp->closid;
> +		rmid = rdtgrp->mon.rmid;
> +	}

Same comment as above ... but actually, why is closid/rmid needed at all? This
function is intended to *reset* the kernel mode so needing a valid/active closid and
rmid does not look right.

> +
> +	if (cpumask_empty(&rdtgrp->kmode_cpu_mask))
> +		cpumask_copy(disable_mask, cpu_online_mask);
> +	else
> +		cpumask_copy(disable_mask, &rdtgrp->kmode_cpu_mask);

Having kmode_cpu_mask accurately reflect the online CPUs will simplify this to
not need any of this wrangling and kmode_cpu_mask can just be used directly.

> +
> +	resctrl_arch_configure_kmode(disable_mask, closid, rmid, false);
> +	free_cpumask_var(disable_mask);
> +
> +out_clear:
> +	cpumask_clear(&rdtgrp->kmode_cpu_mask);
> +	rdtgrp->kmode = false;
> +	return 0;
> +}
> +
> +/**
> + * rdtgroup_by_kmode_path() - Resolve a "<ctrl>/<mon>/" path to an rdtgroup
> + * @ctrl_name:	Control-group name, or "" for the default control group.
> + * @mon_name:	Monitor-group name, or "" to select the control group itself.
> + *
> + * Matches the path syntax emitted by resctrl_kernel_mode_show():
> + *   "//"            - the default control group
> + *   "<ctrl>//"      - control group @ctrl_name
> + *   "/<mon>/"       - monitor group @mon_name under the default control group
> + *   "<ctrl>/<mon>/" - monitor group @mon_name under control group @ctrl_name
> + *
> + * Context: Caller must hold rdtgroup_mutex.

(lockdep)

> + *
> + * Return: Pointer to the matching rdtgroup, &rdtgroup_default when both
> + * names are empty (the show form "//"), or NULL if no such group exists.
> + */
> +static struct rdtgroup *rdtgroup_by_kmode_path(const char *ctrl_name,
> +					       const char *mon_name)
> +{
> +	struct rdtgroup *rdtg, *parent = NULL, *crg;
> +
> +	/* Show emits "//" for the default control group; round-trip it here. */
> +	if (!*ctrl_name && !*mon_name)
> +		return &rdtgroup_default;
> +
> +	/* Control-group-only form: "<ctrl>//". */
> +	if (!*mon_name) {
> +		list_for_each_entry(rdtg, &rdt_all_groups, rdtgroup_list) {
> +			if (rdtg->type != RDTCTRL_GROUP)
> +				continue;
> +			if (!strcmp(rdt_kn_name(rdtg->kn), ctrl_name))
> +				return rdtg;
> +		}
> +		return NULL;
> +	}
> +
> +	/* Monitor-group form: locate the parent control group first. */
> +	if (!*ctrl_name) {
> +		parent = &rdtgroup_default;
> +	} else {
> +		list_for_each_entry(rdtg, &rdt_all_groups, rdtgroup_list) {
> +			if (rdtg->type != RDTCTRL_GROUP)
> +				continue;
> +			if (!strcmp(rdt_kn_name(rdtg->kn), ctrl_name)) {
> +				parent = rdtg;
> +				break;
> +			}
> +		}
> +		if (!parent)
> +			return NULL;
> +	}
> +
> +	list_for_each_entry(crg, &parent->mon.crdtgrp_list, mon.crdtgrp_list)
> +		if (!strcmp(rdt_kn_name(crg->kn), mon_name))
> +			return crg;
> +	return NULL;
> +}
> +
> +/**
> + * resctrl_kernel_mode_write() - Select kernel mode and bind group via info/kernel_mode
> + * @of:		kernfs file handle.
> + * @buf:	One line in the same format emitted by resctrl_kernel_mode_show(),
> + *		i.e. "<mode>[:group=<ctrl>/<mon>/]" with an optional surrounding
> + *		"[...]"; must end with a newline.  The ":group=<spec>" suffix is
> + *		optional -- when omitted the default control group
> + *		(&rdtgroup_default) is used.
> + * @nbytes:	Length of @buf.
> + * @off:	File offset (unused).
> + *
> + * Parses @buf, validates that <mode> is listed in resctrl_mode_str[] and is
> + * supported by the platform (resctrl_kcfg.kmode), resolves <ctrl>/<mon>/ to
> + * an existing rdtgroup (or picks &rdtgroup_default if no group was specified
> + * or if the new mode is INHERIT), clears any previous binding via
> + * rdtgroup_config_kmode_clear(), programs hardware via
> + * rdtgroup_config_kmode() when @kmode is not BIT(INHERIT_CTRL_AND_MON), and
> + * on success updates resctrl_kcfg.k_rdtgrp and resctrl_kcfg.kmode_cur.  The
> + * display-only "group=none" form produced by show for inactive modes is
> + * rejected.  Errors are reported in last_cmd_status.
> + *
> + * Return: @nbytes on success, negative errno with last_cmd_status set on error.
> + */
> +static ssize_t resctrl_kernel_mode_write(struct kernfs_open_file *of,
> +					 char *buf, size_t nbytes, loff_t off)
> +{
> +	char *mode_str, *group_str, *slash;
> +	const char *ctrl_name, *mon_name;
> +	struct rdtgroup *rdtgrp;
> +	int ret = 0;
> +	size_t len;
> +	u32 kmode;
> +	int i;
> +
> +	if (nbytes == 0 || buf[nbytes - 1] != '\n')
> +		return -EINVAL;
> +	buf[nbytes - 1] = '\0';
> +
> +	/* Tolerate surrounding whitespace before the bracket/mode parsing. */
> +	buf = strim(buf);
> +	len = strlen(buf);
> +
> +	/* Strip the optional "[...]" that show uses to mark the active line. */
> +	if (len >= 2 && buf[0] == '[' && buf[len - 1] == ']') {
> +		buf[len - 1] = '\0';
> +		buf++;
> +		len -= 2;
> +	}

I do not think the brackets should be valid input.

> +
> +	/*
> +	 * Split "<mode>:group=<spec>"; the ":group=<spec>" suffix is optional
> +	 * and when omitted the default control group (&rdtgroup_default) is used.
> +	 */
> +	group_str = strstr(buf, ":group=");
> +	if (group_str) {
> +		*group_str = '\0';
> +		group_str += strlen(":group=");
> +	}
> +	mode_str = buf;
> +
> +	mutex_lock(&rdtgroup_mutex);
> +	rdt_last_cmd_clear();
> +
> +	for (i = 0; i < RESCTRL_NUM_KERNEL_MODES; i++)
> +		if (!strcmp(mode_str, resctrl_mode_str[i]))
> +			break;
> +	if (i == RESCTRL_NUM_KERNEL_MODES) {
> +		rdt_last_cmd_puts("Unknown kernel mode\n");
> +		ret = -EINVAL;
> +		goto out_unlock;
> +	}
> +
> +	if (!(resctrl_kcfg.kmode & BIT(i))) {
> +		rdt_last_cmd_puts("Kernel mode not available\n");
> +		ret = -EINVAL;
> +		goto out_unlock;
> +	}
> +
> +	kmode = BIT(i);

Can kmode be of enum type to be assigned the actual enum value to avoid all these BIT(enum value) usages?

> +
> +	if (!group_str) {
> +		/* No ":group=" suffix: fall back to the default control group. */
> +		rdtgrp = &rdtgroup_default;
> +	} else if (!strcmp(group_str, "none")) {
> +		/* Display-only placeholder emitted by show; not selectable. */
> +		rdt_last_cmd_puts("Cannot bind to 'none' group\n");
> +		ret = -EINVAL;
> +		goto out_unlock;
> +	} else {
> +		/* Require exactly "<ctrl>/<mon>/" - two '/' with the second terminating. */

User should not be expected to provide monitor group when the monitoring is inherited.

> +		slash = strchr(group_str, '/');
> +		if (!slash) {
> +			rdt_last_cmd_puts("Group must be <ctrl>/<mon>/\n");
> +			ret = -EINVAL;
> +			goto out_unlock;
> +		}
> +		*slash = '\0';
> +		ctrl_name = group_str;
> +		mon_name = slash + 1;
> +		slash = strchr(mon_name, '/');
> +		if (!slash || slash[1] != '\0') {
> +			rdt_last_cmd_puts("Group must be <ctrl>/<mon>/\n");
> +			ret = -EINVAL;
> +			goto out_unlock;
> +		}
> +		*slash = '\0';
> +
> +		rdtgrp = rdtgroup_by_kmode_path(ctrl_name, mon_name);
> +		if (!rdtgrp) {
> +			rdt_last_cmd_puts("Group not found\n");
> +			ret = -EINVAL;
> +			goto out_unlock;
> +		}
> +	}
> +
> +	/*
> +	 * INHERIT mode binds nothing; force the bound group to the default so
> +	 * round-trips with show (which prints "group=//") are stable and any
> +	 * user-supplied :group= suffix is silently normalised.
> +	 */
> +	if (kmode == BIT(INHERIT_CTRL_AND_MON))
> +		rdtgrp = &rdtgroup_default;

rdtgrp = NULL ?

> +
> +	/* No-op if the same mode is already active on the same group. */
> +	if (resctrl_kcfg.kmode_cur == kmode && resctrl_kcfg.k_rdtgrp == rdtgrp)
> +		goto out_unlock;
> +
> +	/*
> +	 * global_assign_ctrl_assign_mon_per_cpu binds one CLOSID and RMID for
> +	 * all kernel work (Documentation/filesystems/resctrl.rst uses
> +	 * "<ctrl>/<mon>/", i.e. an RDTMON_GROUP).
> +	 *
> +	 * global_assign_ctrl_inherit_mon_per_cpu assigns one CLOSID globally
> +	 * while leaving RMID inheritance to user contexts; that uses the
> +	 * control group's CLOSID slot only, i.e. an RDTCTRL_GROUP.
> +	 */
> +	if (kmode == BIT(GLOBAL_ASSIGN_CTRL_ASSIGN_MON_PER_CPU) &&
> +	    rdtgrp->type != RDTMON_GROUP) {
> +		rdt_last_cmd_puts("global_assign_ctrl_assign_mon_per_cpu requires a monitor group\n");
> +		ret = -EINVAL;
> +		goto out_unlock;
> +	}
> +	if (kmode == BIT(GLOBAL_ASSIGN_CTRL_INHERIT_MON_PER_CPU) &&
> +	    rdtgrp->type != RDTCTRL_GROUP) {
> +		rdt_last_cmd_puts("global_assign_ctrl_inherit_mon_per_cpu requires a control group\n");
> +		ret = -EINVAL;
> +		goto out_unlock;
> +	}
> +
> +	/* Switching to a different group: release the old binding first. */
> +	if (resctrl_kcfg.k_rdtgrp != rdtgrp) {
> +		ret = rdtgroup_config_kmode_clear(resctrl_kcfg.k_rdtgrp,
> +						  resctrl_kcfg.kmode_cur);
> +		if (ret) {
> +			rdt_last_cmd_puts("Failed to release previous kernel-mode binding\n");
> +			goto out_unlock;
> +		}
> +	}
> +
> +	if (kmode != BIT(INHERIT_CTRL_AND_MON)) {
> +		ret = rdtgroup_config_kmode(rdtgrp);
> +		if (ret) {
> +			rdt_last_cmd_puts("Kernel mode change failed\n");

If it fails here then previous binding was released successfully but new binding failed. What is
state of system?

> +			goto out_unlock;
> +		}
> +	}
> +
> +	resctrl_kcfg.k_rdtgrp = rdtgrp;
> +	resctrl_kcfg.kmode_cur = kmode;
> +
> +out_unlock:
> +	mutex_unlock(&rdtgroup_mutex);
> +	return ret ?: nbytes;
> +}
> +
>  void *rdt_kn_parent_priv(struct kernfs_node *kn)
>  {
>  	/*
> @@ -1960,9 +2332,10 @@ static struct rftype res_common_files[] = {
>  	},
>  	{
>  		.name		= "kernel_mode",
> -		.mode		= 0444,
> +		.mode		= 0644,
>  		.kf_ops		= &rdtgroup_kf_single_ops,
>  		.seq_show	= resctrl_kernel_mode_show,
> +		.write		= resctrl_kernel_mode_write,
>  		.fflags		= RFTYPE_TOP_INFO,
>  	},
>  	{

Reinette

  reply	other threads:[~2026-06-16 23:42 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-30 23:24 [PATCH v3 00/12] [PATCH v3 00/12] x86/resctrl: Add kernel-mode (e.g., PLZA) support to the resctrl subsystem Babu Moger
2026-04-30 23:24 ` [PATCH v3 01/12] x86/resctrl: Support Privilege-Level Zero Association (PLZA) Babu Moger
2026-06-11 23:23   ` Reinette Chatre
2026-06-12 16:56     ` Moger, Babu
2026-06-12 17:00       ` Moger, Babu
2026-06-17  0:00       ` Reinette Chatre
2026-04-30 23:24 ` [PATCH v3 02/12] x86/resctrl: Add data structures and definitions for PLZA configuration Babu Moger
2026-06-11 23:40   ` Reinette Chatre
2026-06-12 15:40     ` Luck, Tony
2026-06-12 17:46       ` Moger, Babu
2026-06-12 17:32     ` Moger, Babu
2026-06-12 17:49       ` Moger, Babu
2026-04-30 23:24 ` [PATCH v3 03/12] fs/resctrl: Add kernel mode (kmode) data structures and arch hook Babu Moger
2026-06-16 23:30   ` Reinette Chatre
2026-04-30 23:24 ` [PATCH v3 04/12] x86,fs/resctrl: Program PLZA through kmode arch hooks Babu Moger
2026-05-19 20:59   ` Luck, Tony
2026-05-20 17:49     ` Babu Moger
2026-05-20 22:16       ` Luck, Tony
2026-05-20 23:09         ` Moger, Babu
2026-06-11 11:44           ` Peter Newman
2026-06-11 14:46             ` Babu Moger
2026-06-16 23:33   ` Reinette Chatre
2026-04-30 23:24 ` [PATCH v3 05/12] x86/resctrl: Initialize supported kernel modes for PLZA Babu Moger
2026-06-16 23:35   ` Reinette Chatre
2026-04-30 23:24 ` [PATCH v3 06/12] fs/resctrl: Initialize the global kernel-mode policy at subsystem init Babu Moger
2026-06-16 23:36   ` Reinette Chatre
2026-04-30 23:24 ` [PATCH v3 07/12] fs/resctrl: Add info/kernel_mode for kernel-mode policy introspection Babu Moger
2026-06-16 23:38   ` Reinette Chatre
2026-04-30 23:24 ` [PATCH v3 08/12] fs/resctrl: Make info/kernel_mode writable and identify the bound group Babu Moger
2026-06-16 23:42   ` Reinette Chatre [this message]
2026-04-30 23:24 ` [PATCH v3 09/12] fs/resctrl: Reset kernel-mode binding when its rdtgroup goes away Babu Moger
2026-06-16 23:42   ` Reinette Chatre
2026-04-30 23:24 ` [PATCH v3 10/12] fs/resctrl: Expose kmode_cpus / kmode_cpus_list per rdtgroup Babu Moger
2026-04-30 23:24 ` [PATCH v3 11/12] resctrl: Hide kmode_cpus[_list] on groups not bound to kernel-mode Babu Moger
2026-04-30 23:24 ` [PATCH v3 12/12] fs/resctrl: Allow user space to write kmode_cpus / kmode_cpus_list Babu Moger
2026-06-11 21:53 ` [PATCH v3 00/12] [PATCH v3 00/12] x86/resctrl: Add kernel-mode (e.g., PLZA) support to the resctrl subsystem Reinette Chatre
2026-06-12 15:37   ` Moger, Babu
2026-06-17  4:34     ` 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=57f6324b-6340-4633-b3a0-b40683a5ec12@intel.com \
    --to=reinette.chatre@intel.com \
    --cc=Dave.Martin@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=alexandre.chartre@oracle.com \
    --cc=babu.moger@amd.com \
    --cc=bhelgaas@google.com \
    --cc=bp@alien8.de \
    --cc=chang.seok.bae@intel.com \
    --cc=corbet@lwn.net \
    --cc=dapeng1.mi@linux.intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=elver@google.com \
    --cc=eranian@google.com \
    --cc=feng.tang@linux.alibaba.com \
    --cc=hpa@zytor.com \
    --cc=james.morse@arm.com \
    --cc=kees@kernel.org \
    --cc=kim.phillips@amd.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lirongqing@baidu.com \
    --cc=mingo@redhat.com \
    --cc=naveen@kernel.org \
    --cc=paulmck@kernel.org \
    --cc=pawan.kumar.gupta@linux.intel.com \
    --cc=peternewman@google.com \
    --cc=peterz@infradead.org \
    --cc=rdunlap@infradead.org \
    --cc=seanjc@google.com \
    --cc=skhan@linuxfoundation.org \
    --cc=tglx@kernel.org \
    --cc=thomas.lendacky@amd.com \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.org \
    --cc=xin@zytor.com \
    --cc=yazen.ghannam@amd.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