[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrWAk-zVKKjvrq+fRAX5HKhdHF36h+jY+91_tQOa67xozA@mail.gmail.com>
Date: Thu, 3 Sep 2020 07:52:35 -0700
From: Andy Lutomirski <luto@...nel.org>
To: Joerg Roedel <joro@...tes.org>
Cc: X86 ML <x86@...nel.org>, Dave Hansen <dave.hansen@...ux.intel.com>,
Andy Lutomirski <luto@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
"H. Peter Anvin" <hpa@...or.com>, Joerg Roedel <jroedel@...e.de>,
LKML <linux-kernel@...r.kernel.org>,
Naresh Kamboju <naresh.kamboju@...aro.org>,
stable <stable@...r.kernel.org>
Subject: Re: [PATCH] x86/mm/32: Bring back vmalloc faulting on x86_32
On Wed, Sep 2, 2020 at 8:59 AM Joerg Roedel <joro@...tes.org> wrote:
>
> From: Joerg Roedel <jroedel@...e.de>
>
> One can not simply remove vmalloc faulting on x86-32. Upstream
>
> commit: 7f0a002b5a21 ("x86/mm: remove vmalloc faulting")
>
> removed it on x86 alltogether because previously the
> arch_sync_kernel_mappings() interface was introduced. This interface
> added synchronization of vmalloc/ioremap page-table updates to all
> page-tables in the system at creation time and was thought to make
> vmalloc faulting obsolete.
>
> But that assumption was incredibly naive.
Does this mean we can get rid of arch_sync_kernel_mappings()? Or
should we consider adding some locking to make it non-racy again?
-Andy
Powered by blists - more mailing lists