search for: linutronix

> On Sep 14, 2018, at 5:50 AM, Thomas Gleixner <tglx at linutronix.de> wrote: > > With the storage array in place it's now trivial to support CLOCK_TAI in > the vdso. Instead of extending the array to accomodate CLOCK_TAI, make use > of the fact that: > > - CLOCK ids are set in stone > - CLOCK_THREAD_CPUTIME is never going to be suppo...

> On Sep 14, 2018, at 5:50 AM, Thomas Gleixner <tglx at linutronix.de> wrote: > > With the storage array in place it's now trivial to support CLOCK_TAI in > the vdso. Instead of extending the array to accomodate CLOCK_TAI, make use > of the fact that: > > - CLOCK ids are set in stone > - CLOCK_THREAD_CPUTIME is never going to be suppo...

Matt attempted to add CLOCK_TAI support to the VDSO clock_gettime() implementation, which extended the clockid switch case and added yet another slightly different copy of the same code. Especially the extended switch case is problematic as the compiler tends to generate a jump table which then requires to use retpolines. If jump tables are disabled it adds yet another conditional to the existing

Matt attempted to add CLOCK_TAI support to the VDSO clock_gettime() implementation, which extended the clockid switch case and added yet another slightly different copy of the same code. Especially the extended switch case is problematic as the compiler tends to generate a jump table which then requires to use retpolines. If jump tables are disabled it adds yet another conditional to the existing

> From: Thomas Gleixner [mailto:tglx at linutronix.de] > Sent: Saturday, February 11, 2017 02:02 > ... > That's important if the stuff happens cross CPU. If the update happens on > the same CPU then this is a different story and as there are VMexits > involved they might provide the required ordering already. But I can't tel...

> From: Thomas Gleixner [mailto:tglx at linutronix.de] > Sent: Saturday, February 11, 2017 02:02 > ... > That's important if the stuff happens cross CPU. If the update happens on > the same CPU then this is a different story and as there are VMexits > involved they might provide the required ordering already. But I can't tel...

> On Sep 18, 2018, at 3:46 PM, Thomas Gleixner <tglx at linutronix.de> wrote: > > On Tue, 18 Sep 2018, Andy Lutomirski wrote: >>> On Sep 18, 2018, at 12:52 AM, Thomas Gleixner <tglx at linutronix.de> wrote: >>> >>>>> On Mon, 17 Sep 2018, John Stultz wrote: >>>>> On Mon, Sep 17, 2018 at 12:25 PM, Andy...

> On Sep 18, 2018, at 3:46 PM, Thomas Gleixner <tglx at linutronix.de> wrote: > > On Tue, 18 Sep 2018, Andy Lutomirski wrote: >>> On Sep 18, 2018, at 12:52 AM, Thomas Gleixner <tglx at linutronix.de> wrote: >>> >>>>> On Mon, 17 Sep 2018, John Stultz wrote: >>>>> On Mon, Sep 17, 2018 at 12:25 PM, Andy...

Thomas Gleixner <tglx at linutronix.de> writes: > Runtime validate the VCLOCK_MODE in clocksource::archdata and disable > VCLOCK if invalid, which disables the VDSO but keeps the system running. > > Signed-off-by: Thomas Gleixner <tglx at linutronix.de> > --- > arch/x86/Kconfig | 1 + > arch/x...

> On Sep 14, 2018, at 7:27 AM, Thomas Gleixner <tglx at linutronix.de> wrote: > > On Fri, 14 Sep 2018, Andy Lutomirski wrote: >>> On Sep 14, 2018, at 5:50 AM, Thomas Gleixner <tglx at linutronix.de> wrote: >>> >>> With the storage array in place it's now trivial to support CLOCK_TAI in >>> the vdso. Instead...

...ing multi-instance hotplug callbacks. This order avoids the warning issued from __cpuhp_remove_state_cpuslocked when the number of remaining instances isn't yet zero. Fixes: 8017c279196a ("net/virtio-net: Convert to hotplug state machine") Cc: Sebastian Andrzej Siewior <bigeasy at linutronix.de> Signed-off-by: Andrew Jones <drjones at redhat.com> --- drivers/net/virtio_net.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index 99a26a9efec1..f41ab0ea942a 100644 --- a/drivers/net/virtio_net.c +++ b/drivers...

