linux-kernel - Re: [tip: sched/core] sched/fair: Skip sched_balance

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]

Message-ID: <7099a373-8d6c-4c67-806c-84b50315f160@amd.com>
Date: Tue, 18 Nov 2025 00:30:36 +0530
From: K Prateek Nayak <kprateek.nayak@....com>
To: Tim Chen <tim.c.chen@...ux.intel.com>, Shrikanth Hegde
	<sshegde@...ux.ibm.com>, <linux-kernel@...r.kernel.org>, "Peter Zijlstra
 (Intel)" <peterz@...radead.org>
CC: <linux-tip-commits@...r.kernel.org>, Chen Yu <yu.c.chen@...el.com>,
	Vincent Guittot <vincent.guittot@...aro.org>, Srikar Dronamraju
	<srikar@...ux.ibm.com>, Mohini Narkhede <mohini.narkhede@...el.com>,
	<x86@...nel.org>
Subject: Re: [tip: sched/core] sched/fair: Skip sched_balance_running cmpxchg
 when balance is not due

On 11/18/2025 12:25 AM, Tim Chen wrote:
>> I wondered what is really different since the tim's v4 boots fine.
>> There is try instead in the tip, i think that is messing it since likely
>> we are dereferencing 0?
>>
>>
>> With this diff it boots fine.
>>
>> ---
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index aaa47ece6a8e..01814b10b833 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -11841,7 +11841,7 @@ static int sched_balance_rq(int this_cpu, struct rq *this_rq,
>>          }
>>   
>>          if (!need_unlock && (sd->flags & SD_SERIALIZE)) {
>> -               if (!atomic_try_cmpxchg_acquire(&sched_balance_running, 0, 1))
> 
> The second argument of atomic_try_cmpxchg_acquire is "int *old" while that of atomic_cmpxchg_acquire
> is "int old". So the above check would result in NULL pointer access.  Probably have
> to do something like the following to use atomic_try_cmpxchg_acquire()
> 
> 		int zero = 0;
> 		if (!atomic_try_cmpxchg_acquire(&sched_balance_running, &zero, 1))

Peter seems to have refreshed tip:sched/core with above but is
there any advantage of using atomic_try_cmpxchg_acquire() as
opposed to plain old atomic_cmpxchg_acquire() and then checking
the old value it returns?

That zero variable serves no other purpose and is a bit of an
eyesore IMO.

> 		
> Otherwise we should do atomic_cmpxchg_acquire() as below
> 
>> +               if (!atomic_cmpxchg_acquire(&sched_balance_running, 0, 1))
> 
-- 
Thanks and Regards,
Prateek