Re: [PATCH V2 04/19] math64: Tidy mul_u64_u32_shr()

2024-04-24 Thread Peter Zijlstra
On Mon, Mar 25, 2024 at 08:40:08AM +0200, Adrian Hunter wrote: > Put together declaration and initialization of local variables. > > Suggested-by: Thomas Gleixner > Signed-off-by: Adrian Hunter > --- Nothing wrong with this patch, but it is highly unlikely this code is actually tested much.

Re: [RFC PATCH 6/7] execmem: add support for cache of large ROX pages

2024-04-16 Thread Peter Zijlstra
On Mon, Apr 15, 2024 at 08:00:26PM +0300, Mike Rapoport wrote: > On Mon, Apr 15, 2024 at 12:47:50PM +0200, Peter Zijlstra wrote: > > On Thu, Apr 11, 2024 at 07:05:25PM +0300, Mike Rapoport wrote: > > > > > To populate the cache, a writable large page i

Re: [RFC PATCH 6/7] execmem: add support for cache of large ROX pages

2024-04-15 Thread Peter Zijlstra
On Thu, Apr 11, 2024 at 07:05:25PM +0300, Mike Rapoport wrote: > To populate the cache, a writable large page is allocated from vmalloc with > VM_ALLOW_HUGE_VMAP, filled with invalid instructions and then remapped as > ROX. > +static void execmem_invalidate(void *ptr, size_t size, bool writable)

Re: [RFC PATCH 5/7] x86/module: perpare module loading for ROX allocations of text

2024-04-15 Thread Peter Zijlstra
On Thu, Apr 11, 2024 at 07:05:24PM +0300, Mike Rapoport wrote: > diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c > index 45a280f2161c..b4d6868df573 100644 > --- a/arch/x86/kernel/alternative.c > +++ b/arch/x86/kernel/alternative.c > @@ -504,17 +513,17 @@ void

Re: [PATCH v4 07/15] mm/execmem, arch: convert remaining overrides of module_alloc to execmem