...ing multi-instance hotplug callbacks. This order avoids the warning issued from __cpuhp_remove_state_cpuslocked when the number of remaining instances isn't yet zero. Fixes: 8017c279196a ("net/virtio-net: Convert to hotplug state machine") Cc: Sebastian Andrzej Siewior <bigeasy at linutronix.de> Signed-off-by: Andrew Jones <drjones at redhat.com> --- drivers/net/virtio_net.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index 99a26a9efec1..f41ab0ea942a 100644 --- a/drivers/net/virtio_net.c +++ b/drivers...

Matt attempted to add CLOCK_TAI support to the VDSO clock_gettime() implementation, which extended the clockid switch case and added yet another slightly different copy of the same code. Especially the extended switch case is problematic as the compiler tends to generate a jump table which then requires to use retpolines. If jump tables are disabled it adds yet another conditional to the existing

On Fri, 14 Sep 2018, Arnd Bergmann wrote: > On Fri, Sep 14, 2018 at 2:52 PM Thomas Gleixner <tglx at linutronix.de> wrote: > A couple of architectures (s390, ia64, riscv, powerpc, arm64) > implement the vdso as assembler code at the moment, so they > won't be as easy to consolidate (other than outright replacing all > the code). > > The other five: > arch/x86/entry/vdso/vclock_ge...

On Thu, 9 Feb 2017, Vitaly Kuznetsov wrote: > +#ifdef CONFIG_HYPERV_TSCPAGE > +static notrace u64 vread_hvclock(int *mode) > +{ > + const struct ms_hyperv_tsc_page *tsc_pg = > + (const struct ms_hyperv_tsc_page *)&hvclock_page; > + u64 sequence, scale, offset, current_tick, cur_tsc; > + > + while (1) { > + sequence = READ_ONCE(tsc_pg->tsc_sequence); > + if

On Thu, 9 Feb 2017, Vitaly Kuznetsov wrote: > +#ifdef CONFIG_HYPERV_TSCPAGE > +static notrace u64 vread_hvclock(int *mode) > +{ > + const struct ms_hyperv_tsc_page *tsc_pg = > + (const struct ms_hyperv_tsc_page *)&hvclock_page; > + u64 sequence, scale, offset, current_tick, cur_tsc; > + > + while (1) { > + sequence = READ_ONCE(tsc_pg->tsc_sequence); > + if

> On Sep 18, 2018, at 12:52 AM, Thomas Gleixner <tglx at linutronix.de> wrote: > >> On Mon, 17 Sep 2018, John Stultz wrote: >>> On Mon, Sep 17, 2018 at 12:25 PM, Andy Lutomirski <luto at kernel.org> wrote: >>> Also, I'm not entirely convinced that this "last" thing is needed at >>> all. John, what's t...

> On Sep 18, 2018, at 12:52 AM, Thomas Gleixner <tglx at linutronix.de> wrote: > >> On Mon, 17 Sep 2018, John Stultz wrote: >>> On Mon, Sep 17, 2018 at 12:25 PM, Andy Lutomirski <luto at kernel.org> wrote: >>> Also, I'm not entirely convinced that this "last" thing is needed at >>> all. John, what's t...

On Wed, 19 Sep 2018, Thomas Gleixner wrote: > On Tue, 18 Sep 2018, Andy Lutomirski wrote: > > > On Sep 18, 2018, at 3:46 PM, Thomas Gleixner <tglx at linutronix.de> wrote: > > > On Tue, 18 Sep 2018, Andy Lutomirski wrote: > > >> Do we do better if we use signed arithmetic for the whole calculation? > > >> Then a small backwards movement would result in a small backwards result. > > >> Or we could offset every...

...r <mrhinelander at gmail.com> Date: Sun, May 31, 2009 at 1:28 AM Subject: BUG: Documentation/lguest/lguest.c bad paths for includes cause make to fail To: mm-commits at vger.kernel.org, kraai at ftbfs.org, rusty at rustcorp.com.au, Andi Kleen <ak at suse.de>, Thomas Gleixner <tglx at linutronix.de>, Ingo Molnar <mingo at elte.hu> 2.6.28-rc2-mm1 make fails at Documentation/lguest/lguest.c ?Two includes have bad paths: line 34 #include <zlib.h> (maybe should be linux/zlib.h?), and line 47 #include "asm-x86/bootparam.h" Are incorrect paths related to this recent g...