[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6f71aecb-9a2c-4705-a3f4-71231ef6a831@intel.com>
Date: Tue, 2 Sep 2025 09:11:27 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Nadav Amit <nadav.amit@...il.com>
Cc: Giovanni Cabiddu <giovanni.cabiddu@...el.com>,
Rik van Riel <riel@...riel.com>, the arch/x86 maintainers <x86@...nel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Borislav Petkov <bp@...en8.de>, peterz@...radead.org,
Dave Hansen <dave.hansen@...ux.intel.com>, zhengqi.arch@...edance.com,
thomas.lendacky@....com, kernel-team@...a.com,
"open list:MEMORY MANAGEMENT" <linux-mm@...ck.org>,
Andrew Morton <akpm@...ux-foundation.org>, jackmanb@...gle.com,
jannh@...gle.com, mhklinux@...look.com, andrew.cooper3@...rix.com,
Manali.Shukla@....com, Ingo Molnar <mingo@...nel.org>, baolu.lu@...el.com,
david.guckian@...el.com, damian.muszynski@...el.com
Subject: Re: [BUG] x86/mm: regression after 4a02ed8e1cc3
On 9/2/25 09:08, Nadav Amit wrote:
> It would be nice (if possible) that callees like broadcast_tlb_flush()
> would constify flush_tlb_info (I’m not encouraging lots of consification,
> but maybe it’s appropriate here) to prevent the misuse of flush_tlb_info.
Yeah, agreed. It would be nice if there was a clear and enforced line
between producers and consumers here.
Powered by blists - more mailing lists