linux-kernel - Re: [PATCH v2] x86/mm: Hide mm_free_global_asid() definition under 'CONFIG_BROADCAST_TLB

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: <20260116204708.GCaWqjzNmTUYiEFftb@fat_crate.local>
Date: Fri, 16 Jan 2026 21:47:08 +0100
From: Borislav Petkov <bp@...en8.de>
To: Hou Wenlong <houwenlong.hwl@...group.com>
Cc: linux-kernel@...r.kernel.org, Rik van Riel <riel@...riel.com>,
	Thomas Gleixner <tglx@...nel.org>, Ingo Molnar <mingo@...hat.com>,
	Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
	"H. Peter Anvin" <hpa@...or.com>, Andy Lutomirski <luto@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Will Deacon <will@...nel.org>, Ryan Roberts <ryan.roberts@....com>,
	Jann Horn <jannh@...gle.com>, Barry Song <baohua@...nel.org>
Subject: Re: [PATCH v2] x86/mm: Hide mm_free_global_asid() definition under
 'CONFIG_BROADCAST_TLB_FLUSH'

On Fri, Jan 16, 2026 at 11:47:22AM +0800, Hou Wenlong wrote:
> Honestly, I did not run all the tests you asked. I admit that my
> attitude was somewhat hasty and not thorough. I sincerely apologize for
> the trouble this has caused you and for taking up your time.

Thanks for being honest - I appreciate that greatly.

> After testing the configuration you provided, I analyzed my code
> modifications and noticed that the definition of 'mm_free_global_asid()' is
> included under '#ifndef module' and is only called in destroy_context().
> Therefore, I checked all the places where destroy_context() is called and
> found that it is only called in 'kernel/fork.c', which is not invoked in
> a module (and the original mm_free_global_asid() was not exported either).
> To save time, I only tested 'allyesconfig' and my test configuration with
> module compilation under 'x86_64' and 'i386', and since I did not encounter
> any issues, I went ahead and sent the patch. I realize now that I did not
> conduct a complete set of tests.

Yes, that's the thing. Sometimes even visual analysis escapes one weird
configuration which we cannot think about. That's why we try to run a full
battery of build tests, especially when code is changing around ifdeffery
and/or in header files.

And note that you can simply say that you don't have the resources to run
those tests - that's perfectly fine, I can do that. All I'd like to hear is
what you did and didn't test so that I can help. We're a community and usually
help each other where we can. :-)

> Upon carefully comparing the configuration you provided, I found that
> the GCC versions are different (mine is 12.2.0 and yours is 13.3.0), and
> I am using the tip/master branch from the 12th, which also does not
> match your '6.19-rc3'. After a full night of testing (using the tip/master
> branch and the '6.19-rc5' tag), I still did not find any issues; it may be
> related to the compiler. I will try using GCC 13.3.0 to see if that
> makes a difference and will conduct more randconfig tests.

Thanks, that's helpful.

I'll run your v2 through my tests too and if it passes, I'll queue it.

Thanks again for the honest and thorough explanation!

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette