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] [day] [month] [year] [list]

Message-ID: <ea7e6e43-c9fa-4ae0-93d9-8837ce6a6b63@linaro.org>
Date: Tue, 21 Oct 2025 22:02:05 +0200
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Peter Zijlstra <peterz@...radead.org>,
 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>, Dan Carpenter <error27@...il.com>
Subject: Re: [PATCH] sched: remove unused cpumask variable in mm_cid_get()

On 21/10/2025 15:30, Peter Zijlstra wrote:
>>> 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.


That's not correct. I want my code to have zero W=1 errors and way I
achieved that is that I fixed all the warnings and now I build code I
maintain with allyesconfig (so werror) and W=1. That's way I am sure no
new warnings will slip into subsystem I maintain.

I recommend other maintainers also not to introduce W=1 errors and don't
accept patches who introduce them, even if that patch (like in this
case) just re-shuffled things and made some non important issue visible.

Why? Because we anyway do not want W=1 errors in RC release...

> 
>> 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

Great, so since your code is quite important and I cannot build my code
without that part, we are all stuck because you want W=0 compliance...

> warnings there are just not sane, like that ludicrous unused static
> inline warning.

That ludicrous warning could have been fixed when it hit next, because
it was not hiding from you. Building with W=1 is pretty standard thing
for new code. The truth is that that commit was applied shortly - few
days before merge window:
1. my earliest report comes from 26th of September
https://krzk.eu/#/builders/135/builds/180

2. Merge window opens Sep 28.

Two days in next, great!

> 
> 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

That is fine as well. Your subsystem, your call, but unfortunately we
cannot build our stuff when yours fails.


Best regards,
Krzysztof