[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <af694be2e99ffac0d67bad73686679f577368264.camel@surriel.com>
Date: Tue, 31 Dec 2024 11:11:51 -0500
From: Rik van Riel <riel@...riel.com>
To: Borislav Petkov <bp@...en8.de>
Cc: x86@...nel.org, linux-kernel@...r.kernel.org, kernel-team@...a.com,
dave.hansen@...ux.intel.com, luto@...nel.org, peterz@...radead.org,
tglx@...utronix.de, mingo@...hat.com, hpa@...or.com,
akpm@...ux-foundation.org, nadav.amit@...il.com,
zhengqi.arch@...edance.com, linux-mm@...ck.org
Subject: Re: [PATCH 01/12] x86/mm: make MMU_GATHER_RCU_TABLE_FREE
unconditional
On Mon, 2024-12-30 at 19:41 +0100, Borislav Petkov wrote:
> On Mon, Dec 30, 2024 at 12:53:02PM -0500, Rik van Riel wrote:
> > Currently x86 uses CONFIG_MMU_GATHER_TABLE_FREE when using
> > paravirt, and not when running on bare metal.
> >
> > There is no real good reason to do things differently for
> > each setup. Make them all the same.
> >
> > After this change, the synchronization between get_user_pages_fast
> > and page table freeing is handled by RCU, which prevents page
> > tables
> > from being reused for other data while get_user_pages_fast is
> > walking
> > them.
>
> I'd rather like to read here why this is not a problem anymore and
> why
>
> 48a8b97cfd80 ("x86/mm: Only use tlb_remove_table() for paravirt")
>
> is not relevant anymore.
That would be a question for Peter :)
>
> > This allows us to invalidate page tables while other CPUs have
> ^^
>
> Please use passive voice in your commit message: no "we" or "I", etc,
> and describe your changes in imperative mood.
Will do. Between your feedback, the suggestions
from Qi and Nadav, and the kernel test robot
flagging some build issues without CONFIG_CPU_SUP_AMD,
there's enough to warrant a v4 :)
--
All Rights Reversed.
Powered by blists - more mailing lists