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

[Thomas Weißschuh]

On Tue, Jun 02, 2026 at 08:41:31PM +0200, David Hildenbrand (Arm) wrote:
> 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 am not sure about all of the side-effects of GUP.
Userspace is allowed to read this data in any way it wants. It is *not* allowed
to interpret it however, which is obviously not enforcable anyways.
*All* writes from userspace need to be rejected. But those are forbidden via
VMA flags which as far as I can see are respected by GUP.

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

If that restriction goes away, mlockall() would work automatically for the vDSO
data pages, no?

> 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.

There are no side-effects, this is just global shared memory.
(But as mentioned before, writes can not be allowed)
Accesses from other tasks need to be prevented, which is what
patch 4 tries to do based on FAULT_FLAG_REMOTE.

The only data in these pages which is not globally shared and accessible
are the time namespace offsets. But /proc/$PID/timens_offsets is
world-readable anyways.

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

We use VM_DONTDUMP on the VMA, shouldn't that prevent dumping?
Dumping these pages is not a (security) issue, just pointless.

> Is that all ok and desired?

It is not necessarily desired, but shouldn't hurt.


Thomas