linux-kernel - Re: [PATCH v5 10/12] x86,tlb: do targeted broadcast flushing from tlbbatch code

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: <5F51AFA6-EA48-42BF-8E24-10FAAAA7BE4B@gmail.com>
Date: Mon, 20 Jan 2025 19:50:44 +0200
From: Nadav Amit <nadav.amit@...il.com>
To: Rik van Riel <riel@...riel.com>
Cc: 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>,
 jannh@...gle.com,
 mhklinux@...look.com,
 andrew.cooper3@...rix.com
Subject: Re: [PATCH v5 10/12] x86,tlb: do targeted broadcast flushing from
 tlbbatch code

[ Thanks for your patience. ]

> On 20 Jan 2025, at 19:11, Rik van Riel <riel@...riel.com> wrote:
> 
> On Mon, 2025-01-20 at 19:09 +0200, Nadav Amit wrote:
> 
> This is the page reclaim code.
> 
> The process that has those other pages mapped might be
> running on other CPUs simultaneously with the page
> reclaim code.
> 
> Even if we were invalidating one of our own pages this
> way, there could be other threads in the same process,
> running while we are in the page reclaim code.

Of course, but there is nothing new here. Let me see where we lose
each other by first stating the goal, what you propose, and what I
suggest.

We are issuing invlpgb and we need to ensure tlbsync on the same core
that initiated invlpgb before arch_tlbbatch_flush() finishes. That’s
all that matters for our discussion (correct me if I miss something).

You solved it by disabling migration and running tlbsync at the end.

I suggest *not* to disable migration, to keep running tlbsync at the
arch_tlbbatch_flush() as you do, and if context-switch happens after
arch_tlbbatch_add_pending() and before arch_tlbbatch_flush(), to run
tlbsync during the context switch.