| Message ID | a1a9bd0df508f1b5c04684b7366940577dfc6262.1727858295.git.christophe.leroy@csgroup.eu (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [1/2] powerpc/vdso: Add a page for non-time data | expand |
| Context | Check | Description |
|---|---|---|
| snowpatch_ozlabs/github-powerpc_selftests | success | Successfully ran 8 jobs. |
| snowpatch_ozlabs/github-powerpc_ppctests | success | Successfully ran 8 jobs. |
| snowpatch_ozlabs/github-powerpc_sparse | success | Successfully ran 4 jobs. |
| snowpatch_ozlabs/github-powerpc_clang | success | Successfully ran 5 jobs. |
| snowpatch_ozlabs/github-powerpc_kernel_qemu | success | Successfully ran 21 jobs. |
Hey Christophe, Michael, This series actually looks pretty okay to me. I realize ThomasW is working on more generic cleanups that might obliterate the need for this, and that may or may not wind up in 6.13. But, I was thinking, this seems like a good correct thing to do, and to do it now for 6.12, maybe as a fix through the powerpc tree. Then ThomasW can base his work atop this, which might wind up including the nice lr optimizations you've made. And then also if ThomasW's work doesn't land or gets reverted or whatever, at least we'll have this in tree for 6.12. Michael - what do you think of that? Worth taking these two patches into your fixes? Jason
On October 4, 2024 2:33:54 AM GMT+10:00, "Jason A. Donenfeld" <Jason@zx2c4.com> wrote: >Hey Christophe, Michael, > >This series actually looks pretty okay to me. I realize ThomasW is >working on more generic cleanups that might obliterate the need for >this, and that may or may not wind up in 6.13. But, I was thinking, this >seems like a good correct thing to do, and to do it now for 6.12, maybe >as a fix through the powerpc tree. Then ThomasW can base his work atop >this, which might wind up including the nice lr optimizations you've >made. And then also if ThomasW's work doesn't land or gets reverted or >whatever, at least we'll have this in tree for 6.12. > >Michael - what do you think of that? Worth taking these two patches into >your fixes? I agree the series looks good. But they're not fixes by my reading, so I'd be inclined to put them in next for v6.13? cheers
On Fri, Oct 04, 2024 at 08:52:40PM +1000, Michael Ellerman wrote: > > > On October 4, 2024 2:33:54 AM GMT+10:00, "Jason A. Donenfeld" <Jason@zx2c4.com> wrote: > >Hey Christophe, Michael, > > > >This series actually looks pretty okay to me. I realize ThomasW is > >working on more generic cleanups that might obliterate the need for > >this, and that may or may not wind up in 6.13. But, I was thinking, this > >seems like a good correct thing to do, and to do it now for 6.12, maybe > >as a fix through the powerpc tree. Then ThomasW can base his work atop > >this, which might wind up including the nice lr optimizations you've > >made. And then also if ThomasW's work doesn't land or gets reverted or > >whatever, at least we'll have this in tree for 6.12. > > > >Michael - what do you think of that? Worth taking these two patches into > >your fixes? > > I agree the series looks good. But they're not fixes by my reading, so I'd be inclined to put them in next for v6.13? They're "close enough" to fixes. The get_realdatapage stuff is super wonky and weird and it's quite good Christophe has gotten rid of it. Returning NULL from the generic accesor function never really sat right and looks buggy even if it does work. But more to the point, given the other scheduled churn for 6.13, it's going to be a tree-clashing nightmare to get this in later. And this Sunday is rc2 only, so why not. Jason
diff --git a/arch/powerpc/include/asm/vdso/getrandom.h b/arch/powerpc/include/asm/vdso/getrandom.h index 501d6bb14e8a..4302e7c67aa5 100644 --- a/arch/powerpc/include/asm/vdso/getrandom.h +++ b/arch/powerpc/include/asm/vdso/getrandom.h @@ -7,6 +7,8 @@ #ifndef __ASSEMBLY__ +#include <asm/vdso_datapage.h> + static __always_inline int do_syscall_3(const unsigned long _r0, const unsigned long _r3, const unsigned long _r4, const unsigned long _r5) { @@ -43,11 +45,20 @@ static __always_inline ssize_t getrandom_syscall(void *buffer, size_t len, unsig static __always_inline struct vdso_rng_data *__arch_get_vdso_rng_data(void) { - return NULL; + struct vdso_arch_data *data; + + asm( + " bcl 20, 31, .+4\n" + "0: mflr %0\n" + " addis %0, %0, (_vdso_datapage - 0b)@ha\n" + " addi %0, %0, (_vdso_datapage - 0b)@l\n" + : "=r" (data) :: "lr"); + + return &data->rng_data; } ssize_t __c_kernel_getrandom(void *buffer, size_t len, unsigned int flags, void *opaque_state, - size_t opaque_len, const struct vdso_rng_data *vd); + size_t opaque_len); #endif /* !__ASSEMBLY__ */ diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c index 131a8cc10dbe..7b3feb6bc210 100644 --- a/arch/powerpc/kernel/asm-offsets.c +++ b/arch/powerpc/kernel/asm-offsets.c @@ -335,7 +335,6 @@ int main(void) /* datapage offsets for use by vdso */ OFFSET(VDSO_DATA_OFFSET, vdso_arch_data, data); - OFFSET(VDSO_RNG_DATA_OFFSET, vdso_arch_data, rng_data); OFFSET(CFG_TB_TICKS_PER_SEC, vdso_arch_data, tb_ticks_per_sec); #ifdef CONFIG_PPC64 OFFSET(CFG_ICACHE_BLOCKSZ, vdso_arch_data, icache_block_size); diff --git a/arch/powerpc/kernel/vdso/getrandom.S b/arch/powerpc/kernel/vdso/getrandom.S index 3deddcf89f99..a80d9fb436f7 100644 --- a/arch/powerpc/kernel/vdso/getrandom.S +++ b/arch/powerpc/kernel/vdso/getrandom.S @@ -31,7 +31,6 @@ PPC_STL r2, PPC_MIN_STKFRM + STK_GOT(r1) .cfi_rel_offset r2, PPC_MIN_STKFRM + STK_GOT #endif - get_datapage r8 VDSO_RNG_DATA_OFFSET bl CFUNC(DOTSYM(\funct)) PPC_LL r0, PPC_MIN_STKFRM + PPC_LR_STKOFF(r1) #ifdef __powerpc64__ diff --git a/arch/powerpc/kernel/vdso/vgetrandom.c b/arch/powerpc/kernel/vdso/vgetrandom.c index 5f855d45fb7b..cc79b960a541 100644 --- a/arch/powerpc/kernel/vdso/vgetrandom.c +++ b/arch/powerpc/kernel/vdso/vgetrandom.c @@ -8,7 +8,7 @@ #include <linux/types.h> ssize_t __c_kernel_getrandom(void *buffer, size_t len, unsigned int flags, void *opaque_state, - size_t opaque_len, const struct vdso_rng_data *vd) + size_t opaque_len) { - return __cvdso_getrandom_data(vd, buffer, len, flags, opaque_state, opaque_len); + return __cvdso_getrandom(buffer, len, flags, opaque_state, opaque_len); }
VDSO time functions do not call any other function, so they don't need to save/restore LR. However, retrieving the address of VDSO data page requires using LR hence saving then restoring it, which can be heavy on some CPUs. On the other hand, VDSO functions on powerpc are not standard functions and require a wrapper function to call C VDSO functions. And that wrapper has to save and restore LR in order to call the C VDSO function, so retrieving VDSO data page address in that wrapper doesn't require additional save/restore of LR. For random VDSO functions it is a bit different. Because the function calls __arch_chacha20_blocks_nostack(), it saves and restores LR. Retrieving VDSO data page address can then be done there without additional save/restore of LR. So lets implement __arch_get_vdso_rng_data() and simplify the wrapper. It starts paving the way for the day powerpc will implement a more standard ABI for VDSO functions. Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> --- arch/powerpc/include/asm/vdso/getrandom.h | 15 +++++++++++++-- arch/powerpc/kernel/asm-offsets.c | 1 - arch/powerpc/kernel/vdso/getrandom.S | 1 - arch/powerpc/kernel/vdso/vgetrandom.c | 4 ++-- 4 files changed, 15 insertions(+), 6 deletions(-)