Re: [tip: sched/core] sched/fair: Skip sched_balance_running cmpxchg when balance is not due

[Peter Zijlstra <peterz@infradead.org>]

On Thu, Nov 20, 2025 at 11:26:00PM -0700, Nathan Chancellor wrote:
> On Tue, Nov 18, 2025 at 10:54:32AM +0100, Peter Zijlstra wrote:
> > On Mon, Nov 17, 2025 at 10:55:07AM -0800, Tim Chen wrote:
> > 
> > > >          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))
> > > 		
> > > Otherwise we should do atomic_cmpxchg_acquire() as below
> > 
> > Yes, and I'm all mightily miffed all the compilers accept 0 (which is
> > int) for an 'int *' argument without so much as a warning :/
> 
> The C11 standard says in 6.3.2.3p3
> 
>   An integer constant expression with the value 0, or such an expression
>   cast to type void *, is called a null pointer constant.

That's just bloody ludicrous :-(, I mean, the explicit cast to void*
sure, but the implicit conversion is just idiotic. I realize there's
legacy here, but urgh.

> which seems to indicate to me that
> 
>   int *foo = 0;
> 
> and
> 
>   #define NULL (void *)0
>   int *foo = NULL;
> 
> have to be treated the same way :/ I think that is a big part of the
> motivation to bring nullptr into C in C23:
> 
>   https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3042.htm

Even without that, just dropping the implicit conversion is a giant step
forward.

> > Nathan, you looked into this a bit yesterday, afaict there is:
> > 
> >   -Wzero-as-null-pointer-constant
> > 
> > which is supposed to issue a warn here, but I can't get clang-22 to
> > object :/ (GCC doesn't take that warning for C mode, only C++, perhaps
> > that's the problem?).
> 
> Right, it appears to be the same case for clang, notice the comment in
> diagnoseZeroToNullptrConversion():
> 
>   https://github.com/llvm/llvm-project/commit/d7ba86b6bf54740dd4007e65a927151cb9f510b4
> 
> That warning should probably be updated to work for C23 but that does
> not really help us now because nullptr is not available in older
> standards (and I think the support for C23 is only solid in really
> recent compilers IIUC).

So personally I really don't see a problem with '(void *)0', what if
anything does nullptr actually bring over that?

> > Help?
> 
> Maybe we could have something like -Wnon-literal-null-conversion-strict
> in clang that would behave like -Wnon-literal-null-conversion but warn
> even in the literal zero conversion case (i.e., require a 'void *'
> cast)... That does not really help GCC though since it does not warn on
> any case of implicit conversion to NULL:

Yes, that makes sense. Perhaps we can even convince GCC folks to also
implement this ;-)

Just having it in clang would mean clangd will have the warning and thus
all the LSP enabled editors will provide the warn, which is a win.