linux-kernel - Re: [RFC v2 7/9] x86/mm: Introduce Remote Action Request

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: <1debe11314379cd767c5f75131e81eed70670b91.camel@surriel.com>
Date: Tue, 20 May 2025 16:31:16 -0400
From: Rik van Riel <riel@...riel.com>
To: Nadav Amit <nadav.amit@...il.com>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, "open
 list:MEMORY MANAGEMENT"	 <linux-mm@...ck.org>, the arch/x86 maintainers
 <x86@...nel.org>, 	kernel-team@...a.com, Dave Hansen
 <dave.hansen@...ux.intel.com>, luto@...nel.org, 	peterz@...radead.org,
 Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar	 <mingo@...hat.com>,
 Borislav Petkov <bp@...en8.de>, "H. Peter Anvin"	 <hpa@...or.com>, Yu-cheng
 Yu <yu-cheng.yu@...el.com>
Subject: Re: [RFC v2 7/9] x86/mm: Introduce Remote Action Request

On Tue, 2025-05-20 at 23:26 +0300, Nadav Amit wrote:
> 
> > On 20 May 2025, at 16:00, Rik van Riel <riel@...riel.com> wrote:
> > 
> > > Putting aside the rest of the code, I see you don’t call
> > > should_flush_tlb().
> > > I think it is worth mentioning in commit log or comment the
> > > rationale
> > > behind
> > > it (and maybe benchmarks to justify it).
> > > 
> > > 
> > The long term plan here is to simply have the originating
> > CPU included in the cpumask, and have it send a RAR
> > request to itself.
> 
> That’s unrelated. I was referring to considering supporting
> some sort of lazy TLB to eliminate sending RAR to cores that
> do not care about it. Is there a cost of RAR to more cores than
> needed? My guess is that there is one, and maybe in such cases
> you would want actual IPI and special handling.

For RAR, I suspect the big cost is waking up
CPUs in idle states, and waiting for them to
wake up.

One possibility may be to change leave_mm()
to have an argument to set some flag that
the RAR code can read to see whether or
not to send a RAR interrupt to that CPU,
even if it is in the cpumask.

I don't think we can use the exact same
should_flush_tlb() logic, because the
tlb_gen is not updated by a RAR flush,
and the should_flush_tlb() logic is
somewhat intertwined with the tlb_gen
logic.

-- 
All Rights Reversed.