linux-next.git/lib/vdso, branch master

vdso: Rename HAVE_GENERIC_VDSO to VDSO_DATASTORE

2026-07-15T08:49:03+00:00

Over time the meaning of HAVE_GENERIC_VDSO has become off. Today it only controls the availability of the vDSO datastore. Rename the symbol to match its function. Signed-off-by: Thomas Weißschuh Signed-off-by: Thomas Gleixner Reviewed-by: Vincenzo Frascino Reviewed-by: Philippe Mathieu-Daudé Link: https://patch.msgid.link/20260709-vdso-have_generic_vdso-v1-6-d2e1061f268b@linutronix.de

vdso: Automatically select HAVE_GENERIC_VDSO if necessary

2026-07-15T08:49:02+00:00

gettimeofday() and getrandom() in the vDSO require the vDSO datastore. Enable it automatically if either one of them is enabled so the architecture code doesn't need to know this. Signed-off-by: Thomas Weißschuh Signed-off-by: Thomas Gleixner Reviewed-by: Vincenzo Frascino Reviewed-by: Philippe Mathieu-Daudé Link: https://patch.msgid.link/20260709-vdso-have_generic_vdso-v1-4-d2e1061f268b@linutronix.de

vdso/gettimeofday: Verify COMPAT_32BIT_TIME interactions

2026-07-07T21:52:54+00:00

If CONFIG_COMPAT_32BIT_TIME is disabled then the vDSO should not provide any 32-bit time related functionality. Add some build-time validations to make sure the architecture-specific glue satisfies this requirement. Signed-off-by: Thomas Weißschuh Signed-off-by: Thomas Gleixner Reviewed-by: Philippe Mathieu-Daudé Reviewed-by: Arnd Bergmann Link: https://patch.msgid.link/20260702-vdso-compat_32bit_time-v3-9-db9f36d8d432@linutronix.de

vdso/gettimeofday: Validate system call existence for time() and gettimeofday()

2026-07-07T21:52:53+00:00

Not all architectures have the system calls for time() and gettimeofday(). When the system call is missing, the vDSO function should also not be present. Validate that. Signed-off-by: Thomas Weißschuh Signed-off-by: Thomas Gleixner Reviewed-by: Philippe Mathieu-Daudé Reviewed-by: Arnd Bergmann Link: https://patch.msgid.link/20260702-vdso-compat_32bit_time-v3-2-db9f36d8d432@linutronix.de

vdso/datastore: Simplify the mapping logic for VDSO_TIME_PAGE_OFFSET

2026-07-07T21:52:53+00:00

The logic for CONFIG_GENERIC_GETTIMEOFDAY=n and !timens_page is identical now. Use this to simplify the logic a bit. Signed-off-by: Thomas Weißschuh Signed-off-by: Thomas Gleixner Link: https://patch.msgid.link/20260630-vdso-mlockall-v4-6-6c93708ce723@linutronix.de

vdso/datastore: Allow prefaulting by mlockall()

2026-07-07T21:52:52+00:00

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. The data page mapping is now also aligned with the architecture-specific code pages. Some architecture-specific data pages, like the x86 VCLOCK pages, continue to use VM_IO as they are not always mappable. They will require their own special handling later when the general approach has been agreed upon. As a side-effect this will allow GUP on these pages and allow more ways to access the data in them. This is fine, as all data in this mapping is globally visible anyways. Either because it is mapped into all tasks, or in the case of the time namespace pages, can be read from procfs. Regular mlock() would also work, but userspace does not know the boundaries of the vDSO. Reported-by: Nam Cao Signed-off-by: Thomas Weißschuh Signed-off-by: Thomas Gleixner Tested-by: Nam Cao Link: https://patch.msgid.link/20260630-vdso-mlockall-v4-5-6c93708ce723@linutronix.de

vdso/datastore: Explicitly prevent remote access to timens vvar page

2026-07-07T21:52:52+00:00

The fault handler for the timens page does not have access to the target task and therefore can not be invoked remotely. Currently the handler relies on the fact that the vvar mapping is marked as VM_IO and VM_PFNMAP for which the mm core always prevents remote access. However the VM_IO and VM_PFNMAP flags are going to be removed. Add an explicit check to prevent remote access to the mapping. Signed-off-by: Thomas Weißschuh Signed-off-by: Thomas Gleixner Tested-by: Nam Cao Link: https://patch.msgid.link/20260630-vdso-mlockall-v4-4-6c93708ce723@linutronix.de

vdso/datastore: Map zeroed pages for unavailable data

2026-07-07T21:52:52+00:00

mlockall() stops if a page in a VMA is unmappable. As the datastore VMA can contain holes, mlockall() would not process all data pages. Replace the mapping error VM_FAULT_SIGBUS by just mapping the underlying unused and zeroed-out data page. The vDSO will not access these pages in any case and for other userspace these pages have undefined contents. This will allow mlockall() to process all pages within the VMA as soon as VM_IO is removed from the VMA. Signed-off-by: Thomas Weißschuh Signed-off-by: Thomas Gleixner Tested-by: Nam Cao Link: https://patch.msgid.link/20260630-vdso-mlockall-v4-3-6c93708ce723@linutronix.de

vdso/datastore: Map pages in terms of the faults pgoff

2026-07-07T21:52:52+00:00

To support mlockall() on the datapages the VMA can have no holes where inner pages return VM_FAULT_SIGBUS. An upcoming change will avoid these holes by mapping a zeroed pages into these holes. That logic will be simpler when the mapping logic is based on vmf->pgoff instead of the vdso_k_ symbols. Switch to the equivalent vmf->pgoff logic. Signed-off-by: Thomas Weißschuh Signed-off-by: Thomas Gleixner Tested-by: Nam Cao Link: https://patch.msgid.link/20260630-vdso-mlockall-v4-2-6c93708ce723@linutronix.de

vdso/datastore: Rename data pages variable

2026-07-07T21:52:52+00:00

An upcoming change will make this a file-scoped variable, for which it should have a clearer name. Rename the variable to prepare for that. Signed-off-by: Thomas Weißschuh Signed-off-by: Thomas Gleixner Tested-by: Nam Cao Link: https://patch.msgid.link/20260630-vdso-mlockall-v4-1-6c93708ce723@linutronix.de