On 17.06.25 17:43, David Hildenbrand wrote:
Let's make the kernel a bit less horrible, by removing the
linearity requirement in CoW PFNMAP mappings with
!CONFIG_ARCH_HAS_PTE_SPECIAL. In particular, stop messing with
vma->vm_pgoff in weird ways.
Simply lookup in applicable (i.e., CoW PFNMAP) mappings whether we
have an anon folio.
Nobody should ever try mapping anon folios using PFNs, that just screams
for other possible issues. To be sure, let's sanity-check when inserting
PFNs. Are they really required? Probably not, but it's a good safety net
at least for now.
The runtime overhead should be limited: there is nothing to do for !CoW
mappings (common case), and archs that care about performance
(i.e., GUP-fast) should be supporting CONFIG_ARCH_HAS_PTE_SPECIAL
either way.
Likely the sanity checks added in mm/huge_memory.c are not required for
now, because that code is probably only wired up with
CONFIG_ARCH_HAS_PTE_SPECIAL, but this way is certainly cleaner and
more consistent -- and doesn't really cost us anything in the cases we
really care about.
Signed-off-by: David Hildenbrand <da...@redhat.com>
---
I'm still thinking about this patch here, and will likely send out the
other patches first as a v1, and come back to this one later.
Really, someone mapping random memory using /dev/mem, and then getting
anonymous memory in there is the (nasty) corner case I ignored.
There are rather nasty ways of trying to detect if an anon folio really
fits into a VMA, but I'd like to avoid that.
What I am thinking about right now is that we could, for these special
architectures, simply disallow CoW faults on /dev/mem.
So we would still allow MAP_PRIVATE mappings (e.g., random app opening
/dev/mem using MAP_PRIVATE but never actually writing to that memory),
but the actual CoW faults would fail without pte_special().
Some more thinking to do ...
--
Cheers,
David / dhildenb
