From: Thomas Weißschuh <hidden> Date: 2024-10-10 07:02:01
Historically each architecture defined their own datapage to store the
VDSO data. This stands in contrast to the generic nature of the VDSO
code itself.
We plan to introduce a generic framework for the management of the VDSO
data storage that can be used by all architectures and which works
together with the existing generic VDSO code.
Before that is possible align the different architectures by
standardizing on the existing generic infrastructure and moving things
out of the VDSO data page which does not belong there.
Patches 1- 2: csky
Patch 3: s390
Patches 4- 5: arm64
Patch 6: riscv
Patch 7: arm
Patch 8: LoongArch
Patch 9: MIPS
Patches 10-20: x86
Patches 21-27: powerpc
Patch 28: Renamings to avoid a name clash with the new code.
These patches are intended to be merged via the tip tree,
so the following patches can be based on a unified base.
The queue, including the full generic storage, is available at
git://git.kernel.org/pub/scm/linux/kernel/git/thomas.weissschuh/linux.git vdso/store
Signed-off-by: Thomas Weißschuh <redacted>
---
Nam Cao (1):
vdso: Rename struct arch_vdso_data to arch_vdso_time_data
Thomas Weißschuh (27):
csky/vdso: Remove gettimeofday() and friends from VDSO
csky/vdso: Remove arch_vma_name()
s390/vdso: Drop LBASE_VDSO
arm64: vdso: Drop LBASE_VDSO
arm64: vdso: Use only one single vvar mapping
riscv: vdso: Use only one single vvar mapping
arm: vdso: Remove assembly for datapage access
LoongArch: vDSO: Use vdso/datapage.h to access vDSO data
MIPS: vdso: Avoid name conflict around "vdso_data"
x86/mm/mmap: Remove arch_vma_name()
x86: vdso: Use __arch_get_vdso_data() to access vdso data
x86: vdso: Place vdso_data at beginning of vvar page
x86: vdso: Access rng data from kernel without vvar
x86: vdso: Allocate vvar page from C code
x86: vdso: Access timens vdso data without vvar.h
x86: vdso: Access rng vdso data without vvar.h
x86: vdso: Move the rng offset to vsyscall.h
x86: vdso: Access vdso data without vvar.h
x86: vdso: Delete vvar.h
x86: vdso: Split virtual clock pages into dedicated mapping
powerpc: vdso: Remove offset comment from 32bit vdso_arch_data
powerpc: procfs: Propagate error of remap_pfn_range()
powerpc/pseries/lparcfg: Fix printing of system_active_processors
powerpc/pseries/lparcfg: Use num_possible_cpus() for potential processors
powerpc: Add kconfig option for the systemcfg page
powerpc: Split systemcfg data out of vdso data page
powerpc: Split systemcfg struct definitions out from vdso
arch/Kconfig | 2 +-
arch/arm/include/asm/vdso/gettimeofday.h | 4 +-
arch/arm/vdso/Makefile | 2 +-
arch/arm/vdso/datapage.S | 16 ---
arch/arm/vdso/vdso.lds.S | 3 +-
arch/arm64/include/asm/vdso.h | 9 +-
arch/arm64/kernel/vdso.c | 43 +++-----
arch/arm64/kernel/vdso/vdso.lds.S | 2 +-
arch/arm64/kernel/vdso32/vdso.lds.S | 2 +-
arch/csky/Kconfig | 4 -
arch/csky/include/asm/vdso/clocksource.h | 9 --
arch/csky/include/asm/vdso/gettimeofday.h | 114 ---------------------
arch/csky/include/asm/vdso/processor.h | 12 ---
arch/csky/include/asm/vdso/vsyscall.h | 22 ----
arch/csky/kernel/vdso.c | 31 +-----
arch/csky/kernel/vdso/Makefile | 1 -
arch/csky/kernel/vdso/vdso.lds.S | 4 -
arch/csky/kernel/vdso/vgettimeofday.c | 30 ------
arch/loongarch/include/asm/vdso/getrandom.h | 3 +-
arch/loongarch/include/asm/vdso/gettimeofday.h | 4 +-
arch/loongarch/include/asm/vdso/vdso.h | 18 +---
arch/loongarch/kernel/asm-offsets.c | 9 ++
arch/loongarch/vdso/vdso.lds.S | 8 +-
arch/loongarch/vdso/vgetcpu.c | 2 +-
arch/mips/vdso/genvdso.c | 4 +-
arch/powerpc/Kconfig | 8 ++
arch/powerpc/include/asm/systemcfg.h | 52 ++++++++++
arch/powerpc/include/asm/vdso_datapage.h | 61 +----------
arch/powerpc/kernel/proc_powerpc.c | 37 +++++--
arch/powerpc/kernel/setup-common.c | 5 +-
arch/powerpc/kernel/smp.c | 11 +-
arch/powerpc/kernel/time.c | 4 +
arch/powerpc/kernel/vdso.c | 20 ----
arch/powerpc/platforms/powernv/smp.c | 5 +-
arch/powerpc/platforms/pseries/hotplug-cpu.c | 5 +-
arch/powerpc/platforms/pseries/lparcfg.c | 5 +-
arch/riscv/Kconfig | 2 +-
.../riscv/include/asm/vdso/{data.h => time_data.h} | 8 +-
arch/riscv/kernel/sys_hwprobe.c | 2 +-
arch/riscv/kernel/vdso.c | 52 +++-------
arch/riscv/kernel/vdso/hwprobe.c | 4 +-
arch/s390/Kconfig | 2 +-
arch/s390/include/asm/vdso.h | 3 -
arch/s390/include/asm/vdso/data.h | 12 ---
arch/s390/include/asm/vdso/time_data.h | 12 +++
arch/s390/kernel/vdso32/vdso32.lds.S | 2 +-
arch/s390/kernel/vdso64/vdso64.lds.S | 2 +-
arch/x86/entry/vdso/vdso-layout.lds.S | 20 ++--
arch/x86/entry/vdso/vma.c | 87 ++++++++++------
arch/x86/include/asm/vdso/getrandom.h | 10 +-
arch/x86/include/asm/vdso/gettimeofday.h | 12 ++-
arch/x86/include/asm/vdso/vsyscall.h | 14 ++-
arch/x86/include/asm/vvar.h | 71 -------------
arch/x86/kernel/vmlinux.lds.S | 23 -----
arch/x86/mm/mmap.c | 5 -
arch/x86/tools/relocs.c | 1 -
include/vdso/datapage.h | 8 +-
57 files changed, 295 insertions(+), 628 deletions(-)
---
base-commit: 8cf0b93919e13d1e8d4466eb4080a4c4d9d66d7b
change-id: 20241009-vdso-generic-base-63066fd474b5
Best regards,
--
Thomas Weißschuh [off-list ref]
From: Thomas Weißschuh <hidden> Date: 2024-10-10 07:02:01
The time-related VDSO functionality was introduced in 2021 in
commit 87f3248cdb9a ("csky: Reconstruct VDSO framework") and
commit 0d3b051adbb7 ("csky: Add VDSO with GENERIC_GETTIMEOFDAY, GENERIC_TIME_VSYSCALL, HAVE_GENERIC_VDSO").
However the corresponding aux-vector entry AT_SYSINFO_EHDR was never
wired up, making these functions impossible to test or use.
The VDSO itself is kept as it also provides rt_sigreturn which is
exposed differently to userspace.
Signed-off-by: Thomas Weißschuh <redacted>
---
arch/csky/Kconfig | 4 --
arch/csky/include/asm/vdso/clocksource.h | 9 ---
arch/csky/include/asm/vdso/gettimeofday.h | 114 ------------------------------
arch/csky/include/asm/vdso/processor.h | 12 ----
arch/csky/include/asm/vdso/vsyscall.h | 22 ------
arch/csky/kernel/vdso.c | 24 +------
arch/csky/kernel/vdso/Makefile | 1 -
arch/csky/kernel/vdso/vdso.lds.S | 4 --
arch/csky/kernel/vdso/vgettimeofday.c | 30 --------
9 files changed, 2 insertions(+), 218 deletions(-)
@@ -5,7 +5,6 @@ include $(srctree)/lib/vdso/Makefile# Symbols present in the vdsovdso-syms+=rt_sigreturn-vdso-syms+=vgettimeofday# Files to link into the vdsoobj-vdso=$(patsubst%,%.o,$(vdso-syms))note.o
From: Thomas Weißschuh <hidden> Date: 2024-10-10 07:02:02
All callers of arch_vma_name() also get the name via vm_ops, which for
these VMAs will use the name from 'struct vma_special_mapping'.
Therefore the custom implementation is unnecessary and can be removed in
favor of the default implementation from kernel/signal.c.
Signed-off-by: Thomas Weißschuh <redacted>
---
arch/csky/kernel/vdso.c | 7 -------
1 file changed, 7 deletions(-)
From: Thomas Weißschuh <hidden> Date: 2024-10-10 07:02:03
This constant is always "0", providing no value and making the logic
harder to understand.
Also prepare for a consolidation of the vdso linkerscript logic by
aligning it with other architectures.
Signed-off-by: Thomas Weißschuh <redacted>
---
arch/s390/include/asm/vdso.h | 3 ---
arch/s390/kernel/vdso32/vdso32.lds.S | 2 +-
arch/s390/kernel/vdso64/vdso64.lds.S | 2 +-
3 files changed, 2 insertions(+), 5 deletions(-)
From: Thomas Weißschuh <hidden> Date: 2024-10-10 07:02:04
The vvar mapping is the same for all processes. Use a single mapping to
simplify the logic and align it with the other architectures.
In addition this will enable the move of the vvar handling into generic code.
Signed-off-by: Thomas Weißschuh <redacted>
---
arch/arm64/kernel/vdso.c | 43 +++++++++++++------------------------------
1 file changed, 13 insertions(+), 30 deletions(-)
From: Thomas Weißschuh <hidden> Date: 2024-10-10 07:02:04
This constant is always "0", providing no value and making the logic
harder to understand.
Also prepare for a consolidation of the vdso linkerscript logic by
aligning it with other architectures.
Signed-off-by: Thomas Weißschuh <redacted>
---
arch/arm64/include/asm/vdso.h | 9 +--------
arch/arm64/kernel/vdso/vdso.lds.S | 2 +-
arch/arm64/kernel/vdso32/vdso.lds.S | 2 +-
3 files changed, 3 insertions(+), 10 deletions(-)
From: Thomas Weißschuh <hidden> Date: 2024-10-10 07:02:05
The vvar mapping is the same for all processes. Use a single mapping to
simplify the logic and align it with the other architectures.
In addition this will enable the move of the vvar handling into generic code.
Signed-off-by: Thomas Weißschuh <redacted>
---
arch/riscv/kernel/vdso.c | 52 ++++++++++++++++--------------------------------
1 file changed, 17 insertions(+), 35 deletions(-)
From: Thomas Weißschuh <hidden> Date: 2024-10-10 07:02:05
vdso/datapage.h provides a hidden declaration for _vdso_data.
When using it the compiler will automatically generate PC-relative
accesses which avoids the need for a custom assembly-based accessor.
Signed-off-by: Thomas Weißschuh <redacted>
---
arch/arm/include/asm/vdso/gettimeofday.h | 4 +---
arch/arm/vdso/Makefile | 2 +-
arch/arm/vdso/datapage.S | 16 ----------------
arch/arm/vdso/vdso.lds.S | 3 ++-
4 files changed, 4 insertions(+), 21 deletions(-)
From: Thomas Weißschuh <hidden> Date: 2024-10-10 07:02:06
The generic vdso/datapage.h declares a symbol named "vdso_data".
Avoid a conflict by renaming the identically named variable in genvdso.c.
Signed-off-by: Thomas Weißschuh <redacted>
---
arch/mips/vdso/genvdso.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
From: Thomas Weißschuh <hidden> Date: 2024-10-10 07:02:06
vdso/datapage.h provides symbols and functions to ease the access to
shared vDSO data from both the kernel and the vDSO.
Make use of it to simplify the current code and also prepare for further
changes unifying the vDSO data storage between architectures.
Signed-off-by: Thomas Weißschuh <redacted>
---
arch/loongarch/include/asm/vdso/getrandom.h | 3 +--
arch/loongarch/include/asm/vdso/gettimeofday.h | 4 ++--
arch/loongarch/include/asm/vdso/vdso.h | 18 +-----------------
arch/loongarch/kernel/asm-offsets.c | 9 +++++++++
arch/loongarch/vdso/vdso.lds.S | 8 +++++++-
arch/loongarch/vdso/vgetcpu.c | 2 +-
6 files changed, 21 insertions(+), 23 deletions(-)
From: Thomas Weißschuh <hidden> Date: 2024-10-10 07:02:07
This function does not contain any logic, delete it so the equivalent
weak definition from kernel/signal.c is used instead.
Signed-off-by: Thomas Weißschuh <redacted>
---
arch/x86/mm/mmap.c | 5 -----
1 file changed, 5 deletions(-)
From: Thomas Weißschuh <hidden> Date: 2024-10-10 07:02:08
The implementation details of the vdso_data access will change.
Prepare for that by using the existing helper function.
Signed-off-by: Thomas Weißschuh <redacted>
---
arch/x86/include/asm/vdso/getrandom.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
From: Thomas Weißschuh <hidden> Date: 2024-10-10 07:02:08
The offset of the vdso_data only has historic reasons, as back then
other vvars also existed and offset 0 was already used.
(See commit 8c49d9a74bac ("x86-64: Clean up vdso/kernel shared variables"))
Over time most other vvars got removed and offset 0 is free again.
Moving vdso_data to the beginning of the vvar page aligns x86 with other
architectures and opens up the way for the removal of the custom x86
vvar machinery.
Signed-off-by: Thomas Weißschuh <redacted>
---
arch/x86/include/asm/vvar.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Thomas Weißschuh <hidden> Date: 2024-10-10 07:02:09
Remove the usage of the vvar _vdso_rng_data from the kernel-space code,
as the x86 vvar machinery is about to be removed.
The definition of the structure is unnecessary, as the data lives in a
page pre-allocated by the linker anyways.
The vdso user-space access to the rng data will be switched soon.
DEFINE_VVAR_SINGLE() is now unused. It will be removed later togehter
with the rest of vvar.h.
Signed-off-by: Thomas Weißschuh <redacted>
---
arch/x86/entry/vdso/vma.c | 1 -
arch/x86/include/asm/vdso/vsyscall.h | 2 +-
arch/x86/include/asm/vvar.h | 4 +++-
3 files changed, 4 insertions(+), 3 deletions(-)
From: Thomas Weißschuh <hidden> Date: 2024-10-10 07:02:11
The vdso_data is at the start of the timens page.
Make use of this invariant to remove the usage of vvar.h.
This also matches the logic for the pvclock and hvclock pages.
Signed-off-by: Thomas Weißschuh <redacted>
---
arch/x86/entry/vdso/vdso-layout.lds.S | 6 ------
arch/x86/include/asm/vdso/getrandom.h | 2 +-
arch/x86/include/asm/vdso/gettimeofday.h | 6 ++++--
3 files changed, 5 insertions(+), 9 deletions(-)
From: Thomas Weißschuh <hidden> Date: 2024-10-10 07:02:12
The vdso_rng_data is at a well-known offset in the vvar page.
Make use of this invariant to remove the usage of vvar.h.
Signed-off-by: Thomas Weißschuh <redacted>
---
arch/x86/entry/vdso/vdso-layout.lds.S | 2 ++
arch/x86/include/asm/vdso/getrandom.h | 8 ++++----
arch/x86/include/asm/vvar.h | 5 -----
3 files changed, 6 insertions(+), 9 deletions(-)
From: Thomas Weißschuh <hidden> Date: 2024-10-10 07:02:13
vvar.h will go away, so move the last useful bit into vsyscall.h.
Signed-off-by: Thomas Weißschuh <redacted>
---
arch/x86/entry/vdso/vdso-layout.lds.S | 1 +
arch/x86/include/asm/vdso/vsyscall.h | 3 ++-
arch/x86/include/asm/vvar.h | 2 --
3 files changed, 3 insertions(+), 3 deletions(-)
From: Thomas Weißschuh <hidden> Date: 2024-10-10 07:02:14
The vdso_data is at the start of the vvar page.
Make use of this invariant to remove the usage of vvar.h.
This also matches the logic for the timens data.
Signed-off-by: Thomas Weißschuh <redacted>
---
arch/x86/entry/vdso/vdso-layout.lds.S | 5 -----
arch/x86/include/asm/vdso/gettimeofday.h | 6 +++---
2 files changed, 3 insertions(+), 8 deletions(-)
From: Thomas Weißschuh <hidden> Date: 2024-10-10 07:02:15
All users have been removed.
Signed-off-by: Thomas Weißschuh <redacted>
---
arch/x86/include/asm/vvar.h | 66 ---------------------------------------------
1 file changed, 66 deletions(-)
@@ -1,66 +0,0 @@-/* SPDX-License-Identifier: GPL-2.0-only */-/*- * vvar.h: Shared vDSO/kernel variable declarations- * Copyright (c) 2011 Andy Lutomirski- *- * A handful of variables are accessible (read-only) from userspace- * code in the vsyscall page and the vdso. They are declared here.- * Some other file must define them with DEFINE_VVAR.- *- * In normal kernel code, they are used like any other variable.- * In user code, they are accessed through the VVAR macro.- *- * These variables live in a page of kernel data that has an extra RO- * mapping for userspace. Each variable needs a unique offset within- * that page; specify that offset with the DECLARE_VVAR macro. (If- * you mess up, the linker will catch it.)- */--#ifndef _ASM_X86_VVAR_H-#define _ASM_X86_VVAR_H--#ifdef EMIT_VVAR-/*- * EMIT_VVAR() is used by the kernel linker script to put vvars in the- * right place. Also, it's used by kernel code to import offsets values.- */-#define DECLARE_VVAR(offset, type, name) \- EMIT_VVAR(name, offset)-#define DECLARE_VVAR_SINGLE(offset, type, name) \- EMIT_VVAR(name, offset)--#else--extern char __vvar_page;--#define DECLARE_VVAR(offset, type, name) \- extern type vvar_ ## name[CS_BASES] \- __attribute__((visibility("hidden"))); \- extern type timens_ ## name[CS_BASES] \- __attribute__((visibility("hidden"))); \--#define DECLARE_VVAR_SINGLE(offset, type, name) \- extern type vvar_ ## name \- __attribute__((visibility("hidden"))); \--#define VVAR(name) (vvar_ ## name)-#define TIMENS(name) (timens_ ## name)--#define DEFINE_VVAR(type, name) \- type name[CS_BASES] \- __attribute__((section(".vvar_" #name), aligned(16))) __visible--#define DEFINE_VVAR_SINGLE(type, name) \- type name \- __attribute__((section(".vvar_" #name), aligned(16))) __visible--#endif--/* DECLARE_VVAR(offset, type, name) */--DECLARE_VVAR(0, struct vdso_data, _vdso_data)--#undef DECLARE_VVAR-#undef DECLARE_VVAR_SINGLE--#endif
From: Thomas Weißschuh <hidden> Date: 2024-10-10 07:02:16
The generic vdso data storage can not handle the special pvclock and
hvclock pages. Split them into their own mapping, so the other vdso
storage can be migrated to the generic code.
Signed-off-by: Thomas Weißschuh <redacted>
---
arch/x86/entry/vdso/vdso-layout.lds.S | 10 +++--
arch/x86/entry/vdso/vma.c | 70 ++++++++++++++++++++++++++---------
arch/x86/include/asm/vdso/vsyscall.h | 5 +++
3 files changed, 64 insertions(+), 21 deletions(-)
From: Thomas Weißschuh <hidden> Date: 2024-10-10 07:02:17
This offset was copy-pasted from the systemcfg structure.
It has no meaning for the 32bit VDSO.
Signed-off-by: Thomas Weißschuh <redacted>
---
arch/powerpc/include/asm/vdso_datapage.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Thomas Weißschuh <hidden> Date: 2024-10-10 07:02:18
If the operation fails and userspace is unaware it will access unmapped
memory, crashing the process.
Signed-off-by: Thomas Weißschuh <redacted>
---
arch/powerpc/kernel/proc_powerpc.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
From: Thomas Weißschuh <hidden> Date: 2024-10-10 07:02:19
When printing the information "system_active_processors", the variable
partition_potential_processors is used instead of
partition_active_processors. The wrong value is displayed.
Use partition_active_processors instead.
Signed-off-by: Thomas Weißschuh <redacted>
---
arch/powerpc/platforms/pseries/lparcfg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
@@ -553,7 +553,7 @@ static int pseries_lparcfg_data(struct seq_file *m, void *v)}else{/* non SPLPAR case */seq_printf(m,"system_active_processors=%d\n",-partition_potential_processors);+partition_active_processors);seq_printf(m,"system_potential_processors=%d\n",partition_potential_processors);
From: Thomas Weißschuh <hidden> Date: 2024-10-10 07:02:19
The systemcfg processorCount variable tracks currently online variables,
not possible ones, so the stored value is wrong.
The code preferably tries to use the ibm,lrdr-capacity field 4 which
"represents the maximum number of processors that the guest can have."
Switch from processorCount to the better matching num_possible_cpus().
Signed-off-by: Thomas Weißschuh <redacted>
---
arch/powerpc/platforms/pseries/lparcfg.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
From: Thomas Weißschuh <hidden> Date: 2024-10-10 07:02:20
The systemcfg page through procfs is only a backwards-compatible
interface for very old applications.
Make it possible to be disabled.
This also creates a convenient config #define to guard any accesses to
the systemcfg page.
Signed-off-by: Thomas Weißschuh <redacted>
---
arch/powerpc/Kconfig | 8 ++++++++
arch/powerpc/kernel/proc_powerpc.c | 4 ++--
2 files changed, 10 insertions(+), 2 deletions(-)
@@ -1298,6 +1298,14 @@ config MODULES_SIZEendmenu+configPPC64_PROC_SYSTEMCFG+def_booly+depends onPPC64&&PROC_FS+help+Thisoptionenablesthepresenceof/proc/ppc64/systemcfgthrough+whichthesystemcfgpagecanbeaccessed.+Thisinterfaceonlyexistsforbackwards-compatibility.+ifPPC64# This value must have zeroes in the bottom 60 bits otherwise lots will breakconfigPAGE_OFFSET
From: Thomas Weißschuh <hidden> Date: 2024-10-10 07:02:21
The systemcfg data only has minimal overlap with the vdso data.
Splitting the two avoids mapping the implementation-defined vdso data
into /proc/ppc64/systemcfg.
It is also a preparation for the standardization of vdso data storage.
The only field actually used by both systemcfg and vdso is
tb_ticks_per_sec and it is only changed once during time_init().
Initialize it in both structures there.
Signed-off-by: Thomas Weißschuh <redacted>
---
arch/powerpc/include/asm/vdso_datapage.h | 32 ++++++----------------------
arch/powerpc/kernel/proc_powerpc.c | 25 +++++++++++++++++++++-
arch/powerpc/kernel/setup-common.c | 4 +++-
arch/powerpc/kernel/smp.c | 10 +++++----
arch/powerpc/kernel/time.c | 3 +++
arch/powerpc/kernel/vdso.c | 20 -----------------
arch/powerpc/platforms/powernv/smp.c | 4 +++-
arch/powerpc/platforms/pseries/hotplug-cpu.c | 4 +++-
8 files changed, 48 insertions(+), 54 deletions(-)
@@ -1186,8 +1186,8 @@ int generic_cpu_disable(void)return-EBUSY;set_cpu_online(cpu,false);-#ifdef CONFIG_PPC64-vdso_data->processorCount--;+#ifdef CONFIG_PPC64_PROC_SYSTEMCFG+systemcfg->processorCount--;#endif/* Update affinity of all IRQs previously aimed at this CPU */irq_migrate_all_off_this_cpu();
@@ -951,6 +951,9 @@ void __init time_init(void)}vdso_data->tb_ticks_per_sec=tb_ticks_per_sec;+#ifdef CONFIG_PPC64_PROC_SYSTEMCFG+systemcfg->tb_ticks_per_sec=tb_ticks_per_sec;+#endif/* initialise and enable the large decrementer (if we have one) */set_decrementer_max();
From: Thomas Weißschuh <hidden> Date: 2024-10-10 07:02:22
From: Nam Cao <redacted>
The struct arch_vdso_data is only about vdso time data. So rename it to
arch_vdso_time_data to make it obvious.
Non time-related data will be migrated out of these structs soon.
Signed-off-by: Nam Cao <redacted>
---
arch/Kconfig | 2 +-
arch/riscv/Kconfig | 2 +-
arch/riscv/include/asm/vdso/{data.h => time_data.h} | 8 ++++----
arch/riscv/kernel/sys_hwprobe.c | 2 +-
arch/riscv/kernel/vdso/hwprobe.c | 4 ++--
arch/s390/Kconfig | 2 +-
arch/s390/include/asm/vdso/data.h | 12 ------------
arch/s390/include/asm/vdso/time_data.h | 12 ++++++++++++
include/vdso/datapage.h | 8 ++++----
9 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/arch/riscv/include/asm/vdso/data.h b/arch/riscv/include/asm/vdso/time_data.hsimilarity index 71%rename from arch/riscv/include/asm/vdso/data.hrename to arch/riscv/include/asm/vdso/time_data.hindex dc2f76f58b7632f0392af6aaf475076203f1a54a..dfa65228999bed41dfd6c5e36cb678e1e055eec8 100644--- a/arch/riscv/include/asm/vdso/data.h+++ b/arch/riscv/include/asm/vdso/time_data.h
@@ -1,12 +1,12 @@/* SPDX-License-Identifier: GPL-2.0 */-#ifndef __RISCV_ASM_VDSO_DATA_H-#define __RISCV_ASM_VDSO_DATA_H+#ifndef __RISCV_ASM_VDSO_TIME_DATA_H+#define __RISCV_ASM_VDSO_TIME_DATA_H#include<linux/types.h>#include<vdso/datapage.h>#include<asm/hwprobe.h>-structarch_vdso_data{+structarch_vdso_time_data{/* Stash static answers to the hwprobe queries when all CPUs are selected. */__u64all_cpu_hwprobe_values[RISCV_HWPROBE_MAX_KEY+1];
On Thu, Oct 10, 2024 at 09:01:30AM +0200, Thomas Weißschuh wrote:
From: Nam Cao <redacted>
The struct arch_vdso_data is only about vdso time data. So rename it to
arch_vdso_time_data to make it obvious.
Non time-related data will be migrated out of these structs soon.
Signed-off-by: Nam Cao <redacted>
---
arch/Kconfig | 2 +-
arch/riscv/Kconfig | 2 +-
arch/riscv/include/asm/vdso/{data.h => time_data.h} | 8 ++++----
arch/riscv/kernel/sys_hwprobe.c | 2 +-
arch/riscv/kernel/vdso/hwprobe.c | 4 ++--
arch/s390/Kconfig | 2 +-
arch/s390/include/asm/vdso/data.h | 12 ------------
arch/s390/include/asm/vdso/time_data.h | 12 ++++++++++++
include/vdso/datapage.h | 8 ++++----
9 files changed, 26 insertions(+), 26 deletions(-)
On Thu, Oct 10, 2024 at 09:01:05AM +0200, Thomas Weißschuh wrote:
This constant is always "0", providing no value and making the logic
harder to understand.
Also prepare for a consolidation of the vdso linkerscript logic by
aligning it with other architectures.
Signed-off-by: Thomas Weißschuh <redacted>
---
arch/s390/include/asm/vdso.h | 3 ---
arch/s390/kernel/vdso32/vdso32.lds.S | 2 +-
arch/s390/kernel/vdso64/vdso64.lds.S | 2 +-
3 files changed, 2 insertions(+), 5 deletions(-)
From: Will Deacon <will@kernel.org> Date: 2024-10-28 18:02:04
On Thu, Oct 10, 2024 at 09:01:06AM +0200, Thomas Weißschuh wrote:
This constant is always "0", providing no value and making the logic
harder to understand.
Also prepare for a consolidation of the vdso linkerscript logic by
aligning it with other architectures.
Signed-off-by: Thomas Weißschuh <redacted>
---
arch/arm64/include/asm/vdso.h | 9 +--------
arch/arm64/kernel/vdso/vdso.lds.S | 2 +-
arch/arm64/kernel/vdso32/vdso.lds.S | 2 +-
3 files changed, 3 insertions(+), 10 deletions(-)
From: Will Deacon <will@kernel.org> Date: 2024-10-28 18:39:49
On Thu, Oct 10, 2024 at 09:01:07AM +0200, Thomas Weißschuh wrote:
The vvar mapping is the same for all processes. Use a single mapping to
simplify the logic and align it with the other architectures.
In addition this will enable the move of the vvar handling into generic code.
Signed-off-by: Thomas Weißschuh <redacted>
---
arch/arm64/kernel/vdso.c | 43 +++++++++++++------------------------------
1 file changed, 13 insertions(+), 30 deletions(-)
I took this for a spin in qemu to double-check that compat and native
tasks can peacefully co-exist while using the vDSO. It all seems ok, so:
Acked-by: Will Deacon <will@kernel.org>
Tested-by: Will Deacon <will@kernel.org>
Will
From: Thomas Gleixner <hidden> Date: 2024-10-30 11:39:48
Folks!
On Thu, Oct 10 2024 at 09:01, Thomas Weißschuh wrote:
Historically each architecture defined their own datapage to store the
VDSO data. This stands in contrast to the generic nature of the VDSO
code itself.
We plan to introduce a generic framework for the management of the VDSO
data storage that can be used by all architectures and which works
together with the existing generic VDSO code.
Before that is possible align the different architectures by
standardizing on the existing generic infrastructure and moving things
out of the VDSO data page which does not belong there.
Patches 1- 2: csky
Patch 3: s390
Patches 4- 5: arm64
Patch 6: riscv
Patch 7: arm
Patch 8: LoongArch
Patch 9: MIPS
Patches 10-20: x86
Patches 21-27: powerpc
Patch 28: Renamings to avoid a name clash with the new code.
As this has been sitting for two weeks now without major comments, I'm
planning to merge that through the tip tree tomorrow.
Thanks,
tglx
Folks!
On Thu, Oct 10 2024 at 09:01, Thomas Weißschuh wrote:
quoted
Historically each architecture defined their own datapage to store the
VDSO data. This stands in contrast to the generic nature of the VDSO
code itself.
We plan to introduce a generic framework for the management of the VDSO
data storage that can be used by all architectures and which works
together with the existing generic VDSO code.
Before that is possible align the different architectures by
standardizing on the existing generic infrastructure and moving things
out of the VDSO data page which does not belong there.
Patches 1- 2: csky
Patch 3: s390
Patches 4- 5: arm64
Patch 6: riscv
Patch 7: arm
Patch 8: LoongArch
Patch 9: MIPS
Patches 10-20: x86
Patches 21-27: powerpc
Patch 28: Renamings to avoid a name clash with the new code.
As this has been sitting for two weeks now without major comments, I'm
planning to merge that through the tip tree tomorrow.
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2024-11-06 07:06:50
Christophe Leroy [off-list ref] writes:
Le 30/10/2024 à 12:39, Thomas Gleixner a écrit :
quoted
Folks!
On Thu, Oct 10 2024 at 09:01, Thomas Weißschuh wrote:
quoted
Historically each architecture defined their own datapage to store the
VDSO data. This stands in contrast to the generic nature of the VDSO
code itself.
We plan to introduce a generic framework for the management of the VDSO
data storage that can be used by all architectures and which works
together with the existing generic VDSO code.
Before that is possible align the different architectures by
standardizing on the existing generic infrastructure and moving things
out of the VDSO data page which does not belong there.
Patches 1- 2: csky
Patch 3: s390
Patches 4- 5: arm64
Patch 6: riscv
Patch 7: arm
Patch 8: LoongArch
Patch 9: MIPS
Patches 10-20: x86
Patches 21-27: powerpc
Patch 28: Renamings to avoid a name clash with the new code.
As this has been sitting for two weeks now without major comments, I'm
planning to merge that through the tip tree tomorrow.
I thought the same, but there actually isn't any conflict at the moment
between the two trees.
Some of Thomas W's later changes to convert arches to generic VDSO
storage do conflict, but they look to be destined for the next merge
window.
cheers
Hello:
This series was applied to riscv/linux.git (fixes)
by Thomas Gleixner [off-list ref]:
On Thu, 10 Oct 2024 09:01:02 +0200 you wrote:
Historically each architecture defined their own datapage to store the
VDSO data. This stands in contrast to the generic nature of the VDSO
code itself.
We plan to introduce a generic framework for the management of the VDSO
data storage that can be used by all architectures and which works
together with the existing generic VDSO code.
[...]
Here is the summary with links:
- [01/28] csky/vdso: Remove gettimeofday() and friends from VDSO
(no matching commit)
- [02/28] csky/vdso: Remove arch_vma_name()
(no matching commit)
- [03/28] s390/vdso: Drop LBASE_VDSO
(no matching commit)
- [04/28] arm64: vdso: Drop LBASE_VDSO
(no matching commit)
- [05/28] arm64: vdso: Use only one single vvar mapping
(no matching commit)
- [06/28] riscv: vdso: Use only one single vvar mapping
https://git.kernel.org/riscv/c/d34b60752fcb
- [07/28] arm: vdso: Remove assembly for datapage access
(no matching commit)
- [08/28] LoongArch: vDSO: Use vdso/datapage.h to access vDSO data
(no matching commit)
- [09/28] MIPS: vdso: Avoid name conflict around "vdso_data"
(no matching commit)
- [10/28] x86/mm/mmap: Remove arch_vma_name()
(no matching commit)
- [11/28] x86: vdso: Use __arch_get_vdso_data() to access vdso data
(no matching commit)
- [12/28] x86: vdso: Place vdso_data at beginning of vvar page
(no matching commit)
- [13/28] x86: vdso: Access rng data from kernel without vvar
(no matching commit)
- [14/28] x86: vdso: Allocate vvar page from C code
(no matching commit)
- [15/28] x86: vdso: Access timens vdso data without vvar.h
(no matching commit)
- [16/28] x86: vdso: Access rng vdso data without vvar.h
(no matching commit)
- [17/28] x86: vdso: Move the rng offset to vsyscall.h
(no matching commit)
- [18/28] x86: vdso: Access vdso data without vvar.h
(no matching commit)
- [19/28] x86: vdso: Delete vvar.h
(no matching commit)
- [20/28] x86: vdso: Split virtual clock pages into dedicated mapping
(no matching commit)
- [21/28] powerpc: vdso: Remove offset comment from 32bit vdso_arch_data
(no matching commit)
- [22/28] powerpc: procfs: Propagate error of remap_pfn_range()
(no matching commit)
- [23/28] powerpc/pseries/lparcfg: Fix printing of system_active_processors
(no matching commit)
- [24/28] powerpc/pseries/lparcfg: Use num_possible_cpus() for potential processors
(no matching commit)
- [25/28] powerpc: Add kconfig option for the systemcfg page
(no matching commit)
- [26/28] powerpc: Split systemcfg data out of vdso data page
(no matching commit)
- [27/28] powerpc: Split systemcfg struct definitions out from vdso
(no matching commit)
- [28/28] vdso: Rename struct arch_vdso_data to arch_vdso_time_data
(no matching commit)
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html