From: Dan Williams <dan.j.williams@intel.com>
To: Naveen N Rao <naveen@kernel.org>,
Dan Williams <dan.j.williams@intel.com>
Cc: <dave.hansen@linux.intel.com>, Ingo Molnar <mingo@kernel.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 1/3] x86/devmem: Remove duplicate range_is_allowed() definition
Date: Wed, 16 Apr 2025 14:25:49 -0700 [thread overview]
Message-ID: <6800205d86e73_71fe294e4@dwillia2-xfh.jf.intel.com.notmuch> (raw)
In-Reply-To: <s6fek3k3zsgf74yuppzckhcnud67pgfitz66n6uwkky7gvjcpc@rp4pxvie2dpb>
Naveen N Rao wrote:
> On Thu, Apr 10, 2025 at 06:22:23PM -0700, Dan Williams wrote:
> > It looks like x86 has a local re-implementation of range_is_allowed()
> > just to add a pat_enabled() check for the strong symbol override of
> > phys_mem_access_prot_allowed() from drivers/char/mem.c.
> >
> > In preparation for updating range_is_allowed() logic, arrange for there
> > to be only one shared instance of "range_is_allowed()" in the kernel by
> > moving a common helper to include/linux/io.h.
> >
> > Cc: Dave Hansen <dave.hansen@linux.intel.com>
> > Cc: Ingo Molnar <mingo@kernel.org>
> > Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> > ---
> > arch/x86/mm/pat/memtype.c | 31 ++++---------------------------
> > drivers/char/mem.c | 18 ------------------
> > include/linux/io.h | 21 +++++++++++++++++++++
> > 3 files changed, 25 insertions(+), 45 deletions(-)
> >
> > diff --git a/arch/x86/mm/pat/memtype.c b/arch/x86/mm/pat/memtype.c
> > index 72d8cbc61158..c97b6598f187 100644
> > --- a/arch/x86/mm/pat/memtype.c
> > +++ b/arch/x86/mm/pat/memtype.c
> > @@ -38,6 +38,7 @@
> > #include <linux/kernel.h>
> > #include <linux/pfn_t.h>
> > #include <linux/slab.h>
> > +#include <linux/io.h>
> > #include <linux/mm.h>
> > #include <linux/highmem.h>
> > #include <linux/fs.h>
> > @@ -773,38 +774,14 @@ pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
> > return vma_prot;
> > }
> >
> > -#ifdef CONFIG_STRICT_DEVMEM
> > -/* This check is done in drivers/char/mem.c in case of STRICT_DEVMEM */
> > -static inline int range_is_allowed(unsigned long pfn, unsigned long size)
> > -{
> > - return 1;
> > -}
>
> It looks like no checks were done here if CONFIG_STRICT_DEVMEM was set,
> so this patch changes that.
Yes, but this still matches the historical intent, and the historical
intent is a tad messy.
The pat_enabled check was originally added as a *bypass* of additional
logic in phys_mem_access_prot_allowed() [1] to validate that /dev/mem was
establishing compatible mappings of "System-RAM" via /dev/mem. This
patch maintains that expectation that phys_mem_access_prot_allowed()
returns immediately when there is no potential cache conflict.
However, the point is moot in current code because [2] and [3] removed
all cache type validation from phys_mem_access_prot_allowed() in favor
track_pfn_remap().
According to:
Commit 9e41bff2708e ("x86: fix /dev/mem mmap breakage when PAT is disabled") [1]
Commit 1886297ce0c8 ("x86/mm/pat: Fix BUG_ON() in mmap_mem() on QEMU/i386") [2]
Commit 0c3c8a18361a ("x86, PAT: Remove duplicate memtype reserve in devmem mmap") [3]
> > -#else
> > -/* This check is needed to avoid cache aliasing when PAT is enabled */
> > -static inline int range_is_allowed(unsigned long pfn, unsigned long size)
> > -{
> > - u64 from = ((u64)pfn) << PAGE_SHIFT;
> > - u64 to = from + size;
> > - u64 cursor = from;
> > -
> > - if (!pat_enabled())
> > - return 1;
> > -
> > - while (cursor < to) {
> > - if (!devmem_is_allowed(pfn))
> > - return 0;
> > - cursor += PAGE_SIZE;
> > - pfn++;
> > - }
> > - return 1;
> > -}
> > -#endif /* CONFIG_STRICT_DEVMEM */
> > -
> > int phys_mem_access_prot_allowed(struct file *file, unsigned long pfn,
> > unsigned long size, pgprot_t *vma_prot)
> > {
> > enum page_cache_mode pcm = _PAGE_CACHE_MODE_WB;
> >
> > + if (!pat_enabled())
> > + return 1;
> > +
>
> Shouldn't this test for pat_enabled() (perhaps only if
> CONFIG_STRICT_DEVMEM is set) and continue with the rest of the function
> otherwise?
No because, per above, the check is here to short-circuit the rest of
phys_mem_access_prot_allowed() when PAT is disabled.
I will add some notes to the changelog to save the next person from
needing to find the history here.
I found it interesting that Venki suggested that the duplicated
"range_is_allowed()" be cleaned up back in 2008 [4], so this is a
cleanup 17 years (almost to the day) in the making:
Commit 0124cecfc85a ("x86, PAT: disable /dev/mem mmap RAM with PAT") [4]
next prev parent reply other threads:[~2025-04-16 21:26 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-11 1:22 [PATCH v2 0/3] Restrict devmem for confidential VMs Dan Williams
2025-04-11 1:22 ` [PATCH v2 1/3] x86/devmem: Remove duplicate range_is_allowed() definition Dan Williams
2025-04-14 18:17 ` Naveen N Rao
2025-04-16 21:25 ` Dan Williams [this message]
2025-04-17 7:28 ` Naveen N Rao
2025-04-17 18:27 ` Dan Williams
2025-04-19 9:09 ` Naveen N Rao
2025-04-11 1:22 ` [PATCH v2 2/3] devmem: Block mmap access when read/write access is restricted Dan Williams
2025-04-11 2:32 ` Kees Cook
2025-04-11 4:59 ` Dan Williams
2025-04-11 15:38 ` Dave Hansen
2025-04-11 21:48 ` Dan Williams
2025-04-11 1:22 ` [PATCH v2 3/3] x86/devmem: Restrict /dev/mem access for potentially unaccepted memory by default Dan Williams
2025-04-14 18:22 ` Naveen N Rao
2025-04-16 21:30 ` Dan Williams
2025-04-14 10:56 ` [PATCH v2 0/3] Restrict devmem for confidential VMs Nikolay Borisov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6800205d86e73_71fe294e4@dwillia2-xfh.jf.intel.com.notmuch \
--to=dan.j.williams@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=naveen@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®