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: <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

Powered by Openwall GNU/*/Linux Powered by OpenVZ