From: Dave Martin <Dave.Martin@arm.com> To: Vincenzo Frascino <vincenzo.frascino@arm.com> Cc: linux-arch@vger.kernel.org, Shuah Khan <shuah@kernel.org>, Catalin Marinas <catalin.marinas@arm.com>, Arnd Bergmann <arnd@arndb.de>, Mark Salyzyn <salyzyn@android.com>, Huw Davies <huw@codeweavers.com>, Andre Przywara <andre.przywara@arm.com>, Daniel Lezcano <daniel.lezcano@linaro.org>, Will Deacon <will.deacon@arm.com>, linux-kernel@vger.kernel.org, Ralf Baechle <ralf@linux-mips.org>, linux-mips@vger.kernel.org, Paul Burton <paul.burton@mips.com>, linux-kselftest@vger.kernel.org, Rasmus Villemoes <linux@rasmusvillemoes.dk>, Russell King <linux@armlinux.org.uk>, Dmitry Safonov <0x7f454c46@gmail.com>, Shijith Thotton <sthotton@marvell.com>, Peter Collingbourne <pcc@google.com>, Thomas Gleixner <tglx@linutronix.de>, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v7 04/25] arm64: Substitute gettimeofday with C implementation Date: Thu, 27 Jun 2019 11:01:51 +0100 [thread overview] Message-ID: <20190627100150.GC2790@e103592.cambridge.arm.com> (raw) In-Reply-To: <19ebd45a-b666-d7de-fd9e-2b72e18892d9@arm.com> On Wed, Jun 26, 2019 at 08:01:58PM +0100, Vincenzo Frascino wrote: [...] > On 6/26/19 5:14 PM, Dave Martin wrote: > > On Wed, Jun 26, 2019 at 02:27:59PM +0100, Vincenzo Frascino wrote: > >> Hi Dave, > >> > >> On 25/06/2019 16:33, Dave Martin wrote: > >>> On Fri, Jun 21, 2019 at 10:52:31AM +0100, Vincenzo Frascino wrote: > >>>> To take advantage of the commonly defined vdso interface for > >>>> gettimeofday the architectural code requires an adaptation. > >>>> > >>>> Re-implement the gettimeofday vdso in C in order to use lib/vdso. > >>>> > >>>> With the new implementation arm64 gains support for CLOCK_BOOTTIME > >>>> and CLOCK_TAI. > >>>> > >>>> Cc: Catalin Marinas <catalin.marinas@arm.com> > >>>> Cc: Will Deacon <will.deacon@arm.com> > >>>> Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com> > >>>> Tested-by: Shijith Thotton <sthotton@marvell.com> > >>>> Tested-by: Andre Przywara <andre.przywara@arm.com> > >>> > >>> [...] > >>> > >>>> diff --git a/arch/arm64/include/asm/vdso/gettimeofday.h b/arch/arm64/include/asm/vdso/gettimeofday.h > >>>> new file mode 100644 > >>>> index 000000000000..bc3cb6738051 > >>>> --- /dev/null > >>>> +++ b/arch/arm64/include/asm/vdso/gettimeofday.h > >>>> @@ -0,0 +1,86 @@ > >>>> +/* SPDX-License-Identifier: GPL-2.0 */ > >>>> +/* > >>>> + * Copyright (C) 2018 ARM Limited > >>>> + */ > >>>> +#ifndef __ASM_VDSO_GETTIMEOFDAY_H > >>>> +#define __ASM_VDSO_GETTIMEOFDAY_H > >>>> + > >>>> +#ifndef __ASSEMBLY__ > >>>> + > >>>> +#include <asm/unistd.h> > >>>> +#include <uapi/linux/time.h> > >>>> + > >>>> +#define VDSO_HAS_CLOCK_GETRES 1 > >>>> + > >>>> +static __always_inline int gettimeofday_fallback( > >>>> + struct __kernel_old_timeval *_tv, > >>>> + struct timezone *_tz) > >>> > >>> Out of interest, does this need to be __always_inline? > >>> > >> > >> It is a design choice. Philosophically, I prefer to control and reduce the scope > >> of the decisions the compiler has to make in order to not have surprises. > >> > >>>> +{ > >>>> + register struct timezone *tz asm("x1") = _tz; > >>>> + register struct __kernel_old_timeval *tv asm("x0") = _tv; > >>>> + register long ret asm ("x0"); > >>>> + register long nr asm("x8") = __NR_gettimeofday; > >>>> + > >>>> + asm volatile( > >>>> + " svc #0\n" > >>> > >>> Can inlining of this function result in non-trivial expressions being > >>> substituted for _tz or _tv? > >>> > >>> A function call can clobber register asm vars that are assigned to the > >>> caller-save registers or that the PCS uses for function arguments, and > >>> the situations where this can happen are poorly defined AFAICT. There's > >>> also no reliable way to detect at build time whether the compiler has > >>> done this, and no robust way to stop if happening. > >>> > >>> (IMHO the compiler is wrong to do this, but it's been that way for ever, > >>> and I think I saw GCC 9 show this behaviour recently when I was > >>> investigating something related.) > >>> > >>> > >>> To be safe, it's better to put this out of line, or remove the reg asm() > >>> specifiers, mark x0-x18 and lr as clobbered here (so that the compiler > >>> doesn't map arguments to them), and put movs in the asm to move things > >>> into the right registers. The syscall number can be passed with an "i" > >>> constraint. (And yes, this sucks.) > >>> > >>> If the code this is inlined in is simple enough though, we can be fairly > >>> confident of getting away with it. > >>> > >> > >> I took very seriously what you are mentioning here because I think > >> that robustness of the code comes before than everything especially > >> in the kernel and I carried on some experiments to try to verify if > >> in this case is safe to assume that the compiler is doing the right > >> thing. > >> > >> Based on my investigation and on previous observations of the > >> generation of the vDSO library, I can conclude that the approach > >> seems safe due to the fact that the usage of this code is very > >> limited, the code itself is simple enough and that gcc would inline > >> this code anyway based on the current compilation options. > > > > I'd caution about "seems safe". A lot of subtly wrong code not only > > seems safe, but _is_ safe in its original context, in practice. Add > > some code to the vdso over time though, or tweak the compilation options > > at some point in the future, or use a different compiler, and things > > could still go wrong. > > > > (Further comments below.) > > > > Allow me to provide a clarification on "seems safe" vs "is safe": my approach > "seems safe" because I am providing empirical evidence to support my thesis, but > I guess we both know that there is no simple way to prove in one way or another > that the problem has a complete solution. > The proposed problem involves suppositions on potential future code additions > and changes of behavior of the compiler that I can't either control or prevent. > In other words, I can comment and propose solutions only based on the current > status of the things, and it is what my analysis targets, not on what will > happen in future. > > I will reply point by point below. > > >> The experiment that I did was to define some self-contained code that > >> tries to mimic what you are describing and compile it with 3 > >> different versions of gcc (6.4, 8.1 and 8.3) and in all the tree > >> cases the behavior seems correct. > >> > >> Code: > >> ===== > >> > >> typedef int ssize_t; > >> typedef int size_t; > >> > >> static int my_strlen(const char *s) > >> { > >> int i = 0; > >> > >> while (s[i] == '\0') > >> i++; > >> > >> return i; > >> } > >> > >> static inline ssize_t my_syscall(int fd, const void *buf, size_t count) > >> { > >> register ssize_t arg1 asm ("x0") = fd; > >> register const void *arg2 asm ("x1") = buf; > >> register size_t arg3 asm ("x2") = count; > >> > >> __asm__ volatile ( > >> "mov x8, #64\n" > >> "svc #0\n" > >> : "=&r" (arg1) > >> : "r" (arg2), "r" (arg3) > >> : "x8" > >> ); > >> > >> return arg1; > >> } > >> > >> void sys_caller(const char *s) > >> { > >> my_syscall(1, s, my_strlen(s)); > >> } > >> > >> > >> GCC 8.3.0: > >> ========== > >> > >> main.8.3.0.o: file format elf64-littleaarch64 > >> > >> > >> Disassembly of section .text: > >> > >> 0000000000000000 <sys_caller>: > >> 0: 39400001 ldrb w1, [x0] > >> 4: 35000161 cbnz w1, 30 <sys_caller+0x30> > >> 8: d2800023 mov x3, #0x1 // #1 > >> c: d1000404 sub x4, x0, #0x1 > >> 10: 2a0303e2 mov w2, w3 > >> 14: 91000463 add x3, x3, #0x1 > >> 18: 38636881 ldrb w1, [x4, x3] > >> 1c: 34ffffa1 cbz w1, 10 <sys_caller+0x10> > >> 20: aa0003e1 mov x1, x0 > >> 24: d2800808 mov x8, #0x40 // #64 > >> 28: d4000001 svc #0x0 > >> 2c: d65f03c0 ret > >> 30: 52800002 mov w2, #0x0 // #0 > >> 34: 17fffffb b 20 <sys_caller+0x20> > >> > >> > >> GCC 8.1.0: > >> ========== > >> > >> main.8.1.0.o: file format elf64-littleaarch64 > >> > >> > >> Disassembly of section .text: > >> > >> 0000000000000000 <sys_caller>: > >> 0: 39400001 ldrb w1, [x0] > >> 4: 35000161 cbnz w1, 30 <sys_caller+0x30> > >> 8: d2800023 mov x3, #0x1 // #1 > >> c: d1000404 sub x4, x0, #0x1 > >> 10: 2a0303e2 mov w2, w3 > >> 14: 91000463 add x3, x3, #0x1 > >> 18: 38636881 ldrb w1, [x4, x3] > >> 1c: 34ffffa1 cbz w1, 10 <sys_caller+0x10> > >> 20: aa0003e1 mov x1, x0 > >> 24: d2800808 mov x8, #0x40 // #64 > >> 28: d4000001 svc #0x0 > >> 2c: d65f03c0 ret > >> 30: 52800002 mov w2, #0x0 // #0 > >> 34: 17fffffb b 20 <sys_caller+0x20> > >> > >> > >> > >> GCC 6.4.0: > >> ========== > >> > >> main.6.4.0.o: file format elf64-littleaarch64 > >> > >> > >> Disassembly of section .text: > >> > >> 0000000000000000 <sys_caller>: > >> 0: 39400001 ldrb w1, [x0] > >> 4: 35000161 cbnz w1, 30 <sys_caller+0x30> > >> 8: d2800023 mov x3, #0x1 // #1 > >> c: d1000404 sub x4, x0, #0x1 > >> 10: 2a0303e2 mov w2, w3 > >> 14: 91000463 add x3, x3, #0x1 > >> 18: 38636881 ldrb w1, [x4, x3] > >> 1c: 34ffffa1 cbz w1, 10 <sys_caller+0x10> > >> 20: aa0003e1 mov x1, x0 > >> 24: d2800808 mov x8, #0x40 // #64 > >> 28: d4000001 svc #0x0 > >> 2c: d65f03c0 ret > >> 30: 52800002 mov w2, #0x0 // #0 > >> 34: 17fffffb b 20 <sys_caller+0x20> > > > > Thanks for having a go at this. If the compiler can show the > > problematic behaviour, it looks like your could could probably trigger > > it, and as you observe, it doesn't trigger. > > > > I am sure I have seen it in the past, but today I am struggling > > to tickle the compiler in the right way. My original reproducer may > > have involved LTO, but either way I don't still have it :( > > > > vDSO library is a shared object not compiled with LTO as far as I can > see, hence if this involved LTO should not applicable in this case. That turned to be a spurious hypothesis on my part -- LTO isn't the smoking gun. (See below.) > > The classic example of this (triggered directly and not due to inlining) > > would be something like: > > > > int bar(int, int); > > > > void foo(int x, int y) > > { > > register int x_ asm("r0") = x; > > register int y_ asm("r1") = bar(x, y); > > > > asm volatile ( > > "svc #0" > > :: "r" (x_), "r" (y_) > > : "memory" > > ); > > } > > > > -> > > > > 0000000000000000 <foo>: > > 0: a9bf7bfd stp x29, x30, [sp, #-16]! > > 4: 910003fd mov x29, sp > > 8: 94000000 bl 0 <bar> > > c: 2a0003e1 mov w1, w0 > > 10: d4000001 svc #0x0 > > 14: a8c17bfd ldp x29, x30, [sp], #16 > > 18: d65f03c0 ret > > > > Contextualized to what my vdso fallback functions do, this should not be a > concern because in no case a function result is directly set to a variable > declared as register. > > Since the vdso fallback functions serve a very specific and limited purpose, I > do not expect that that code is going to change much in future. > > The only thing that can happen is something similar to what I wrote in my > example, which as I empirically proved does not trigger the problematic behavior. > > > > > The gcc documentation is vague and ambiguous about precisely whan this > > can happen and about how to avoid it. > > > > On this I agree, it is not very clear, but this seems more something to raise > with the gcc folks in order to have a more "explicit" description that leaves no > room to the interpretation. > > ... > > > > > However, the workaround is cheap, and to avoid the chance of subtle > > intermittent code gen bugs it may be worth it: > > > > void foo(int x, int y) > > { > > asm volatile ( > > "mov x0, %0\n\t" > > "mov x1, %1\n\t" > > "svc #0" > > :: "r" (x), "r" (bar(x, y)) > > : "r0", "r1", "memory" > > ); > > } > > > > -> > > > > 0000000000000000 <foo>: > > 0: a9be7bfd stp x29, x30, [sp, #-32]! > > 4: 910003fd mov x29, sp > > 8: f9000bf3 str x19, [sp, #16] > > c: 2a0003f3 mov w19, w0 > > 10: 94000000 bl 0 <bar> > > 14: 2a0003e2 mov w2, w0 > > 18: aa1303e0 mov x0, x19 > > 1c: aa0203e1 mov x1, x2 > > 20: d4000001 svc #0x0 > > 24: f9400bf3 ldr x19, [sp, #16] > > 28: a8c27bfd ldp x29, x30, [sp], #32 > > 2c: d65f03c0 ret > > > > > > What do you think? > > > > The solution seems ok, thanks for providing it, but IMHO I think we > should find a workaround for something that is broken, which, unless > I am missing something major, this seems not the case. So, after a bit of further experimentation, I found that I could trigger it with implicit function calls on an older compiler. I couldn't show it with explicit function calls (as in your example). With the following code, inlining if an expression that causes an implicit call to a libgcc helper can trigger this issue, but I had to try an older compiler: int foo(int x, int y) { register int res asm("r0"); register const int x_ asm("r0") = x; register const int y_ asm("r1") = y; asm volatile ( "svc #0" : "=r" (res) : "r" (x_), "r" (y_) : "memory" ); return res; } int bar(int x, int y) { return foo(x, x / y); } -> (arm-linux-gnueabihf-gcc 9.1 -O2) 00000000 <foo>: 0: df00 svc 0 2: 4770 bx lr 00000004 <bar>: 4: b510 push {r4, lr} 6: 4604 mov r4, r0 8: f7ff fffe bl 0 <__aeabi_idiv> c: 4601 mov r1, r0 e: 4620 mov r0, r4 10: df00 svc 0 12: bd10 pop {r4, pc} -> (arm-linux-gnueabihf-gcc 5.1 -O2) 00000000 <foo>: 0: df00 svc 0 2: 4770 bx lr 00000004 <bar>: 4: b508 push {r3, lr} 6: f7ff fffe bl 0 <__aeabi_idiv> a: 4601 mov r1, r0 c: df00 svc 0 e: bd08 pop {r3, pc} I was struggling to find a way to emit an implicit function call for AArch64, except for 128-bit divide, which would complicate things since uint128_t doesn't fit in a single register anyway. Maybe this was considered a bug and fixed sometime after GCC 5, but I think the GCC documentation is still quite unclear on the semantics of register asm vars that alias call-clobbered registers in the PCS. If we can get a promise out of the GCC folks that this will not happen with any future compiler, then maybe we could just require a new enough compiler to be used. Then of course there is clang. Cheers ---Dave
WARNING: multiple messages have this Message-ID (diff)
From: Dave Martin <Dave.Martin@arm.com> To: Vincenzo Frascino <vincenzo.frascino@arm.com> Cc: linux-arch@vger.kernel.org, Shijith Thotton <sthotton@marvell.com>, Peter Collingbourne <pcc@google.com>, Arnd Bergmann <arnd@arndb.de>, Huw Davies <huw@codeweavers.com>, Catalin Marinas <catalin.marinas@arm.com>, Daniel Lezcano <daniel.lezcano@linaro.org>, Will Deacon <will.deacon@arm.com>, linux-kernel@vger.kernel.org, Ralf Baechle <ralf@linux-mips.org>, Mark Salyzyn <salyzyn@android.com>, Paul Burton <paul.burton@mips.com>, Rasmus Villemoes <linux@rasmusvillemoes.dk>, linux-kselftest@vger.kernel.org, Andre Przywara <andre.przywara@arm.com>, Russell King <linux@armlinux.org.uk>, Dmitry Safonov <0x7f454c46@gmail.com>, linux-mips@vger.kernel.org, Shuah Khan <shuah@kernel.org>, Thomas Gleixner <tglx@linutronix.de>, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v7 04/25] arm64: Substitute gettimeofday with C implementation Date: Thu, 27 Jun 2019 11:01:51 +0100 [thread overview] Message-ID: <20190627100150.GC2790@e103592.cambridge.arm.com> (raw) In-Reply-To: <19ebd45a-b666-d7de-fd9e-2b72e18892d9@arm.com> On Wed, Jun 26, 2019 at 08:01:58PM +0100, Vincenzo Frascino wrote: [...] > On 6/26/19 5:14 PM, Dave Martin wrote: > > On Wed, Jun 26, 2019 at 02:27:59PM +0100, Vincenzo Frascino wrote: > >> Hi Dave, > >> > >> On 25/06/2019 16:33, Dave Martin wrote: > >>> On Fri, Jun 21, 2019 at 10:52:31AM +0100, Vincenzo Frascino wrote: > >>>> To take advantage of the commonly defined vdso interface for > >>>> gettimeofday the architectural code requires an adaptation. > >>>> > >>>> Re-implement the gettimeofday vdso in C in order to use lib/vdso. > >>>> > >>>> With the new implementation arm64 gains support for CLOCK_BOOTTIME > >>>> and CLOCK_TAI. > >>>> > >>>> Cc: Catalin Marinas <catalin.marinas@arm.com> > >>>> Cc: Will Deacon <will.deacon@arm.com> > >>>> Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com> > >>>> Tested-by: Shijith Thotton <sthotton@marvell.com> > >>>> Tested-by: Andre Przywara <andre.przywara@arm.com> > >>> > >>> [...] > >>> > >>>> diff --git a/arch/arm64/include/asm/vdso/gettimeofday.h b/arch/arm64/include/asm/vdso/gettimeofday.h > >>>> new file mode 100644 > >>>> index 000000000000..bc3cb6738051 > >>>> --- /dev/null > >>>> +++ b/arch/arm64/include/asm/vdso/gettimeofday.h > >>>> @@ -0,0 +1,86 @@ > >>>> +/* SPDX-License-Identifier: GPL-2.0 */ > >>>> +/* > >>>> + * Copyright (C) 2018 ARM Limited > >>>> + */ > >>>> +#ifndef __ASM_VDSO_GETTIMEOFDAY_H > >>>> +#define __ASM_VDSO_GETTIMEOFDAY_H > >>>> + > >>>> +#ifndef __ASSEMBLY__ > >>>> + > >>>> +#include <asm/unistd.h> > >>>> +#include <uapi/linux/time.h> > >>>> + > >>>> +#define VDSO_HAS_CLOCK_GETRES 1 > >>>> + > >>>> +static __always_inline int gettimeofday_fallback( > >>>> + struct __kernel_old_timeval *_tv, > >>>> + struct timezone *_tz) > >>> > >>> Out of interest, does this need to be __always_inline? > >>> > >> > >> It is a design choice. Philosophically, I prefer to control and reduce the scope > >> of the decisions the compiler has to make in order to not have surprises. > >> > >>>> +{ > >>>> + register struct timezone *tz asm("x1") = _tz; > >>>> + register struct __kernel_old_timeval *tv asm("x0") = _tv; > >>>> + register long ret asm ("x0"); > >>>> + register long nr asm("x8") = __NR_gettimeofday; > >>>> + > >>>> + asm volatile( > >>>> + " svc #0\n" > >>> > >>> Can inlining of this function result in non-trivial expressions being > >>> substituted for _tz or _tv? > >>> > >>> A function call can clobber register asm vars that are assigned to the > >>> caller-save registers or that the PCS uses for function arguments, and > >>> the situations where this can happen are poorly defined AFAICT. There's > >>> also no reliable way to detect at build time whether the compiler has > >>> done this, and no robust way to stop if happening. > >>> > >>> (IMHO the compiler is wrong to do this, but it's been that way for ever, > >>> and I think I saw GCC 9 show this behaviour recently when I was > >>> investigating something related.) > >>> > >>> > >>> To be safe, it's better to put this out of line, or remove the reg asm() > >>> specifiers, mark x0-x18 and lr as clobbered here (so that the compiler > >>> doesn't map arguments to them), and put movs in the asm to move things > >>> into the right registers. The syscall number can be passed with an "i" > >>> constraint. (And yes, this sucks.) > >>> > >>> If the code this is inlined in is simple enough though, we can be fairly > >>> confident of getting away with it. > >>> > >> > >> I took very seriously what you are mentioning here because I think > >> that robustness of the code comes before than everything especially > >> in the kernel and I carried on some experiments to try to verify if > >> in this case is safe to assume that the compiler is doing the right > >> thing. > >> > >> Based on my investigation and on previous observations of the > >> generation of the vDSO library, I can conclude that the approach > >> seems safe due to the fact that the usage of this code is very > >> limited, the code itself is simple enough and that gcc would inline > >> this code anyway based on the current compilation options. > > > > I'd caution about "seems safe". A lot of subtly wrong code not only > > seems safe, but _is_ safe in its original context, in practice. Add > > some code to the vdso over time though, or tweak the compilation options > > at some point in the future, or use a different compiler, and things > > could still go wrong. > > > > (Further comments below.) > > > > Allow me to provide a clarification on "seems safe" vs "is safe": my approach > "seems safe" because I am providing empirical evidence to support my thesis, but > I guess we both know that there is no simple way to prove in one way or another > that the problem has a complete solution. > The proposed problem involves suppositions on potential future code additions > and changes of behavior of the compiler that I can't either control or prevent. > In other words, I can comment and propose solutions only based on the current > status of the things, and it is what my analysis targets, not on what will > happen in future. > > I will reply point by point below. > > >> The experiment that I did was to define some self-contained code that > >> tries to mimic what you are describing and compile it with 3 > >> different versions of gcc (6.4, 8.1 and 8.3) and in all the tree > >> cases the behavior seems correct. > >> > >> Code: > >> ===== > >> > >> typedef int ssize_t; > >> typedef int size_t; > >> > >> static int my_strlen(const char *s) > >> { > >> int i = 0; > >> > >> while (s[i] == '\0') > >> i++; > >> > >> return i; > >> } > >> > >> static inline ssize_t my_syscall(int fd, const void *buf, size_t count) > >> { > >> register ssize_t arg1 asm ("x0") = fd; > >> register const void *arg2 asm ("x1") = buf; > >> register size_t arg3 asm ("x2") = count; > >> > >> __asm__ volatile ( > >> "mov x8, #64\n" > >> "svc #0\n" > >> : "=&r" (arg1) > >> : "r" (arg2), "r" (arg3) > >> : "x8" > >> ); > >> > >> return arg1; > >> } > >> > >> void sys_caller(const char *s) > >> { > >> my_syscall(1, s, my_strlen(s)); > >> } > >> > >> > >> GCC 8.3.0: > >> ========== > >> > >> main.8.3.0.o: file format elf64-littleaarch64 > >> > >> > >> Disassembly of section .text: > >> > >> 0000000000000000 <sys_caller>: > >> 0: 39400001 ldrb w1, [x0] > >> 4: 35000161 cbnz w1, 30 <sys_caller+0x30> > >> 8: d2800023 mov x3, #0x1 // #1 > >> c: d1000404 sub x4, x0, #0x1 > >> 10: 2a0303e2 mov w2, w3 > >> 14: 91000463 add x3, x3, #0x1 > >> 18: 38636881 ldrb w1, [x4, x3] > >> 1c: 34ffffa1 cbz w1, 10 <sys_caller+0x10> > >> 20: aa0003e1 mov x1, x0 > >> 24: d2800808 mov x8, #0x40 // #64 > >> 28: d4000001 svc #0x0 > >> 2c: d65f03c0 ret > >> 30: 52800002 mov w2, #0x0 // #0 > >> 34: 17fffffb b 20 <sys_caller+0x20> > >> > >> > >> GCC 8.1.0: > >> ========== > >> > >> main.8.1.0.o: file format elf64-littleaarch64 > >> > >> > >> Disassembly of section .text: > >> > >> 0000000000000000 <sys_caller>: > >> 0: 39400001 ldrb w1, [x0] > >> 4: 35000161 cbnz w1, 30 <sys_caller+0x30> > >> 8: d2800023 mov x3, #0x1 // #1 > >> c: d1000404 sub x4, x0, #0x1 > >> 10: 2a0303e2 mov w2, w3 > >> 14: 91000463 add x3, x3, #0x1 > >> 18: 38636881 ldrb w1, [x4, x3] > >> 1c: 34ffffa1 cbz w1, 10 <sys_caller+0x10> > >> 20: aa0003e1 mov x1, x0 > >> 24: d2800808 mov x8, #0x40 // #64 > >> 28: d4000001 svc #0x0 > >> 2c: d65f03c0 ret > >> 30: 52800002 mov w2, #0x0 // #0 > >> 34: 17fffffb b 20 <sys_caller+0x20> > >> > >> > >> > >> GCC 6.4.0: > >> ========== > >> > >> main.6.4.0.o: file format elf64-littleaarch64 > >> > >> > >> Disassembly of section .text: > >> > >> 0000000000000000 <sys_caller>: > >> 0: 39400001 ldrb w1, [x0] > >> 4: 35000161 cbnz w1, 30 <sys_caller+0x30> > >> 8: d2800023 mov x3, #0x1 // #1 > >> c: d1000404 sub x4, x0, #0x1 > >> 10: 2a0303e2 mov w2, w3 > >> 14: 91000463 add x3, x3, #0x1 > >> 18: 38636881 ldrb w1, [x4, x3] > >> 1c: 34ffffa1 cbz w1, 10 <sys_caller+0x10> > >> 20: aa0003e1 mov x1, x0 > >> 24: d2800808 mov x8, #0x40 // #64 > >> 28: d4000001 svc #0x0 > >> 2c: d65f03c0 ret > >> 30: 52800002 mov w2, #0x0 // #0 > >> 34: 17fffffb b 20 <sys_caller+0x20> > > > > Thanks for having a go at this. If the compiler can show the > > problematic behaviour, it looks like your could could probably trigger > > it, and as you observe, it doesn't trigger. > > > > I am sure I have seen it in the past, but today I am struggling > > to tickle the compiler in the right way. My original reproducer may > > have involved LTO, but either way I don't still have it :( > > > > vDSO library is a shared object not compiled with LTO as far as I can > see, hence if this involved LTO should not applicable in this case. That turned to be a spurious hypothesis on my part -- LTO isn't the smoking gun. (See below.) > > The classic example of this (triggered directly and not due to inlining) > > would be something like: > > > > int bar(int, int); > > > > void foo(int x, int y) > > { > > register int x_ asm("r0") = x; > > register int y_ asm("r1") = bar(x, y); > > > > asm volatile ( > > "svc #0" > > :: "r" (x_), "r" (y_) > > : "memory" > > ); > > } > > > > -> > > > > 0000000000000000 <foo>: > > 0: a9bf7bfd stp x29, x30, [sp, #-16]! > > 4: 910003fd mov x29, sp > > 8: 94000000 bl 0 <bar> > > c: 2a0003e1 mov w1, w0 > > 10: d4000001 svc #0x0 > > 14: a8c17bfd ldp x29, x30, [sp], #16 > > 18: d65f03c0 ret > > > > Contextualized to what my vdso fallback functions do, this should not be a > concern because in no case a function result is directly set to a variable > declared as register. > > Since the vdso fallback functions serve a very specific and limited purpose, I > do not expect that that code is going to change much in future. > > The only thing that can happen is something similar to what I wrote in my > example, which as I empirically proved does not trigger the problematic behavior. > > > > > The gcc documentation is vague and ambiguous about precisely whan this > > can happen and about how to avoid it. > > > > On this I agree, it is not very clear, but this seems more something to raise > with the gcc folks in order to have a more "explicit" description that leaves no > room to the interpretation. > > ... > > > > > However, the workaround is cheap, and to avoid the chance of subtle > > intermittent code gen bugs it may be worth it: > > > > void foo(int x, int y) > > { > > asm volatile ( > > "mov x0, %0\n\t" > > "mov x1, %1\n\t" > > "svc #0" > > :: "r" (x), "r" (bar(x, y)) > > : "r0", "r1", "memory" > > ); > > } > > > > -> > > > > 0000000000000000 <foo>: > > 0: a9be7bfd stp x29, x30, [sp, #-32]! > > 4: 910003fd mov x29, sp > > 8: f9000bf3 str x19, [sp, #16] > > c: 2a0003f3 mov w19, w0 > > 10: 94000000 bl 0 <bar> > > 14: 2a0003e2 mov w2, w0 > > 18: aa1303e0 mov x0, x19 > > 1c: aa0203e1 mov x1, x2 > > 20: d4000001 svc #0x0 > > 24: f9400bf3 ldr x19, [sp, #16] > > 28: a8c27bfd ldp x29, x30, [sp], #32 > > 2c: d65f03c0 ret > > > > > > What do you think? > > > > The solution seems ok, thanks for providing it, but IMHO I think we > should find a workaround for something that is broken, which, unless > I am missing something major, this seems not the case. So, after a bit of further experimentation, I found that I could trigger it with implicit function calls on an older compiler. I couldn't show it with explicit function calls (as in your example). With the following code, inlining if an expression that causes an implicit call to a libgcc helper can trigger this issue, but I had to try an older compiler: int foo(int x, int y) { register int res asm("r0"); register const int x_ asm("r0") = x; register const int y_ asm("r1") = y; asm volatile ( "svc #0" : "=r" (res) : "r" (x_), "r" (y_) : "memory" ); return res; } int bar(int x, int y) { return foo(x, x / y); } -> (arm-linux-gnueabihf-gcc 9.1 -O2) 00000000 <foo>: 0: df00 svc 0 2: 4770 bx lr 00000004 <bar>: 4: b510 push {r4, lr} 6: 4604 mov r4, r0 8: f7ff fffe bl 0 <__aeabi_idiv> c: 4601 mov r1, r0 e: 4620 mov r0, r4 10: df00 svc 0 12: bd10 pop {r4, pc} -> (arm-linux-gnueabihf-gcc 5.1 -O2) 00000000 <foo>: 0: df00 svc 0 2: 4770 bx lr 00000004 <bar>: 4: b508 push {r3, lr} 6: f7ff fffe bl 0 <__aeabi_idiv> a: 4601 mov r1, r0 c: df00 svc 0 e: bd08 pop {r3, pc} I was struggling to find a way to emit an implicit function call for AArch64, except for 128-bit divide, which would complicate things since uint128_t doesn't fit in a single register anyway. Maybe this was considered a bug and fixed sometime after GCC 5, but I think the GCC documentation is still quite unclear on the semantics of register asm vars that alias call-clobbered registers in the PCS. If we can get a promise out of the GCC folks that this will not happen with any future compiler, then maybe we could just require a new enough compiler to be used. Then of course there is clang. Cheers ---Dave _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-06-27 10:01 UTC|newest] Thread overview: 307+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-06-21 9:52 [PATCH v7 00/25] Unify vDSOs across more architectures Vincenzo Frascino 2019-06-21 9:52 ` Vincenzo Frascino 2019-06-21 9:52 ` [PATCH v7 01/25] kernel: Standardize vdso_datapage Vincenzo Frascino 2019-06-21 9:52 ` Vincenzo Frascino 2019-06-23 23:44 ` [tip:timers/vdso] vdso: Define standardized vdso_datapage tip-bot for Vincenzo Frascino 2019-06-24 13:56 ` [PATCH v7 01/25] kernel: Standardize vdso_datapage Catalin Marinas 2019-06-24 13:56 ` Catalin Marinas 2019-06-24 13:56 ` Catalin Marinas 2019-06-25 7:49 ` [tip:timers/vdso] vdso: Remove superfluous #ifdef __KERNEL__ in vdso/datapage.h tip-bot for Catalin Marinas 2019-06-26 12:34 ` tip-bot for Catalin Marinas 2019-06-21 9:52 ` [PATCH v7 02/25] kernel: Define gettimeofday vdso common code Vincenzo Frascino 2019-06-21 9:52 ` Vincenzo Frascino 2019-06-23 23:43 ` [tip:timers/vdso] hrtimer: Split out hrtimer defines into separate header tip-bot for Vincenzo Frascino 2019-06-23 23:45 ` [tip:timers/vdso] lib/vdso: Provide generic VDSO implementation tip-bot for Vincenzo Frascino 2019-06-21 9:52 ` [PATCH v7 03/25] kernel: Unify update_vsyscall implementation Vincenzo Frascino 2019-06-21 9:52 ` Vincenzo Frascino 2019-06-21 10:49 ` Huw Davies 2019-06-21 10:49 ` Huw Davies 2019-06-23 23:46 ` [tip:timers/vdso] timekeeping: Provide a generic update_vsyscall() implementation tip-bot for Vincenzo Frascino 2019-06-21 9:52 ` [PATCH v7 04/25] arm64: Substitute gettimeofday with C implementation Vincenzo Frascino 2019-06-21 9:52 ` Vincenzo Frascino 2019-06-23 23:47 ` [tip:timers/vdso] arm64: vdso: Substitute gettimeofday() " tip-bot for Vincenzo Frascino 2019-06-24 13:36 ` [PATCH v7 04/25] arm64: Substitute gettimeofday " Will Deacon 2019-06-24 13:36 ` Will Deacon 2019-06-24 13:59 ` Vincenzo Frascino 2019-06-24 13:59 ` Vincenzo Frascino 2019-06-25 16:18 ` [PATCH 1/3] lib/vdso: Delay mask application in do_hres() Vincenzo Frascino 2019-06-25 16:18 ` Vincenzo Frascino 2019-06-25 16:18 ` [PATCH 2/3] arm64: Fix __arch_get_hw_counter() implementation Vincenzo Frascino 2019-06-25 16:18 ` Vincenzo Frascino 2019-06-26 12:38 ` [tip:timers/vdso] " tip-bot for Vincenzo Frascino 2019-06-25 16:18 ` [PATCH 3/3] arm64: compat: " Vincenzo Frascino 2019-06-25 16:18 ` Vincenzo Frascino 2019-06-26 12:39 ` [tip:timers/vdso] " tip-bot for Vincenzo Frascino 2019-06-25 17:02 ` [PATCH 1/3] lib/vdso: Delay mask application in do_hres() Thomas Gleixner 2019-06-25 17:02 ` Thomas Gleixner 2019-06-25 18:27 ` Thomas Gleixner 2019-06-25 18:27 ` Thomas Gleixner 2019-06-25 20:15 ` Andy Lutomirski 2019-06-25 20:15 ` Andy Lutomirski 2019-06-25 20:15 ` Andy Lutomirski 2019-06-25 20:15 ` Andy Lutomirski 2019-06-25 22:24 ` Thomas Gleixner 2019-06-25 22:24 ` Thomas Gleixner 2019-06-25 22:24 ` Thomas Gleixner 2019-06-25 22:24 ` Thomas Gleixner 2019-06-26 6:38 ` Thomas Gleixner 2019-06-26 6:38 ` Thomas Gleixner 2019-06-26 9:25 ` Vincenzo Frascino 2019-06-26 9:25 ` Vincenzo Frascino 2019-06-26 10:02 ` lib/vdso: Make delta calculation work correctly Thomas Gleixner 2019-06-26 11:08 ` Vincenzo Frascino 2019-06-26 11:08 ` Vincenzo Frascino 2019-06-26 12:37 ` [tip:timers/vdso] " tip-bot for Thomas Gleixner 2019-06-24 13:58 ` [PATCH v7 04/25] arm64: Substitute gettimeofday with C implementation Catalin Marinas 2019-06-24 13:58 ` Catalin Marinas 2019-06-24 13:58 ` Catalin Marinas 2019-06-25 7:49 ` [tip:timers/vdso] arm64: vdso: Remove unnecessary asm-offsets.c definitions tip-bot for Catalin Marinas 2019-06-26 12:35 ` tip-bot for Catalin Marinas 2019-06-25 15:33 ` [PATCH v7 04/25] arm64: Substitute gettimeofday with C implementation Dave Martin 2019-06-25 15:33 ` Dave Martin 2019-06-26 13:27 ` Vincenzo Frascino 2019-06-26 13:27 ` Vincenzo Frascino 2019-06-26 16:14 ` Dave Martin 2019-06-26 16:14 ` Dave Martin 2019-06-26 19:01 ` Vincenzo Frascino 2019-06-26 19:01 ` Vincenzo Frascino 2019-06-27 10:01 ` Dave Martin [this message] 2019-06-27 10:01 ` Dave Martin 2019-06-27 10:57 ` Vincenzo Frascino 2019-06-27 10:57 ` Vincenzo Frascino 2019-06-27 11:27 ` Dave Martin 2019-06-27 11:27 ` Dave Martin 2019-06-27 11:59 ` Vincenzo Frascino 2019-06-27 11:59 ` Vincenzo Frascino 2019-06-27 11:59 ` Vincenzo Frascino 2019-06-27 14:38 ` Dave Martin 2019-06-27 14:38 ` Dave Martin 2019-06-27 15:34 ` Vincenzo Frascino 2019-06-27 15:34 ` Vincenzo Frascino 2019-06-25 17:43 ` [PATCH] arm64: vdso: Fix compilation with clang < 8 Vincenzo Frascino 2019-06-25 17:43 ` Vincenzo Frascino 2019-06-26 11:36 ` [PATCH v2] arm64: vdso: Fix compilation with clang older then 8 Vincenzo Frascino 2019-06-26 11:36 ` Vincenzo Frascino 2019-06-26 12:39 ` [tip:timers/vdso] arm64: vdso: Fix compilation with clang older than 8 tip-bot for Vincenzo Frascino [not found] ` <CGME20190628130921eucas1p239935b0771032c331911eacc1a69dd2e@eucas1p2.samsung.com> 2019-06-28 13:09 ` [PATCH v7 04/25] arm64: Substitute gettimeofday with C implementation Marek Szyprowski 2019-06-28 13:09 ` Marek Szyprowski 2019-06-28 14:32 ` Vincenzo Frascino 2019-06-28 14:32 ` Vincenzo Frascino 2019-06-28 16:50 ` Sylwester Nawrocki 2019-06-28 16:50 ` Sylwester Nawrocki 2019-06-28 16:50 ` Sylwester Nawrocki 2019-06-29 6:58 ` Vincenzo Frascino 2019-06-29 6:58 ` Vincenzo Frascino 2019-07-08 12:57 ` Sylwester Nawrocki 2019-07-08 12:57 ` Sylwester Nawrocki 2019-07-08 12:57 ` Sylwester Nawrocki 2019-07-08 13:09 ` Vincenzo Frascino 2019-07-08 13:09 ` Vincenzo Frascino 2019-07-08 13:09 ` Vincenzo Frascino 2019-06-21 9:52 ` [PATCH v7 05/25] arm64: Build vDSO with -ffixed-x18 Vincenzo Frascino 2019-06-21 9:52 ` Vincenzo Frascino 2019-06-23 23:48 ` [tip:timers/vdso] arm64: vdso: " tip-bot for Peter Collingbourne 2019-06-21 9:52 ` [PATCH v7 06/25] arm64: compat: Add missing syscall numbers Vincenzo Frascino 2019-06-21 9:52 ` Vincenzo Frascino 2019-06-23 23:48 ` [tip:timers/vdso] " tip-bot for Vincenzo Frascino 2019-06-21 9:52 ` [PATCH v7 07/25] arm64: compat: Expose signal related structures Vincenzo Frascino 2019-06-21 9:52 ` Vincenzo Frascino 2019-06-23 23:49 ` [tip:timers/vdso] " tip-bot for Vincenzo Frascino 2019-06-21 9:52 ` [PATCH v7 08/25] arm64: compat: Generate asm offsets for signals Vincenzo Frascino 2019-06-21 9:52 ` Vincenzo Frascino 2019-06-23 23:50 ` [tip:timers/vdso] " tip-bot for Vincenzo Frascino 2019-06-21 9:52 ` [PATCH v7 09/25] lib: vdso: Add compat support Vincenzo Frascino 2019-06-21 9:52 ` Vincenzo Frascino 2019-06-23 23:45 ` [tip:timers/vdso] lib/vdso: " tip-bot for Vincenzo Frascino 2019-06-21 9:52 ` [PATCH v7 10/25] arm64: compat: Add vDSO Vincenzo Frascino 2019-06-21 9:52 ` Vincenzo Frascino 2019-06-23 23:51 ` [tip:timers/vdso] " tip-bot for Vincenzo Frascino 2019-06-24 14:00 ` [PATCH v7 10/25] " Catalin Marinas 2019-06-24 14:00 ` Catalin Marinas 2019-06-24 14:00 ` Catalin Marinas 2019-06-25 7:50 ` [tip:timers/vdso] arm64: compat: No need for pre-ARMv7 barriers on an ARMv8 system tip-bot for Catalin Marinas 2019-06-26 12:36 ` tip-bot for Catalin Marinas 2019-07-10 4:02 ` [PATCH v7 10/25] arm64: compat: Add vDSO John Stultz 2019-07-10 4:02 ` John Stultz 2019-07-10 4:02 ` John Stultz 2019-07-10 6:12 ` Thomas Gleixner 2019-07-10 6:12 ` Thomas Gleixner 2019-07-10 6:12 ` Thomas Gleixner 2019-07-10 9:48 ` Vincenzo Frascino 2019-07-10 9:48 ` Vincenzo Frascino 2019-07-10 8:27 ` Will Deacon 2019-07-10 8:27 ` Will Deacon 2019-07-10 8:27 ` Will Deacon 2019-07-10 8:58 ` Thomas Gleixner 2019-07-10 8:58 ` Thomas Gleixner 2019-07-10 8:58 ` Thomas Gleixner 2019-07-10 9:12 ` Will Deacon 2019-07-10 9:12 ` Will Deacon 2019-07-10 9:12 ` Will Deacon 2019-07-10 9:47 ` Vincenzo Frascino 2019-07-10 9:47 ` Vincenzo Frascino 2019-07-10 9:47 ` Vincenzo Frascino 2019-07-10 13:41 ` Vincenzo Frascino 2019-07-10 13:41 ` Vincenzo Frascino 2019-07-10 13:41 ` Vincenzo Frascino 2019-07-10 13:04 ` [PATCH] arm64: vdso: Fix ABI regression in compat vdso Vincenzo Frascino 2019-07-10 13:04 ` Vincenzo Frascino 2019-07-10 13:25 ` Will Deacon 2019-07-10 13:25 ` Will Deacon 2019-07-10 13:42 ` Vincenzo Frascino 2019-07-10 13:42 ` Vincenzo Frascino 2019-07-10 14:01 ` [PATCH v2] " Vincenzo Frascino 2019-07-10 14:01 ` Vincenzo Frascino 2019-07-10 15:44 ` John Stultz 2019-07-10 15:44 ` John Stultz 2019-07-10 15:44 ` John Stultz 2019-07-10 15:53 ` Vincenzo Frascino 2019-07-10 15:53 ` Vincenzo Frascino 2019-07-10 15:53 ` Vincenzo Frascino 2019-07-11 9:45 ` Will Deacon 2019-07-11 9:45 ` Will Deacon 2019-07-11 10:34 ` Thomas Gleixner 2019-07-11 10:34 ` Thomas Gleixner 2019-07-11 11:32 ` Will Deacon 2019-07-11 11:32 ` Will Deacon 2019-06-21 9:52 ` [PATCH v7 11/25] arm64: Refactor vDSO code Vincenzo Frascino 2019-06-21 9:52 ` Vincenzo Frascino 2019-06-23 23:51 ` [tip:timers/vdso] arm64: vdso: " tip-bot for Vincenzo Frascino 2019-06-21 9:52 ` [PATCH v7 12/25] arm64: compat: vDSO setup for compat layer Vincenzo Frascino 2019-06-21 9:52 ` Vincenzo Frascino 2019-06-23 23:52 ` [tip:timers/vdso] arm64: compat: VDSO " tip-bot for Vincenzo Frascino 2019-06-21 9:52 ` [PATCH v7 13/25] arm64: elf: vDSO code page discovery Vincenzo Frascino 2019-06-21 9:52 ` Vincenzo Frascino 2019-06-23 23:53 ` [tip:timers/vdso] arm64: elf: VDSO " tip-bot for Vincenzo Frascino 2019-06-21 9:52 ` [PATCH v7 14/25] arm64: compat: Get sigreturn trampolines from vDSO Vincenzo Frascino 2019-06-21 9:52 ` Vincenzo Frascino 2019-06-23 23:53 ` [tip:timers/vdso] " tip-bot for Vincenzo Frascino 2019-06-21 9:52 ` [PATCH v7 15/25] arm64: Add vDSO compat support Vincenzo Frascino 2019-06-21 9:52 ` Vincenzo Frascino 2019-06-23 23:54 ` [tip:timers/vdso] arm64: vdso: Enable " tip-bot for Vincenzo Frascino 2019-06-21 9:52 ` [PATCH v7 16/25] arm: Add support for generic vDSO Vincenzo Frascino 2019-06-21 9:52 ` Vincenzo Frascino 2019-12-04 13:51 ` [PATCH v7 16/25] arm: Add support for generic vDSO (causing crash) Guenter Roeck 2019-12-04 13:51 ` Guenter Roeck 2019-12-04 13:51 ` Guenter Roeck 2019-12-04 13:58 ` Vincenzo Frascino 2019-12-04 13:58 ` Vincenzo Frascino 2019-12-04 13:58 ` Vincenzo Frascino 2019-12-04 16:16 ` Guenter Roeck 2019-12-04 16:16 ` Guenter Roeck 2019-12-04 16:16 ` Guenter Roeck 2019-12-04 17:15 ` Vincenzo Frascino 2019-12-04 17:15 ` Vincenzo Frascino 2019-12-04 17:15 ` Vincenzo Frascino 2019-12-04 19:39 ` Guenter Roeck 2019-12-04 19:39 ` Guenter Roeck 2019-12-04 19:39 ` Guenter Roeck 2019-12-05 9:42 ` Philippe Mathieu-Daudé 2019-12-05 9:42 ` Philippe Mathieu-Daudé 2019-12-05 9:42 ` Philippe Mathieu-Daudé 2019-12-05 10:00 ` Vincenzo Frascino 2019-12-05 10:00 ` Vincenzo Frascino 2019-12-05 11:02 ` Arnd Bergmann 2019-12-05 11:02 ` Arnd Bergmann 2019-12-05 11:02 ` Arnd Bergmann 2019-12-05 14:56 ` Philippe Mathieu-Daudé 2019-12-05 14:56 ` Philippe Mathieu-Daudé 2019-12-05 14:56 ` Philippe Mathieu-Daudé 2019-12-05 14:56 ` Philippe Mathieu-Daudé 2019-06-21 9:52 ` [PATCH v7 17/25] arm: Add clock_getres entry point Vincenzo Frascino 2019-06-21 9:52 ` Vincenzo Frascino 2019-06-21 9:52 ` [PATCH v7 18/25] arm: Add clock_gettime64 " Vincenzo Frascino 2019-06-21 9:52 ` Vincenzo Frascino 2019-06-21 9:52 ` [PATCH v7 19/25] mips: Add support for generic vDSO Vincenzo Frascino 2019-06-21 9:52 ` Vincenzo Frascino 2019-07-26 5:15 ` Paul Burton 2019-07-26 5:15 ` Paul Burton 2019-07-26 5:15 ` Paul Burton 2019-07-26 5:15 ` Paul Burton 2019-07-26 16:29 ` [PATCH 0/2] mips: vdso: Fix Makefile Vincenzo Frascino 2019-07-26 16:29 ` Vincenzo Frascino 2019-07-26 16:29 ` [PATCH 1/2] mips: vdso: Fix source path Vincenzo Frascino 2019-07-26 16:29 ` Vincenzo Frascino 2019-07-26 16:29 ` [PATCH 2/2] mips: vdso: Fix flip/flop vdso building bug Vincenzo Frascino 2019-07-26 16:29 ` Vincenzo Frascino 2019-07-28 22:20 ` [PATCH 0/2] mips: vdso: Fix Makefile Paul Burton 2019-07-28 22:20 ` Paul Burton 2019-07-28 22:20 ` Paul Burton 2019-07-28 22:20 ` Paul Burton 2019-06-21 9:52 ` [PATCH v7 20/25] mips: Add clock_getres entry point Vincenzo Frascino 2019-06-21 9:52 ` Vincenzo Frascino 2019-07-26 5:15 ` Paul Burton 2019-07-26 5:15 ` Paul Burton 2019-07-26 5:15 ` Paul Burton 2019-07-26 5:15 ` Paul Burton 2019-06-21 9:52 ` [PATCH v7 21/25] mips: Add clock_gettime64 " Vincenzo Frascino 2019-06-21 9:52 ` Vincenzo Frascino 2019-07-26 5:15 ` Paul Burton 2019-07-26 5:15 ` Paul Burton 2019-07-26 5:15 ` Paul Burton 2019-07-26 5:15 ` Paul Burton 2019-06-21 9:52 ` [PATCH v7 22/25] x86: Add support for generic vDSO Vincenzo Frascino 2019-06-21 9:52 ` Vincenzo Frascino 2019-06-23 23:55 ` [tip:timers/vdso] x86/vdso: Switch to generic vDSO implementation tip-bot for Vincenzo Frascino 2019-06-21 9:52 ` [PATCH v7 23/25] x86: Add clock_getres entry point Vincenzo Frascino 2019-06-21 9:52 ` Vincenzo Frascino 2019-06-23 23:56 ` [tip:timers/vdso] x86/vdso: Add clock_getres() " tip-bot for Vincenzo Frascino 2019-06-21 9:52 ` [PATCH v7 24/25] x86: Add clock_gettime64 " Vincenzo Frascino 2019-06-21 9:52 ` Vincenzo Frascino 2019-06-23 23:56 ` [tip:timers/vdso] x86/vdso: Add clock_gettime64() " tip-bot for Vincenzo Frascino 2019-06-21 9:52 ` [PATCH v7 25/25] kselftest: Extend vDSO selftest Vincenzo Frascino 2019-06-21 9:52 ` Vincenzo Frascino 2019-06-24 0:34 ` [PATCH v7 00/25] Unify vDSOs across more architectures Thomas Gleixner 2019-06-24 0:34 ` Thomas Gleixner 2019-06-24 0:34 ` Thomas Gleixner 2019-06-24 1:15 ` Andy Lutomirski 2019-06-24 1:15 ` Andy Lutomirski 2019-06-24 1:15 ` Andy Lutomirski 2019-06-24 1:15 ` Andy Lutomirski 2019-06-24 7:42 ` Thomas Gleixner 2019-06-24 7:42 ` Thomas Gleixner 2019-06-24 7:42 ` Thomas Gleixner 2019-06-24 7:42 ` Thomas Gleixner 2019-06-24 13:21 ` Vincenzo Frascino 2019-06-24 13:21 ` Vincenzo Frascino 2019-06-24 13:21 ` Vincenzo Frascino 2019-06-24 14:18 ` Thomas Gleixner 2019-06-24 14:18 ` Thomas Gleixner 2019-06-24 14:18 ` Thomas Gleixner 2019-06-24 14:23 ` Russell King - ARM Linux admin 2019-06-24 14:23 ` Russell King - ARM Linux admin 2019-06-24 14:23 ` Russell King - ARM Linux admin 2019-06-24 14:49 ` Catalin Marinas 2019-06-24 14:49 ` Catalin Marinas 2019-06-24 14:49 ` Catalin Marinas 2019-06-24 16:20 ` Vincenzo Frascino 2019-06-24 16:20 ` Vincenzo Frascino 2019-06-24 16:20 ` Vincenzo Frascino 2019-10-25 11:42 ` Geert Uytterhoeven 2019-10-25 11:42 ` Geert Uytterhoeven 2019-10-25 11:42 ` Geert Uytterhoeven 2019-10-25 11:42 ` Geert Uytterhoeven 2019-06-24 18:41 ` Paul Burton 2019-06-24 18:41 ` Paul Burton 2019-06-24 18:41 ` Paul Burton 2019-06-24 23:16 ` Vincenzo Frascino 2019-06-24 23:16 ` Vincenzo Frascino 2019-06-24 23:16 ` Vincenzo Frascino 2019-06-24 23:16 ` Vincenzo Frascino 2019-06-25 17:11 ` Paul Burton 2019-06-25 17:11 ` Paul Burton 2019-06-25 17:11 ` Paul Burton 2019-06-25 17:17 ` Vincenzo Frascino 2019-06-25 17:17 ` Vincenzo Frascino 2019-06-25 17:17 ` Vincenzo Frascino 2019-06-25 7:51 ` [tip:timers/vdso] MAINTAINERS: Add entry for the generic VDSO library tip-bot for Thomas Gleixner 2019-06-26 12:36 ` tip-bot for Thomas Gleixner 2019-06-26 15:41 ` Joe Perches 2019-06-26 15:41 ` Joe Perches 2019-06-26 16:31 ` Andy Lutomirski 2019-06-26 16:31 ` Andy Lutomirski 2019-06-26 16:38 ` Thomas Gleixner 2019-06-26 16:38 ` Thomas Gleixner 2019-06-24 12:50 ` [PATCH v7 00/25] Unify vDSOs across more architectures Andre Przywara 2019-06-24 12:50 ` Andre Przywara 2019-06-24 12:50 ` Andre Przywara
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190627100150.GC2790@e103592.cambridge.arm.com \ --to=dave.martin@arm.com \ --cc=0x7f454c46@gmail.com \ --cc=andre.przywara@arm.com \ --cc=arnd@arndb.de \ --cc=catalin.marinas@arm.com \ --cc=daniel.lezcano@linaro.org \ --cc=huw@codeweavers.com \ --cc=linux-arch@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-kselftest@vger.kernel.org \ --cc=linux-mips@vger.kernel.org \ --cc=linux@armlinux.org.uk \ --cc=linux@rasmusvillemoes.dk \ --cc=paul.burton@mips.com \ --cc=pcc@google.com \ --cc=ralf@linux-mips.org \ --cc=salyzyn@android.com \ --cc=shuah@kernel.org \ --cc=sthotton@marvell.com \ --cc=tglx@linutronix.de \ --cc=vincenzo.frascino@arm.com \ --cc=will.deacon@arm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.