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 <thomas.weissschuh@linutronix.de>
---
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 <thomas.weissschuh@linutronix.de>

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

Le 30/10/2024 à 12:39, Thomas Gleixner a écrit :
> 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.

To avoid any future conflicts with powerpc tree, I suggest you merge 
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git 
topic/vdso into your tree before applying this series.

Christophe

Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Le 30/10/2024 à 12:39, Thomas Gleixner a écrit :
>> 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.
>
> To avoid any future conflicts with powerpc tree, I suggest you merge 
> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git 
> topic/vdso into your tree before applying this series.

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