linux-kernel - Re: [PATCH v2 -next] cgroup/cpuset: Avoid clearing CS_SCHED_LOAD

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Mon, 22 Apr 2024 22:53:30 -0400
From: Waiman Long <longman@...hat.com>
To: Xiu Jianfeng <xiujianfeng@...wei.com>, lizefan.x@...edance.com,
 tj@...nel.org, hannes@...xchg.org
Cc: cgroups@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 -next] cgroup/cpuset: Avoid clearing
 CS_SCHED_LOAD_BALANCE twice

On 4/22/24 22:44, Xiu Jianfeng wrote:
> In cpuset_css_online(), CS_SCHED_LOAD_BALANCE will be cleared twice,
> the former one in the is_in_v2_mode() case could be removed because
> is_in_v2_mode() can be true for cgroup v1 if the "cpuset_v2_mode"
> mount option is specified, that balance flag change isn't appropriate
> for this particular case.
>
> Signed-off-by: Xiu Jianfeng <xiujianfeng@...wei.com>
>
> ---
> v2: remove the one in is_in_v2_mode() case.
> ---
>   kernel/cgroup/cpuset.c | 5 -----
>   1 file changed, 5 deletions(-)
>
> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
> index d8d3439eda4e..bb9bf25889c9 100644
> --- a/kernel/cgroup/cpuset.c
> +++ b/kernel/cgroup/cpuset.c
> @@ -4051,11 +4051,6 @@ static int cpuset_css_online(struct cgroup_subsys_state *css)
>   		cs->effective_mems = parent->effective_mems;
>   		cs->use_parent_ecpus = true;
>   		parent->child_ecpus_count++;
> -		/*
> -		 * Clear CS_SCHED_LOAD_BALANCE if parent is isolated
> -		 */
> -		if (!is_sched_load_balance(parent))
> -			clear_bit(CS_SCHED_LOAD_BALANCE, &cs->flags);
>   	}
>   
>   	/*

Thank for the v2.

Reviewed-by: Waiman Long <longman@...hat.com>