Re: [PATCH v5] reboot: support offline CPUs before reboot

Hsin-Yi Wang writes: > Currently system reboots uses architecture specific codes (smp_send_stop) > to offline non reboot CPUs. Most architecture's implementation is looping > through all non reboot online CPUs and call ipi function to each of them. Some > architecture like arm64, arm, and x86...

Re: [RFC PATCH v3 08/12] lib: vdso: allow arches to provide vdso data pointer

Christophe Leroy writes: > > static __maybe_unused int > +#ifdef VDSO_GETS_VD_PTR_FROM_ARCH > +__cvdso_clock_gettime_common(const struct vdso_data *vd, clockid_t clock, > + struct __kernel_timespec *ts) > +{ > +#else > __cvdso_clock_gettime_common(clockid_t clock, struct

Re: [PATCH RESEND v4] reboot: support offline CPUs before reboot

Hsin-Yi Wang writes: > > Signed-off-by: Hsin-Yi Wang > --- > Resend v4: > * Cc more people and mailing lists. Also fix a few nits from v4. Please don't name it resend if you actually changed the patch. Resend wants to be an unmodified patch and the only reasons to do that are: - add more

Re: [RFC PATCH v3 06/12] lib: vdso: __iter_div_u64_rem() is suboptimal for 32 bit time

Christophe Leroy writes: > Using __iter_div_ulong_rem() is suboptimal on 32 bits. > Nanoseconds are only 32 bits, and VDSO data is updated every 10ms > so nsec will never overflow 32 bits. That's theory and perhaps true for bare metal, but there is no guarantee on VIRT that the CPU which has

Re: [PATCH] lib: vdso: mark __cvdso_clock_getres() as static

Christophe Leroy writes: > Is there a git tree with the latest VDSO status ? > > https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git?h=timers%2Fvdso > is 6 monthes old. Will push a new one later today. I'll let you know. Thanks, tglx

Re: [PATCH] lib: vdso: mark __cvdso_clock_getres() as static

Christophe Leroy writes: > When __cvdso_clock_getres() became __cvdso_clock_getres_common() > and a new __cvdso_clock_getres() was added, static qualifier was > forgotten. > > Fixes: 502a590a170b ("lib/vdso: Move fallback invocation to the callers") > Signed-off-by: Christophe Leroy I've

Re: [RFC PATCH v2 07/10] lib: vdso: don't use READ_ONCE() in __c_kernel_time()

Christophe Leroy writes: > > With READ_ONCE() the 64 bits are being read: > > Without the READ_ONCE() only 32 bits are read. That's the most optimal. > > Without READ_ONCE() but with a barrier() after the read, we should get > the same result but GCC (GCC 8.1) does less good: > > Assuming both

Re: [RFC PATCH] powerpc/32: Switch VDSO to C implementation.

Christophe, Christophe Leroy writes: > On 01/09/2020 02:05 PM, Thomas Gleixner wrote: >> The reason why this is implemented in this way is that >> __arch_get_hw_counter() needs a way to express that the clocksource of >> the moment is not suitable for VDSO so that the

Re: [RFC PATCH v2 07/10] lib: vdso: don't use READ_ONCE() in __c_kernel_time()

Christophe Leroy writes: > > diff --git a/lib/vdso/gettimeofday.c b/lib/vdso/gettimeofday.c > index 17b4cff6e5f0..5a17a9d2e6cd 100644 > --- a/lib/vdso/gettimeofday.c > +++ b/lib/vdso/gettimeofday.c > @@ -144,7 +144,7 @@ __cvdso_gettimeofday(const struct vdso_data *vd, struct >

Re: [RFC PATCH v2 05/10] lib: vdso: inline do_hres()

Arnd Bergmann writes: > On Mon, Dec 23, 2019 at 3:31 PM Christophe Leroy > wrote: >> >> do_hres() is called from several places, so GCC doesn't inline >> it at first. >> >> do_hres() takes a struct __kernel_timespec * parameter for >> passing the result. In the 32 bits case, this parameter

Re: [RFC PATCH v2 01/10] lib: vdso: ensure all arches have 32bit fallback

Andy Lutomirski writes: > On Mon, Dec 23, 2019 at 6:31 AM Christophe Leroy > wrote: >> >> In order to simplify next step which moves fallback call at arch >> level, ensure all arches have a 32bit fallback instead of handling >> the lack of 32bit fallback in the common code based >> on

Re: [RFC PATCH] powerpc/32: Switch VDSO to C implementation.

Christophe! Christophe Leroy writes: > In do_hres(), I see: > > cycles = __arch_get_hw_counter(vd->clock_mode); > ns = vdso_ts->nsec; > last = vd->cycle_last; > if (unlikely((s64)cycles < 0)) > return -1; > >

[tip: sched/urgent] sched/rt, powerpc: Use CONFIG_PREEMPTION

The following commit has been merged into the sched/urgent branch of tip: Commit-ID: fdc5569eaba997852e0bfb57d11af496e4c1fa9a Gitweb: https://git.kernel.org/tip/fdc5569eaba997852e0bfb57d11af496e4c1fa9a Author:Thomas Gleixner AuthorDate:Thu, 24 Oct 2019 18:04:58 +02:00

Re: [PATCH 00/12] Convert cpu_up/down to device_online/offline

On Mon, 18 Nov 2019, Qais Yousef wrote: > I had to make an educated guess that you're probably the 'maintainer' of cpu > hotplug - but there's no explicit entry that says that. Please let me know if > I need to bring the attention of others too. :) > The series do have few rough edges to

