mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "tip-bot2 for Thomas Weißschuh" <tip-bot2@linutronix.de>
To: linux-tip-commits@vger.kernel.org
Cc: Nam Cao <namcao@linutronix.de>,
	thomas.weissschuh@linutronix.de,
	Thomas Gleixner <tglx@kernel.org>,
	x86@kernel.org, linux-kernel@vger.kernel.org
Subject: [tip: timers/vdso] vdso/datastore: Allow prefaulting by mlockall()
Date: Tue, 07 Jul 2026 21:54:51 -0000	[thread overview]
Message-ID: <178346129159.744054.975961566705759196.tip-bot2@tip-bot2> (raw)
In-Reply-To: <20260630-vdso-mlockall-v4-5-6c93708ce723@linutronix.de>

The following commit has been merged into the timers/vdso branch of tip:

Commit-ID:     c27e727c9a60e6303088a956eea45b6b5c02cef3
Gitweb:        https://git.kernel.org/tip/c27e727c9a60e6303088a956eea45b6b5c02cef3
Author:        Thomas Weißschuh <thomas.weissschuh@linutronix.de>
AuthorDate:    Tue, 30 Jun 2026 09:31:59 +02:00
Committer:     Thomas Gleixner <tglx@kernel.org>
CommitterDate: Tue, 07 Jul 2026 23:52:52 +02:00

vdso/datastore: Allow prefaulting by mlockall()

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 <namcao@linutronix.de>
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Tested-by: Nam Cao <namcao@linutronix.de>
Link: https://patch.msgid.link/20260630-vdso-mlockall-v4-5-6c93708ce723@linutronix.de
---
 lib/vdso/datastore.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/vdso/datastore.c b/lib/vdso/datastore.c
index 0ca4396..d7ab077 100644
--- a/lib/vdso/datastore.c
+++ b/lib/vdso/datastore.c
@@ -125,7 +125,7 @@ const struct vm_special_mapping vdso_vvar_mapping = {
 struct vm_area_struct *vdso_install_vvar_mapping(struct mm_struct *mm, unsigned long addr)
 {
 	return _install_special_mapping(mm, addr, VDSO_NR_PAGES * PAGE_SIZE,
-					VM_READ | VM_MAYREAD | VM_IO | VM_DONTDUMP |
+					VM_READ | VM_MAYREAD | VM_DONTDUMP |
 					VM_MIXEDMAP | VM_SEALED_SYSMAP,
 					&vdso_vvar_mapping);
 }

  reply	other threads:[~2026-07-07 21:54 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-30  7:31 [PATCH v4 0/6] " Thomas Weißschuh
2026-06-30  7:31 ` [PATCH v4 1/6] vdso/datastore: Rename data pages variable Thomas Weißschuh
2026-07-07 21:54   ` [tip: timers/vdso] " tip-bot2 for Thomas Weißschuh
2026-06-30  7:31 ` [PATCH v4 2/6] vdso/datastore: Map pages in terms of the faults pgoff Thomas Weißschuh
2026-07-07 21:54   ` [tip: timers/vdso] " tip-bot2 for Thomas Weißschuh
2026-06-30  7:31 ` [PATCH v4 3/6] vdso/datastore: Map zeroed pages for unavailable data Thomas Weißschuh
2026-07-07 21:54   ` [tip: timers/vdso] " tip-bot2 for Thomas Weißschuh
2026-06-30  7:31 ` [PATCH v4 4/6] vdso/datastore: Explicitly prevent remote access to timens vvar page Thomas Weißschuh
2026-07-07 21:54   ` [tip: timers/vdso] " tip-bot2 for Thomas Weißschuh
2026-06-30  7:31 ` [PATCH v4 5/6] vdso/datastore: Allow prefaulting by mlockall() Thomas Weißschuh
2026-07-07 21:54   ` tip-bot2 for Thomas Weißschuh [this message]
2026-06-30  7:32 ` [PATCH v4 6/6] vdso/datastore: Simplify the mapping logic for VDSO_TIME_PAGE_OFFSET Thomas Weißschuh
2026-07-07 21:54   ` [tip: timers/vdso] " tip-bot2 for Thomas Weißschuh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=178346129159.744054.975961566705759196.tip-bot2@tip-bot2 \
    --to=tip-bot2@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tip-commits@vger.kernel.org \
    --cc=namcao@linutronix.de \
    --cc=tglx@kernel.org \
    --cc=thomas.weissschuh@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®