From: Waiman Long <llong@redhat.com>
To: Chen Ridong <chenridong@huaweicloud.com>,
tj@kernel.org, hannes@cmpxchg.org, mkoutny@suse.com
Cc: cgroups@vger.kernel.org, linux-kernel@vger.kernel.org,
lujialin4@huawei.com, chenridong@huawei.com
Subject: Re: [PATCH -next RFC -v2 08/11] cpuset: refactor cpus_allowed_validate_change
Date: Mon, 15 Sep 2025 15:05:21 -0400 [thread overview]
Message-ID: <7a42945a-9d82-47ad-9175-cfc3c0c311c3@redhat.com> (raw)
In-Reply-To: <20250909033233.2731579-9-chenridong@huaweicloud.com>
On 9/8/25 11:32 PM, Chen Ridong wrote:
> From: Chen Ridong <chenridong@huawei.com>
>
> Refactor cpus_allowed_validate_change to handle the special case where
> cpuset.cpus can be set even when violating partition sibling CPU
> exclusivity rules. This differs from the general validation logic in
> validate_change. Add a wrapper function to properly handle this
> exceptional case.
That special rule is needed as setting v2 cpuset.cpus will never fail.
For v1, it may only fails if the exclusivity rule set by the exclusive
flag is violated. For v2, write failure may only happen on
cpuset.cpus.exclusive. As a result, existing partitions may have to be
invalidated if it will break exclusivity rule.
>
> The trialcs->prs_err field is cleared before performing validation checks
> for both CPU changes and partition errors. If cpus_allowed_validate_change
> fails its validation, trialcs->prs_err is set to PERR_NOTEXCL. If partition
> validation fails, the specific error code returned by validate_partition
> is assigned to trialcs->prs_err.
>
> With the partition validation status now directly available through
> trialcs->prs_err, the local boolean variable 'invalidate' becomes
> redundant and can be safely removed.
>
> Signed-off-by: Chen Ridong <chenridong@huawei.com>
> ---
> kernel/cgroup/cpuset.c | 84 ++++++++++++++++++++++--------------------
> 1 file changed, 45 insertions(+), 39 deletions(-)
>
> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
> index 770b33e30576..6aa93bd9d5dd 100644
> --- a/kernel/cgroup/cpuset.c
> +++ b/kernel/cgroup/cpuset.c
> @@ -2416,6 +2416,42 @@ static enum prs_errcode validate_partition(struct cpuset *cs, struct cpuset *tri
> return PERR_NONE;
> }
>
> +static int cpus_allowed_validate_change(struct cpuset *cs, struct cpuset *trialcs,
> + struct tmpmasks *tmp)
> +{
> + int retval;
> + struct cpuset *parent = parent_cs(cs);
> +
> + retval = validate_change(cs, trialcs);
> +
> + if ((retval == -EINVAL) && cpuset_v2()) {
> + struct cgroup_subsys_state *css;
> + struct cpuset *cp;
> +
> + /*
> + * The -EINVAL error code indicates that partition sibling
> + * CPU exclusivity rule has been violated. We still allow
> + * the cpumask change to proceed while invalidating the
> + * partition. However, any conflicting sibling partitions
> + * have to be marked as invalid too.
> + */
> + trialcs->prs_err = PERR_NOTEXCL;
> + rcu_read_lock();
> + cpuset_for_each_child(cp, css, parent) {
> + struct cpumask *xcpus = user_xcpus(trialcs);
> +
> + if (is_partition_valid(cp) &&
> + cpumask_intersects(xcpus, cp->effective_xcpus)) {
> + rcu_read_unlock();
> + update_parent_effective_cpumask(cp, partcmd_invalidate, NULL, tmp);
> + rcu_read_lock();
> + }
> + }
> + rcu_read_unlock();
> + retval = 0;
> + }
> + return retval;
> +}
>
> /**
> * update_cpumask - update the cpus_allowed mask of a cpuset and all tasks in it
> @@ -2428,8 +2464,6 @@ static int update_cpumask(struct cpuset *cs, struct cpuset *trialcs,
> {
> int retval;
> struct tmpmasks tmp;
> - struct cpuset *parent = parent_cs(cs);
> - bool invalidate = false;
> bool force = false;
> int old_prs = cs->partition_root_state;
> enum prs_errcode prs_err;
> @@ -2446,12 +2480,10 @@ static int update_cpumask(struct cpuset *cs, struct cpuset *trialcs,
> return -ENOMEM;
>
> compute_trialcs_excpus(trialcs, cs);
> + trialcs->prs_err = PERR_NONE;
>
> - prs_err = validate_partition(cs, trialcs);
> - if (prs_err) {
> - invalidate = true;
> - cs->prs_err = prs_err;
> - }
> + if (cpus_allowed_validate_change(cs, trialcs, &tmp) < 0)
> + goto out_free;
>
> /*
> * Check all the descendants in update_cpumasks_hier() if
> @@ -2459,40 +2491,14 @@ static int update_cpumask(struct cpuset *cs, struct cpuset *trialcs,
> */
> force = !cpumask_equal(cs->effective_xcpus, trialcs->effective_xcpus);
>
> - retval = validate_change(cs, trialcs);
> -
> - if ((retval == -EINVAL) && cpuset_v2()) {
> - struct cgroup_subsys_state *css;
> - struct cpuset *cp;
> -
> - /*
> - * The -EINVAL error code indicates that partition sibling
> - * CPU exclusivity rule has been violated. We still allow
> - * the cpumask change to proceed while invalidating the
> - * partition. However, any conflicting sibling partitions
> - * have to be marked as invalid too.
> - */
> - invalidate = true;
> - rcu_read_lock();
> - cpuset_for_each_child(cp, css, parent) {
> - struct cpumask *xcpus = user_xcpus(trialcs);
> -
> - if (is_partition_valid(cp) &&
> - cpumask_intersects(xcpus, cp->effective_xcpus)) {
> - rcu_read_unlock();
> - update_parent_effective_cpumask(cp, partcmd_invalidate, NULL, &tmp);
> - rcu_read_lock();
> - }
> - }
> - rcu_read_unlock();
> - retval = 0;
> + prs_err = validate_partition(cs, trialcs);
> + if (prs_err) {
> + trialcs->prs_err = prs_err;
> + cs->prs_err = prs_err;
> }
>
> - if (retval < 0)
> - goto out_free;
> -
> if (is_partition_valid(cs) ||
> - (is_partition_invalid(cs) && !invalidate)) {
> + (is_partition_invalid(cs) && !trialcs->prs_err)) {
> struct cpumask *xcpus = trialcs->effective_xcpus;
>
> if (cpumask_empty(xcpus) && is_partition_invalid(cs))
> @@ -2503,7 +2509,7 @@ static int update_cpumask(struct cpuset *cs, struct cpuset *trialcs,
> */
> if (is_remote_partition(cs))
> remote_cpus_update(cs, NULL, xcpus, &tmp);
> - else if (invalidate)
> + else if (trialcs->prs_err)
> update_parent_effective_cpumask(cs, partcmd_invalidate,
> NULL, &tmp);
> else
Reviewed-by: Waiman Long <longman@redhat.com>
next prev parent reply other threads:[~2025-09-15 19:05 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-09 3:32 [PATCH -next RFC -v2 00/11] Refactor cpus mask setting Chen Ridong
2025-09-09 3:32 ` [PATCH -next RFC -v2 01/11] cpuset: move the root cpuset write check earlier Chen Ridong
2025-09-15 18:43 ` Waiman Long
2025-09-09 3:32 ` [PATCH -next RFC -v2 02/11] cpuset: remove unused assignment to trialcs->partition_root_state Chen Ridong
2025-09-15 18:44 ` Waiman Long
2025-09-09 3:32 ` [PATCH -next RFC -v2 03/11] cpuset: change return type of is_partition_[in]valid to bool Chen Ridong
2025-09-15 18:44 ` Waiman Long
2025-09-09 3:32 ` [PATCH -next RFC -v2 04/11] cpuset: Refactor exclusive CPU mask computation logic Chen Ridong
2025-09-15 18:47 ` Waiman Long
2025-09-09 3:32 ` [PATCH -next RFC -v2 05/11] cpuset: refactor CPU mask buffer parsing logic Chen Ridong
2025-09-15 18:49 ` Waiman Long
2025-09-09 3:32 ` [PATCH -next RFC -v2 06/11] cpuset: introduce cpus_excl_conflict and mems_excl_conflict helpers Chen Ridong
2025-09-15 18:42 ` Waiman Long
2025-09-16 7:59 ` Chen Ridong
2025-09-09 3:32 ` [PATCH -next RFC -v2 07/11] cpuset: refactor out validate_partition Chen Ridong
2025-09-15 18:53 ` Waiman Long
2025-09-09 3:32 ` [PATCH -next RFC -v2 08/11] cpuset: refactor cpus_allowed_validate_change Chen Ridong
2025-09-15 19:05 ` Waiman Long [this message]
2025-09-09 3:32 ` [PATCH -next RFC -v2 09/11] cpuset: refactor partition_cpus_change Chen Ridong
2025-09-15 19:34 ` Waiman Long
2025-09-16 8:01 ` Chen Ridong
2025-09-09 3:32 ` [PATCH -next RFC -v2 10/11] cpuset: use parse_cpulist for setting cpus.exclusive Chen Ridong
2025-09-15 19:39 ` Waiman Long
2025-09-09 3:32 ` [PATCH -next RFC -v2 11/11] cpuset: use partition_cpus_change for setting exclusive cpus Chen Ridong
2025-09-15 20:05 ` Waiman Long
2025-09-16 8:02 ` Chen Ridong
2025-09-15 11:18 ` [PATCH -next RFC -v2 00/11] Refactor cpus mask setting Chen Ridong
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=7a42945a-9d82-47ad-9175-cfc3c0c311c3@redhat.com \
--to=llong@redhat.com \
--cc=cgroups@vger.kernel.org \
--cc=chenridong@huawei.com \
--cc=chenridong@huaweicloud.com \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lujialin4@huawei.com \
--cc=mkoutny@suse.com \
--cc=tj@kernel.org \
/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