What it does on PAT (only implementation so far ...) is looking up the
memory type to select the caching mode that can be use.
"sanitize" was IMHO a good fit, because we must make sure that we don't use
the wrong caching mode.
update/setup/... don't make that quite clear. Any other suggestions?
I'm very poor on naming.. :( So far anything seems slightly better than
sanitize to me, as the word "sanitize" is actually also used in memtype.c
for other purpose.. see sanitize_phys().
Sure, one can sanitize a lot of things. Here it's the cachemode/pgrpot,
in the other functions it's an address.
Likely we should just call it pfnmap_X_cachemode()/
Set/update don't really fit for X in case pfnmap_X_cachemode() is a NOP.
pfnmap_setup_cachemode() ? Hm.
+ * @pfn: the start of the pfn range
+ * @size: the size of the pfn range
+ * @prot: the pgprot to sanitize
+ *
+ * Sanitize the given pgprot for a pfn range, for example, adjusting the
+ * cachemode.
+ *
+ * This function cannot fail for a single page, but can fail for multiple
+ * pages.
+ *
+ * Returns 0 on success and -EINVAL on error.
+ */
+int pfnmap_sanitize_pgprot(unsigned long pfn, unsigned long size,
+ pgprot_t *prot);
extern int track_pfn_copy(struct vm_area_struct *dst_vma,
struct vm_area_struct *src_vma, unsigned long *pfn);
extern void untrack_pfn_copy(struct vm_area_struct *dst_vma,
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index fdcf0a6049b9f..b8ae5e1493315 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -1455,7 +1455,9 @@ vm_fault_t vmf_insert_pfn_pmd(struct vm_fault *vmf, pfn_t
pfn, bool write)
return VM_FAULT_OOM;
}
- track_pfn_insert(vma, &pgprot, pfn);
+ if (pfnmap_sanitize_pgprot(pfn_t_to_pfn(pfn), PAGE_SIZE, &pgprot))
+ return VM_FAULT_FALLBACK;
Would "pgtable" leak if it fails? If it's PAGE_SIZE, IIUC it won't ever
trigger, though.
Maybe we could have a "void pfnmap_sanitize_pgprot_pfn(&pgprot, pfn)" to
replace track_pfn_insert() and never fail? Dropping vma ref is definitely
a win already in all cases.
It could be a simple wrapper around pfnmap_sanitize_pgprot(), yes. That's
certainly helpful for the single-page case.
Regarding never failing here: we should check the whole range. We have to
make sure that none of the pages has a memory type / caching mode that is
incompatible with what we setup.
Would it happen in real world?
> > IIUC per-vma registration needs to happen first, which checks for
memtype
conflicts in the first place, or reserve_pfn_range() could already have
failed.
> > Here it's the fault path looking up the memtype, so I would expect
it is
guaranteed all pfns under the same vma is following the verified (and same)
memtype?
The whole point of track_pfn_insert() is that it is used when we *don't*
use reserve_pfn_range()->track_pfn_remap(), no?
track_pfn_remap() would check the whole range that gets mapped, so
track_pfn_insert() user must similarly check the whole range that gets
mapped.
Note that even track_pfn_insert() is already pretty clear on the
intended usage: "called when a _new_ single pfn is established"
--
Cheers,
David / dhildenb
