Re: [PATCH v3 0/6] vdso/datastore: Allow prefaulting by mlockall()

From: David Hildenbrand (Arm)

Date: Tue Jun 02 2026 - 14:46:59 EST


On 5/18/26 11:49, Thomas Weißschuh wrote:
> 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.

GUP also refuses VM_IO, so this change unlocks GUP'ing these pages and using
them for DIRECT_IO etc.

Well, I assume that GUP-fast (no VMA available) would be able to GUP them
already. But mechanisms that don't use GUP-fast would get reliably blocked for now.

I've been wondering for a while, whether the VM_IO for GUP is still required.

IIRC, we want to disallow read/write access that could have side effects through
ptrace, including process_vm_*(). For memory-mapped I/O that might certainly the
case.

With your change, you'd also unlock get_dump_page() on vdso pages.

Is that all ok and desired?

--
Cheers,

David