Re: [PATCH 04/28] arm64: vdso: Drop LBASE_VDSO

Re: [PATCH 04/28] arm64: vdso: Drop LBASE_VDSO

[Will Deacon]

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

Acked-by: Will Deacon <will@kernel.org>

Will

Re: [PATCH 05/28] arm64: vdso: Use only one single vvar mapping

[Will Deacon]

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

Re: [PATCH 00/28] vdso: Preparations for generic data storage

[Thomas Gleixner]

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

Re: [PATCH 00/28] vdso: Preparations for generic data storage

[Christophe Leroy]

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

Re: [PATCH 00/28] vdso: Preparations for generic data storage

[Michael Ellerman]

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

Re: [PATCH 00/28] vdso: Preparations for generic data storage

[patchwork-bot+linux-riscv]

Hello:

This series was applied to riscv/linux.git (fixes)
by Thomas Gleixner <tglx@linutronix.de>:

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