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

[David Hildenbrand (Arm)]

On 6/3/26 12:10, Thomas Weißschuh wrote:
> 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.

Ok, good!

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

Yes, even for FOLL_FORCE (see below).

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

Yes. But I guess there is this "debugger should not read/write memory with
side-effects thing.

Again, the GUP-fast interaction is a bit confusing, because that should still
succeed.

But debuggers don't use that. So the VM_IO protects that for now.

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

Ah, right.

So we still have

VM_READ | VM_MAYREAD | VM_DONTDUMP | VM_MIXEDMAP ...

So even FOLL_FORCE cannot write to it.

It might be good to document the change (pages can not be GUP'ed, including
being read by ptrace etc). But I agree that it should likely be fine.

-- 
Cheers,

David