[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <682e4ed6ec16_1626e1004e@dwillia2-xfh.jf.intel.com.notmuch>
Date: Wed, 21 May 2025 15:08:22 -0700
From: Dan Williams <dan.j.williams@...el.com>
To: Arnd Bergmann <arnd@...nel.org>, Dave Hansen
<dave.hansen@...ux.intel.com>, Dan Williams <dan.j.williams@...el.com>
CC: 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>, <x86@...nel.org>, Greg Kroah-Hartman
<gregkh@...uxfoundation.org>, Nikolay Borisov <nik.borisov@...e.com>,
<linux-kernel@...r.kernel.org>, Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCH 2/3] x86/devmem: remove phys_mem_access_prot_allowed()
Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@...db.de>
>
> phys_mem_access_prot_allowed() was originally a workaround for
> certain 32-bit CPUs, but after commit 1886297ce0c8 ("x86/mm/pat:
> Fix BUG_ON() in mmap_mem() on QEMU/i386"), it no longer does anything
> special as the only remaining bit now is the same logic that follows in
> phys_mem_access_prot(), mapping everything as normal memory except when
> either O_DSYNC is set or the address is highmem.
>
> Just remove the thing entirely.
>
> Signed-off-by: Arnd Bergmann <arnd@...db.de>
> ---
> arch/x86/mm/pat/memtype.c | 15 ---------------
> drivers/char/mem.c | 10 ----------
> include/linux/pgtable.h | 2 --
> 3 files changed, 27 deletions(-)
Agree, I came to the same conclusion in the commit message of
1b3f2bd04d90, but then failed to circle back and remove the thing. So,
Reviewed-by: Dan Williams <dan.j.williams@...el.com>
Powered by blists - more mailing lists