Re: Should this_cpu_read() be volatile?

2018-12-08 Thread Peter Zijlstra
On Fri, Dec 07, 2018 at 04:40:52PM -0800, Nadav Amit wrote: > > I'm actually having difficulty finding the this_cpu_read() in any of the > > functions you mention, so I cannot make any concrete suggestions other > > than pointing at the alternative functions available. > > > So I got deeper

Re: [PATCH 1/8] perf: Allow to block process in syscall tracepoints

2018-12-08 Thread Peter Zijlstra
On Fri, Dec 07, 2018 at 03:14:33PM -0500, Steven Rostedt wrote: > On Fri, 7 Dec 2018 16:11:05 +0100 > Peter Zijlstra wrote: > > > On Fri, Dec 07, 2018 at 08:41:18AM -0500, Steven Rostedt wrote: > > > On Fri, 7 Dec 2018 09:58:39 +0100 > > > Peter Zijlstra wrot

Re: [PATCH 1/8] perf: Allow to block process in syscall tracepoints

2018-12-08 Thread Peter Zijlstra
On Fri, Dec 07, 2018 at 12:49:21PM -0300, Arnaldo Carvalho de Melo wrote: > Em Fri, Dec 07, 2018 at 04:11:05PM +0100, Peter Zijlstra escreveu: > > On Fri, Dec 07, 2018 at 08:41:18AM -0500, Steven Rostedt wrote: > > > On Fri, 7 Dec 2018 09:58:39 +0100 Peter Zijl

Re: [PATCH v3 00/24] locking/lockdep: Add support for dynamic keys

2018-12-08 Thread Peter Zijlstra
On Fri, Dec 07, 2018 at 08:35:52AM -0800, Bart Van Assche wrote: > On Fri, 2018-12-07 at 13:23 +0100, Peter Zijlstra wrote: > > I took the first 15 patches for now to shrink the series. > > Thanks Peter. Since I would like to rebase the remaining patches on top of > what you h

Re: [PATCH 1/8] perf: Allow to block process in syscall tracepoints

2018-12-07 Thread Peter Zijlstra
On Fri, Dec 07, 2018 at 08:41:18AM -0500, Steven Rostedt wrote: > On Fri, 7 Dec 2018 09:58:39 +0100 > Peter Zijlstra wrote: > > > These patches give no justification *what*so*ever* for why we're doing > > ugly arse things like this. And why does this, whatever this is

Re: [PATCH v3 00/24] locking/lockdep: Add support for dynamic keys

2018-12-07 Thread Peter Zijlstra
Bart, I took the first 15 patches for now to shrink the series. I think the rest wants a little more work.

Re: [PATCH v3 17/24] locking/lockdep: Free lock classes that are no longer in use

