Re: [PATCH 1/2] lockdep: improve current->(hard|soft)irqs_enabled synchronisation with actual irq state

2020-07-25 Thread Peter Zijlstra
On Thu, Jul 23, 2020 at 08:56:14PM +1000, Nicholas Piggin wrote: > diff --git a/arch/powerpc/include/asm/hw_irq.h > b/arch/powerpc/include/asm/hw_irq.h > index 3a0db7b0b46e..35060be09073 100644 > --- a/arch/powerpc/include/asm/hw_irq.h > +++ b/arch/powerpc/include/asm/hw_irq.h > @@ -200,17

Re: [PATCH v3 5/6] powerpc/pseries: implement paravirt qspinlocks for SPLPAR

2020-07-25 Thread Peter Zijlstra
On Fri, Jul 24, 2020 at 03:10:59PM -0400, Waiman Long wrote: > On 7/24/20 4:16 AM, Will Deacon wrote: > > On Thu, Jul 23, 2020 at 08:47:59PM +0200, pet...@infradead.org wrote: > > > On Thu, Jul 23, 2020 at 02:32:36PM -0400, Waiman Long wrote: > > > > BTW, do you have any comment on my v2 lock

Re: [PATCH 1/2] lockdep: improve current->(hard|soft)irqs_enabled synchronisation with actual irq state

2020-07-23 Thread Peter Zijlstra
On Thu, Jul 23, 2020 at 11:11:03PM +1000, Nicholas Piggin wrote: > Excerpts from Peter Zijlstra's message of July 23, 2020 9:40 pm: > > On Thu, Jul 23, 2020 at 08:56:14PM +1000, Nicholas Piggin wrote: > > > >> diff --git a/arch/powerpc/include/asm/hw_irq.h > >>

Re: [PATCH v3 5/6] powerpc/pseries: implement paravirt qspinlocks for SPLPAR

2020-07-23 Thread Peter Zijlstra
On Thu, Jul 09, 2020 at 12:06:13PM -0400, Waiman Long wrote: > We don't really need to do a pv_spinlocks_init() if pv_kick() isn't > supported. Waiman, if you cannot explain how not having kick is a sane thing, what are you saying here?

Re: [PATCH 1/2] lockdep: improve current->(hard|soft)irqs_enabled synchronisation with actual irq state

2020-07-23 Thread Peter Zijlstra
On Thu, Jul 23, 2020 at 08:56:14PM +1000, Nicholas Piggin wrote: > diff --git a/arch/powerpc/include/asm/hw_irq.h > b/arch/powerpc/include/asm/hw_irq.h > index 3a0db7b0b46e..35060be09073 100644 > --- a/arch/powerpc/include/asm/hw_irq.h > +++ b/arch/powerpc/include/asm/hw_irq.h > @@ -200,17

Re: [PATCH v2 06/10] powerpc/smp: Generalize 2nd sched domain

2020-07-22 Thread Peter Zijlstra
On Wed, Jul 22, 2020 at 01:48:22PM +0530, Srikar Dronamraju wrote: > * pet...@infradead.org [2020-07-22 09:46:24]: > > > On Tue, Jul 21, 2020 at 05:08:10PM +0530, Srikar Dronamraju wrote: > > > Currently "CACHE" domain happens to be the 2nd sched domain as per > > > powerpc_topology. This domain

Re: [RFC PATCH 4/7] x86: use exit_lazy_tlb rather than membarrier_mm_sync_core_before_usermode

2020-07-21 Thread Peter Zijlstra
On Tue, Jul 21, 2020 at 11:15:13AM -0400, Mathieu Desnoyers wrote: > - On Jul 21, 2020, at 11:06 AM, Peter Zijlstra pet...@infradead.org wrote: > > > On Tue, Jul 21, 2020 at 08:04:27PM +1000, Nicholas Piggin wrote: > > > >> That being said, the x86 sync cor

Re: [RFC PATCH 4/7] x86: use exit_lazy_tlb rather than membarrier_mm_sync_core_before_usermode

2020-07-16 Thread Peter Zijlstra
On Wed, Jul 15, 2020 at 10:18:20PM -0700, Andy Lutomirski wrote: > > On Jul 15, 2020, at 9:15 PM, Nicholas Piggin wrote: > > CPU0 CPU1 > > 1. user stuff > > a. membarrier() 2. enter kernel > > b. read rq->curr 3. rq->curr switched to

Re: [PATCH v2 1/3] module: Rename module_alloc() to text_alloc() and move to kernel proper

2020-07-14 Thread Peter Zijlstra
On Tue, Jul 14, 2020 at 07:31:03PM +0300, Jarkko Sakkinen wrote: > On Tue, Jul 14, 2020 at 03:01:09PM +0200, Peter Zijlstra wrote: > > to help with text_alloc() usage in generic code, but I think > > fundamentally, there's only these two options. > > There is one arc

Re: [PATCH v2 1/3] module: Rename module_alloc() to text_alloc() and move to kernel proper

2020-07-14 Thread Peter Zijlstra
On Tue, Jul 14, 2020 at 03:19:24PM +0300, Ard Biesheuvel wrote: > So perhaps the answer is to have text_alloc() not with a 'where' > argument but with a 'why' argument. Or more simply, just have separate > alloc/free APIs for each case, with generic versions that can be > overridden by the

Re: [RFC PATCH 7/7] lazy tlb: shoot lazies, a non-refcounting lazy tlb option

