linux-kernel - Re: [GIT pull] sched/urgent for v6.16-rc7

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAHk-=wiMNdBYJcDo47riSP5=_Re4A-itmBwBfsnDxZqvfn5tHQ@mail.gmail.com>
Date: Sun, 20 Jul 2025 11:20:31 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Thomas Gleixner <tglx@...utronix.de>, Peter Zijlstra <peterz@...radead.org>
Cc: linux-kernel@...r.kernel.org, x86@...nel.org
Subject: Re: [GIT pull] sched/urgent for v6.16-rc7

On Sun, 20 Jul 2025 at 05:05, Thomas Gleixner <tglx@...utronix.de> wrote:
>
> A single fix for the scheduler. A recent commit changed the runqueue
> counter nr_uninterruptible to an unsigned int. Due to the fact that the
> counters are not updated on migration of a uninterruptble task to a
> different CPU, these counters can exceed INT_MAX. The counter is cast to
> long in the load average calculation, which means that the cast expands
> into negative space resulting in bogus load average values. Convert it back
> to unsigned long to fix this.

I've obviously pulled this, but considering that the thing isn't
actually really an unsigned value in the first place, and all users
seem to cast it to 'long' anyway, there's an obvious question... Why
is it unsigned in the first place, rather than just make it be the
more natural signed type?

At that point, the _size_ of the type wouldn't even have mattered
(outside of actual overflows, of course).

Of course, regardless of all this, if it does negative due to
migration, it looks like the calc_load_fold_active() calculations end
up being a bit nonsensical. Not that it looks like that matters
either, but it did make me go "Hmm - people seem to _assume_ it's
always positive, it has a _type_ that is always positive, but then we
have those odd hacks for the fact that it can actually be negative".

So none of this seems to _matter_ (outside of the "unsigned int got
*really* mangled" issue that this pull fixes), but it's all a bit odd.

             Linus