2018-12-07 Thread Peter Zijlstra
On Thu, Dec 06, 2018 at 05:11:41PM -0800, Bart Van Assche wrote: > + if (WARN_ON_ONCE(!hlock_class(prev)->hash_entry.pprev) || > + WARN_ONCE(!hlock_class(next)->hash_entry.pprev, > + KERN_INFO "Detected use-after-free of lock class %s\n", > +

Re: [PATCH v3 16/24] locking/lockdep: Retain the class key and name while freeing a lock class

2018-12-07 Thread Peter Zijlstra
e discussion with v2; you meant to say: 'uses the class name pointer', right? You're not actually ever going to dereference it, since that would be a UaF. > > Cc: Peter Zijlstra > Cc: Waiman Long > Cc: Johannes Berg > Signed-off-by: Bart Van Assche > --- > kernel/locking/loc

Re: [PATCH 1/8] perf: Allow to block process in syscall tracepoints

2018-12-07 Thread Peter Zijlstra
On Thu, Dec 06, 2018 at 01:19:46PM -0500, Steven Rostedt wrote: > On Thu, 6 Dec 2018 09:34:00 +0100 > Peter Zijlstra wrote: > > > > > > > I don't understand this.. why are we using schedule_timeout() and all > > > that? > > > > Urgh..

Re: [PATCH 2/2] x86/speculation: switch_to_cond_stibp on is the likely case

2018-12-07 Thread Peter Zijlstra
On Thu, Dec 06, 2018 at 10:38:00AM -0500, Waiman Long wrote: > On 12/06/2018 03:41 AM, Peter Zijlstra wrote: > > On Wed, Dec 05, 2018 at 02:49:28PM -0500, Waiman Long wrote: > >> Since conditional STIBP is the default, it should be treated as > >> the l

Re: [PATCH v2 0/2] arm64: Only call into preempt_schedule() if need_resched()

2018-12-06 Thread Peter Zijlstra
eempt_count_dec_and_test() now > reloads the need_resched flag if it initially saw that it was set. This > resolves the issue spotted by Peter, where an IRQ coming in during the > decrement can cause a reschedule to be missed. Yes, I think this one will work, so: Acked-by: Peter Zijlstra

Re: [PATCH 1/8] perf: Allow to block process in syscall tracepoints

2018-12-06 Thread Peter Zijlstra
On Thu, Dec 06, 2018 at 09:24:55AM +0100, Jiri Olsa wrote: > On Thu, Dec 06, 2018 at 09:10:28AM +0100, Peter Zijlstra wrote: > > On Wed, Dec 05, 2018 at 05:05:02PM +0100, Jiri Olsa wrote: > > > +static void trace_block_syscall(struct pt_regs *regs, bool enter) > &

Re: [PATCH v7 00/14] x86/alternative: text_poke() enhancements

2018-12-06 Thread Peter Zijlstra
On Tue, Dec 04, 2018 at 05:33:54PM -0800, Nadav Amit wrote: > Which leads me to (b) - the patch-set is big "enough" IMHO. Indeed, > there are open security issues in the kernel when it comes to W^X. But > some people would want to use Andy's temporary mm-struct for other uses. > So additional

Re: [PATCH v7 14/14] module: Prevent module removal racing with text_poke()

2018-12-06 Thread Peter Zijlstra
On Tue, Dec 04, 2018 at 05:34:08PM -0800, Nadav Amit wrote: > It seems dangerous to allow code modifications to take place > concurrently with module unloading. So take the text_mutex while the > memory of the module is freed. Fun detail, only x86 seems to actually take text_mutex while poking

Re: [PATCH v7 13/14] module: Do not set nx for module memory before freeing

2018-12-06 Thread Peter Zijlstra
On Tue, Dec 04, 2018 at 05:34:07PM -0800, Nadav Amit wrote: > So let's remove it. Andy suggested that the changes of the PTEs can be > avoided (excluding the direct-mapping alias), which is true. However, > in x86 it requires some cleanup of the contiguous page allocator, which > is outside of

Re: [PATCH 2/6] __wr_after_init: write rare for static allocation

2018-12-06 Thread Peter Zijlstra
On Wed, Dec 05, 2018 at 03:13:56PM -0800, Andy Lutomirski wrote: > > + if (op == WR_MEMCPY) > > + memcpy((void *)wr_poking_addr, (void *)src, len); > > + else if (op == WR_MEMSET) > > + memset((u8 *)wr_poking_addr, (u8)src, len); > > + else if (op ==

Re: [RFC] sched/fair: Align vruntime to last_se when curr_se's timeslice run out

2018-12-06 Thread Peter Zijlstra
On Wed, Dec 05, 2018 at 08:41:39PM +0800, weiqi (C) wrote: > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index ee271bb..1f61b9c 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -4020,7 +4020,23 @@ static void clear_buddies(struct cfs_rq *cfs_rq, > struct

Re: [PATCH 2/2] x86/speculation: switch_to_cond_stibp on is the likely case

2018-12-06 Thread Peter Zijlstra
On Wed, Dec 05, 2018 at 02:49:28PM -0500, Waiman Long wrote: > Since conditional STIBP is the default, it should be treated as > the likely case. Changes the use of static_branch_unlikely() to > static_branch_likely() for switch_to_cond_stibp. So now you're making kernels on 'fixed' or unaffected

Re: [PATCH 1/8] perf: Allow to block process in syscall tracepoints

2018-12-06 Thread Peter Zijlstra
On Thu, Dec 06, 2018 at 09:10:28AM +0100, Peter Zijlstra wrote: > On Wed, Dec 05, 2018 at 05:05:02PM +0100, Jiri Olsa wrote: > > +static void trace_block_syscall(struct pt_regs *regs, bool enter) > > +{ > > + current->perf_blocked = true; > > + > > + do {

Re: [PATCH 1/8] perf: Allow to block process in syscall tracepoints

2018-12-06 Thread Peter Zijlstra
On Wed, Dec 05, 2018 at 05:05:02PM +0100, Jiri Olsa wrote: > @@ -10461,6 +10484,19 @@ SYSCALL_DEFINE5(perf_event_open, > return -EINVAL; > } > > + if (attr.block) { > + /* > + * Allow only syscall tracepoints, check for syscall class > +

Re: [PATCH 1/8] perf: Allow to block process in syscall tracepoints

2018-12-06 Thread Peter Zijlstra
On Wed, Dec 05, 2018 at 05:05:02PM +0100, Jiri Olsa wrote: > +static void trace_block_syscall(struct pt_regs *regs, bool enter) > +{ > + current->perf_blocked = true; > + > + do { > + schedule_timeout(100 * HZ); > + current->perf_blocked_cnt = 0; > + > +

Re: [PATCH 1/8] perf: Allow to block process in syscall tracepoints

2018-12-06 Thread Peter Zijlstra
On Wed, Dec 05, 2018 at 05:05:02PM +0100, Jiri Olsa wrote: > Adding support to specify 'block' bool in struct perf_event_attr NAK for having _Bool in structures.

Re: [PATCH 22/27] locking/lockdep: Reuse list entries that are no longer in use

2018-12-04 Thread Peter Zijlstra
On Mon, Dec 03, 2018 at 10:16:59AM -0800, Bart Van Assche wrote: > On Mon, 2018-12-03 at 18:32 +0100, Peter Zijlstra wrote: > > On Mon, Dec 03, 2018 at 08:40:48AM -0800, Bart Van Assche wrote: > > > > > > I think we can do this with a free bitmap and an array o

Re: [PATCH 22/27] locking/lockdep: Reuse list entries that are no longer in use

2018-12-03 Thread Peter Zijlstra
On Mon, Dec 03, 2018 at 08:40:48AM -0800, Bart Van Assche wrote: > > I think we can do this with a free bitmap and an array of 2 pending > > bitmaps and an index. Add newly freed entries to the pending bitmap > > indicated by the current index, when complete flip the index -- such > > that

Re: [PATCH 25/27] locking/lockdep: Add support for dynamic keys

2018-12-03 Thread Peter Zijlstra
On Mon, Dec 03, 2018 at 09:07:00AM -0800, Bart Van Assche wrote: > How about adding this as an additional patch before patch 25/27? Excellent, thanks! > diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c > index 9a7cca6dc3d4..ce05b9b419f4 100644 > --- a/kernel/locking/lockdep.c >

[RFC][PATCH 08/10] x86/mm/cpa: Fold cpa_flush_range() and cpa_flush_array()

2018-12-03 Thread Peter Zijlstra
into a single cpa_flush() call. Signed-off-by: Peter Zijlstra (Intel) --- arch/x86/mm/pageattr.c | 92 + 1 file changed, 18 insertions(+), 74 deletions(-) --- a/arch/x86/mm/pageattr.c +++ b/arch/x86/mm/pageattr.c @@ -304,51 +304,7 @@ static void

[RFC][PATCH 09/10] x86/mm/cpa: Better use clflushopt

2018-12-03 Thread Peter Zijlstra
Currently we issue an MFENCE before and after flushing a range. This means that if we flush a bunch of single page ranges -- like with the cpa array, we issue a whole bunch of superfluous MFENCEs. Reorgainze the code a little to avoid this. Signed-off-by: Peter Zijlstra (Intel) --- arch/x86/mm

[RFC][PATCH 03/10] x86/mm/cpa: Add __cpa_addr() helper

2018-12-03 Thread Peter Zijlstra
The code to compute the virtual address of a cpa_data is duplicated; introduce a helper before more copies happen. Signed-off-by: Peter Zijlstra (Intel) --- arch/x86/mm/pageattr.c | 38 +++--- 1 file changed, 19 insertions(+), 19 deletions(-) --- a/arch/x86/mm

[RFC][PATCH 06/10] x86/mm/cpa: Optimize cpa_flush_array() TLB invalidation

2018-12-03 Thread Peter Zijlstra
Instead of punting and doing tlb_flush_all(), do the same as flush_tlb_kernel_range() does and use single page invalidations. Signed-off-by: Peter Zijlstra (Intel) --- arch/x86/mm/mm_internal.h |2 ++ arch/x86/mm/pageattr.c| 42 -- arch/x86/mm

[RFC][PATCH 02/10] x86/mm/cpa: Add ARRAY and PAGES_ARRAY selftests

2018-12-03 Thread Peter Zijlstra
The current pageattr-test code only uses the regular range interface, add code that also tests the array and pages interface. Signed-off-by: Peter Zijlstra (Intel) --- arch/x86/mm/pageattr-test.c | 28 1 file changed, 24 insertions(+), 4 deletions(-) --- a/arch

[RFC][PATCH 07/10] x86/mm/cpa: Make cpa_data::numpages invariant

2018-12-03 Thread Peter Zijlstra
Make sure __change_page_attr_set_clr() doesn't modify cpa->numpages. Signed-off-by: Peter Zijlstra (Intel) --- arch/x86/mm/pageattr.c | 21 + 1 file changed, 13 insertions(+), 8 deletions(-) --- a/arch/x86/mm/pageattr.c +++ b/arch/x86/mm/pageattr.c @@ -1623,14 +1623

[RFC][PATCH 00/10] x86/mm/cpa: Various fixes and improvements

2018-12-03 Thread Peter Zijlstra
With exception of the very first patch, this whole series is probablt RFC at this point. (and thanks to sending that earlier email saying that I was stumped by this crap, I instantly spotted my problem) Dave, I didn't address that tlbinv(0) point you made, mostly because I didn't have a good

[RFC][PATCH 05/10] x86/mm/cpa: Cleanup...

2018-12-03 Thread Peter Zijlstra
Since cpa->vaddr is invariant, this means we can remove all workarounds that deal with it changing. Signed-off-by: Peter Zijlstra (Intel) --- arch/x86/mm/pageattr-test.c |7 ++- arch/x86/mm/pageattr.c | 13 - 2 files changed, 6 insertions(+), 14 deleti

[PATCH 01/10] x86/mm/cpa: Fix cpa_flush_array() TLB invalidation

2018-12-03 Thread Peter Zijlstra
quot;x86/mm/cpa: Use flush_tlb_kernel_range()") Reported-by: "StDenis, Tom" Signed-off-by: Peter Zijlstra (Intel) --- arch/x86/mm/pageattr.c | 24 1 file changed, 16 insertions(+), 8 deletions(-) diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c in

[RFC][PATCH 04/10] x86/mm/cpa: Make cpa_data::vaddr invariant

2018-12-03 Thread Peter Zijlstra
TE: since cpa_data::numpages is 'unsigned long' so should cpa_data::curpage be. NOTE: after this only cpa->numpages is still modified. Signed-off-by: Peter Zijlstra (Intel) --- arch/x86/mm/pageattr.c | 18 -- 1 file changed, 8 insertions(+), 10 deletions(-) --- a/arch/x86/m

[RFC][PATCH 10/10] x86/mm/cpa: Rename @addrinarray

2018-12-03 Thread Peter Zijlstra
The CPA_ARRAY interface works in single pages, and everything, except in these 'few' locations is this variable called 'numpages'. Remove this abberation. Signed-off-by: Peter Zijlstra (Intel) --- arch/x86/mm/pageattr.c | 52 - 1 file changed

Re: [PATCH 0/4] x86/mm/cpa: Fix cpa-array TLB invalidation

2018-12-03 Thread Peter Zijlstra
for now. Fixes: a7295fd53c39 ("x86/mm/cpa: Use flush_tlb_kernel_range()") Reported-by: "StDenis, Tom" Signed-off-by: Peter Zijlstra (Intel) --- arch/x86/mm/pageattr.c | 24 1 file changed, 16 insertions(+), 8 deletions(-) diff --git a/arch/x86/mm

Re: [PATCH] locktorture: Fix assignment of boolean variables

2018-12-03 Thread Peter Zijlstra
On Mon, Dec 03, 2018 at 10:20:42AM +0100, Julia Lawall wrote: > Personally, I would prefer that assignments involving boolean variables > use true or false. It seems more readable. Potentially better for tools > as well. Then those tools are broken per the C spec. > But if the community really

Re: [PATCH] tools: Fix diverse typos

2018-12-03 Thread Peter Zijlstra
On Mon, Dec 03, 2018 at 11:22:00AM +0100, Ingo Molnar wrote: > Go over the tools/ files that are maintained in Arnaldo's tree and > fix common typos: half of them were in comments, the other half > in JSON files. > > ( Care should be taken not to re-import these typos in the future, > if the

Re: [PATCH] locktorture: Fix assignment of boolean variables

2018-12-03 Thread Peter Zijlstra
On Mon, Dec 03, 2018 at 09:35:00AM +0100, Peter Zijlstra wrote: > On Sat, Dec 01, 2018 at 12:37:01PM -0800, Paul E. McKenney wrote: > > On Sat, Dec 01, 2018 at 04:31:49PM +0800, Wen Yang wrote: > > > Fix the following warnings reported by coccinelle: > > > > > >

Re: [PATCH] locktorture: Fix assignment of boolean variables

2018-12-03 Thread Peter Zijlstra
On Sat, Dec 01, 2018 at 12:37:01PM -0800, Paul E. McKenney wrote: > On Sat, Dec 01, 2018 at 04:31:49PM +0800, Wen Yang wrote: > > Fix the following warnings reported by coccinelle: > > > > kernel/locking/locktorture.c:703:6-10: WARNING: Assignment of bool to 0/1 > >

Re: [PATCH] sched/fair: Fix assignment of boolean variables

2018-12-03 Thread Peter Zijlstra
e/true needs to stay away from C. > Signed-off-by: Wen Yang > CC: Ingo Molnar > CC: Peter Zijlstra > CC: linux-kernel@vger.kernel.org > --- > kernel/sched/fair.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/sched/fair.c b/kernel/sched/fa

Re: [PATCH 22/27] locking/lockdep: Reuse list entries that are no longer in use

2018-12-01 Thread Peter Zijlstra
On Thu, Nov 29, 2018 at 08:48:50AM -0800, Bart Van Assche wrote: > On Thu, 2018-11-29 at 13:01 +0100, Peter Zijlstra wrote: > > On Thu, Nov 29, 2018 at 11:49:02AM +0100, Peter Zijlstra wrote: > > > On Wed, Nov 28, 2018 at 03:43:20PM -0800, Bar

Re: [PATCH v2 0/5] x86/mm: Drop usage of __flush_tlb_all() in kernel_physical_mapping_init()

2018-12-01 Thread Peter Zijlstra
x86/mm: Validate kernel_physical_mapping_init() pte population > x86/mm: Drop usage of __flush_tlb_all() in > kernel_physical_mapping_init() > Since you failed to send me 1,2, only for 3-5: Acked-by: Peter Zijlstra (Intel) although going by the subjects, the earlier two patches should be fine too.

Re: [PATCH v2 5/5] x86/mm: Drop usage of __flush_tlb_all() in kernel_physical_mapping_init()

2018-12-01 Thread Peter Zijlstra
A small nit: On Fri, Nov 30, 2018 at 04:35:32PM -0800, Dan Williams wrote: > [1]: > https://lore.kernel.org/lkml/9dfd717d-857d-493d-a606-b635d72ba...@amacapital.net > [2]: > https://lore.kernel.org/lkml/749919a4-cdb1-48a3-adb4-adb81a5fa...@intel.com I much prefer the form:

Re: [PATCH] riscv, atomic: Add #define's for the atomic_{cmp,}xchg_*() variants

2018-12-01 Thread Peter Zijlstra
ever told > (#define-d these for) the generic implementation: it is time to do so. > > Signed-off-by: Andrea Parri > Cc: Palmer Dabbelt > Cc: Albert Ou > Cc: Will Deacon > Cc: Peter Zijlstra > Cc: Boqun Feng Acked-by: Peter Zijlstra (Intel) > --- > arch/riscv/

Re: [PATCH 0/4] x86/mm/cpa: Fix cpa-array TLB invalidation

2018-11-30 Thread Peter Zijlstra
On Fri, Nov 30, 2018 at 05:49:34PM +, StDenis, Tom wrote: > On 2018-11-30 12:48 p.m., Peter Zijlstra wrote: > > On Fri, Nov 30, 2018 at 04:19:46PM +, StDenis, Tom wrote: > >> On 2018-11-30 10:31 a.m., Peter Zijlstra wrote: > > > >>> I pus

Re: [PATCH 0/4] x86/mm/cpa: Fix cpa-array TLB invalidation

2018-11-30 Thread Peter Zijlstra
On Fri, Nov 30, 2018 at 03:27:02PM +, StDenis, Tom wrote: > I can apply the patch you attached but the inline patches just don't > apply. Could be my imap client (thunderbird) mangled them but I've > applied patches this way before. could you attach them instead please? That's arguably a

Re: [PATCH 0/4] x86/mm/cpa: Fix cpa-array TLB invalidation

2018-11-30 Thread Peter Zijlstra
On Fri, Nov 30, 2018 at 04:19:46PM +, StDenis, Tom wrote: > On 2018-11-30 10:31 a.m., Peter Zijlstra wrote: > > I pushed them out to: > > > >git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git x86/mm > > > > I hope that works; I'm out

Re: [PATCH 0/4] x86/mm/cpa: Fix cpa-array TLB invalidation

2018-11-30 Thread Peter Zijlstra
On Fri, Nov 30, 2018 at 04:23:47PM +0100, Peter Zijlstra wrote: > Hurm.. no. They apply cleanly to Linus' tree here. > > linux-2.6$ git describe > v4.20-rc4-156-g94f371cb7394 > linux-2.6$ quilt push 4 > Applying patch patches/peterz-cpa-addr.patch > patching file a

Re: [PATCH 0/4] x86/mm/cpa: Fix cpa-array TLB invalidation

2018-11-30 Thread Peter Zijlstra
On Fri, Nov 30, 2018 at 03:14:30PM +, StDenis, Tom wrote: > On 2018-11-30 10:09 a.m., Peter Zijlstra wrote: > > On Fri, Nov 30, 2018 at 02:52:26PM +, StDenis, Tom wrote: > >> Hi Peter, > >> > >> Unfortunately I can't apply this on top of our

Re: [PATCH 0/4] x86/mm/cpa: Fix cpa-array TLB invalidation

2018-11-30 Thread Peter Zijlstra
On Fri, Nov 30, 2018 at 02:52:26PM +, StDenis, Tom wrote: > Hi Peter, > > Unfortunately I can't apply this on top of our drm-next the first patch > fails. Against what tree would you like the patches? rebasing should not be hard I think.

Re: 答复: [RFC] locking/rwsem: Avoid issuing wakeup before setting the reader waiter to nil

2018-11-30 Thread Peter Zijlstra
On Fri, Nov 30, 2018 at 09:34:19AM +, Liu,Qi(ACU-T1) wrote: > Is there a semantic divergence between x86 instruction "LOCK cmpxchg" > and the macro cmpxchg defined in linux kernel? The former guarantee > full barrier in any case, and the latter only imply barrier in case of > success? > So,

[PATCH 3/4] x86/mm/cpa: Fold cpa_flush_range() and cpa_flush_array()

2018-11-30 Thread Peter Zijlstra
@cpa, so we have to save and restore part of that to ensure we flush the original range. Signed-off-by: Peter Zijlstra (Intel) --- arch/x86/mm/pageattr.c | 96 ++--- 1 file changed, 29 insertions(+), 67 deletions(-) --- a/arch/x86/mm/pageattr.c +++ b

[PATCH 0/4] x86/mm/cpa: Fix cpa-array TLB invalidation

2018-11-30 Thread Peter Zijlstra
Hi, Yesterday Tom reported a CPA bug triggered by the AMDGPU team. It turns out that with commit: a7295fd53c39 ("x86/mm/cpa: Use flush_tlb_kernel_range()") I misread the cpa array code and messed up the TLB invalidations for it. These patches (hopefully) fix the issue while also shrinking

[PATCH 1/4] x86/mm/cpa: Add __cpa_addr() helper

2018-11-30 Thread Peter Zijlstra
The code to compute the virtual address of a cpa_data is duplicated; introduce a helper before more copies happen. Signed-off-by: Peter Zijlstra (Intel) --- arch/x86/mm/pageattr.c | 38 +++--- 1 file changed, 19 insertions(+), 19 deletions(-) --- a/arch/x86/mm

[PATCH 2/4] x86/mm/cpa: Fix cpa_flush_array()

2018-11-30 Thread Peter Zijlstra
3c39 ("x86/mm/cpa: Use flush_tlb_kernel_range()") Reported-by: "StDenis, Tom" Signed-off-by: Peter Zijlstra (Intel) --- arch/x86/mm/mm_internal.h |2 + arch/x86/mm/pageattr.c| 62 -- arch/x86/mm/tlb.c |4 ++

[PATCH 4/4] x86/mm/cpa: Better use clflushopt

2018-11-30 Thread Peter Zijlstra
Currently we issue an MFENCE before and after flushing a range. This means that if we flush a bunch of single page ranges -- like with the cpa array, we issue a whole bunch of superfluous MFENCEs. Reorgainze the code a little to avoid this. Signed-off-by: Peter Zijlstra (Intel) --- arch/x86/mm

Re: [PATCH 0/2] locking/lockdep: Track number of zapped classes & report abuse

2018-11-29 Thread Peter Zijlstra
On Thu, Nov 29, 2018 at 05:41:35PM -0500, Waiman Long wrote: > When a kernel module is repeatedly load and unload, it will eventually > exhaust the lockdep entries resulting in a bug message. This is a use > case that the current lockdep code cannot support. > > This patchset tracks the number of

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-29 Thread Peter Zijlstra
On Thu, Nov 29, 2018 at 04:14:46PM -0600, Josh Poimboeuf wrote: > On Thu, Nov 29, 2018 at 11:01:48PM +0100, Peter Zijlstra wrote: > > On Thu, Nov 29, 2018 at 11:10:50AM -0600, Josh Poimboeuf wrote: > > > On Thu, Nov 29, 2018 at 08:59:31AM -0800, Andy Lutomirski wrote: > >

Re: [RFC] locking/rwsem: Avoid issuing wakeup before setting the reader waiter to nil

2018-11-29 Thread Peter Zijlstra
On Thu, Nov 29, 2018 at 01:34:21PM -0800, Davidlohr Bueso wrote: > I messed up something such that waiman was not in the thread. Ccing. > > > On Thu, 29 Nov 2018, Waiman Long wrote: > > > > > That can be costly for x86 which will now have 2 locked instructions. > > > > Yeah, and when used as an

Re: [RFC] locking/rwsem: Avoid issuing wakeup before setting the reader waiter to nil

2018-11-29 Thread Peter Zijlstra
On Thu, Nov 29, 2018 at 01:34:05PM -0500, Waiman Long wrote: > That will certainly work for x86. However, I am not sure if that will be > optimal for arm and powerpc. smp_mb__before_atomic() cmpxchg_relaxed() works. Also see pv_kick_node()'s commit: 34d54f3d6917

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-29 Thread Peter Zijlstra
On Thu, Nov 29, 2018 at 11:10:50AM -0600, Josh Poimboeuf wrote: > On Thu, Nov 29, 2018 at 08:59:31AM -0800, Andy Lutomirski wrote: > > (like pointing IP at a stub that retpolines to the target by reading > > the function pointer, a la the unoptimizable version), then okay, I > > guess, with only

Re: [RFC] locking/rwsem: Avoid issuing wakeup before setting the reader waiter to nil

2018-11-29 Thread Peter Zijlstra
On Thu, Nov 29, 2018 at 12:58:26PM -0500, Waiman Long wrote: > OK, you convinced me. However, that can still lead to anonymous wakeups > that can be problematic if it happens in certain places. Should we try > to reduce anonymous wakeup as much as possible? No, we should at all times accept and

Re: [RFC] locking/rwsem: Avoid issuing wakeup before setting the reader waiter to nil

2018-11-29 Thread Peter Zijlstra
On Thu, Nov 29, 2018 at 06:27:00PM +0100, Peter Zijlstra wrote: > > wake_up_q() should, per the barriers in wake_up_process, ensure that if > wake_a_add() fails, there will be a wakeup of that task after that > point. > > So if we put wake_up_q() at the location where wake_u

Re: [RFC] locking/rwsem: Avoid issuing wakeup before setting the reader waiter to nil

2018-11-29 Thread Peter Zijlstra
On Thu, Nov 29, 2018 at 12:02:19PM -0500, Waiman Long wrote: > On 11/29/2018 11:06 AM, Peter Zijlstra wrote: > > Why; at that point we know the wakeup will happen after, which is all we > > require. > > > Thread 1

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-29 Thread Peter Zijlstra
On Thu, Nov 29, 2018 at 08:59:31AM -0800, Andy Lutomirski wrote: > If you make it conditional on CPL, do it for 32-bit as well, add > comments, > and convince yourself that there isn’t a better solution > (like pointing IP at a stub that retpolines to the target by reading > the function

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-29 Thread Peter Zijlstra
On Thu, Nov 29, 2018 at 09:02:23AM -0800, Andy Lutomirski wrote: > > On Nov 29, 2018, at 8:50 AM, Linus Torvalds > > wrote: > > So no. Do *not* try to change %rsp on the stack in the bp handler. > > Instead, I'd suggest: > > > > - just restart the instruction (with the suggested "ptregs->rip

Re: [PATCH 23/27] locking/lockdep: Check data structure consistency

2018-11-29 Thread Peter Zijlstra
On Thu, Nov 29, 2018 at 08:50:02AM -0800, Bart Van Assche wrote: > On Thu, 2018-11-29 at 13:30 +0100, Peter Zijlstra wrote: > > IIRC there were a few other sites in the series, please check them all. > > OK, I will add braces around multi-line statement blocks. You may

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-29 Thread Peter Zijlstra
On Thu, Nov 29, 2018 at 10:33:42AM -0600, Josh Poimboeuf wrote: > > can't we 'fix' that again? The alternative is moving that IRET-frame and > > fixing everything up, which is going to be fragile, ugly and such > > things more. > This seems to work... That's almost too easy... nice! > diff

Re: [RFC] locking/rwsem: Avoid issuing wakeup before setting the reader waiter to nil

2018-11-29 Thread Peter Zijlstra
On Thu, Nov 29, 2018 at 10:21:58AM -0500, Waiman Long wrote: > >> diff --git a/kernel/locking/rwsem-xadd.c b/kernel/locking/rwsem-xadd.c > >> index 09b1800..50d9af6 100644 > >> --- a/kernel/locking/rwsem-xadd.c > >> +++ b/kernel/locking/rwsem-xadd.c > >> @@ -198,15 +198,22 @@ static void

Re: [patch V2 08/28] sched/smt: Make sched_smt_present track topology

2018-11-29 Thread Peter Zijlstra
On Thu, Nov 29, 2018 at 09:50:13AM -0500, Konrad Rzeszutek Wilk wrote: > On Thu, Nov 29, 2018 at 09:42:56AM -0500, Konrad Rzeszutek Wilk wrote: > > On Sun, Nov 25, 2018 at 07:33:36PM +0100, Thomas Gleixner wrote: > > > Currently the 'sched_smt_present' static key is enabled when at CPU > > >

Re: [REGRESSION] x86, perf: counter freezing breaks rr

2018-11-29 Thread Peter Zijlstra
On Tue, Nov 27, 2018 at 03:36:15PM -0800, Andi Kleen wrote: > > It does seem that FREEZE_PERFMON_ON_PMI (misnamed as it is) is of > > rather limited use (or even negative, in our case) to a counter that's > > already restricted to ring 3. > > It's much faster. The PMI cost goes down dramatically.

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-29 Thread Peter Zijlstra
On Thu, Nov 29, 2018 at 05:37:39AM -0800, Andy Lutomirski wrote: > > > > On Nov 29, 2018, at 1:42 AM, Peter Zijlstra wrote: > > > > On Wed, Nov 28, 2018 at 10:05:54PM -0800, Andy Lutomirski wrote: > > > >>>> +static void static_call

Re: [RFC] locking/rwsem: Avoid issuing wakeup before setting the reader waiter to nil

2018-11-29 Thread Peter Zijlstra
On Thu, Nov 29, 2018 at 02:12:32PM +0100, Peter Zijlstra wrote: > > +Cc davidlohr and waiman > Urgh; so the case where the cmpxchg() fails because it already has a > wakeup in progress, which then 'violates' our expectation of when the > wakeup happens. > > Yes, I think th

Re: [RFC] locking/rwsem: Avoid issuing wakeup before setting the reader waiter to nil

2018-11-29 Thread Peter Zijlstra
+Cc davidlohr and waiman On Thu, Nov 29, 2018 at 08:50:30PM +0800, Yongji Xie wrote: > From: Xie Yongji > > Our system encountered a problem recently, the khungtaskd detected > some process hang on mmap_sem. But the odd thing was that one task which > is not on mmap_sem.wait_list still sleeps

Re: [PATCH v6 00/10] x86/alternative: text_poke() fixes

2018-11-29 Thread Peter Zijlstra
On Mon, Nov 26, 2018 at 05:46:09PM +, Nadav Amit wrote: > One small request - on [02/10], since after your review the patch changed to > be the single line that you provided, I set you as a co-developer. IIUC this > requires your signed-off-by. I really wouldn't know. Feel free to do as you

Re: [PATCH v7 2/2] sched/fair: update scale invariance of PELT

2018-11-29 Thread Peter Zijlstra
On Wed, Nov 28, 2018 at 11:53:36AM +, Patrick Bellasi wrote: > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index ac855b2f4774..93e0cf5d8a76 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -3661,6 +3661,10 @@ util_est_dequeue(struct cfs_rq *cfs_rq, struct >

Re: [PATCH 00/27] locking/lockdep: Add support for dynamic keys

2018-11-29 Thread Peter Zijlstra
On Wed, Nov 28, 2018 at 03:42:58PM -0800, Bart Van Assche wrote: > Hi Ingo and Peter, > > A known shortcoming of the current lockdep implementation is that it requires > lock keys to be allocated statically and that this key sharing can cause false > positive deadlock reports. This patch series

Re: [PATCH 23/27] locking/lockdep: Check data structure consistency

2018-11-29 Thread Peter Zijlstra
On Wed, Nov 28, 2018 at 03:43:21PM -0800, Bart Van Assche wrote: > +static bool in_list(struct list_head *e, struct list_head *h) > +{ > + struct list_head *f; > + > + list_for_each(f, h) > + if (e == f) > + return true; Coding style wants { } around any

Re: [PATCH 25/27] locking/lockdep: Add support for dynamic keys

2018-11-29 Thread Peter Zijlstra
On Wed, Nov 28, 2018 at 03:43:23PM -0800, Bart Van Assche wrote: > A shortcoming of the current lockdep implementation is that it requires > lock keys to be allocated statically. That forces certain lock objects > to share lock keys. Since lock dependency analysis groups lock objects > per key

Re: [PATCH 22/27] locking/lockdep: Reuse list entries that are no longer in use

2018-11-29 Thread Peter Zijlstra
On Thu, Nov 29, 2018 at 11:49:02AM +0100, Peter Zijlstra wrote: > On Wed, Nov 28, 2018 at 03:43:20PM -0800, Bart Van Assche wrote: > > Instead of abandoning elements of list_entries[] that are no longer in > > use, make alloc_list_entry() reuse array elements that have been fre

Re: [PATCH 22/27] locking/lockdep: Reuse list entries that are no longer in use

2018-11-29 Thread Peter Zijlstra
On Wed, Nov 28, 2018 at 03:43:20PM -0800, Bart Van Assche wrote: > Instead of abandoning elements of list_entries[] that are no longer in > use, make alloc_list_entry() reuse array elements that have been freed. > diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h > index

Re: [PATCH 20/27] locking/lockdep: Free lock classes that are no longer in use

2018-11-29 Thread Peter Zijlstra
On Wed, Nov 28, 2018 at 03:43:18PM -0800, Bart Van Assche wrote: > +/* Must be called with the graph lock held. */ > +static void remove_class_from_lock_chain(struct lock_chain *chain, > + struct lock_class *class) > +{ > + u64 chain_key; > + int i; > +

Re: [PATCH 25/27] locking/lockdep: Add support for dynamic keys

2018-11-29 Thread Peter Zijlstra
On Wed, Nov 28, 2018 at 03:43:23PM -0800, Bart Van Assche wrote: > +/* hash_entry is used to keep track of dynamically allocated keys. */ > struct lock_class_key { > + struct hlist_node hash_entry; > struct lockdep_subclass_key subkeys[MAX_LOCKDEP_SUBCLASSES]; > };

Re: [PATCH 24/27] locking/lockdep: Introduce __lockdep_free_key_range()

2018-11-29 Thread Peter Zijlstra
On Wed, Nov 28, 2018 at 03:43:22PM -0800, Bart Van Assche wrote: > This patch does not change any functionality but makes the next patch > in this series easier to read. Ooh, I completely forgot about commit: 35a9393c95b3 ("lockdep: Fix the module unload key range freeing logic") I was still

Re: [RFC PATCH 1/5] x86: introduce preemption disable prefix

2018-11-29 Thread Peter Zijlstra
On Fri, Oct 19, 2018 at 07:29:45AM -0700, Andy Lutomirski wrote: > > On Oct 19, 2018, at 1:33 AM, Peter Zijlstra wrote: > > > >> On Fri, Oct 19, 2018 at 01:08:23AM +, Nadav Amit wrote: > >> Consider for example do_int3(), and see my inlined comments: > &g

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-29 Thread Peter Zijlstra
On Wed, Nov 28, 2018 at 10:05:54PM -0800, Andy Lutomirski wrote: > >> +static void static_call_bp_handler(struct pt_regs *regs, void *_data) > >> +{ > >> +struct static_call_bp_data *data = _data; > >> + > >> +/* > >> + * For inline static calls, push the return address on the stack

Re: [PATCH 2/2] arm64: preempt: Provide our own implementation of asm/preempt.h

2018-11-28 Thread Peter Zijlstra
On Wed, Nov 28, 2018 at 04:35:42PM +0100, Ard Biesheuvel wrote: > On Tue, 27 Nov 2018 at 20:44, Will Deacon wrote: > > > > The asm-generic/preempt.h implementation doesn't make use of the > > PREEMPT_NEED_RESCHED flag, since this can interact badly with load/store > > architectures which rely on

[tip:x86/pti] sched/smt: Make sched_smt_present track topology

2018-11-28 Thread tip-bot for Peter Zijlstra (Intel)
Commit-ID: c5511d03ec090980732e929c318a7a6374b5550e Gitweb: https://git.kernel.org/tip/c5511d03ec090980732e929c318a7a6374b5550e Author: Peter Zijlstra (Intel) AuthorDate: Sun, 25 Nov 2018 19:33:36 +0100 Committer: Thomas Gleixner CommitDate: Wed, 28 Nov 2018 11:57:06 +0100 sched/smt

Re: [PATCH v7 2/2] sched/fair: update scale invariance of PELT

2018-11-28 Thread Peter Zijlstra
On Wed, Nov 28, 2018 at 10:54:13AM +0100, Vincent Guittot wrote: > Is there anything else that I should do for these patches ? IIRC, Morten mention they break util_est; Patrick was going to explain. But yes, I like them.

Re: [PATCH 0/2] arm64: Only call into preempt_schedule() if need_resched()

2018-11-28 Thread Peter Zijlstra
On Wed, Nov 28, 2018 at 09:56:40AM +0100, Peter Zijlstra wrote: > On Tue, Nov 27, 2018 at 07:45:00PM +, Will Deacon wrote: > > Hi all, > > > > This pair of patches improves our preempt_enable() implementation slightly > > on arm64 by making the resulting call to pre

Re: [PATCH 0/2] arm64: Only call into preempt_schedule() if need_resched()

2018-11-28 Thread Peter Zijlstra
On Tue, Nov 27, 2018 at 07:45:00PM +, Will Deacon wrote: > Hi all, > > This pair of patches improves our preempt_enable() implementation slightly > on arm64 by making the resulting call to preempt_schedule() conditional > on need_resched(), which is tracked in bit 32 of the preempt count. The

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-27 Thread Peter Zijlstra
On Tue, Nov 27, 2018 at 09:43:30AM +0100, Peter Zijlstra wrote: > Now; if I'm not mistaken, the below @site is in fact @regs->ip - 1, no? > > We already patched site with INT3, which is what we just trapped on. So > we could in fact write something like: > > static void s

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-27 Thread Peter Zijlstra
On Mon, Nov 26, 2018 at 02:14:49PM -0600, Josh Poimboeuf wrote: > On Mon, Nov 26, 2018 at 10:28:08AM -0800, Andy Lutomirski wrote: > > Can you add a comment that it will need updating when kernel CET is added? > > Will do, though I get the feeling there's a lot of other (existing) code > that

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-27 Thread Peter Zijlstra
On Mon, Nov 26, 2018 at 03:26:28PM -0600, Josh Poimboeuf wrote: > Yeah, that's probably better. I assume you also mean that we would have > all text_poke_bp() users create a handler callback? That way the > interface is clear and consistent for everybody. Like: Can do, it does indeed make the

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-26 Thread Peter Zijlstra
On Mon, Nov 26, 2018 at 11:56:24AM -0600, Josh Poimboeuf wrote: > diff --git a/arch/x86/kernel/static_call.c b/arch/x86/kernel/static_call.c > index d3869295b88d..8fd6c8556750 100644 > --- a/arch/x86/kernel/static_call.c > +++ b/arch/x86/kernel/static_call.c > @@ -7,24 +7,19 @@ > > #define

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-26 Thread Peter Zijlstra
On Mon, Nov 26, 2018 at 11:56:24AM -0600, Josh Poimboeuf wrote: > Peter suggested updating the text_poke_bp() interface to add a handler > which is called from int3 context. This seems to work. > @@ -760,8 +761,10 @@ int poke_int3_handler(struct pt_regs *regs) > if (user_mode(regs) ||

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-26 Thread Peter Zijlstra
On Mon, Nov 26, 2018 at 05:11:05PM +0100, Ard Biesheuvel wrote: > On Mon, 26 Nov 2018 at 17:08, Peter Zijlstra wrote: > > > > On Mon, Nov 26, 2018 at 07:55:00AM -0600, Josh Poimboeuf wrote: > > > +#ifdef CONFIG_HAVE_STATIC_CALL_INLINE > > > +void arch_static_c

Re: [PATCH 19/25] sched/vite: Handle nice updates under vtime

2018-11-26 Thread Peter Zijlstra
On Mon, Nov 26, 2018 at 04:53:54PM +0100, Frederic Weisbecker wrote: > > > + irq_work_queue_on(_cpu(vtime_set_nice_work, cpu), cpu); > > > > What happens if you already had one pending? Do we loose updates? > > No, if irq_work is already pending, it doesn't requeue iff the work hasn't > been

  1   2   3   4   5   6   7   8   9   10   >