2020-07-14 Thread Peter Zijlstra
On Tue, Jul 14, 2020 at 05:46:05AM -0700, Andy Lutomirski wrote: > x86 has this exact problem. At least no more than 64*8 CPUs share the cache > line :) I've seen patches for a 'sparse' bitmap to solve related problems. It's basically the same code, except it multiplies everything (size,

Re: [PATCH 1/3] module: Rename module_alloc() to text_alloc() and move to kernel proper

2020-07-14 Thread Peter Zijlstra
On Tue, Jul 14, 2020 at 11:33:33AM +0100, Russell King - ARM Linux admin wrote: > For 32-bit ARM, our bpf code uses "blx/bx" (or equivalent code > sequences) rather than encoding a "bl" or "b", so BPF there doesn't > care where the executable memory is mapped, and doesn't need any > PLTs. Given

Re: [PATCH v2 1/3] module: Rename module_alloc() to text_alloc() and move to kernel proper

2020-07-14 Thread Peter Zijlstra
On Tue, Jul 14, 2020 at 11:28:27AM +0100, Will Deacon wrote: > As Ard says, module_alloc() _is_ special, in the sense that the virtual > memory it allocates wants to be close to the kernel text, whereas the > concept of allocating executable memory is broader and doesn't have these >

Re: [RFC PATCH 5/7] lazy tlb: introduce lazy mm refcount helper functions

2020-07-10 Thread Peter Zijlstra
On Fri, Jul 10, 2020 at 11:56:44AM +1000, Nicholas Piggin wrote: > diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c > index 73199470c265..ad95812d2a3f 100644 > --- a/arch/powerpc/kernel/smp.c > +++ b/arch/powerpc/kernel/smp.c > @@ -1253,7 +1253,7 @@ void start_secondary(void

Re: [RFC PATCH 4/7] x86: use exit_lazy_tlb rather than membarrier_mm_sync_core_before_usermode

2020-07-10 Thread Peter Zijlstra
On Fri, Jul 10, 2020 at 11:56:43AM +1000, Nicholas Piggin wrote: > And get rid of the generic sync_core_before_usermode facility. > > This helper is the wrong way around I think. The idea that membarrier > state requires a core sync before returning to user is the easy one > that does not need

Re: [RFC PATCH 7/7] lazy tlb: shoot lazies, a non-refcounting lazy tlb option

2020-07-10 Thread Peter Zijlstra
On Fri, Jul 10, 2020 at 11:56:46AM +1000, Nicholas Piggin wrote: > On big systems, the mm refcount can become highly contented when doing > a lot of context switching with threaded applications (particularly > switching between the idle thread and an application thread). > > Abandoning lazy tlb

Re: [PATCH v3 5/6] powerpc/pseries: implement paravirt qspinlocks for SPLPAR

2020-07-09 Thread Peter Zijlstra
> > arch/powerpc/include/asm/qspinlock_paravirt.h | 7 ++ > > arch/powerpc/platforms/pseries/Kconfig| 5 ++ > > arch/powerpc/platforms/pseries/setup.c| 6 +- > > include/asm-generic/qspinlock.h | 2 + > > Another ack? Acked-by: Peter Zijlstra (Intel)

Re: [PATCH v3 4/6] powerpc/64s: implement queued spinlocks and rwlocks

2020-07-09 Thread Peter Zijlstra
5 + > > arch/powerpc/include/asm/spinlock_types.h | 5 + > > arch/powerpc/lib/Makefile | 3 +++ > > > include/asm-generic/qspinlock.h | 2 ++ > > Who's ack do we need for that part? Mine I suppose would do, as discussed earlier, it probably isn't requ

Re: [PATCH v3 0/6] powerpc: queued spinlocks and rwlocks

2020-07-09 Thread Peter Zijlstra
On Wed, Jul 08, 2020 at 07:54:34PM -0400, Waiman Long wrote: > On 7/8/20 4:41 AM, Peter Zijlstra wrote: > > On Tue, Jul 07, 2020 at 03:57:06PM +1000, Nicholas Piggin wrote: > > > Yes, powerpc could certainly get more performance out of the slow > > > paths, and then

Re: [PATCH v3 0/6] powerpc: queued spinlocks and rwlocks

2020-07-08 Thread Peter Zijlstra
On Tue, Jul 07, 2020 at 03:57:06PM +1000, Nicholas Piggin wrote: > Yes, powerpc could certainly get more performance out of the slow > paths, and then there are a few parameters to tune. Can you clarify? The slow path is already in use on ARM64 which is weak, so I doubt there's superfluous

Re: [PATCH v3 0/6] powerpc: queued spinlocks and rwlocks

2020-07-08 Thread Peter Zijlstra
On Tue, Jul 07, 2020 at 11:33:45PM -0400, Waiman Long wrote: > From 5d7941a498935fb225b2c7a3108cbf590114c3db Mon Sep 17 00:00:00 2001 > From: Waiman Long > Date: Tue, 7 Jul 2020 22:29:16 -0400 > Subject: [PATCH 2/9] locking/pvqspinlock: Introduce > CONFIG_PARAVIRT_QSPINLOCKS_LITE > > Add a new

Re: [PATCH 2/8] powerpc/pseries: use smp_rmb() in H_CONFER spin yield

2020-07-02 Thread Peter Zijlstra
On Thu, Jul 02, 2020 at 05:48:33PM +1000, Nicholas Piggin wrote: > There is no need for rmb(), this allows faster lwsync here. Since you determined this; I'm thinking you actually understand the ordering here. How about recording this understanding in a comment? Also, should the lock->slock load

Re: [PATCH v4 7/8] lockdep: Change hardirq{s_enabled,_context} to per-cpu variables

2020-06-30 Thread Peter Zijlstra
On Tue, Jun 30, 2020 at 07:59:39AM +0200, Ahmed S. Darwish wrote: > Peter Zijlstra wrote: > > ... > > > -#define lockdep_assert_irqs_disabled() do {\ > > - WARN_ONCE(debug_locks && !current->lockdep_recursion &am

Re: [PATCH v4 7/8] lockdep: Change hardirq{s_enabled,_context} to per-cpu variables

2020-06-24 Thread Peter Zijlstra
ch we should again permit tracing by using non-raw functions in > core.c. Update the lockdep_off() comment in report.c, to reflect the > fact there is still a potential risk of deadlock due to using printk() > from scheduler code. > > Suggested-by: Peter Zijlstra (Intel) > Signed-off

Re: [PATCH v4 7/8] lockdep: Change hardirq{s_enabled,_context} to per-cpu variables

2020-06-24 Thread Peter Zijlstra
On Tue, Jun 23, 2020 at 10:24:04PM +0200, Peter Zijlstra wrote: > On Tue, Jun 23, 2020 at 08:12:32PM +0200, Peter Zijlstra wrote: > > Fair enough; I'll rip it all up and boot a KCSAN kernel, see what if > > anything happens. > > OK, so the below patch doesn't seem to hav

Re: [PATCH v4 7/8] lockdep: Change hardirq{s_enabled,_context} to per-cpu variables

2020-06-23 Thread Peter Zijlstra
On Tue, Jun 23, 2020 at 10:24:04PM +0200, Peter Zijlstra wrote: > On Tue, Jun 23, 2020 at 08:12:32PM +0200, Peter Zijlstra wrote: > > Fair enough; I'll rip it all up and boot a KCSAN kernel, see what if > > anything happens. > > OK, so the below patch doesn't seem to hav

Re: [PATCH v4 7/8] lockdep: Change hardirq{s_enabled,_context} to per-cpu variables

2020-06-23 Thread Peter Zijlstra
On Tue, Jun 23, 2020 at 08:12:32PM +0200, Peter Zijlstra wrote: > Fair enough; I'll rip it all up and boot a KCSAN kernel, see what if > anything happens. OK, so the below patch doesn't seem to have any nasty recursion issues here. The only 'problem' is that lockdep now sees report_lock can

Re: [PATCH v4 7/8] lockdep: Change hardirq{s_enabled,_context} to per-cpu variables

2020-06-23 Thread Peter Zijlstra
On Tue, Jun 23, 2020 at 09:13:35PM +0200, Marco Elver wrote: > I see the below report when I boot with your branch + KCSAN and > PROVE_LOCKING. config attached. Trying to make sense of what's > happening. Ah, I was still playing with tip/master + PROVE_LOCKING + KCSAN and slowly removing parts of

Re: [PATCH v4 7/8] lockdep: Change hardirq{s_enabled,_context} to per-cpu variables

2020-06-23 Thread Peter Zijlstra
On Tue, Jun 23, 2020 at 07:59:57PM +0200, Marco Elver wrote: > On Tue, Jun 23, 2020 at 06:37PM +0200, Peter Zijlstra wrote: > > On Tue, Jun 23, 2020 at 06:13:21PM +0200, Ahmed S. Darwish wrote: > > > Well, freshly merged code is using it. For example, KCSAN: > > >

Re: [PATCH v4 7/8] lockdep: Change hardirq{s_enabled,_context} to per-cpu variables

2020-06-23 Thread Peter Zijlstra
On Tue, Jun 23, 2020 at 06:13:21PM +0200, Ahmed S. Darwish wrote: > Well, freshly merged code is using it. For example, KCSAN: > > => f1bc96210c6a ("kcsan: Make KCSAN compatible with lockdep") > => kernel/kcsan/report.c: > > void kcsan_report(...) > { > ... > /* >

Re: [PATCH v4 7/8] lockdep: Change hardirq{s_enabled,_context} to per-cpu variables

2020-06-23 Thread Peter Zijlstra
On Tue, Jun 23, 2020 at 05:00:31PM +0200, Ahmed S. Darwish wrote: > On Tue, Jun 23, 2020 at 10:36:52AM +0200, Peter Zijlstra wrote: > ... > > -#define lockdep_assert_irqs_disabled() do { > > \ > > - WARN_ONCE(debug_locks &&

[PATCH v4 6/8] arm: Break cyclic percpu include

2020-06-23 Thread Peter Zijlstra
In order to use in irqflags.h, we need to make sure asm/percpu.h does not itself depend on irqflags.h. Signed-off-by: Peter Zijlstra (Intel) --- arch/arm/include/asm/percpu.h |2 ++ 1 file changed, 2 insertions(+) --- a/arch/arm/include/asm/percpu.h +++ b/arch/arm/include/asm/percpu.h

[PATCH v4 5/8] s390: Break cyclic percpu include

2020-06-23 Thread Peter Zijlstra
In order to use in irqflags.h, we need to make sure asm/percpu.h does not itself depend on irqflags.h Signed-off-by: Peter Zijlstra (Intel) --- arch/s390/include/asm/smp.h |1 + arch/s390/include/asm/thread_info.h |1 - 2 files changed, 1 insertion(+), 1 deletion(-) --- a/arch

[PATCH v4 4/8] powerpc64: Break asm/percpu.h vs spinlock_types.h dependency

2020-06-23 Thread Peter Zijlstra
In order to use in lockdep.h, we need to make sure asm/percpu.h does not itself depend on lockdep. The below seems to make that so and builds powerpc64-defconfig + PROVE_LOCKING. Signed-off-by: Peter Zijlstra (Intel) --- arch/powerpc/include/asm/dtl.h | 52

[PATCH v4 8/8] lockdep: Remove lockdep_hardirq{s_enabled, _context}() argument

2020-06-23 Thread Peter Zijlstra
Now that the macros use per-cpu data, we no longer need the argument. Signed-off-by: Peter Zijlstra (Intel) --- arch/x86/entry/common.c|2 +- include/linux/irqflags.h |8 include/linux/lockdep.h|2 +- kernel/locking/lockdep.c | 30

[PATCH v4 2/8] x86/entry: Fix NMI vs IRQ state tracking

2020-06-23 Thread Peter Zijlstra
While the nmi_enter() users did trace_hardirqs_{off_prepare,on_finish}() there was no matching lockdep_hardirqs_*() calls to complete the picture. Introduce idtentry_{enter,exit}_nmi() to enable proper IRQ state tracking across the NMIs. Signed-off-by: Peter Zijlstra (Intel) --- arch/x86/entry

[PATCH v4 1/8] lockdep: Prepare for NMI IRQ state tracking

2020-06-23 Thread Peter Zijlstra
There is no reason not to always, accurately, track IRQ state. This change also makes IRQ state tracking ignore lockdep_off(). Signed-off-by: Peter Zijlstra (Intel) --- kernel/locking/lockdep.c | 44 +--- 1 file changed, 41 insertions(+), 3 deletions

[PATCH v4 3/8] sparc64: Fix asm/percpu.h build error

2020-06-23 Thread Peter Zijlstra
In order to break a header dependency between lockdep and task_struct, I need per-cpu stuff from lockdep. Signed-off-by: Peter Zijlstra (Intel) --- arch/sparc/include/asm/percpu_64.h |2 ++ arch/sparc/include/asm/trap_block.h |2 ++ 2 files changed, 4 insertions(+) --- a/arch/sparc

[PATCH v4 0/8] lockdep: Change IRQ state tracking to use per-cpu variables

2020-06-23 Thread Peter Zijlstra
Ahmed and Sebastian wanted additional lockdep_assert*() macros and ran into header hell. I figured using per-cpu variables would cure that, and also ran into header hell, still tracktable though. By moving the IRQ state into per-cpu variables we remove the dependency on task_struct. Patches go

[PATCH v4 7/8] lockdep: Change hardirq{s_enabled, _context} to per-cpu variables

2020-06-23 Thread Peter Zijlstra
Currently all IRQ-tracking state is in task_struct, this means that task_struct needs to be defined before we use it. Especially for lockdep_assert_irq*() this can lead to header-hell. Move the hardirq state into per-cpu variables to avoid the task_struct dependency. Signed-off-by: Peter

Re: [PATCH 3/3] powerpc/8xx: Provide ptep_get() with 16k pages

2020-06-17 Thread Peter Zijlstra
On Thu, Jun 18, 2020 at 12:21:22AM +1000, Michael Ellerman wrote: > Peter Zijlstra writes: > > On Mon, Jun 15, 2020 at 12:57:59PM +, Christophe Leroy wrote: > >> +#if defined(CONFIG_PPC_8xx) && defined(CONFIG_PPC_16K_PAGES) > >> +#define __HAVE_ARCH

Re: [PATCH v2 12/12] x86/traps: Fix up invalid PASID

2020-06-17 Thread Peter Zijlstra
On Tue, Jun 16, 2020 at 04:23:46PM -0700, Fenghua Yu wrote: > Hi, Peter, > > On Mon, Jun 15, 2020 at 09:09:28PM +0200, Peter Zijlstra wrote: > > On Mon, Jun 15, 2020 at 11:55:29AM -0700, Fenghua Yu wrote: > > > > > Or do you suggest to add a random new flag

Re: [PATCH v2 12/12] x86/traps: Fix up invalid PASID

2020-06-15 Thread Peter Zijlstra
On Mon, Jun 15, 2020 at 01:17:35PM -0700, Fenghua Yu wrote: > Hi, Peter, > > On Mon, Jun 15, 2020 at 09:09:28PM +0200, Peter Zijlstra wrote: > > On Mon, Jun 15, 2020 at 11:55:29AM -0700, Fenghua Yu wrote: > > > > > Or do you suggest to add a random new flag

Re: [PATCH v2 12/12] x86/traps: Fix up invalid PASID

2020-06-15 Thread Peter Zijlstra
On Mon, Jun 15, 2020 at 11:55:29AM -0700, Fenghua Yu wrote: > Or do you suggest to add a random new flag in struct thread_info instead > of a TIF flag? Why thread_info? What's wrong with something simple like the below. It takes a bit from the 'strictly current' flags word. diff --git

Re: [PATCH v2 12/12] x86/traps: Fix up invalid PASID

2020-06-15 Thread Peter Zijlstra
On Mon, Jun 15, 2020 at 11:19:21AM -0700, Raj, Ashok wrote: > On Mon, Jun 15, 2020 at 06:03:57PM +0200, Peter Zijlstra wrote: > > > > I don't get why you need a rdmsr here, or why not having one would > > require a TIF flag. Is that because this MSR is

Re: [PATCH v2 12/12] x86/traps: Fix up invalid PASID

2020-06-15 Thread Peter Zijlstra
On Mon, Jun 15, 2020 at 11:12:59AM -0700, Fenghua Yu wrote: > > I don't get why you need a rdmsr here, or why not having one would > > require a TIF flag. Is that because this MSR is XSAVE/XRSTOR managed? > > My concern is TIF flags are precious (only 3 slots available). Defining > a new TIF flag

Re: [PATCH v2 12/12] x86/traps: Fix up invalid PASID

2020-06-15 Thread Peter Zijlstra
On Mon, Jun 15, 2020 at 08:48:54AM -0700, Fenghua Yu wrote: > Hi, Peter, > On Mon, Jun 15, 2020 at 09:56:49AM +0200, Peter Zijlstra wrote: > > On Fri, Jun 12, 2020 at 05:41:33PM -0700, Fenghua Yu wrote: > > > +/* > > > + * Apply some heuristics to see if the #G

Re: [PATCH 3/3] powerpc/8xx: Provide ptep_get() with 16k pages

2020-06-15 Thread Peter Zijlstra
ent with this magic? The casual reader might wonder WTH just happened when he stumbles on this :-) Other than that, the series looks good to me, Thanks! Acked-by: Peter Zijlstra (Intel)

Re: [PATCH v2 12/12] x86/traps: Fix up invalid PASID

2020-06-15 Thread Peter Zijlstra
On Fri, Jun 12, 2020 at 05:41:33PM -0700, Fenghua Yu wrote: > +/* > + * Apply some heuristics to see if the #GP fault was caused by a thread > + * that hasn't had the IA32_PASID MSR initialized. If it looks like that > + * is the problem, try initializing the IA32_PASID MSR. If the heuristic > +

Re: [PATCH v2 12/12] x86/traps: Fix up invalid PASID

2020-06-15 Thread Peter Zijlstra
On Fri, Jun 12, 2020 at 05:41:33PM -0700, Fenghua Yu wrote: > @@ -447,6 +458,18 @@ dotraplinkage void do_general_protection(struct pt_regs > *regs, long error_code) > int ret; > > RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU"); > + > + /* > + * Perform

Re: [PATCH v2 00/12] x86: tag application address space for devices

2020-06-15 Thread Peter Zijlstra
On Fri, Jun 12, 2020 at 05:41:21PM -0700, Fenghua Yu wrote: > This series only provides simple and basic support for ENQCMD and the MSR: > 1. Clean up type definitions (patch 1-3). These patches can be in a >separate series. >- Define "pasid" as "unsigned int" consistently (patch 1 and

Re: [RFC][PATCH v3 1/5] sparc64: Fix asm/percpu.h build error

2020-06-04 Thread Peter Zijlstra
On Thu, Jun 04, 2020 at 06:57:03PM +0200, Peter Zijlstra wrote: > I think I see, what happens is that these headers end up in the VDSO > build, and that doesn't have these CFLAGS, because userspace. > > Let me see what to do about that. I feel like the below is cheating, but it'

Re: [RFC][PATCH v3 1/5] sparc64: Fix asm/percpu.h build error

2020-06-04 Thread Peter Zijlstra
On Fri, May 29, 2020 at 04:29:17PM -0700, David Miller wrote: > From: Peter Zijlstra > Date: Fri, 29 May 2020 23:35:51 +0200 > > > ../arch/sparc/include/asm/percpu_64.h:7:24: warning: call-clobbered > > register used for global register variable > > register unsigned

Re: linux-next: build failure on powerpc 8xx with 16k pages

2020-06-04 Thread Peter Zijlstra
On Thu, Jun 04, 2020 at 12:17:23PM +0100, Will Deacon wrote: > Hi, [+Peter] > > On Thu, Jun 04, 2020 at 10:48:03AM +, Christophe Leroy wrote: > > Using mpc885_ads_defconfig with CONFIG_PPC_16K_PAGES instead of > > CONFIG_PPC_4K_PAGES, getting the following build failure: > > > > CC

Re: [PATCH 11/14] x86/entry: Clarify irq_{enter,exit}_rcu()

2020-06-02 Thread Peter Zijlstra
On Tue, Jun 02, 2020 at 10:42:35AM -0400, Qian Cai wrote: > Reverted this commit fixed the POWER9 boot warning, ARGH, I'm an idiot. Please try this instead: diff --git a/kernel/softirq.c b/kernel/softirq.c index a3eb6eba8c41..c4201b7f42b1 100644 --- a/kernel/softirq.c +++ b/kernel/softirq.c @@

[PATCH v3 0/5] lockdep: Change IRQ state tracking to use per-cpu variables

2020-05-29 Thread Peter Zijlstra
Ahmed and Sebastian wanted additional lockdep_assert*() macros and ran into header hell. Move the IRQ state into per-cpu variables, which removes the dependency on task_struct, which is what generated the header-hell. These patches are intended to go on top of:

[PATCH v3 2/5] powerpc64: Break asm/percpu.h vs spinlock_types.h dependency

2020-05-29 Thread Peter Zijlstra
In order to use in lockdep.h, we need to make sure asm/percpu.h does not itself depend on lockdep. The below seems to make that so and builds powerpc64-defconfig + PROVE_LOCKING. Signed-off-by: Peter Zijlstra (Intel) --- arch/powerpc/include/asm/dtl.h | 52

[RFC][PATCH v3 1/5] sparc64: Fix asm/percpu.h build error

2020-05-29 Thread Peter Zijlstra
for global register variable register unsigned long __local_per_cpu_offset asm("g5"); But i've no idea how to fix that :/ but it does build. Not-Signed-off-by: Peter Zijlstra (Intel) --- arch/sparc/include/asm/trap_block.h |2 ++ 1 file changed, 2 insertions(+) --- a/arch/sparc/i

[PATCH v3 5/5] lockdep: Remove lockdep_hardirq{s_enabled, _context}() argument

2020-05-29 Thread Peter Zijlstra
Now that the macros use per-cpu data, we no longer need the argument. Signed-off-by: Peter Zijlstra (Intel) --- arch/x86/entry/common.c|2 +- include/linux/irqflags.h |8 include/linux/lockdep.h|2 +- kernel/locking/lockdep.c | 30

[PATCH v3 4/5] lockdep: Change hardirq{s_enabled, _context} to per-cpu variables

2020-05-29 Thread Peter Zijlstra
Currently all IRQ-tracking state is in task_struct, this means that task_struct needs to be defined before we use it. Especially for lockdep_assert_irq*() this can lead to header-hell. Move the hardirq state into per-cpu variables to avoid the task_struct dependency. Signed-off-by: Peter

[PATCH v3 3/5] s390: Break cyclic percpu include

2020-05-29 Thread Peter Zijlstra
In order to use in irqflags.h, we need to make sure asm/percpu.h does not itself depend on irqflags.h Signed-off-by: Peter Zijlstra (Intel) --- arch/s390/include/asm/smp.h |1 + arch/s390/include/asm/thread_info.h |1 - 2 files changed, 1 insertion(+), 1 deletion(-) --- a/arch

Re: Endless soft-lockups for compiling workload since next-20200519

2020-05-25 Thread Peter Zijlstra
On Mon, May 25, 2020 at 04:05:49PM +0200, Frederic Weisbecker wrote: > On Mon, May 25, 2020 at 03:21:05PM +0200, Peter Zijlstra wrote: > > @@ -2320,7 +2304,7 @@ static void ttwu_queue_remote(struct task_struct *p, > > int cpu, int wake_flags) > > > > if (llist_

Re: Endless soft-lockups for compiling workload since next-20200519

2020-05-25 Thread Peter Zijlstra
On Mon, May 25, 2020 at 03:21:05PM +0200, Peter Zijlstra wrote: > - flags = atomic_fetch_andnot(NOHZ_KICK_MASK, nohz_flags(this_cpu)); > - if (!(flags & NOHZ_KICK_MASK)) > + if (idle != CPU_IDLE) > return false; > > _nohz_idle_balance(this_

Re: Endless soft-lockups for compiling workload since next-20200519

2020-05-25 Thread Peter Zijlstra
On Thu, May 21, 2020 at 02:41:14PM +0200, Frederic Weisbecker wrote: > On Thu, May 21, 2020 at 01:00:27PM +0200, Peter Zijlstra wrote: > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > > index 01f94cf52783..b6d8a7b991f0 100644 > > --- a/kernel/sched/fair.c > >

Re: Endless soft-lockups for compiling workload since next-20200519

2020-05-21 Thread Peter Zijlstra
On Thu, May 21, 2020 at 12:49:37PM +0200, Peter Zijlstra wrote: > On Thu, May 21, 2020 at 11:39:39AM +0200, Peter Zijlstra wrote: > > On Thu, May 21, 2020 at 02:40:36AM +0200, Frederic Weisbecker wrote: > > > This: > > > > >

Re: Endless soft-lockups for compiling workload since next-20200519

2020-05-21 Thread Peter Zijlstra
On Thu, May 21, 2020 at 11:39:39AM +0200, Peter Zijlstra wrote: > On Thu, May 21, 2020 at 02:40:36AM +0200, Frederic Weisbecker wrote: > This: > > > smp_call_function_single_async() { > > smp_call_function_single_async() { > > // veri

Re: Endless soft-lockups for compiling workload since next-20200519

2020-05-21 Thread Peter Zijlstra
On Thu, May 21, 2020 at 02:40:36AM +0200, Frederic Weisbecker wrote: >atomic_fetch_or(, > nohz_flags(0)) > softirq() {#VMEXIT or anything > that could stop a CPU for a while >

Re: Endless soft-lockups for compiling workload since next-20200519

2020-05-21 Thread Peter Zijlstra
On Thu, May 21, 2020 at 02:40:36AM +0200, Frederic Weisbecker wrote: > On Wed, May 20, 2020 at 02:50:56PM +0200, Peter Zijlstra wrote: > > On Tue, May 19, 2020 at 11:58:17PM -0400, Qian Cai wrote: > > > Just a head up. Repeatedly compiling kernels for a while would trigger

Re: Endless soft-lockups for compiling workload since next-20200519

2020-05-20 Thread Peter Zijlstra
On Tue, May 19, 2020 at 11:58:17PM -0400, Qian Cai wrote: > Just a head up. Repeatedly compiling kernels for a while would trigger > endless soft-lockups since next-20200519 on both x86_64 and powerpc. > .config are in, Could be 90b5363acd47 ("sched: Clean up scheduler_ipi()"), although I've not

Re: [PATCH v2] sched/core: fix illegal RCU from offline CPUs

2020-04-21 Thread Peter Zijlstra
On Fri, Apr 17, 2020 at 09:26:56AM -0400, Qian Cai wrote: > > Acked-by: Michael Ellerman (powerpc) > > Peter, can you take a look at this patch when you have a chance? Sorry, -ETOOMUCHEMAIL, got it now, thanks!

Re: [PATCH 10/28] mm: only allow page table mappings for built-in zsmalloc

2020-04-09 Thread Peter Zijlstra
On Thu, Apr 09, 2020 at 09:08:26AM -0700, Minchan Kim wrote: > On Wed, Apr 08, 2020 at 01:59:08PM +0200, Christoph Hellwig wrote: > > This allows to unexport map_vm_area and unmap_kernel_range, which are > > rather deep internal and should not be available to modules. > > Even though I don't know

Re: [PATCH 10/28] mm: only allow page table mappings for built-in zsmalloc

2020-04-08 Thread Peter Zijlstra
On Wed, Apr 08, 2020 at 08:01:00AM -0700, Randy Dunlap wrote: > Hi, > > On 4/8/20 4:59 AM, Christoph Hellwig wrote: > > diff --git a/mm/Kconfig b/mm/Kconfig > > index 36949a9425b8..614cc786b519 100644 > > --- a/mm/Kconfig > > +++ b/mm/Kconfig > > @@ -702,7 +702,7 @@ config ZSMALLOC > > > >

Re: decruft the vmalloc API

2020-04-08 Thread Peter Zijlstra
much more systematic. This also removes any chance to create vmalloc > mappings outside the designated areas or using executable permissions > from modules. Besides that it removes more than 300 lines of code. > Looks great, thanks for doing this! Acked-by: Peter Zijlstra (Intel)

Re: [PATCH 17/28] mm: remove the prot argument from vm_map_ram

2020-04-08 Thread Peter Zijlstra
On Wed, Apr 08, 2020 at 01:59:15PM +0200, Christoph Hellwig wrote: > This is always GFP_KERNEL - for long term mappings with other properties > vmap should be used. PAGE_KERNEL != GFP_KERNEL :-) > - return vm_map_ram(mock->pages, mock->npages, 0, PAGE_KERNEL); > + return

Re: [PATCH v3 1/1] ppc/crash: Reset spinlocks during crash

2020-04-01 Thread Peter Zijlstra
On Tue, Mar 31, 2020 at 09:00:21PM -0300, Leonardo Bras wrote: > During a crash, there is chance that the cpus that handle the NMI IPI > are holding a spin_lock. If this spin_lock is needed by crashing_cpu it > will cause a deadlock. (rtas.lock and printk logbuf_lock as of today) > > This is a

Re: [PATCH 1/1] ppc/crash: Skip spinlocks during crash

2020-03-30 Thread Peter Zijlstra
On Fri, Mar 27, 2020 at 07:50:20AM +0100, Christophe Leroy wrote: > > > Le 26/03/2020 à 23:28, Leonardo Bras a écrit : > > During a crash, there is chance that the cpus that handle the NMI IPI > > are holding a spin_lock. If this spin_lock is needed by crashing_cpu it > > will cause a deadlock.

Re: [PATCH 18/15] kvm: Replace vcpu->swait with rcuwait

2020-03-22 Thread Peter Zijlstra
On Sun, Mar 22, 2020 at 09:33:17AM -0700, Davidlohr Bueso wrote: > On Fri, 20 Mar 2020, Peter Zijlstra wrote: > > > On Fri, Mar 20, 2020 at 01:55:26AM -0700, Davidlohr Bueso wrote: > > > - swait_event_interruptible_exclusive(*wq, ((

Re: [PATCH 18/15] kvm: Replace vcpu->swait with rcuwait

2020-03-20 Thread Peter Zijlstra
On Fri, Mar 20, 2020 at 01:55:26AM -0700, Davidlohr Bueso wrote: > - swait_event_interruptible_exclusive(*wq, ((!vcpu->arch.power_off) && > -(!vcpu->arch.pause))); > + rcuwait_wait_event(*wait, > +(!vcpu->arch.power_off) &&

Re: [PATCH 17/15] rcuwait: Inform rcuwait_wake_up() users if a wakeup was attempted

2020-03-20 Thread Peter Zijlstra
On Fri, Mar 20, 2020 at 01:55:25AM -0700, Davidlohr Bueso wrote: > diff --git a/kernel/exit.c b/kernel/exit.c > index 6cc6cc485d07..b0bb0a8ec4b1 100644 > --- a/kernel/exit.c > +++ b/kernel/exit.c > @@ -234,9 +234,10 @@ void release_task(struct task_struct *p) > goto repeat; > } >

Re: [patch V2 07/15] powerpc/ps3: Convert half completion to rcuwait

2020-03-19 Thread Peter Zijlstra
On Thu, Mar 19, 2020 at 10:00:24AM +0100, Sebastian Andrzej Siewior wrote: > On 2020-03-18 21:43:09 [+0100], Thomas Gleixner wrote: > > --- a/arch/powerpc/platforms/ps3/device-init.c > > +++ b/arch/powerpc/platforms/ps3/device-init.c > > @@ -725,12 +728,12 @@ static int

Re: [RFC 00/11] perf: Enhancing perf to export processor hazard information

2020-03-02 Thread Peter Zijlstra
On Mon, Mar 02, 2020 at 10:53:44AM +0530, Ravi Bangoria wrote: > Modern processors export such hazard data in Performance > Monitoring Unit (PMU) registers. Ex, 'Sampled Instruction Event > Register' on IBM PowerPC[1][2] and 'Instruction-Based Sampling' on > AMD[3] provides similar information. >

Re: [RFC 02/11] perf/core: Data structure to present hazard data

2020-03-02 Thread Peter Zijlstra
On Mon, Mar 02, 2020 at 10:53:46AM +0530, Ravi Bangoria wrote: > From: Madhavan Srinivasan > > Introduce new perf sample_type PERF_SAMPLE_PIPELINE_HAZ to request kernel > to provide cpu pipeline hazard data. Also, introduce arch independent > structure 'perf_pipeline_haz_data' to pass hazard

Re: [PATCH v4 2/9] perf/core: open access for CAP_SYS_PERFMON privileged process

2020-01-10 Thread Peter Zijlstra
On Thu, Jan 09, 2020 at 02:36:50PM +0300, Alexey Budankov wrote: > On 08.01.2020 19:07, Peter Zijlstra wrote: > > On Wed, Dec 18, 2019 at 12:25:35PM +0300, Alexey Budankov wrote: > >> diff --git a/kernel/events/core.c b/kernel/events/core.c > >> index 059ee7

Re: [PATCH v4 2/9] perf/core: open access for CAP_SYS_PERFMON privileged process

2020-01-08 Thread Peter Zijlstra
On Wed, Dec 18, 2019 at 12:25:35PM +0300, Alexey Budankov wrote: > > Open access to perf_events monitoring for CAP_SYS_PERFMON privileged > processes. For backward compatibility reasons access to perf_events > subsystem remains open for CAP_SYS_ADMIN privileged processes but > CAP_SYS_ADMIN usage

Re: [PATCH v2 2/3] mm/mmu_gather: Invalidate TLB correctly on batch allocation failure and flush

2019-12-18 Thread Peter Zijlstra
On Thu, Dec 19, 2019 at 12:13:48AM +1100, Michael Ellerman wrote: > >> I'm a little confused though; if nohash is a software TLB fill, why do > >> you need a TLBI for tables? > >> > > > > nohash (AKA book3e) has different mmu modes. I don't follow all the > > details w.r.t book3e. Paul or

Re: [PATCH v2 3/3] asm-generic/tlb: Avoid potential double flush

2019-12-18 Thread Peter Zijlstra
On Wed, Dec 18, 2019 at 11:05:30AM +0530, Aneesh Kumar K.V wrote: > --- a/include/asm-generic/tlb.h > +++ b/include/asm-generic/tlb.h > @@ -402,7 +402,12 @@ tlb_update_vma_flags(struct mmu_gather *tlb, struct > vm_area_struct *vma) { } > > static inline void tlb_flush_mmu_tlbonly(struct

Re: [PATCH v2 2/3] mm/mmu_gather: Invalidate TLB correctly on batch allocation failure and flush

2019-12-18 Thread Peter Zijlstra
On Wed, Dec 18, 2019 at 11:05:29AM +0530, Aneesh Kumar K.V wrote: > From: Peter Zijlstra > > Architectures for which we have hardware walkers of Linux page table should > flush TLB on mmu gather batch allocation failures and batch flush. Some > architectures like POWER su

Re: [PATCH v2 1/3] powerpc/mmu_gather: Enable RCU_TABLE_FREE even for !SMP case

2019-12-18 Thread Peter Zijlstra
not spelled out in any detail. > Signed-off-by: Aneesh Kumar K.V Acked-by: Peter Zijlstra (Intel)

Re: [RFC PATCH 1/2] mm/mmu_gather: Invalidate TLB correctly on batch allocation failure and flush

2019-12-18 Thread Peter Zijlstra
On Wed, Dec 18, 2019 at 10:52:53AM +0530, Aneesh Kumar K.V wrote: > Upstream ppc64 is broken after the commit: a46cc7a90fd8 > ("powerpc/mm/radix: Improve TLB/PWC flushes"). > > Also the patches are not adding any extra TLBI on either radix or hash. > > Considering we need to backport this to

[PATCH] asm-generic/tlb: Avoid potential double flush

2019-12-17 Thread Peter Zijlstra
On Tue, Dec 17, 2019 at 01:34:16PM +0100, Peter Zijlstra wrote: > Perhaps if we replace !tlb->end with something like: > > !tlb->freed_tables && !tlb->cleared_p* > > (which GCC should be able to do with a single load and mask) > > I've not really though

Re: [RFC PATCH 1/2] mm/mmu_gather: Invalidate TLB correctly on batch allocation failure and flush

2019-12-17 Thread Peter Zijlstra
On Tue, Dec 17, 2019 at 04:18:40PM +0530, Aneesh Kumar K.V wrote: > On 12/17/19 2:39 PM, Peter Zijlstra wrote: > > On Tue, Dec 17, 2019 at 12:47:12PM +0530, Aneesh Kumar K.V wrote: > > > Architectures for which we have hardware walkers of Linux page table > > > sh

Re: [RFC PATCH 2/2] mm/mmu_gather: Avoid multiple page walk cache flush

2019-12-17 Thread Peter Zijlstra
On Tue, Dec 17, 2019 at 03:45:36PM +0530, Aneesh Kumar K.V wrote: > On 12/17/19 2:28 PM, Peter Zijlstra wrote: > > On Tue, Dec 17, 2019 at 12:47:13PM +0530, Aneesh Kumar K.V wrote: > > > On tlb_finish_mmu() kernel does a tlb flush before mmu gather table > > > inval

Re: [RFC PATCH 1/2] mm/mmu_gather: Invalidate TLB correctly on batch allocation failure and flush

2019-12-17 Thread Peter Zijlstra
alks linux page table and with that, kernel > needs to make sure to TLB invalidate page walk cache before page table pages > are > freed. > Based on changes from Peter Zijlstra AFAICT it is all my patch ;-) Anyway, this commit: > More details in > commit: d86564a2f085 ("mm/

Re: [RFC PATCH 2/2] mm/mmu_gather: Avoid multiple page walk cache flush

2019-12-17 Thread Peter Zijlstra
On Tue, Dec 17, 2019 at 12:47:13PM +0530, Aneesh Kumar K.V wrote: > On tlb_finish_mmu() kernel does a tlb flush before mmu gather table > invalidate. > The mmu gather table invalidate depending on kernel config also does another > TLBI. Avoid the later on tlb_finish_mmu(). That is already

Re: READ_ONCE() + STACKPROTECTOR_STRONG == :/ (was Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.5-2 tag (topic/kasan-bitops))

2019-12-16 Thread Peter Zijlstra
On Mon, Dec 16, 2019 at 10:28:06AM +, Will Deacon wrote: > However, enabling this for 32-bit ARM is total carnage; as Linus mentioned, > a whole bunch of code appears to be relying on atomic 64-bit access of > READ_ONCE(); the perf ring buffer, io_uring, the scheduler, pm_runtime, > cpuidle,

Re: READ_ONCE() + STACKPROTECTOR_STRONG == :/ (was Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.5-2 tag (topic/kasan-bitops))

2019-12-13 Thread Peter Zijlstra
On Fri, Dec 13, 2019 at 11:47:06AM +0100, Luc Van Oostenryck wrote: > On Thu, Dec 12, 2019 at 09:53:38PM +0100, Peter Zijlstra wrote: > > Now, looking at the current GCC source: > > > > > > https://github.com/gcc-mirror/gcc/blob/97d7270f894395e513667a031a0c309d1819

Re: READ_ONCE() + STACKPROTECTOR_STRONG == :/ (was Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.5-2 tag (topic/kasan-bitops))

2019-12-12 Thread Peter Zijlstra
On Thu, Dec 12, 2019 at 09:21:57PM +0100, Peter Zijlstra wrote: > On Thu, Dec 12, 2019 at 07:34:01PM +, Will Deacon wrote: > > void ool_store_release(volatile unsigned long *ptr, unsigned long val) > > { > > smp_store_release(ptr, val); > > } > >

Re: READ_ONCE() + STACKPROTECTOR_STRONG == :/ (was Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.5-2 tag (topic/kasan-bitops))

2019-12-12 Thread Peter Zijlstra
On Thu, Dec 12, 2019 at 07:34:01PM +, Will Deacon wrote: > void ool_store_release(volatile unsigned long *ptr, unsigned long val) > { > smp_store_release(ptr, val); > } > > : >0: a9be7bfdstp x29, x30, [sp, #-32]! >4: 9002adrpx2, 0

Re: READ_ONCE() + STACKPROTECTOR_STRONG == :/ (was Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.5-2 tag (topic/kasan-bitops))

2019-12-12 Thread Peter Zijlstra
On Thu, Dec 12, 2019 at 10:07:56AM +, Will Deacon wrote: > > So your proposed change _should_ be fine. Will, I'm assuming you never > > saw this on your ARGH64 builds when you did this code ? > > I did see it, but (a) looking at the code out-of-line makes it look a lot > worse than it

Re: READ_ONCE() + STACKPROTECTOR_STRONG == :/ (was Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.5-2 tag (topic/kasan-bitops))

2019-12-12 Thread Peter Zijlstra
On Thu, Dec 12, 2019 at 04:42:13PM +1100, Michael Ellerman wrote: > [ trimmed CC a bit ] > > Peter Zijlstra writes: > > On Fri, Dec 06, 2019 at 11:46:11PM +1100, Michael Ellerman wrote: > ... > > you write: > > > > "Currently bitops-instrumented

  1   2   3   4   5   6   7   8   >