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
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
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
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
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
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
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:
> > >
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(...)
> {
> ...
> /*
>
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 &&
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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
> +
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
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
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'
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
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
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
@@
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:
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
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
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
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
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
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_
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_
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
> >
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:
> >
> > >
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
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
>
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
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
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!
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
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
> >
> >
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)
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
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
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.
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, ((
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) &&
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;
> }
>
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
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.
>
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
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
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
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
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
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
not spelled out in any detail.
> Signed-off-by: Aneesh Kumar K.V
Acked-by: Peter Zijlstra (Intel)
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
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
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
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
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/
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
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,
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
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);
> > }
> >
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
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
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
On Tue, Dec 10, 2019 at 04:38:54PM +1100, Michael Ellerman wrote:
> Good question, I'll have a look.
>
> There seems to be confusion about what the type of the bit number is,
> which is leading to sign extension in some cases and not others.
Shiny.
> It looks like the type should be unsigned
On Fri, Dec 06, 2019 at 11:46:11PM +1100, Michael Ellerman wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hi Linus,
>
> Please pull another powerpc update for 5.5.
>
> As you'll see from the diffstat this is mostly not powerpc code. In order to
> do
> KASAN instrumentation of
On Wed, Nov 06, 2019 at 04:27:33PM +, Dmitry Safonov wrote:
> Hi Peter,
>
> On 11/6/19 9:20 AM, Peter Zijlstra wrote:
> > On Wed, Nov 06, 2019 at 03:04:51AM +, Dmitry Safonov wrote:
> >> Add log level argument to show_stack().
> >> Done in
On Wed, Nov 06, 2019 at 03:04:51AM +, Dmitry Safonov wrote:
> Add log level argument to show_stack().
> Done in three stages:
> 1. Introducing show_stack_loglvl() for every architecture
> 2. Migrating old users with an explicit log level
> 3. Renaming show_stack_loglvl() into show_stack()
>
>
On Wed, Oct 30, 2019 at 11:22:29AM +0100, Michal Hocko wrote:
> On Wed 30-10-19 11:14:49, Peter Zijlstra wrote:
> > On Wed, Oct 30, 2019 at 05:34:28PM +0800, Yunsheng Lin wrote:
> > > When passing the return value of dev_to_node() to cpumask_of_node()
> > > without check
which is only used when CONFIG_DEBUG_PER_CPU_MAPS is defined, this
> patch changes it to handle NUMA_NO_NODE as normal node_to_cpumask_map().
>
> [1] https://lkml.org/lkml/2019/9/11/66
> Signed-off-by: Yunsheng Lin
> Suggested-by: Michal Hocko
> Acked-by: Michal Hocko
> Acked-by: Paul Burton # MIPS bits
Still:
Nacked-by: Peter Zijlstra (Intel)
On Mon, Oct 14, 2019 at 11:25:09AM +0200, Greg KH wrote:
> Good luck, I don't really think that most, if any, of this is needed,
> but hey, it's nice to clean it up where it can be :)
Some of the virtual devices we have (that use devm) really ought to set
the node too, like drivers/base/cpu.c and
On Fri, Oct 11, 2019 at 11:27:54AM +0800, Yunsheng Lin wrote:
> But I failed to see why the above is related to making node_to_cpumask_map()
> NUMA_NO_NODE aware?
Your initial bug is for hns3, which is a PCI device, which really _MUST_
have a node assigned.
It not having one, is a straight up
On Wed, Oct 09, 2019 at 01:25:14PM +0100, Robin Murphy wrote:
> On 2019-10-08 9:38 am, Yunsheng Lin wrote:
> > On 2019/9/25 18:41, Peter Zijlstra wrote:
> > > On Wed, Sep 25, 2019 at 05:14:20PM +0800, Yunsheng Lin wrote:
> > > > From the discussion above, It seems
On Fri, Oct 04, 2019 at 01:42:36PM +0200, Peter Zijlstra wrote:
> If you can find anything there that isn't right, please explain that in
> detail and we'll need to look hard at fixing _that_.
Also, I can't imagine Nick is happy with 128 CPUs banging on that atomic
counter, esp. since a
On Thu, Oct 03, 2019 at 05:36:31PM -0300, Leonardo Bras wrote:
> > Also, I'm not sure I understand things properly.
> >
> > So serialize_against_pte_lookup() wants to wait for all currently
> > out-standing __find_linux_pte() instances (which are very similar to
> > gup_fast).
> >
> > It seems
On Thu, Oct 03, 2019 at 06:24:07PM -0300, Leonardo Bras wrote:
> Hello Peter, thanks for the feedback!
>
> On Thu, 2019-10-03 at 13:51 +0200, Peter Zijlstra wrote:
> > On Thu, Oct 03, 2019 at 09:11:45AM +0200, Peter Zijlstra wrote:
> > > On Wed, Oct 02, 2019 at 10:33:1
On Thu, Oct 03, 2019 at 01:40:38PM -0700, John Hubbard wrote:
> On 10/3/19 4:51 AM, Peter Zijlstra wrote:
> > On Thu, Oct 03, 2019 at 09:11:45AM +0200, Peter Zijlstra wrote:
> >> On Wed, Oct 02, 2019 at 10:33:15PM -0300, Leonardo Bras wrote:
> ...
> >
> >
On Thu, Oct 03, 2019 at 09:11:45AM +0200, Peter Zijlstra wrote:
> On Wed, Oct 02, 2019 at 10:33:15PM -0300, Leonardo Bras wrote:
> > diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
> > index 818691846c90..3043ea9812d5 100644
> > --- a/include/
On Wed, Oct 02, 2019 at 10:33:24PM -0300, Leonardo Bras wrote:
> Adds config option LOCKLESS_PAGE_TABLE_WALK_TRACKING to make possible
> enabling tracking lockless pagetable walks directly from kernel config.
>
> Signed-off-by: Leonardo Bras
> ---
> mm/Kconfig | 11 +++
> 1 file
On Wed, Oct 02, 2019 at 10:33:14PM -0300, Leonardo Bras wrote:
> If a process (qemu) with a lot of CPUs (128) try to munmap() a large
> chunk of memory (496GB) mapped with THP, it takes an average of 275
> seconds, which can cause a lot of problems to the load (in qemu case,
> the guest will lock
On Wed, Oct 02, 2019 at 10:33:15PM -0300, Leonardo Bras wrote:
> diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
> index 818691846c90..3043ea9812d5 100644
> --- a/include/asm-generic/pgtable.h
> +++ b/include/asm-generic/pgtable.h
> @@ -1171,6 +1171,64 @@ static inline
On Thu, Sep 26, 2019 at 01:45:53PM +0200, Geert Uytterhoeven wrote:
> Hi Peter,
>
> On Thu, Sep 26, 2019 at 11:42 AM Peter Zijlstra wrote:
> > On Wed, Sep 25, 2019 at 03:25:44PM +0200, Michal Hocko wrote:
> > > I am sorry but I still do not understand why you consider
On Thu, Sep 26, 2019 at 11:05:59AM +0200, Peter Zijlstra wrote:
> On Wed, Sep 25, 2019 at 11:45:26PM +0200, Peter Zijlstra wrote:
> > [7.149889] [Firmware Bug]: device: 'pci:7f': no node assigned on
> > NUMA capable HW
> > [7.882888] [Firmware Bug]: device:
On Wed, Sep 25, 2019 at 11:45:26PM +0200, Peter Zijlstra wrote:
> [7.149889] [Firmware Bug]: device: 'pci:7f': no node assigned on NUMA
> capable HW
> [7.882888] [Firmware Bug]: device: 'pci:ff': no node assigned on NUMA
> capable HW
Going by the limited number o
On Wed, Sep 25, 2019 at 06:31:54PM +0200, Peter Zijlstra wrote:
> On Wed, Sep 25, 2019 at 03:25:44PM +0200, Michal Hocko wrote:
> > I am sorry but I still do not understand why you consider this whack a
> > mole better then simply live with the fact that NUMA_NO_NODE i
On Wed, Sep 25, 2019 at 03:25:44PM +0200, Michal Hocko wrote:
> I am sorry but I still do not understand why you consider this whack a
> mole better then simply live with the fact that NUMA_NO_NODE is a
> reality and that using the full cpu mask is a reasonable answer to that.
Because it doesn't
401 - 500 of 1080 matches
Mail list logo
