linux-kernel - Re: [PATCH] sched: remove unused cpumask variable in mm_cid

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: <20251021133018.GV3419281@noisy.programming.kicks-ass.net>
Date: Tue, 21 Oct 2025 15:30:18 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Uwe Kleine-König <u.kleine-koenig@...libre.com>
Cc: Thomas Gleixner <tglx@...utronix.de>, Vlastimil Babka <vbabka@...e.cz>,
	Breno Leitao <leitao@...ian.org>,
	Kriish Sharma <kriish.sharma2006@...il.com>,
	Ingo Molnar <mingo@...hat.com>, Juri Lelli <juri.lelli@...hat.com>,
	Vincent Guittot <vincent.guittot@...aro.org>,
	Dietmar Eggemann <dietmar.eggemann@....com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
	Valentin Schneider <vschneid@...hat.com>,
	linux-kernel@...r.kernel.org, david.hunter.linux@...il.com,
	skhan@...uxfoundation.org, Menglong Dong <menglong8.dong@...il.com>,
	André Draszik <andre.draszik@...aro.org>,
	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
	Aditya Gollamudi <adigollamudi@...il.com>,
	Kevin Brodsky <kevin.brodsky@....com>,
	Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
	Dan Carpenter <error27@...il.com>
Subject: Re: [PATCH] sched: remove unused cpumask variable in mm_cid_get()

On Tue, Oct 21, 2025 at 02:01:42PM +0200, Uwe Kleine-König wrote:

> There are several other submissions of the same patch with different
> commit logs; I found:
> 
> https://lore.kernel.org/all/20251002-sched-w1-v1-1-a6fdf549d179@linaro.org/
> https://lore.kernel.org/all/20251009194818.1587650-1-kriish.sharma2006@gmail.com/
> https://lore.kernel.org/all/20251015091935.2977229-1-andriy.shevchenko@linux.intel.com/
> https://lore.kernel.org/all/20251020221728.177983-1-adigollamudi@gmail.com/
> https://lore.kernel.org/all/20251017073050.2411988-1-kevin.brodsky@arm.com/ 

I know right, I seem to be getting at least one a day. If only people
were as good in testing -next I suppose. It also shows people can't be
arsed to search the archive :/

> Also Krzysztof's build bot is very unhappy:
> https://krzk.eu/#/builders/135

Not familiar with that thing.

> > People using W=1 and WERROR can keep the pieces. Anyway, this is a much
> > more coherent explanation that the original patch.
> 
> Can we please get this fixed even though you don't bother about W=1
> builds? There seem to be others who do. And note that even
> 
> 	make W=1 drivers/pwm/
> 
> is broken due to that, so it affects also maintainers who only want W=1
> for their own subtree.

Only if you have WERROR=y, which really you shouldn't have if you use
W>0.

> Regarding the Fixes line: Vlastimil Babka bisected it to 378b7708194f
> ("sched: Make migrate_{en,dis}able() inline"), but I think this is just
> the commit that made the compiler notice that. IMHO Andy identified the
> more plausible commit with:
> 
> Fixes: 223baf9d17f2 ("sched: Fix performance regression introduced by mm_cid")

Right, as said, Thomas is rewriting all that. His first patch is a
revert of that commit:

  https://lkml.kernel.org/r/20251015164952.694882104@linutronix.de

> Note there is a lkp report about André's patch (i.e. the first in my
> list above) at
> https://lore.kernel.org/all/202510041546.DvhFLp2x-lkp@intel.com/#t. I
> don't understand the issue found there, but maybe someone should before
> the patch is applied.

That's unrelated to the patch in question -- it is the robot
re-reporting a smatch thing because the code changed and the new report
no longer exactly matches the old report or something.

smatch wasn't able to discover the relation between next->mm and
next->mm_cid_active and warns us that next->mm can be NULL (per a
previous test for that) and that feeding said NULL into mm_cid_get() is
a problem -- it would be, except next->mm_cid_active cannot be set if
!next->mm.

*sigh*, it just means Thomas will have to rebase his series -- not the
end of the world I suppose but I really don't get this obsession with
W=1.

The problem is really that I'm now mandated to keep the scheduler W=1
clean, and I really, as in *really* don't care for W=1. A number of
warnings there are just not sane, like that ludicrous unused static
inline warning.

But sure -- send a patch for this, with a coherent changelog. I'll be a
bigger pain in the arse the moment the 'fix' really doesn't make sense.
I'll probably propose removing the warnings from W=1, like here:

  https://lkml.kernel.org/r/20250813152142.GP4067720@noisy.programming.kicks-ass.net

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)