While mlockall() is meant to lock page *memory*, effectively it will
also create and lock the corresponding page table entries.
Latency-sensitive applications expect not to experience any pagefaults
after calling mlockall(). However mlockall() ignores VM_IO mappings,
which is used by the generic vDSO datastore.
While the fault handler itself is very fast, going through the full
pagefault exception handling is much slower, on the order of 20us in a
test machine.

Since the memory behind the datastore mappings is always present and
accessible it is not necessary to use VM_IO for them.

Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
Changes in v3:
- Rebase on v7.1-rc1
- Stop using zero page, which can not be mapped in this way
- Link to v2: https://lore.kernel.org/r/20250901-vdso-mlockall-v2-0-68f5a6f03345@linutronix.de

Changes in v2:
- Stop using nth_page() which is being removed
- Link to v1: https://lore.kernel.org/r/20250812-vdso-mlockall-v1-0-2f49ba7cf819@linutronix.de

---
Thomas Weißschuh (6):
      vdso/datastore: Rename data pages variable
      vdso/datastore: Map pages in terms of the faults pgoff
      vdso/datastore: Map zeroed pages for unavailable data
      vdso/datastore: Explicitly prevent remote access to timens vvar page
      vdso/datastore: Allow prefaulting by mlockall()
      vdso/datastore: Simplify the mapping logic for VDSO_TIME_PAGE_OFFSET

 kernel/time/namespace_vdso.c |  7 ++---
 lib/vdso/datastore.c         | 65 ++++++++++++++++++++------------------------
 2 files changed, 32 insertions(+), 40 deletions(-)
---
base-commit: b0f603a5e7c076c7e424b5a621022b3bec16225b
change-id: 20250721-vdso-mlockall-461bb33205b1

Best regards,
--  
Thomas Weißschuh <thomas.weissschuh@linutronix.de>