Re: [PATCH 03/23] y2038: vdso: change timeval to __kernel_old_timeval

the 'timeval' definition from the > kernel sources. > > Signed-off-by: Arnd Bergmann Reviewed-by: Thomas Gleixner

Re: [RFC PATCH] powerpc/32: Switch VDSO to C implementation.

On Sat, 26 Oct 2019, Christophe Leroy wrote: > Le 26/10/2019 à 17:53, Thomas Gleixner a écrit : > > > > > > gettimeofday:    vdso: 750 nsec/call > > > > > > > > > > > > gettimeofday:    vdso: 1533 nsec/call > &g

Re: [RFC PATCH] powerpc/32: Switch VDSO to C implementation.

On Tue, 22 Oct 2019, Christophe Leroy wrote: > Le 22/10/2019 à 11:01, Christophe Leroy a écrit : > > Le 21/10/2019 à 23:29, Thomas Gleixner a écrit : > > > On Mon, 21 Oct 2019, Christophe Leroy wrote: > > > > > > > This is a tentative to switch powerpc/32 v

Re: [RFC PATCH] powerpc/32: Switch VDSO to C implementation.

On Mon, 21 Oct 2019, Christophe Leroy wrote: > This is a tentative to switch powerpc/32 vdso to generic C implementation. > It will likely not work on 64 bits or even build properly at the moment. > > powerpc is a bit special for VDSO as well as system calls in the > way that it requires setting

[PATCH] lib/vdso: Make clock_getres() POSIX compliant again