2024-04-15 Thread Peter Zijlstra
On Thu, Apr 11, 2024 at 07:00:43PM +0300, Mike Rapoport wrote: > +static struct execmem_info execmem_info __ro_after_init = { > + .ranges = { > + [EXECMEM_DEFAULT] = { > + .flags = EXECMEM_KASAN_SHADOW, > + .alignment = MODULE_ALIGN, > +

Re: [PATCH v4 06/15] mm/execmem, arch: convert simple overrides of module_alloc to execmem

2024-04-15 Thread Peter Zijlstra
On Thu, Apr 11, 2024 at 07:00:42PM +0300, Mike Rapoport wrote: > +static struct execmem_info execmem_info __ro_after_init = { > + .ranges = { > + [EXECMEM_DEFAULT] = { > + .start = MODULES_VADDR, > + .end = MODULES_END, > +

Re: [PATCH v4 05/15] mm: introduce execmem_alloc() and execmem_free()

2024-04-15 Thread Peter Zijlstra
On Thu, Apr 11, 2024 at 07:00:41PM +0300, Mike Rapoport wrote: > +/** > + * enum execmem_type - types of executable memory ranges > + * > + * There are several subsystems that allocate executable memory. > + * Architectures define different restrictions on placement, > + * permissions, alignment

Re: [PATCH v2 5/6] powerpc/smp: Add read_mostly attribute

2023-10-19 Thread Peter Zijlstra
On Wed, Oct 18, 2023 at 10:07:45PM +0530, Srikar Dronamraju wrote: > There are some variables that are only updated at boot time. > So add read_mostly attribute to such variables You don't have __ro_after_init ?

Re: [PATCH v2 4/6] powerpc/smp: Disable MC domain for shared processor

2023-10-19 Thread Peter Zijlstra
On Thu, Oct 19, 2023 at 03:48:48PM +1100, Michael Ellerman wrote: > Srikar Dronamraju writes: > > Like L2-cache info, coregroup information which is used to determine MC > > sched domains is only present on dedicated LPARs. i.e PowerVM doesn't > > export coregroup information for shared processor

Re: [PATCH v2 2/6] powerpc/smp: Enable Asym packing for cores on shared processor

2023-10-19 Thread Peter Zijlstra
On Thu, Oct 19, 2023 at 03:38:40PM +1100, Michael Ellerman wrote: > Srikar Dronamraju writes: > > If there are shared processor LPARs, underlying Hypervisor can have more > > virtual cores to handle than actual physical cores. > > > > Starting with Power 9, a core has 2 nearly independent thread

Re: [PATCH] powerpc/smp: Dynamically build powerpc topology

2023-09-04 Thread Peter Zijlstra
On Wed, Aug 30, 2023 at 05:56:14PM +0530, Srikar Dronamraju wrote: > Currently there are four powerpc specific sched topologies. These are > all statically defined. However not all these topologies are used by > all powerpc systems. > > To avoid unnecessary degenerations by the scheduler ,

Re: [RFC][PATCH] sched: Rename DIE domain

2023-07-17 Thread Peter Zijlstra
On Mon, Jul 17, 2023 at 03:51:25PM +0200, Vincent Guittot wrote: > On Wed, 12 Jul 2023 at 16:11, Peter Zijlstra wrote: > > > > Hi > > > > Thomas just tripped over the x86 topology setup creating a 'DIE' domain > > for the package mask :-) > > May be a link

Re: [RFC][PATCH] sched: Rename DIE domain

2023-07-12 Thread Peter Zijlstra
On Wed, Jul 12, 2023 at 04:02:38PM +0100, Valentin Schneider wrote: > On 12/07/23 16:10, Peter Zijlstra wrote: > > Hi > > > > Thomas just tripped over the x86 topology setup creating a 'DIE' domain > > for the package mask :-) > > > > Since these names a

Re: [PATCH v4 00/15] powerpc/objtool: uaccess validation for PPC32 (v4)

2023-07-12 Thread Peter Zijlstra
On Tue, Jul 11, 2023 at 06:08:26PM +0200, Christophe Leroy wrote: > This series adds UACCESS validation for PPC32. It includes > a dozen of changes to objtool core. > > It applies on top of series "Cleanup/Optimise KUAP (v3)" >

[RFC][PATCH] sched: Rename DIE domain

2023-07-12 Thread Peter Zijlstra
Hi Thomas just tripped over the x86 topology setup creating a 'DIE' domain for the package mask :-) Since these names are SCHED_DEBUG only, rename them. I don't think anybody *should* be relying on this, but who knows. Signed-off-by: Peter Zijlstra (Intel) --- arch/powerpc/kernel/smp.c | 2

Re: [RFC 1/1] sched/fair: Consider asymmetric scheduler groups in load balancer

2023-07-04 Thread Peter Zijlstra
On Mon, May 15, 2023 at 01:46:01PM +0200, Tobias Huschle wrote: > The current load balancer implementation implies that scheduler groups, > within the same domain, all host the same number of CPUs. This is > reflected in the condition, that a scheduler group, which is load > balancing and

Re: [PATCH v2 0/2] send tlb_remove_table_smp_sync IPI only to necessary CPUs

2023-07-03 Thread Peter Zijlstra
On Thu, Jun 22, 2023 at 09:47:22AM -0300, Marcelo Tosatti wrote: > > there's patches that cure the thp abuse of this. > > The other case where the IPI can happen is: > > CPU-0 CPU-1 > > tlb_remove_table > tlb_remove_table_sync_one > IPI >

Re: [PATCH v2 2/2] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to MM CPUs

2023-07-03 Thread Peter Zijlstra
On Tue, Jun 20, 2023 at 05:46:18PM +0300, Yair Podemsky wrote: > @@ -191,7 +191,13 @@ static void tlb_remove_table_smp_sync(void *arg) > /* Simply deliver the interrupt */ > } > > -void tlb_remove_table_sync_one(void) > +#ifdef CONFIG_ARCH_HAS_CPUMASK_BITS > +#define REMOVE_TABLE_IPI_MASK

Re: objtool: Seeking help for improving switch table processing

2023-06-27 Thread Peter Zijlstra
On Sat, Jun 24, 2023 at 10:06:23AM +, Christophe Leroy wrote: > Hello Josh and Peter, > > As mentionned in the cover letter of my series "powerpc/objtool: uaccess > validation for PPC32 (v3)" [1], a few switch table lookup fail, and it > would help if you had ideas on how to handle them. >

Re: [PATCH v2 14/14] powerpc: Implement UACCESS validation on PPC32

2023-06-22 Thread Peter Zijlstra
On Thu, Jun 22, 2023 at 12:54:36PM +0200, Christophe Leroy wrote: > diff --git a/tools/objtool/check.c b/tools/objtool/check.c > index f850ab892ad5..8ac5711a055f 100644 > --- a/tools/objtool/check.c > +++ b/tools/objtool/check.c > @@ -218,6 +218,7 @@ static bool __dead_end_function(struct

Re: [PATCH v2 12/14] objtool: Add support for more complex UACCESS control

2023-06-22 Thread Peter Zijlstra
On Thu, Jun 22, 2023 at 12:54:34PM +0200, Christophe Leroy wrote: > On x86, UACCESS is controlled by two instructions: STAC and CLAC. > STAC instruction enables UACCESS while CLAC disables UACCESS. > This is simple enough for objtool to locate UACCESS enable and > disable. > > But on powerpc it

Re: [PATCH v2 11/14] objtool: Remove too strict constraint in jump table search

2023-06-22 Thread Peter Zijlstra
On Thu, Jun 22, 2023 at 12:54:33PM +0200, Christophe Leroy wrote: > In code there is often a pattern like: > > load jump table address > do some test > conditional jump to label1: > do something > unconditional jump to label2: > label1: > do something else >

Re: [PATCH v2 10/14] objtool: Add support for relative switch tables

2023-06-22 Thread Peter Zijlstra
On Thu, Jun 22, 2023 at 12:54:32PM +0200, Christophe Leroy wrote: > On powerpc, switch tables are relative, than means the address of the > table is added to the value of the entry in order to get the pointed > address: (r10 is the table address, r4 the index in the table) > > lis r10,0

Re: [PATCH v2 09/14] objtool: Add INSN_RETURN_CONDITIONAL

2023-06-22 Thread Peter Zijlstra
rn is dead. > > To overcome this situation, introduce INSN_RETURN_CONDITIONAL which > is taken as a confirmation that a function is not noreturn but still > sees following code as reachable. > > Signed-off-by: Christophe Leroy Acked-by: Peter Zijlstra (Intel) > --- > tools/objto

Re: [PATCH v2 08/14] objtool: Fix JUMP_ENTRY_SIZE for bi-arch like powerpc

2023-06-22 Thread Peter Zijlstra
ing a 32 bits or 64 bits kernel. > > Therefore JUMP_ENTRY_SIZE must depend on elf_class_addrsize(elf). > > To allow that, entries[] table must be initialised at runtime. This is > easily done by moving it into its only user which is special_get_alts(). > > Signed-off-by: Chris

Re: [PATCH v2 0/2] send tlb_remove_table_smp_sync IPI only to necessary CPUs

2023-06-21 Thread Peter Zijlstra
text_tracking in the kernel space, this was removed due to race > condition concerns. > - for archs that do not maintain mm_cpumask the mask used should be > cpu_online_mask (Peter Zijlstra). > Would it not be much better to fix the root cause? As per the last time, there's patches that cure the thp abuse of this.

Re: [RFC PATCH v1 1/3] Revert "powerpc/bug: Provide better flexibility to WARN_ON/__WARN_FLAGS() with asm goto"

2023-06-20 Thread Peter Zijlstra
On Tue, Jun 20, 2023 at 10:51:25AM +0530, Naveen N Rao wrote: > Christophe Leroy wrote: > > This reverts commit 1e688dd2a3d6759d416616ff07afc4bb836c4213. > > > > That commit aimed at optimising the code around generation of > > WARN_ON/BUG_ON but this leads to a lot of dead code erroneously > >

Re: [RFC PATCH v1 3/3] powerpc: WIP draft support to objtool check

2023-06-16 Thread Peter Zijlstra
Few comments.. On Fri, Jun 16, 2023 at 03:47:52PM +0200, Christophe Leroy wrote: > diff --git a/tools/objtool/check.c b/tools/objtool/check.c > index 0fcf99c91400..f945fe271706 100644 > --- a/tools/objtool/check.c > +++ b/tools/objtool/check.c > @@ -236,6 +236,7 @@ static bool

Re: [PATCH 12/13] x86/jitalloc: prepare to allocate exectuatble memory as ROX

2023-06-01 Thread Peter Zijlstra
On Thu, Jun 01, 2023 at 01:12:56PM +0300, Mike Rapoport wrote: > +static void __init_or_module do_text_poke(void *addr, const void *opcode, > size_t len) > +{ > + if (system_state < SYSTEM_RUNNING) { > + text_poke_early(addr, opcode, len); > + } else { > +

Re: linux-next: boot failure after merge of the tip tree

2023-05-24 Thread Peter Zijlstra
On Wed, May 24, 2023 at 03:44:59PM +1000, Stephen Rothwell wrote: > Hi all, > > After merging the tip tree, today's linux-next build (powerpc > pseries_le_defconfig) failed to boot like this: > > Built 1 zonelists, mobility grouping on. Total pages: 32736 > Policy zone: Normal > mem

Re: [PATCH 00/23] arch: allow pte_offset_map[_lock]() to fail

2023-05-16 Thread Peter Zijlstra
On Thu, May 11, 2023 at 03:02:55PM +0100, Matthew Wilcox wrote: > We also talked about moving x86 to always RCU-free page tables in > order to make accessing /proc/$pid/smaps lockless. I believe Michel > is going to take a swing at this project. Shouldn't be too controversial I think --

Re: [PATCH 21/23] x86: Allow get_locked_pte() to fail

2023-05-11 Thread Peter Zijlstra
On Wed, May 10, 2023 at 08:16:34PM -0700, Hugh Dickins wrote: > Thanks for looking so quickly, Peter: I didn't Cc you on this particular > series, but shall certainly be doing so on the ones that follow, because > a few of those patches go into interesting pmdp_get_lockless() territory. I'm in

Re: [PATCH 21/23] x86: Allow get_locked_pte() to fail

2023-05-10 Thread Peter Zijlstra
On Tue, May 09, 2023 at 10:08:37PM -0700, Hugh Dickins wrote: > In rare transient cases, not yet made possible, pte_offset_map() and > pte_offset_map_lock() may not find a page table: handle appropriately. > > Signed-off-by: Hugh Dickins > --- > arch/x86/kernel/ldt.c | 6 -- > 1 file

Re: BUG : PowerPC RCU: torture test failed with __stack_chk_fail

2023-04-26 Thread Peter Zijlstra
On Wed, Apr 26, 2023 at 09:44:22AM -0400, Joel Fernandes wrote: > How could you control which code paths don't have the stack protector? > Just curious. https://lkml.kernel.org/r/20230412-no_stackp-v2-0-116f9fe4b...@google.com

Re: BUG : PowerPC RCU: torture test failed with __stack_chk_fail

2023-04-25 Thread Peter Zijlstra
On Tue, Apr 25, 2023 at 06:59:29AM -0400, Joel Fernandes wrote: > > I'm a little confused; the way I understand the whole stack protector > > thing to work is that we push a canary on the stack at call and on > > return check it is still valid. Since in general tasks randomly migrate, > > the

Re: BUG : PowerPC RCU: torture test failed with __stack_chk_fail

2023-04-25 Thread Peter Zijlstra
a new CPU. > > Did I get that right? > > IMO, even without a reproducer, gcc on PPC should just not do that, > that feels terribly broken for the kernel. I wonder what clang does, > I'll go poke around with compilerexplorer after lunch. > > Adding +Peter Zijlstra

Re: [PATCH 0/2] start_kernel: omit stack canary

2023-04-13 Thread Peter Zijlstra
Other than that, Acked-by: Peter Zijlstra (Intel)

Re: [PATCH v2 3/5] locking/arch: Wire up local_try_cmpxchg

2023-04-12 Thread Peter Zijlstra
On Wed, Apr 12, 2023 at 03:37:50PM +0200, Uros Bizjak wrote: > On Wed, Apr 12, 2023 at 1:33 PM Peter Zijlstra wrote: > > > > On Wed, Apr 05, 2023 at 04:17:08PM +0200, Uros Bizjak wrote: > > > diff --git a/arch/powerpc/include/asm/local.h > > > b/arch/powerp

Re: [PATCH v2 3/5] locking/arch: Wire up local_try_cmpxchg

2023-04-12 Thread Peter Zijlstra
On Wed, Apr 05, 2023 at 04:17:08PM +0200, Uros Bizjak wrote: > diff --git a/arch/powerpc/include/asm/local.h > b/arch/powerpc/include/asm/local.h > index bc4bd19b7fc2..45492fb5bf22 100644 > --- a/arch/powerpc/include/asm/local.h > +++ b/arch/powerpc/include/asm/local.h > @@ -90,6 +90,17 @@ static

Re: [PATCH 3/3] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to CPUs in kernel mode

2023-04-06 Thread Peter Zijlstra
On Thu, Apr 06, 2023 at 05:51:52PM +0200, David Hildenbrand wrote: > On 06.04.23 17:02, Peter Zijlstra wrote: > > DavidH, what do you thikn about reviving Jann's patches here: > > > >https://bugs.chromium.org/p/project-zero/issues/detail?id=2365#c1 > > >

Re: [PATCH 3/3] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to CPUs in kernel mode

2023-04-06 Thread Peter Zijlstra
On Thu, Apr 06, 2023 at 04:42:02PM +0200, David Hildenbrand wrote: > On 06.04.23 16:04, Peter Zijlstra wrote: > > On Thu, Apr 06, 2023 at 03:29:28PM +0200, Peter Zijlstra wrote: > > > On Thu, Apr 06, 2023 at 09:38:50AM -0300, Marcelo Tosatti wrote: > > > > > >

Re: [PATCH 3/3] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to CPUs in kernel mode

2023-04-06 Thread Peter Zijlstra
On Thu, Apr 06, 2023 at 04:04:23PM +0200, Peter Zijlstra wrote: > On Thu, Apr 06, 2023 at 03:29:28PM +0200, Peter Zijlstra wrote: > > On Thu, Apr 06, 2023 at 09:38:50AM -0300, Marcelo Tosatti wrote: > > > > > > To actually hit this path you're doing something really dod

Re: [PATCH 3/3] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to CPUs in kernel mode

2023-04-06 Thread Peter Zijlstra
On Thu, Apr 06, 2023 at 03:11:52PM +0100, Valentin Schneider wrote: > On 06/04/23 15:38, Peter Zijlstra wrote: > > On Wed, Apr 05, 2023 at 01:45:02PM +0100, Valentin Schneider wrote: > >> > >> I've been hacking on something like this (CSD deferral for NOHZ-full), >

Re: [PATCH 3/3] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to CPUs in kernel mode

2023-04-06 Thread Peter Zijlstra
On Thu, Apr 06, 2023 at 03:29:28PM +0200, Peter Zijlstra wrote: > On Thu, Apr 06, 2023 at 09:38:50AM -0300, Marcelo Tosatti wrote: > > > > To actually hit this path you're doing something really dodgy. > > > > Apparently khugepaged is using the same infr

Re: [PATCH 3/3] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to CPUs in kernel mode

2023-04-06 Thread Peter Zijlstra
On Wed, Apr 05, 2023 at 01:45:02PM +0100, Valentin Schneider wrote: > On 05/04/23 14:05, Frederic Weisbecker wrote: > > static void smp_call_function_many_cond(const struct cpumask *mask, > > smp_call_func_t func, void *info, > > @@ -946,10 +948,13 @@ static

Re: [PATCH 3/3] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to CPUs in kernel mode

2023-04-06 Thread Peter Zijlstra
On Thu, Apr 06, 2023 at 09:49:22AM -0300, Marcelo Tosatti wrote: > > > 2) Depends on the application and the definition of "occasional". > > > > > > For certain types of applications (for example PLC software or > > > RAN processing), upon occurrence of an event, it is necessary to > > >

Re: [PATCH 3/3] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to CPUs in kernel mode

2023-04-06 Thread Peter Zijlstra
On Thu, Apr 06, 2023 at 09:38:50AM -0300, Marcelo Tosatti wrote: > > To actually hit this path you're doing something really dodgy. > > Apparently khugepaged is using the same infrastructure: > > $ grep tlb_remove_table khugepaged.c > tlb_remove_table_sync_one(); >

Re: [PATCH 3/3] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to CPUs in kernel mode

2023-04-05 Thread Peter Zijlstra
On Wed, Apr 05, 2023 at 04:43:14PM -0300, Marcelo Tosatti wrote: > Two points: > > 1) For a virtualized system, the overhead is not only of executing the > IPI but: > > VM-exit > run VM-exit code in host > handle IPI > run VM-entry code in host > VM-entry I

Re: [PATCH 3/3] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to CPUs in kernel mode

2023-04-05 Thread Peter Zijlstra
On Wed, Apr 05, 2023 at 04:45:32PM -0300, Marcelo Tosatti wrote: > On Wed, Apr 05, 2023 at 01:10:07PM +0200, Frederic Weisbecker wrote: > > On Wed, Apr 05, 2023 at 12:44:04PM +0200, Frederic Weisbecker wrote: > > > On Tue, Apr 04, 2023 at 04:42:24PM +0300, Yair Podemsky wrote: > > > > + int

Re: [PATCH 3/3] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to CPUs in kernel mode

2023-04-05 Thread Peter Zijlstra
On Wed, Apr 05, 2023 at 01:10:07PM +0200, Frederic Weisbecker wrote: > On Wed, Apr 05, 2023 at 12:44:04PM +0200, Frederic Weisbecker wrote: > > On Tue, Apr 04, 2023 at 04:42:24PM +0300, Yair Podemsky wrote: > > > + int state = atomic_read(>state); > > > + /* will return true only for cpus in

Re: [PATCH 3/3] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to CPUs in kernel mode

2023-04-04 Thread Peter Zijlstra
On Tue, Apr 04, 2023 at 05:12:17PM +0200, Peter Zijlstra wrote: > > case 2: > > CPU-A CPU-B > > > > modify pagetables > > tlb_flush (memory barrier) > > state == CONT

Re: [PATCH 3/3] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to CPUs in kernel mode

2023-04-04 Thread Peter Zijlstra
On Tue, Apr 04, 2023 at 04:42:24PM +0300, Yair Podemsky wrote: > The tlb_remove_table_smp_sync IPI is used to ensure the outdated tlb page > is not currently being accessed and can be cleared. > This occurs once all CPUs have left the lockless gup code section. > If they reenter the page table

Re: [PATCH 2/3] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to MM CPUs

2023-04-04 Thread Peter Zijlstra
On Tue, Apr 04, 2023 at 04:42:23PM +0300, Yair Podemsky wrote: > diff --git a/mm/mmu_gather.c b/mm/mmu_gather.c > index 2b93cf6ac9ae..5ea9be6fb87c 100644 > --- a/mm/mmu_gather.c > +++ b/mm/mmu_gather.c > @@ -191,7 +191,13 @@ static void tlb_remove_table_smp_sync(void *arg) > /* Simply

Re: [PATCH v5 7/7] sched, smp: Trace smp callback causing an IPI

2023-03-23 Thread Peter Zijlstra
On Thu, Mar 23, 2023 at 04:25:25PM +, Valentin Schneider wrote: > On 22/03/23 15:04, Peter Zijlstra wrote: > > @@ -798,14 +794,20 @@ static void smp_call_function_many_cond( > > } > > > > /* > > +* Trace each smp_functio

Re: [PATCH v5 7/7] sched, smp: Trace smp callback causing an IPI

2023-03-22 Thread Peter Zijlstra
On Wed, Mar 22, 2023 at 06:22:28PM +, Valentin Schneider wrote: > On 22/03/23 18:22, Peter Zijlstra wrote: > >>hackbench-157 [001]10.894320: ipi_send_cpu: cpu=3 > >> callsite=check_preempt_curr+0x37 callback=0x0 > > > > Argua

Re: [PATCH v5 7/7] sched, smp: Trace smp callback causing an IPI

2023-03-22 Thread Peter Zijlstra
On Wed, Mar 22, 2023 at 05:01:13PM +, Valentin Schneider wrote: > > So I was thinking something like this: > Hm, this does get rid of the func being passed down the helpers, but this > means the trace events are now stateful, i.e. I need the first and last > events in a CSD stack to figure

Re: [PATCH v5 7/7] sched, smp: Trace smp callback causing an IPI

2023-03-22 Thread Peter Zijlstra
On Wed, Mar 22, 2023 at 12:20:28PM +, Valentin Schneider wrote: > On 22/03/23 10:53, Peter Zijlstra wrote: > > Hurmph... so we only really consume @func when we IPI. Would it not be > > more useful to trace this thing for *every* csd enqeued? > > It's true that any CSD e

Re: [PATCH v5 1/7] trace: Add trace_ipi_send_cpumask()

2023-03-22 Thread Peter Zijlstra
On Wed, Mar 22, 2023 at 10:39:55AM +0100, Peter Zijlstra wrote: > On Tue, Mar 07, 2023 at 02:35:52PM +, Valentin Schneider wrote: > > trace_ipi_raise() is unsuitable for generically tracing IPI sources due to > > its "reason" argument being an uninformative str

Re: [PATCH v5 7/7] sched, smp: Trace smp callback causing an IPI

2023-03-22 Thread Peter Zijlstra
On Tue, Mar 07, 2023 at 02:35:58PM +, Valentin Schneider wrote: > @@ -477,6 +490,25 @@ static __always_inline void csd_unlock(struct > __call_single_data *csd) > smp_store_release(>node.u_flags, 0); > } > > +static __always_inline void > +raw_smp_call_single_queue(int cpu, struct

Re: [PATCH v5 1/7] trace: Add trace_ipi_send_cpumask()

2023-03-22 Thread Peter Zijlstra
On Tue, Mar 07, 2023 at 02:35:52PM +, Valentin Schneider wrote: > trace_ipi_raise() is unsuitable for generically tracing IPI sources due to > its "reason" argument being an uninformative string (on arm64 all you get > is "Function call interrupts" for SMP calls). > > Add a variant of it that

Re: [Intel-gfx] [PATCH v5 0/7] Introduce __xchg, non-atomic xchg

2023-02-27 Thread Peter Zijlstra
On Thu, Feb 23, 2023 at 10:24:19PM +0100, Andrzej Hajda wrote: > On 22.02.2023 18:04, Peter Zijlstra wrote: > > On Wed, Jan 18, 2023 at 04:35:22PM +0100, Andrzej Hajda wrote: > > > > > Andrzej Hajda (7): > > >arch: rename all internal names __xchg to __arch

Re: [PATCH v7 5/5] powerpc/64s: enable MMU_LAZY_TLB_SHOOTDOWN

2023-02-27 Thread Peter Zijlstra
On Sun, Feb 26, 2023 at 02:12:38PM -0800, Andrew Morton wrote: > On Fri, 3 Feb 2023 17:18:37 +1000 Nicholas Piggin wrote: > > > On a 16-socket 192-core POWER8 system, the context_switch1_threads > > benchmark from will-it-scale (see earlier changelog), upstream can > > achieve a rate of about 1

Re: [PATCH v5 0/7] Introduce __xchg, non-atomic xchg

2023-02-22 Thread Peter Zijlstra
On Wed, Jan 18, 2023 at 04:35:22PM +0100, Andrzej Hajda wrote: > Andrzej Hajda (7): > arch: rename all internal names __xchg to __arch_xchg > linux/include: add non-atomic version of xchg > arch/*/uprobes: simplify arch_uretprobe_hijack_return_addr > llist: simplify __llist_del_all >

Re: WARN include/linux/trace_recursion.h:162 (powerpc)

2023-02-02 Thread Peter Zijlstra
On Thu, Feb 02, 2023 at 01:46:32PM +0530, Sachin Sant wrote: > Following warning is seen with 6.2.0-rc6-next-20230201 on a > Power10 server. > > [ cut here ] > RCU not on for: check_return_regs_valid+0xc/0x1e0 > WARNING: CPU: 9 PID: 0 at include/linux/trace_recursion.h:162

Re: [PATCH v2 1/6] mm: introduce vma->vm_flags modifier functions

2023-01-25 Thread Peter Zijlstra
On Wed, Jan 25, 2023 at 12:38:46AM -0800, Suren Baghdasaryan wrote: > diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h > index 2d6d790d9bed..6c7c70bf50dd 100644 > --- a/include/linux/mm_types.h > +++ b/include/linux/mm_types.h > @@ -491,7 +491,13 @@ struct vm_area_struct { >

Re: [PATCH v3 16/51] cpuidle: Annotate poll_idle()

2023-01-20 Thread Peter Zijlstra
On Thu, Jan 12, 2023 at 08:43:30PM +0100, Peter Zijlstra wrote: > The __cpuidle functions will become a noinstr class, as such they need > explicit annotations. > > Signed-off-by: Peter Zijlstra (Intel) > Reviewed-by: Rafael J. Wysocki > Acked-by: Frederic Weisbecker > Tes

Re: [PATCH v3 00/51] cpuidle,rcu: Clean up the mess

2023-01-17 Thread Peter Zijlstra
On Mon, Jan 16, 2023 at 04:59:04PM +, Mark Rutland wrote: > I'm sorry to have to bear some bad news on that front. :( Moo, something had to give.. > IIUC what's happenign here is the PSCI cpuidle driver has entered idle and RCU > is no longer watching when arm64's cpu_suspend() manipulates

Re: [PATCH v3 35/51] trace,hardirq: No moar _rcuidle() tracing

2023-01-17 Thread Peter Zijlstra
On Tue, Jan 17, 2023 at 01:24:46PM +0900, Masami Hiramatsu wrote: > Hi Peter, > > On Thu, 12 Jan 2023 20:43:49 +0100 > Peter Zijlstra wrote: > > > Robot reported that trace_hardirqs_{on,off}() tickle the forbidden > > _rcuidle() tracepoint through local_irq_{en,dis

Re: lockref scalability on x86-64 vs cpu_relax

2023-01-13 Thread Peter Zijlstra
On Thu, Jan 12, 2023 at 06:13:16PM -0600, Linus Torvalds wrote: > On Thu, Jan 12, 2023 at 5:36 PM Mateusz Guzik wrote: > > > > To my understanding on said architecture failed cmpxchg still grants you > > exclusive access to the cacheline, making immediate retry preferable > > when trying to

[PATCH v3 37/51] cpuidle,omap3: Push RCU-idle into omap_sram_idle()

2023-01-12 Thread Peter Zijlstra
OMAP3 uses full SoC suspend modes as idle states, as such it needs the whole power-domain and clock-domain code from the idle path. All that code is not suitable to run with RCU disabled, as such push RCU-idle deeper still. Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Tony Lindgren Acked

[PATCH v3 40/51] cpuidle,powerdomain: Remove trace_.*_rcuidle()

2023-01-12 Thread Peter Zijlstra
OMAP was the one and only user. Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Ulf Hansson Acked-by: Rafael J. Wysocki Acked-by: Frederic Weisbecker Tested-by: Tony Lindgren Tested-by: Ulf Hansson --- arch/arm/mach-omap2/powerdomain.c | 10 +- drivers/base/power/runtime.c

[PATCH v3 12/51] cpuidle,dt: Push RCU-idle into driver

2023-01-12 Thread Peter Zijlstra
Doing RCU-idle outside the driver, only to then temporarily enable it again before going idle is daft. Notably: this converts all dt_init_idle_driver() and __CPU_PM_CPU_IDLE_ENTER() users for they are inextrably intertwined. Signed-off-by: Peter Zijlstra (Intel) Acked-by: Rafael J. Wysocki

[PATCH v3 35/51] trace,hardirq: No moar _rcuidle() tracing

2023-01-12 Thread Peter Zijlstra
again. Signed-off-by: Peter Zijlstra (Intel) --- kernel/trace/trace_preemptirq.c | 21 + 1 file changed, 13 insertions(+), 8 deletions(-) --- a/kernel/trace/trace_preemptirq.c +++ b/kernel/trace/trace_preemptirq.c @@ -20,6 +20,15 @@ static DEFINE_PER_CPU(int, tracing_irq_cpu

[PATCH v3 19/51] cpuidle,intel_idle: Fix CPUIDLE_FLAG_INIT_XSTATE

2023-01-12 Thread Peter Zijlstra
() leaves .noinstr.text section Signed-off-by: Peter Zijlstra (Intel) Acked-by: Rafael J. Wysocki Acked-by: Frederic Weisbecker Tested-by: Tony Lindgren Tested-by: Ulf Hansson --- arch/x86/include/asm/fpu/xcr.h |4 ++-- arch/x86/include/asm/special_insns.h |2 +- arch/x86/kernel/fpu

[PATCH v3 02/51] x86/idle: Replace x86_idle with a static_call

2023-01-12 Thread Peter Zijlstra
Typical boot time setup; no need to suffer an indirect call for that. Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Frederic Weisbecker Reviewed-by: Rafael J. Wysocki Tested-by: Tony Lindgren Tested-by: Ulf Hansson --- arch/x86/kernel/process.c | 50

[PATCH v3 00/51] cpuidle,rcu: Clean up the mess

2023-01-12 Thread Peter Zijlstra
Hi All! The (hopefully) final respin of cpuidle vs rcu cleanup patches. Barring any objections I'll be queueing these patches in tip/sched/core in the next few days. v2: https://lkml.kernel.org/r/20220919095939.761690...@infradead.org These here patches clean up the mess that is cpuidle vs

[PATCH v3 09/51] cpuidle,omap3: Push RCU-idle into driver

2023-01-12 Thread Peter Zijlstra
Doing RCU-idle outside the driver, only to then teporarily enable it again before going idle is daft. Notably the cpu_pm_*() calls implicitly re-enable RCU for a bit. Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Frederic Weisbecker Reviewed-by: Tony Lindgren Acked-by: Rafael J. Wysocki

[PATCH v3 16/51] cpuidle: Annotate poll_idle()

2023-01-12 Thread Peter Zijlstra
The __cpuidle functions will become a noinstr class, as such they need explicit annotations. Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Rafael J. Wysocki Acked-by: Frederic Weisbecker Tested-by: Tony Lindgren Tested-by: Ulf Hansson --- drivers/cpuidle/poll_state.c |6 +- 1

[PATCH v3 50/51] cpuidle: Comments about noinstr/__cpuidle

2023-01-12 Thread Peter Zijlstra
Add a few words on noinstr / __cpuidle usage. Signed-off-by: Peter Zijlstra (Intel) --- drivers/cpuidle/cpuidle.c | 12 include/linux/compiler_types.h | 10 ++ 2 files changed, 22 insertions(+) --- a/drivers/cpuidle/cpuidle.c +++ b/drivers/cpuidle/cpuidle.c

[PATCH v3 13/51] cpuidle: Fix ct_idle_*() usage

2023-01-12 Thread Peter Zijlstra
The whole disable-RCU, enable-IRQS dance is very intricate since changing IRQ state is traced, which depends on RCU. Add two helpers for the cpuidle case that mirror the entry code. Signed-off-by: Peter Zijlstra (Intel) Acked-by: Rafael J. Wysocki Acked-by: Frederic Weisbecker Tested-by: Tony

[PATCH v3 34/51] trace: WARN on rcuidle

2023-01-12 Thread Peter Zijlstra
ARCH_WANTS_NO_INSTR (a superset of CONFIG_GENERIC_ENTRY) disallows any and all tracing when RCU isn't enabled. Signed-off-by: Peter Zijlstra (Intel) Acked-by: Rafael J. Wysocki Acked-by: Frederic Weisbecker Tested-by: Tony Lindgren Tested-by: Ulf Hansson --- include/linux/tracepoint.h

[PATCH v3 29/51] cpuidle,tdx: Make tdx noinstr clean

2023-01-12 Thread Peter Zijlstra
.noinstr.text section Signed-off-by: Peter Zijlstra (Intel) Acked-by: Rafael J. Wysocki Acked-by: Frederic Weisbecker Tested-by: Tony Lindgren Tested-by: Ulf Hansson --- arch/x86/boot/compressed/vmlinux.lds.S |1 + arch/x86/coco/tdx/tdcall.S |2 ++ arch/x86/coco/tdx/tdx.c

[PATCH v3 20/51] cpuidle,intel_idle: Fix CPUIDLE_FLAG_IBRS

2023-01-12 Thread Peter Zijlstra
vmlinux.o: warning: objtool: intel_idle_ibrs+0x17: call to spec_ctrl_current() leaves .noinstr.text section vmlinux.o: warning: objtool: intel_idle_ibrs+0x27: call to wrmsrl.constprop.0() leaves .noinstr.text section Signed-off-by: Peter Zijlstra (Intel) Acked-by: Rafael J. Wysocki Acked

[PATCH v3 22/51] x86/tdx: Remove TDX_HCALL_ISSUE_STI

2023-01-12 Thread Peter Zijlstra
Now that arch_cpu_idle() is expected to return with IRQs disabled, avoid the useless STI/CLI dance. Per the specs this is supposed to work, but nobody has yet relied up this behaviour so broken implementations are possible. Signed-off-by: Peter Zijlstra (Intel) Acked-by: Rafael J. Wysocki

[PATCH v3 51/51] context_tracking: Fix noinstr vs KASAN

2023-01-12 Thread Peter Zijlstra
vmlinux.o: warning: objtool: __ct_user_enter+0x72: call to __kasan_check_write() leaves .noinstr.text section vmlinux.o: warning: objtool: __ct_user_exit+0x47: call to __kasan_check_write() leaves .noinstr.text section Signed-off-by: Peter Zijlstra (Intel) --- kernel/context_tracking.c | 12

[PATCH v3 39/51] arm,omap2: Use WFI for omap2_pm_idle()

2023-01-12 Thread Peter Zijlstra
a cpuidle driver; but adding one would be the recourse to (re)gain the other idle states. Suggested-by: Tony Lindgren Signed-off-by: Peter Zijlstra (Intel) Acked-by: Rafael J. Wysocki Acked-by: Frederic Weisbecker Tested-by: Tony Lindgren Tested-by: Ulf Hansson --- arch/arm/mach-omap2/pm24xx.c

[PATCH v3 44/51] entry,kasan,x86: Disallow overriding mem*() functions

2023-01-12 Thread Peter Zijlstra
to memcpy() leaves .noinstr.text section Remove the weak aliases to ensure nobody hijacks these functions and add them to the noinstr section. Signed-off-by: Peter Zijlstra (Intel) Acked-by: Rafael J. Wysocki Acked-by: Frederic Weisbecker Tested-by: Tony Lindgren Tested-by: Ulf Hansson --- arch

[PATCH v3 01/51] x86/perf/amd: Remove tracing from perf_lopwr_cb()

2023-01-12 Thread Peter Zijlstra
The perf_lopwr_cb() is called from the idle routines; there is no RCU there, we must not enter tracing. Signed-off-by: Peter Zijlstra (Intel) Acked-by: Rafael J. Wysocki Acked-by: Frederic Weisbecker Tested-by: Tony Lindgren Tested-by: Ulf Hansson --- arch/x86/events/amd/brs.c

[PATCH v3 41/51] cpuidle,clk: Remove trace_.*_rcuidle()

2023-01-12 Thread Peter Zijlstra
OMAP was the one and only user. Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Ulf Hansson Acked-by: Rafael J. Wysocki Acked-by: Frederic Weisbecker Tested-by: Tony Lindgren Tested-by: Ulf Hansson --- drivers/clk/clk.c |8 1 file changed, 4 insertions(+), 4 deletions

[PATCH v3 18/51] cpuidle,intel_idle: Fix CPUIDLE_FLAG_IRQ_ENABLE *again*

2023-01-12 Thread Peter Zijlstra
sitive RCU splats due to incorrect hardirqs state") Signed-off-by: Peter Zijlstra (Intel) Acked-by: Rafael J. Wysocki Acked-by: Frederic Weisbecker Tested-by: Tony Lindgren Tested-by: Ulf Hansson --- drivers/idle/intel_idle.c |8 +--- 1 file changed, 1 insertion(+), 7 deletions(-

[PATCH v3 26/51] time/tick-broadcast: Remove RCU_NONIDLE usage

2023-01-12 Thread Peter Zijlstra
No callers left that have already disabled RCU. Signed-off-by: Peter Zijlstra (Intel) Acked-by: Mark Rutland Acked-by: Rafael J. Wysocki Acked-by: Frederic Weisbecker Tested-by: Tony Lindgren Tested-by: Ulf Hansson --- kernel/time/tick-broadcast-hrtimer.c | 29

[PATCH v3 38/51] cpuidle,omap4: Push RCU-idle into omap4_enter_lowpower()

2023-01-12 Thread Peter Zijlstra
From: Tony Lindgren OMAP4 uses full SoC suspend modes as idle states, as such it needs the whole power-domain and clock-domain code from the idle path. All that code is not suitable to run with RCU disabled, as such push RCU-idle deeper still. Signed-off-by: Tony Lindgren Signed-off-by: Peter

[PATCH v3 48/51] cpuidle,arch: Mark all ct_cpuidle_enter() callers __cpuidle

2023-01-12 Thread Peter Zijlstra
For all cpuidle drivers that use CPUIDLE_FLAG_RCU_IDLE, ensure that all functions that call ct_cpuidle_enter() are marked __cpuidle. ( due to lack of noinstr validation on these platforms it is entirely possible this isn't complete ) Signed-off-by: Peter Zijlstra (Intel) --- arch/arm/mach

[PATCH v3 33/51] trace: Remove trace_hardirqs_{on,off}_caller()

2023-01-12 Thread Peter Zijlstra
Per commit 56e62a737028 ("s390: convert to generic entry") the last and only callers of trace_hardirqs_{on,off}_caller() went away, clean up. Cc: Sven Schnelle Signed-off-by: Peter Zijlstra (Intel) --- kernel/trace/trace_preemptirq.c | 29 - 1 file c

[PATCH v3 42/51] ubsan: Fix objtool UACCESS warns

2023-01-12 Thread Peter Zijlstra
/restore and whitelist the thing. Signed-off-by: Peter Zijlstra (Intel) Acked-by: Rafael J. Wysocki Acked-by: Frederic Weisbecker Tested-by: Tony Lindgren Tested-by: Ulf Hansson --- lib/ubsan.c |5 - tools/objtool/check.c |1 + 2 files changed, 5 insertions(+), 1 deletion

[PATCH v3 08/51] cpuidle,imx6: Push RCU-idle into driver

2023-01-12 Thread Peter Zijlstra
Doing RCU-idle outside the driver, only to then temporarily enable it again, at least twice, before going idle is daft. Notably both cpu_pm_enter() and cpu_cluster_pm_enter() implicity re-enable RCU. Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Frederic Weisbecker Acked-by: Rafael J

[PATCH v3 25/51] printk: Remove trace_.*_rcuidle() usage

2023-01-12 Thread Peter Zijlstra
The problem, per commit fc98c3c8c9dc ("printk: use rcuidle console tracepoint"), was printk usage from the cpuidle path where RCU was already disabled. Per the patches earlier in this series, this is no longer the case. Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Sergey S

[PATCH v3 47/51] cpuidle: Ensure ct_cpuidle_enter() is always called from noinstr/__cpuidle

2023-01-12 Thread Peter Zijlstra
Tracing (kprobes included) and other compiler instrumentation relies on a normal kernel runtime. Therefore all functions that disable RCU should be noinstr, as should all functions that are called while RCU is disabled. Signed-off-by: Peter Zijlstra (Intel) --- drivers/cpuidle/cpuidle.c | 37

[PATCH v3 43/51] intel_idle: Add force_irq_on module param

2023-01-12 Thread Peter Zijlstra
For testing purposes. Signed-off-by: Peter Zijlstra (Intel) Acked-by: Rafael J. Wysocki Acked-by: Frederic Weisbecker Tested-by: Tony Lindgren Tested-by: Ulf Hansson --- drivers/idle/intel_idle.c |7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) --- a/drivers/idle/intel_idle.c

[PATCH v3 49/51] cpuidle,arch: Mark all regular cpuidle_state::enter methods __cpuidle

2023-01-12 Thread Peter Zijlstra
For all cpuidle drivers that do not use CPUIDLE_FLAG_RCU_IDLE (iow, the simple ones) make sure all the functions are marked __cpuidle. ( due to lack of noinstr validation on these platforms it is entirely possible this isn't complete ) Signed-off-by: Peter Zijlstra (Intel) --- arch/arm

  1   2   3   4   5   6   7   8   9   10   >