| 886653e3 | 03-Mar-2025 |
Anna-Maria Behnsen <[email protected]> |
vdso: Rework struct vdso_time_data and introduce struct vdso_clock
To support multiple PTP clocks, the VDSO data structure needs to be reworked. All clock specific data will end up in struct vdso_cl
vdso: Rework struct vdso_time_data and introduce struct vdso_clock
To support multiple PTP clocks, the VDSO data structure needs to be reworked. All clock specific data will end up in struct vdso_clock and in struct vdso_time_data there will be an array of VDSO clocks.
Now that all preparatory changes are in place:
Split the clock related struct members into a separate struct vdso_clock. Make sure all users are aware, that vdso_time_data is no longer initialized as an array and vdso_clock is now the array inside vdso_data. Remove the vdso_clock define, which mapped it to vdso_time_data for the transition.
Signed-off-by: Anna-Maria Behnsen <[email protected]> Signed-off-by: Nam Cao <[email protected]> Signed-off-by: Thomas Weißschuh <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Link: https://lore.kernel.org/all/[email protected]
show more ...
|
| 97a5a90c | 03-Mar-2025 |
Anna-Maria Behnsen <[email protected]> |
vdso: Move architecture related data before basetime data
Architecture related vdso data is required in the fast path when reading CLOCK_MONOTONIC or CLOCK_REALTIME. At the moment, this information
vdso: Move architecture related data before basetime data
Architecture related vdso data is required in the fast path when reading CLOCK_MONOTONIC or CLOCK_REALTIME. At the moment, this information is located at the end of the vdso_time_data structure, which is a suboptimal cache layout.
Move the architecture specific VDSO data right before the basetime information, which is always required. This change does not have an impact on architectures with CONFIG_ARCH_HAS_VDSO_DATA=n. Architectures, which have it enabled, gain a better cache layout.
Signed-off-by: Anna-Maria Behnsen <[email protected]> Signed-off-by: Nam Cao <[email protected]> Signed-off-by: Thomas Weißschuh <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Link: https://lore.kernel.org/all/[email protected]
show more ...
|
| e15bf9e3 | 03-Mar-2025 |
Anna-Maria Behnsen <[email protected]> |
vdso/helpers: Prepare introduction of struct vdso_clock
To support multiple PTP clocks, the VDSO data structure needs to be reworked. All clock specific data will end up in struct vdso_clock and in
vdso/helpers: Prepare introduction of struct vdso_clock
To support multiple PTP clocks, the VDSO data structure needs to be reworked. All clock specific data will end up in struct vdso_clock and in struct vdso_time_data there will be an array of VDSO clocks. For now, vdso_clock is simply a define which maps vdso_clock to vdso_time_data.
Prepare all functions which need the pointer to the vdso_clock array to work well after the structures get reworked. Replace the struct vdso_time_data pointer with a struct vdso_clock pointer where applicable.
No functional change.
Signed-off-by: Anna-Maria Behnsen <[email protected]> Signed-off-by: Nam Cao <[email protected]> Signed-off-by: Thomas Weißschuh <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Link: https://lore.kernel.org/all/[email protected]
show more ...
|
| a05f14de | 03-Mar-2025 |
Anna-Maria Behnsen <[email protected]> |
vdso/datapage: Define vdso_clock to prepare for multiple PTP clocks
Multiple PTP clocks, which are independent of timekeeping, are required for systems, which utilize PTP for synchronizing e.g. auto
vdso/datapage: Define vdso_clock to prepare for multiple PTP clocks
Multiple PTP clocks, which are independent of timekeeping, are required for systems, which utilize PTP for synchronizing e.g. automation systems independent of clock TAI.
PTP clocks are slow to access, but applications require fast access to the relevant time similar to the regular timekeeping relevant clocks.
To prepare for that the VDSO data representation must be reworked. For transition to the new structure of the vdso, add a define which maps vdso_clock to vdso_data. This will be removed when all users are updated step by step.
No functional change.
Signed-off-by: Anna-Maria Behnsen <[email protected]> Signed-off-by: Nam Cao <[email protected]> Signed-off-by: Thomas Weißschuh <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Link: https://lore.kernel.org/all/[email protected]
show more ...
|
| fa8152ca | 03-Mar-2025 |
Anna-Maria Behnsen <[email protected]> |
vdso: Make vdso_time_data cacheline aligned
vdso_time_data is not cacheline aligned at the moment. When instantiating an array, the start of the second array member is not cache line aligned.
This
vdso: Make vdso_time_data cacheline aligned
vdso_time_data is not cacheline aligned at the moment. When instantiating an array, the start of the second array member is not cache line aligned.
This increases the number of the required cache lines which needs to be read when handling e.g. CLOCK_MONOTONIC_RAW, because the data spawns an extra cache line if the previous data does not end at a cache line boundary.
Therefore make struct vdso_time_data cacheline aligned.
Signed-off-by: Anna-Maria Behnsen <[email protected]> Signed-off-by: Nam Cao <[email protected]> Signed-off-by: Thomas Weißschuh <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Link: https://lore.kernel.org/all/[email protected]
show more ...
|
| 365841e1 | 04-Feb-2025 |
Thomas Weißschuh <[email protected]> |
vdso: Add generic architecture-specific data storage
Some architectures need to expose architecture-specific data to the vDSO.
Enable the generic vDSO storage mechanism to both store and map this d
vdso: Add generic architecture-specific data storage
Some architectures need to expose architecture-specific data to the vDSO.
Enable the generic vDSO storage mechanism to both store and map this data. Some architectures require more than a single page, like LoongArch, so prepare for that usecase, too.
Signed-off-by: Thomas Weißschuh <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Link: https://lore.kernel.org/all/[email protected]
show more ...
|
| 51d6ca37 | 04-Feb-2025 |
Thomas Weißschuh <[email protected]> |
vdso: Add generic random data storage
Extend the generic vDSO data storage with a page for the random state data. The random state data is stored in a dedicated page, as the existing storage page is
vdso: Add generic random data storage
Extend the generic vDSO data storage with a page for the random state data. The random state data is stored in a dedicated page, as the existing storage page is only meant for time-related, time-namespace-aware data. This simplifies to access logic to not need to handle time namespaces anymore and also frees up more space in the time-related page.
In case further generic vDSO data store is required it can be added to the random state page.
Signed-off-by: Thomas Weißschuh <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Link: https://lore.kernel.org/all/[email protected]
show more ...
|
| d4a65302 | 24-Oct-2024 |
Arnd Bergmann <[email protected]> |
vdso: Change PAGE_MASK to signed on all 32-bit architectures
With the introduction of an architecture-independent defintion of PAGE_MASK, we had to make a choice between defining it as 'unsigned lon
vdso: Change PAGE_MASK to signed on all 32-bit architectures
With the introduction of an architecture-independent defintion of PAGE_MASK, we had to make a choice between defining it as 'unsigned long' as on 64-bit architectures, or as signed 'long' as required for architectures with a 64-bit phys_addr_t.
To reduce the risk for regressions and minimize the changes in behavior, the result was using the signed value only when CONFIG_PHYS_ADDR_T_64BIT is set, but that ended up causing a regression after all in the early_init_dt_add_memory_arch() function that uses 64-bit integers for address calculation.
Presumably the same regression also affects mips32 and powerpc32 when dealing with large amounts of memory on DT platforms: like arm32, they were using the signed version unconditionally.
The two most sensible options for addressing the regression are either to go back to an architecture specific definition, using a signed constant on arm/powerpc/mips and unsigned on the others, or to use the same definition everywhere.
Use the simpler of those two and change them all to the signed version, in the hope that this does not cause a different type of bug. Most of the other 32-bit architectures have no large physical address support and are rarely used, so it seems more likely that using the same definition helps than hurts here.
In particular, x86-32 does have physical addressing extensions, so it already changed to the signed version after the previous patch, so it makes sense to use the same version on non-PAE as well.
Fixes: efe8419ae78d ("vdso: Introduce vdso/page.h") Reported-by: Naresh Kamboju <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Tested-by: Anders Roxell <[email protected]> Tested-by: Vincenzo Frascino <[email protected]> Reviewed-by: Vincenzo Frascino <[email protected]> Link: https://lore.kernel.org/all/[email protected] Link: https://lore.kernel.org/lkml/CA+G9fYt86bUAu_v5dXPWnDUwQNVipj+Wq3Djir1KUSKdr9QLNg@mail.gmail.com/
show more ...
|
| 4d456f0c | 01-Sep-2024 |
Xi Ruoyao <[email protected]> |
random: vDSO: add a __vdso_getrandom prototype for all architectures
Without a prototype, we'll have to add a prototype for each architecture implementing vDSO getrandom. As most architectures will
random: vDSO: add a __vdso_getrandom prototype for all architectures
Without a prototype, we'll have to add a prototype for each architecture implementing vDSO getrandom. As most architectures will likely have the vDSO getrandom implemented in a near future, and we'd like to keep the declarations compatible everywhere (to ease the libc implementor work), we should really just have one copy of the prototype.
This also is what's already done inside of include/vdso/gettime.h for those vDSO functions, so this continues that convention.
Suggested-by: Huacai Chen <[email protected]> Signed-off-by: Xi Ruoyao <[email protected]> Acked-by: Huacai Chen <[email protected]> [Jason: rewrite docbook comment for prototype.] Signed-off-by: Jason A. Donenfeld <[email protected]>
show more ...
|
| 7f053812 | 27-Aug-2024 |
Christophe Leroy <[email protected]> |
random: vDSO: minimize and simplify header includes
Depending on the architecture, building a 32-bit vDSO on a 64-bit kernel is problematic when some system headers are included.
Minimise the amoun
random: vDSO: minimize and simplify header includes
Depending on the architecture, building a 32-bit vDSO on a 64-bit kernel is problematic when some system headers are included.
Minimise the amount of headers by moving needed items, such as __{get,put}_unaligned_t, into dedicated common headers and in general use more specific headers, similar to what was done in commit 8165b57bca21 ("linux/const.h: Extract common header for vDSO") and commit 8c59ab839f52 ("lib/vdso: Enable common headers").
On some architectures this results in missing PAGE_SIZE, as was described by commit 8b3843ae3634 ("vdso/datapage: Quick fix - use asm/page-def.h for ARM64"), so define this if necessary, in the same way as done prior by commit cffaefd15a8f ("vdso: Use CONFIG_PAGE_SHIFT in vdso/datapage.h").
Removing linux/time64.h leads to missing 'struct timespec64' in x86's asm/pvclock.h. Add a forward declaration of that struct in that file.
Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Jason A. Donenfeld <[email protected]>
show more ...
|