eas Schwab Signed-off-by: Thomas Gleixner Cc: sta...@vger.kernel.org --- lib/vdso/gettimeofday.c |9 + 1 file changed, 5 insertions(+), 4 deletions(-) --- a/lib/vdso/gettimeofday.c +++ b/lib/vdso/gettimeofday.c @@ -214,9 +214,10 @@ int __cvdso_clock_getres_common(clockid_

Re: passing NULL to clock_getres (VDSO): terminated by unexpected signal 11

On Sun, 20 Oct 2019, Andreas Schwab wrote: > On Okt 20 2019, Thomas Gleixner wrote: > > > POSIX does not mention anything about the validity of the pointer handed to > > clock_getres(). > > Sure it does: "If the argument res is not NULL, the resolution of the >

Re: passing NULL to clock_getres (VDSO): terminated by unexpected signal 11

On Sun, 20 Oct 2019, Andreas Schwab wrote: > On Okt 20 2019, Thomas Gleixner wrote: > > > clock_getres(NULL) is hardly valid. > > Of course not, it lacks a parameter. You know exactly what I mean. > > So special casing > > > > clock_getres(clock, NUL

Re: passing NULL to clock_getres (VDSO): terminated by unexpected signal 11

On Sun, 20 Oct 2019, Christophe Leroy wrote: > Adding Thomas to the discussion as the commit is from him. > > Le 20/10/2019 à 11:53, Andreas Schwab a écrit : > > On Okt 20 2019, Christophe Leroy wrote: > > > > > Le 19/10/2019 à 21:18, Andreas Schwab a écrit : > > > > On Okt 19 2019, Christophe

Re: [PATCH v2 3/5] x86: Kconfig: Remove CONFIG_NODES_SPAN_OTHER_NODES

On Thu, 11 Jul 2019, Hoan Tran OS wrote: > Remove CONFIG_NODES_SPAN_OTHER_NODES as it's enabled > by default with NUMA. As I told you before this does not mention that the option is now enabled even for x86(32bit) configurations which did not enable it before and does not longer depend on

Re: [PATCH 2/3] DMA mapping: Move SME handling to x86-specific files

On Fri, 12 Jul 2019, Thiago Jung Bauermann wrote: > diff --git a/include/linux/mem_encrypt.h b/include/linux/mem_encrypt.h > index b310a9c18113..f2e399fb626b 100644 > --- a/include/linux/mem_encrypt.h > +++ b/include/linux/mem_encrypt.h > @@ -21,23 +21,11 @@ > > #else/*

Re: [PATCH 1/3] x86/Kconfig: Move ARCH_HAS_MEM_ENCRYPT to arch/Kconfig

On Fri, 12 Jul 2019, Thiago Jung Bauermann wrote: > powerpc and s390 are going to use this feature as well, so put it in a > generic location. > > Signed-off-by: Thiago Jung Bauermann Reviewed-by: Thomas Gleixner

Re: [PATCH 3/5] x86: Kconfig: Remove CONFIG_NODES_SPAN_OTHER_NODES

Hoan, On Wed, 10 Jul 2019, Hoan Tran OS wrote: > On 6/25/19 3:45 PM, Thomas Gleixner wrote: > > On Tue, 25 Jun 2019, Hoan Tran OS wrote: > >> @@ -1567,15 +1567,6 @@ config X86_64_ACPI_NUMA > >>---help--- > >> Enable ACPI SRAT based node topology detect

Re: [PATCH 3/5] x86: Kconfig: Remove CONFIG_NODES_SPAN_OTHER_NODES

Hoan, On Tue, 25 Jun 2019, Hoan Tran OS wrote: Please use 'x86/Kconfig: ' as prefix. > This patch removes CONFIG_NODES_SPAN_OTHER_NODES as it's > enabled by default with NUMA. Please do not use 'This patch' in changelogs. It's pointless because we already know that this is a patch. See also

Re: [PATCH 4/5] x86: don't use asm-generic/ptrace.h

h Hellwig > Acked-by: Ingo Molnar > Acked-by: Oleg Nesterov Reviewed-by: Thomas Gleixner

Re: remove asm-generic/ptrace.h v3

On Mon, 24 Jun 2019, Christoph Hellwig wrote: > > asm-generic/ptrace.h is a little weird in that it doesn't actually > implement any functionality, but it provided multiple layers of macros > that just implement trivial inline functions. We implement those > directly in the few architectures and

Re: [PATCH v2 5/5] arm64/speculation: Support 'mitigations=' cmdline option

On Wed, 24 Apr 2019, Will Deacon wrote: > Hi Thomas, > > On Tue, Apr 16, 2019 at 09:26:13PM +0200, Thomas Gleixner wrote: > > On Fri, 12 Apr 2019, Josh Poimboeuf wrote: > > > > > Configure arm64 runtime CPU speculation bug mitigations in accordance > > >

Re: [PATCH] kernel/crash: make parse_crashkernel()'s return value more indicant

On Fri, 19 Apr 2019, Pingfan Liu wrote: > At present, both return and crash_size should be checked to guarantee the > success of parse_crashkernel(). > Simplify the way by returning negative if fail, positive if success. In > case of failure, -EINVAL for bad syntax, -1 for the parsing results in

Re: [PATCH v2 5/5] arm64/speculation: Support 'mitigations=' cmdline option

On Fri, 12 Apr 2019, Josh Poimboeuf wrote: > Configure arm64 runtime CPU speculation bug mitigations in accordance > with the 'mitigations=' cmdline option. This affects Meltdown, Spectre > v2, and Speculative Store Bypass. > > The default behavior is unchanged. > > Signed-off-by: Josh

Re: [PATCH 1/2] ASoC: mpc5200_dma: Fix invalid license ID

On Mon, 15 Apr 2019, Daniel Baluta wrote: > On Mon, Apr 15, 2019 at 10:26 AM Daniel Baluta > wrote: > > On Mon, Apr 15, 2019 at 12:53 AM Fabio Estevam wrote: > > > On Sun, Apr 14, 2019 at 4:15 PM Andra Danciu > > > wrote: > > > > -// SPDX-License-Identifier: GPL > > > > +//

Re: [PATCH 1/2] ASoC: mpc5200_dma: Fix invalid license ID

t; > Cc: Daniel Baluta > > Fixes: 1edfc2485d8dc ("ASoC: mpc5200_dma: Switch to SPDX identifier") > > Reported-by: Thomas Gleixner > > Signed-off-by: Andra Danciu > > --- > > sound/soc/fsl/mpc5200_dma.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion

Re: [PATCH RFC 1/5] cpu/speculation: Add 'cpu_spec_mitigations=' cmdline options

On Wed, 10 Apr 2019, Michael Ellerman wrote: > Josh Poimboeuf writes: > > > On Fri, Apr 05, 2019 at 06:01:36PM +0200, Borislav Petkov wrote: > >> Thinking about this more, we can shave off the first 4 chars and have it > >> be: > >> > >> spec_mitigations= > >> > >> I think it is painfully

Re: [PATCH v4 0/6] normalize IOMMU dma mode boot options

On Mon, 8 Apr 2019, Leizhen (ThunderTown) wrote: > > > > This will break systems using boot options as now, and I think > > this is unacceptable. If you want to do so, just introduce iommu.dma_mode > > on top of those iommu boot options with dma mode boot options unchanged, > > and iommu.dma_mode

Re: [PATCH 6/6 v3] syscalls: Remove start and number from syscall_set_arguments() args

l_set_arguments(). But we are told that > there will be soon. But for now, at least make it consistent with > syscall_get_arguments(). > > Link: http://lkml.kernel.org/r/20190327222014.ga32...@altlinux.org For x86: Reviewed-by: Thomas Gleixner

Re: [PATCH 5/6 v3] syscalls: Remove start and number from syscall_get_arguments() args

ver used, simply rewrite it to return the first 6 > arguments of a system call. > > This should help out the performance of tracing system calls by ptrace, > ftrace and perf. > > Link: http://lkml.kernel.org/r/20161107213233.754809...@goodmis.org For x86: Reviewed-by: Thomas Gleixner

Re: [PATCH 3/5] s390: Fix vDSO clock_getres()

On Wed, 3 Apr 2019, Martin Schwidefsky wrote: > On Mon, 1 Apr 2019 12:51:50 +0100 > Vincenzo Frascino wrote: > > > clock_getres in the vDSO library has to preserve the same behaviour > > of posix_get_hrtimer_res(). > > > > In particular, posix_get_hrtimer_res() does: > > sec = 0; > >

Re: [RFC PATCH v2 10/14] kernel/watchdog: Add a function to obtain the watchdog_allowed_mask

On Wed, 27 Feb 2019, Ricardo Neri wrote: > > -struct cpumask watchdog_allowed_mask __read_mostly; > +static struct cpumask watchdog_allowed_mask __read_mostly; That hunk is correct. > struct cpumask watchdog_cpumask __read_mostly; > unsigned long *watchdog_cpumask_bits =

Re: [RFC PATCH v2 09/14] watchdog/hardlockup: Make arch_touch_nmi_watchdog() to hpet-based implementation

On Thu, 28 Feb 2019, Ricardo Neri wrote: > > > > > > -#if defined(CONFIG_HARDLOCKUP_DETECTOR_PERF) > > > +#if defined(CONFIG_HARDLOCKUP_DETECTOR_PERF) || \ > > > +defined(CONFIG_X86_HARDLOCKUP_DETECTOR_HPET) > > > > Why not instead make CONFIG_X86_HARDLOCKUP_DETECTOR_HPET select > >

Re: [RFC PATCH v2 08/14] watchdog/hardlockup: Decouple the hardlockup detector from perf

On Wed, 27 Feb 2019, Ricardo Neri wrote: > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Detect hard lockups on a system > + * > + * Copyright (C) Intel Corporation 2019 > + * > + * Note: All of this code comes from the original perf-specific hardlockup > + * detector. And because you copied

Re: PROBLEM: monotonic clock going backwards on ppc64

On Sat, 2 Mar 2019, Michael Ellerman wrote: > > The problem seems to be in vDSO code in > > arch/powerpc/kernel/vdso64/gettimeofday.S. > > You're right, the wall-to-monotonic offset (wtom_clock_sec) is a signed > 32-bit value, so that seems like it's going to have problems. > > If I do `date -s

Re: [PATCH] powerpc/irq: drop arch_early_irq_init()

ixes: 089fb442f301 ("powerpc: Use ARCH_IRQ_INIT_FLAGS") > > Cc: Thomas Gleixner > > Signed-off-by: Christophe Leroy Acked-by: Thomas Gleixner

Re: [PATCH V4 2/15] KVM/MMU: Add tlb flush with range helper function

On Sun, 14 Oct 2018, Liran Alon wrote: > > On 13 Oct 2018, at 17:53, lantianyu1...@gmail.com wrote: > > > > From: Lan Tianyu > > > > This patch is to add wrapper functions for tlb_remote_flush_with_range > > callback. > > > > Signed-off-by: Lan Tianyu > > --- > > Change sicne V3: > >

Re: move bus (PCI, PCMCIA, EISA, rapdio) config to drivers/

> (when needed) and then handles everything in the bus-specific > Kconfig file under drivers/. Nice cleanup. Acked-by: Thomas Gleixner

Re: [PATCH] PCI: call dma_debug_add_bus for pci_bus_type in common code

On Mon, 30 Jul 2018, Christoph Hellwig wrote: > There is nothing arch specific about PCI or dma-debug, so move this > call to common code just after registering the bus type. > > Signed-off-by: Christoph Hellwig Acked-by: Thomas Gleixner

Re: [PATCH] Documentation: Add powerpc options for spec_store_bypass_disable

instead. Happy to take > advice on how better to structure it if anyone has opinions. Looks good to me. Acked-by: Thomas Gleixner

Re: [RFC PATCH 17/23] watchdog/hardlockup/hpet: Convert the timer's interrupt to NMI

On Tue, 19 Jun 2018, Ricardo Neri wrote: > On Sat, Jun 16, 2018 at 03:24:49PM +0200, Thomas Gleixner wrote: > > The status register is useless in case of MSI. MSI is edge triggered > > > > The only register which gives you proper information is the counter > >

Re: [RFC PATCH 03/23] genirq: Introduce IRQF_DELIVER_AS_NMI

On Fri, 15 Jun 2018, Ricardo Neri wrote: > On Fri, Jun 15, 2018 at 09:01:02AM +0100, Julien Thierry wrote: > > In my patches, I'm not sure there is much to adapt to your work as most of > > it is arch specific (although I wont say no to another pair of eyes looking > > at them). From what I've

Re: [RFC PATCH 20/23] watchdog/hardlockup/hpet: Rotate interrupt among all monitored CPUs

On Fri, 15 Jun 2018, Ricardo Neri wrote: > On Fri, Jun 15, 2018 at 12:29:06PM +0200, Thomas Gleixner wrote: > > You have to consider two cases: > > > > 1) !remapped mode: > > > > That's reasonably simple because you just have to deal with the HPET >

Re: [RFC PATCH 17/23] watchdog/hardlockup/hpet: Convert the timer's interrupt to NMI

On Fri, 15 Jun 2018, Ricardo Neri wrote: > On Fri, Jun 15, 2018 at 11:19:09AM +0200, Thomas Gleixner wrote: > > On Thu, 14 Jun 2018, Ricardo Neri wrote: > > > Alternatively, there could be a counter that skips reading the HPET status > > > register (and the detection

Re: [RFC PATCH 20/23] watchdog/hardlockup/hpet: Rotate interrupt among all monitored CPUs

On Thu, 14 Jun 2018, Ricardo Neri wrote: > On Wed, Jun 13, 2018 at 11:48:09AM +0200, Thomas Gleixner wrote: > > On Tue, 12 Jun 2018, Ricardo Neri wrote: > > > + /* There are no CPUs to monitor. */ > > > + if (!cpumask_weight(>monitored_mask)) >

Re: [RFC PATCH 17/23] watchdog/hardlockup/hpet: Convert the timer's interrupt to NMI

On Thu, 14 Jun 2018, Ricardo Neri wrote: > On Wed, Jun 13, 2018 at 11:40:00AM +0200, Thomas Gleixner wrote: > > On Tue, 12 Jun 2018, Ricardo Neri wrote: > > > @@ -183,6 +184,8 @@ static irqreturn_t > > > hardlockup_detector_irq_handler(int irq, void *data)

Re: [RFC PATCH 12/23] kernel/watchdog: Introduce a struct for NMI watchdog operations

On Thu, 14 Jun 2018, Nicholas Piggin wrote: > On Wed, 13 Jun 2018 18:31:17 -0700 > > I could look into creating the library for > > common code and relocate the hpet watchdog into arch/x86 for the hpet- > > specific parts. > > If you can investigate that approach, that would be appreciated. I

Re: [RFC PATCH 03/23] genirq: Introduce IRQF_DELIVER_AS_NMI

On Wed, 13 Jun 2018, Julien Thierry wrote: > On 13/06/18 10:20, Thomas Gleixner wrote: > > Adding NMI delivery support at low level architecture irq chip level is > > perfectly fine, but the exposure of that needs to be restricted very > > much. Adding it to the gene

Re: [RFC PATCH 20/23] watchdog/hardlockup/hpet: Rotate interrupt among all monitored CPUs

On Tue, 12 Jun 2018, Ricardo Neri wrote: > + /* There are no CPUs to monitor. */ > + if (!cpumask_weight(>monitored_mask)) > + return NMI_HANDLED; > + > inspect_for_hardlockups(regs); > > + /* > + * Target a new CPU. Keep trying until we find a monitored CPU.

Re: [RFC PATCH 17/23] watchdog/hardlockup/hpet: Convert the timer's interrupt to NMI

On Tue, 12 Jun 2018, Ricardo Neri wrote: > @@ -183,6 +184,8 @@ static irqreturn_t hardlockup_detector_irq_handler(int > irq, void *data) > if (!(hdata->flags & HPET_DEV_PERI_CAP)) > kick_timer(hdata); > > + pr_err("This interrupt should not have happened. Ensure delivery

Re: [RFC PATCH 03/23] genirq: Introduce IRQF_DELIVER_AS_NMI

On Wed, 13 Jun 2018, Julien Thierry wrote: > On 13/06/18 09:34, Peter Zijlstra wrote: > > On Tue, Jun 12, 2018 at 05:57:23PM -0700, Ricardo Neri wrote: > > > diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h > > > index 5426627..dbc5e02 100644 > > > --- a/include/linux/interrupt.h

Re: [RFC PATCH 12/23] kernel/watchdog: Introduce a struct for NMI watchdog operations

On Wed, 13 Jun 2018, Peter Zijlstra wrote: > On Wed, Jun 13, 2018 at 05:41:41PM +1000, Nicholas Piggin wrote: > > On Tue, 12 Jun 2018 17:57:32 -0700 > > Ricardo Neri wrote: > > > > > Instead of exposing individual functions for the operations of the NMI > > > watchdog, define a common interface

Re: Occasionally losing the tick_sched_timer

On Tue, 10 Apr 2018, Nicholas Piggin wrote: > On Tue, 10 Apr 2018 09:42:29 +0200 (CEST) > Thomas Gleixner <t...@linutronix.de> wrote: > > > Thomas do you have any ideas on what we might look for, or if we can add > > > some BUG_ON()s to catch this at its source?

Re: Occasionally losing the tick_sched_timer

Nick, On Tue, 10 Apr 2018, Nicholas Piggin wrote: > We are seeing rare hard lockup watchdog timeouts, a CPU seems to have no > more timers scheduled, despite hard and soft lockup watchdogs should have > their heart beat timers and probably many others. > > The reproducer we have is running a KVM

Re: [PATCH v3] x86: treat pkey-0 special

On Thu, 15 Mar 2018, Dave Hansen wrote: > On 03/15/2018 02:46 AM, Thomas Gleixner wrote: > >> + if (!pkey || !mm_pkey_is_allocated(mm, pkey)) > > Why this extra check? mm_pkey_is_allocated(mm, 0) should not return true > > ever. If it does, then this wants to be fi

Re: [PATCH v3] x86: treat pkey-0 special

On Wed, 14 Mar 2018, Ram Pai wrote: > Applications need the ability to associate an address-range with some > key and latter revert to its initial default key. Pkey-0 comes close to > providing this function but falls short, because the current > implementation disallows applications to explicitly

Re: [PATCH v6 01/24] x86/mm: Define CONFIG_SPF

On Mon, 15 Jan 2018, Laurent Dufour wrote: > On 12/01/2018 19:57, Thomas Gleixner wrote: > > On Fri, 12 Jan 2018, Laurent Dufour wrote: > > > >> Introduce CONFIG_SPF which turns on the Speculative Page Fault handler when > >> building for 64bits with SMP. > &

Re: [PATCH v6 01/24] x86/mm: Define CONFIG_SPF

On Fri, 12 Jan 2018, Laurent Dufour wrote: > Introduce CONFIG_SPF which turns on the Speculative Page Fault handler when > building for 64bits with SMP. > > Signed-off-by: Laurent Dufour > --- > arch/x86/Kconfig | 4 > 1 file changed, 4 insertions(+) > > diff

Re: [PATCH 09/11] powerpc/64s: Allow control of RFI flush via sysfs

On Tue, 9 Jan 2018, Michael Ellerman wrote: Sorry, I wasn't aware about your efforts and did not cc you. I've just queued a more generic sysfs interface for this whole mess: https://lkml.kernel.org/r/20180107214913.096657...@linutronix.de It should be simple to extend for write and it would be

Re: [PATCH 0/9] posix_clocks: Prepare syscalls for 64 bit time_t conversion

On Fri, 17 Nov 2017, Arnd Bergmann wrote: > On Fri, Nov 17, 2017 at 10:54 AM, Thomas Gleixner <t...@linutronix.de> wrote: > > On Fri, 17 Nov 2017, Arnd Bergmann wrote: > >> On Fri, Nov 17, 2017 at 9:58 AM, Thomas Gleixner <t...@linutronix.de> > >> wrote: >

Re: [PATCH 0/9] posix_clocks: Prepare syscalls for 64 bit time_t conversion

On Fri, 17 Nov 2017, Arnd Bergmann wrote: > On Fri, Nov 17, 2017 at 9:58 AM, Thomas Gleixner <t...@linutronix.de> wrote: > > On Fri, 17 Nov 2017, Arnd Bergmann wrote: > >> On Thu, Nov 16, 2017 at 10:04 AM, Thomas Gleixner <t...@linutronix.de> > >> wrote: >

Re: [PATCH 0/9] posix_clocks: Prepare syscalls for 64 bit time_t conversion

On Fri, 17 Nov 2017, Arnd Bergmann wrote: > On Thu, Nov 16, 2017 at 10:04 AM, Thomas Gleixner <t...@linutronix.de> wrote: > > On Wed, 15 Nov 2017, Deepa Dinamani wrote: > >> Would this work for everyone? > > > > Having extra config switches which are selecta

Re: [PATCH 0/9] posix_clocks: Prepare syscalls for 64 bit time_t conversion

On Wed, 15 Nov 2017, Deepa Dinamani wrote: > > I had on concern about x32, maybe we should check > > for "COMPAT_USE_64BIT_TIME" before zeroing out the tv_nsec > > bits. > > Thanks, I think you are right. I had the check conditional on > CONFIG_64BIT_TIME and then removed as I forgot why I added

RE: [PATCH v10 0/4] this patchset is to remove PPCisms for QEIC

On Wed, 1 Nov 2017, Qiang Zhao wrote: > Michael Ellerman wrote > > > > Qiang Zhao writes: > > > > > Hi all, > > > > > > Could anybody review this patchset and take action on them? Thank you! > > > > Who maintains this? I don't actually know, it's not

Re: [PATCH 0/5] arm64: add ls1012a and ls1046a pcie support

hem, just let me know and I'll drop > them. > > They really should be acked by Minghuan or Mingkai, who are listed as > the maintainers of drivers/pci/dwc/pci-layerscape.c and are presumably > responsible for the related dtsi files, too. > > Thomas, Jason, and Marc are listed as maintainers of > drivers/irqchip/irq-ls-scfg-msi.c. It's a trivial change, but I added > them to the cc list. Feel free to pick them up. Acked-by: Thomas Gleixner <t...@linutronix.de>

Re: [PATCH 3/4] PCI: Remove unused declarations

q_routing_table()# only defined by x86 > pcibios_set_irq_routing() # only defined by x86 > > Signed-off-by: Bjorn Helgaas <bhelg...@google.com> Reviewed-by: Thomas Gleixner <t...@linutronix.de>

Re: [PATCH 1/4] PCI: Remove redundant pcibios_set_master() declarations

bhelg...@google.com> Reviewed-by: Thomas Gleixner <t...@linutronix.de>

Re: [PATCH] powerpc: Drop lockdep_assert_cpus_held call from arch_update_cpu_topology

Thiago, On Thu, 5 Oct 2017, Thiago Jung Bauermann wrote: > Thomas Gleixner <t...@linutronix.de> writes: > It doesn't look like powerpc uses arch_update_cpu_topology differently > than other arches. Are you saying that all callers of the function > should be holding cpu_hotplug_l

Re: [PATCH] powerpc: Drop lockdep_assert_cpus_held call from arch_update_cpu_topology

On Wed, 4 Oct 2017, Thiago Jung Bauermann wrote: > It turns out that not all paths calling arch_update_cpu_topology hold > cpu_hotplug_lock, but that's ok because those paths aren't supposed to race > with any concurrent hotplug events. > > Callers of arch_update_cpu_topology are expected to

RE: [PATCH 02/11] x86: make dma_cache_sync a no-op

On Tue, 3 Oct 2017, David Laight wrote: > From: Christoph Hellwig > > Sent: 03 October 2017 11:43 > > x86 does not implement DMA_ATTR_NON_CONSISTENT allocations, so it doesn't > > make any sense to do any work in dma_cache_sync given that it must be a > > no-op when dma_alloc_attrs returns

Re: [patch V2 22/29] lockup_detector: Make watchdog_nmi_reconfigure() two stage

On Tue, 3 Oct 2017, Thomas Gleixner wrote: > On Tue, 3 Oct 2017, Thomas Gleixner wrote: > > On Tue, 3 Oct 2017, Michael Ellerman wrote: > > > Hmm, I tried that patch, it makes the warning go away. But then I > > > triggered a deliberate hard lockup and got nothing. &g

Re: [patch V2 22/29] lockup_detector: Make watchdog_nmi_reconfigure() two stage

On Tue, 3 Oct 2017, Thomas Gleixner wrote: > On Tue, 3 Oct 2017, Michael Ellerman wrote: > > Hmm, I tried that patch, it makes the warning go away. But then I > > triggered a deliberate hard lockup and got nothing. > > > > Then I went back to the existing code (in l

Re: [patch V2 22/29] lockup_detector: Make watchdog_nmi_reconfigure() two stage

On Tue, 3 Oct 2017, Michael Ellerman wrote: > Thomas Gleixner <t...@linutronix.de> writes: > >> The first call is new because previously watchdog_nmi_reconfigure() > >> wasn't called from softlockup_reconfigure_threads(). > > > > Hmm, don't you have the same

Re: [patch V2 22/29] lockup_detector: Make watchdog_nmi_reconfigure() two stage

On Tue, 3 Oct 2017, Nicholas Piggin wrote: > On Tue, 3 Oct 2017 09:04:03 +0200 (CEST) > Thomas Gleixner <t...@linutronix.de> wrote: > > > On Tue, 3 Oct 2017, Thomas Gleixner wrote: > > > On Tue, 3 Oct 2017, Michael Ellerman wrote: > > > > Hi Tho

Re: [patch V2 22/29] lockup_detector: Make watchdog_nmi_reconfigure() two stage

On Tue, 3 Oct 2017, Thomas Gleixner wrote: > On Tue, 3 Oct 2017, Michael Ellerman wrote: > > Hi Thomas, > > Unfortunately this is hitting the WARN_ON in start_wd_cpu() on powerpc > > because we're calling it multiple times for the boot CPU. > >

Re: [patch V2 22/29] lockup_detector: Make watchdog_nmi_reconfigure() two stage

On Tue, 3 Oct 2017, Michael Ellerman wrote: > Hi Thomas, > Unfortunately this is hitting the WARN_ON in start_wd_cpu() on powerpc > because we're calling it multiple times for the boot CPU. > > The first call is via: > > start_wd_on_cpu+0x80/0x2f0 > watchdog_nmi_reconfigure+0x124/0x170 >

Re: [RFC GIT Pull] core watchdog sanitizing

On Mon, 2 Oct 2017, Don Zickus wrote: > On Mon, Oct 02, 2017 at 07:32:57PM +0000, Thomas Gleixner wrote: > > static void softlockup_reconfigure_threads(void) > > There is a second copy of , you will need to add identical locking there > too. Good catch, but then we might m

Re: [RFC GIT Pull] core watchdog sanitizing

On Mon, 2 Oct 2017, Linus Torvalds wrote: > Side note: would it perhaps make sense to have that > cpus_read_lock/unlock() sequence around the whole reconfiguration > section? > > Because while looking at that sequence, it looks a bit odd to me that > cpu's can come and go in the middle of the nmi

Re: [RFC GIT Pull] core watchdog sanitizing

ich should not have been merged in the first place. Your motivation skills are truly outstanding. Enough vented. Find below the cure for that major offense. Thanks, tglx 8< Subject: watchdog/core, powerpc: Replace watchdog_nmi_reconfigure() From: Thomas Gleixner <

[patch V2 29/29] lockup_detector: Cleanup hotplug locking mess

hotplug anymore. Remove it and add the now required protection to the powerpc arch_nmi_watchdog implementation. Signed-off-by: Thomas Gleixner <t...@linutronix.de> Cc: Don Zickus <dzic...@redhat.com> Cc: Chris Metcalf <cmetc...@mellanox.com> Cc: Peter Zijlstra <pet...@infrad

[patch V2 22/29] lockup_detector: Make watchdog_nmi_reconfigure() two stage

and split the functionality in powerpc. Signed-off-by: Thomas Gleixner <t...@linutronix.de> Cc: Don Zickus <dzic...@redhat.com> Cc: Chris Metcalf <cmetc...@mellanox.com> Cc: Peter Zijlstra <pet...@infradead.org> Cc: Benjamin Herrenschmidt <b...@kernel.crashing.org&g

Re: [PATCH 04/12] x86: make dma_cache_sync a no-op

toph Hellwig <h...@lst.de Reviewed-by: Thomas Gleixner <t...@linutronix.de> > --- > arch/x86/include/asm/dma-mapping.h | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/arch/x86/include/asm/dma-mapping.h > b/arch/x86/include/asm/dma-mapping.h > index 398c79889f5c.

[patch 29/29] lockup_detector: Cleanup hotplug locking mess

hotplug anymore. Remove it and add the now required protection to the powerpc arch_nmi_watchdog implementation. Signed-off-by: Thomas Gleixner <t...@linutronix.de> Cc: Benjamin Herrenschmidt <b...@kernel.crashing.org> Cc: Michael Ellerman <m...@ellerman.id.au> Cc: Nicholas Piggin

[patch 22/29] lockup_detector: Make watchdog_nmi_reconfigure() two stage

and split the functionality in powerpc. Signed-off-by: Thomas Gleixner <t...@linutronix.de> Cc: Benjamin Herrenschmidt <b...@kernel.crashing.org> Cc: Michael Ellerman <m...@ellerman.id.au> Cc: Nicholas Piggin <npig...@gmail.com> Cc: linuxppc-dev@lists.ozlabs.org --- arch/powerpc/

Re: [PATCH v2 1/1] futex: remove duplicated code and fix UB

On Thu, 24 Aug 2017, Will Deacon wrote: > On Thu, Aug 24, 2017 at 09:31:05AM +0200, Jiri Slaby wrote: > > +static int futex_atomic_op_inuser(unsigned int encoded_op, u32 __user > > *uaddr) > > +{ > > + unsigned int op = (encoded_op & 0x7000) >> 28; > > + unsigned int cmp =

Re: [PATCH resend] timers: Fix excessive granularity of new timers after a nohz idle

On Tue, 22 Aug 2017, Nicholas Piggin wrote: > I would have preferred to get comments from the timer maintainers, but > they've been busy or away for the past copule of weeks. Perhaps you > would consider carrying it until then? Yes, I was on vacation, but that patch never hit my LKML inbox

Re: [PATCH] powerpc/smp: Call smp_ops->setup_cpu() directly on the boot CPU

n't need the work queue call at all - and the lockdep warning goes > away. > > Signed-off-by: Michael Ellerman <m...@ellerman.id.au> Reviewed-by: Thomas Gleixner <t...@linutronix.de>

Re: Possible circular locking dependency detected between cpu_hotplug_lock.rw_sem and wfc.work

On Thu, 27 Jul 2017, Thomas Gleixner wrote: > On Thu, 27 Jul 2017, Michael Ellerman wrote: > > Thomas Gleixner <t...@linutronix.de> writes: > > > > > On Wed, 26 Jul 2017, Michael Ellerman wrote: > > > > > >> Hi Thomas, > > >> >

Re: Possible circular locking dependency detected between cpu_hotplug_lock.rw_sem and wfc.work

On Thu, 27 Jul 2017, Michael Ellerman wrote: > Thomas Gleixner <t...@linutronix.de> writes: > > > On Wed, 26 Jul 2017, Michael Ellerman wrote: > > > >> Hi Thomas, > >> > >> I'm seeing the lockdep barf below on some bare metal Power8

Re: Possible circular locking dependency detected between cpu_hotplug_lock.rw_sem and wfc.work

On Wed, 26 Jul 2017, Michael Ellerman wrote: > Hi Thomas, > > I'm seeing the lockdep barf below on some bare metal Power8 machines. > > This seems to be caused by our smp_cpus_done(), which does: > > void __init smp_cpus_done(unsigned int max_cpus) > { > /* >* We want the

Re: [PATCH 1/1] futex: remove duplicated code and fix UB

On Mon, 26 Jun 2017, Jiri Slaby wrote: > On 06/23/2017, 09:51 AM, Thomas Gleixner wrote: > > On Wed, 21 Jun 2017, Jiri Slaby wrote: > >> diff --git a/arch/arm64/include/asm/futex.h > >> b/arch/arm64/include/asm/futex.h > >> index f32b42e8725d..5bb2fd4674e7 1006

Re: [PATCH v11 07/10] powerpc/perf: PMU functions for Core IMC and hotplugging

On Thu, 29 Jun 2017, Madhavan Srinivasan wrote: > On Thursday 29 June 2017 01:11 AM, Thomas Gleixner wrote: > Idea is to handle multiple event session for a given core and > yes, my bad, current implementation is racy/broken. > But an alternate approach is to have a per-core mutex an

<    1   2   3   4   5   6   7   8   >