On Fri, Jun 13, 2025 at 10:26:37AM +0200, Alexis Lothoré wrote:
> Hi Peter,
>
> On Fri Jun 13, 2025 at 10:11 AM CEST, Peter Zijlstra wrote:
> > On Fri, Jun 13, 2025 at 09:37:11AM +0200, Alexis Lothoré (eBPF Foundation)
> > wrote:
> >> When the target functio
On Fri, Jun 13, 2025 at 09:37:11AM +0200, Alexis Lothoré (eBPF Foundation)
wrote:
> When the target function receives more arguments than available
> registers, the additional arguments are passed on stack, and so the
> generated trampoline needs to read those to prepare the bpf context,
> but als
On Tue, Apr 01, 2025 at 10:53:46AM -0700, Guenter Roeck wrote:
> > > #define _BUG_FLAGS(ins, flags, extra)
> > > \
> > > do {
> > > \
> > > asm_inline volatile("1:\t" ins "\n"
On Tue, Apr 01, 2025 at 10:53:46AM -0700, Guenter Roeck wrote:
> > > @@ -92,7 +102,8 @@ do {
> > > \
> > > do {\
> > > __auto_type __flags = BUGFLAG_WARNING|(flags);
On Thu, Mar 13, 2025 at 11:43:21AM +, Alessandro Carminati wrote:
> From: Guenter Roeck
>
> Add name of functions triggering warning backtraces to the __bug_table
> object section to enable support for suppressing WARNING backtraces.
>
> To limit image size impact, the pointer to the functio
On Fri, Mar 14, 2025 at 11:15:41AM +0530, Shrikanth Hegde wrote:
> use guard(mutex) for scope based resource management of mutex.
> This would make the code simpler and easier to maintain.
>
> More details on lock guards can be found at
> https://lore.kernel.org/all/20230612093537.614161...@infrad
On Fri, Mar 14, 2025 at 11:15:42AM +0530, Shrikanth Hegde wrote:
> use guard(mutex) for scope based resource management of mutex.
> This would make the code simpler and easier to maintain.
>
> More details on lock guards can be found at
> https://lore.kernel.org/all/20230612093537.614161...@infrad
On Fri, Feb 21, 2025 at 02:20:41PM +0530, Sathvika Vasireddy wrote:
> > > @@ -1625,6 +1626,11 @@ static int add_call_destinations(struct
> > > objtool_file *file)
> > > reloc = insn_reloc(file, insn);
> > > if (!reloc) {
> > > dest_off
On Fri, Feb 21, 2025 at 02:20:41PM +0530, Sathvika Vasireddy wrote:
> Also, just out of curiosity, how does x86 do it? Does it not use a branch to
> next instruction approach?
x86_64 can use LEA like:
#define _THIS_IP_ ({ unsigned long __here; asm ("lea 0(%%rip), %0" : "=r"
(__here)); __here;
On Wed, Jan 15, 2025 at 11:42:40PM +0100, Christophe Leroy wrote:
> Christophe Leroy (15):
> objtool: Fix generic annotation infrastructure cross build
> objtool: Move back misplaced comment
> objtool: Allow an architecture to disable objtool on ASM files
> objtool: Fix JUMP_ENTRY_SIZE for
On Wed, Jan 15, 2025 at 11:42:52PM +0100, Christophe Leroy wrote:
> diff --git a/tools/objtool/check.c b/tools/objtool/check.c
> index 91436f4b3622..54625f09d831 100644
> --- a/tools/objtool/check.c
> +++ b/tools/objtool/check.c
> @@ -2422,6 +2422,14 @@ static int __annotate_late(struct objtool_fi
On Sat, Dec 28, 2024 at 11:26:22AM +0200, Mike Rapoport wrote:
> On Mon, Dec 23, 2024 at 05:41:01PM +0800, Qi Zheng wrote:
> > Here we are explicitly dealing with struct page, and the following logic
> > semms strange:
> >
> > tlb_remove_page_ptdesc((tlb), (page_ptdesc(pte)));
> >
> > tlb_remove_
On Mon, Nov 18, 2024 at 10:04:18AM +0100, Michal Hocko wrote:
> I do not see this patch staged in any tree (e.g. linux-next). Is this on
> its way to be merged?
I only now found it -- it doesn't look super urgent. I'll get it into a
git tree after -rc1.
On Fri, Nov 08, 2024 at 08:20:44PM +0100, Peter Zijlstra wrote:
> Isn't the below more or less what you want?
>
> static unsigned long misc_flags(struct pt_regs *regs)
> {
> unsigned long flags = 0;
>
> if (regs->flags & PERF_EF
On Fri, Nov 08, 2024 at 07:01:16PM +, Colton Lewis wrote:
> Peter Zijlstra writes:
>
> > On Thu, Nov 07, 2024 at 07:03:35PM +, Colton Lewis wrote:
> > > Break the assignment logic for misc flags into their own respective
> > > functions to reduce the
On Thu, Nov 07, 2024 at 07:03:35PM +, Colton Lewis wrote:
> Break the assignment logic for misc flags into their own respective
> functions to reduce the complexity of the nested logic.
>
> Signed-off-by: Colton Lewis
> Reviewed-by: Oliver Upton
> ---
> arch/x86/events/core.c| 3
On Wed, Oct 16, 2024 at 05:01:28PM -0400, Steven Rostedt wrote:
> On Wed, 16 Oct 2024 15:24:22 +0300
> Mike Rapoport wrote:
>
> > diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c
> > index 8da0e66ca22d..b498897b213c 100644
> > --- a/arch/x86/kernel/ftrace.c
> > +++ b/arch/x86/kern
On Mon, Sep 16, 2024 at 12:00:52PM +0530, Venkat Rao Bagalkote wrote:
> I am seeing below kernel crash from 6.11.0-rc4-next-20240820.
0820 is almost a month old by now, did you verify if the same happens on
a recent kernel? We did fix a bunch of issues around this.
bf910ba5a9f6cc6bf7
That commit is now gone and should be replaced with the below on the
next next.
---
commit 1d7f856c2ca449f04a22d876e36b464b7a9d28b6
Author: Peter Zijlstra
Date: Mon Sep 9 12:50:09 2024 +0200
jump_label: Fix static_key_slow_dec() yet again
While commit 83ab38
On Mon, Sep 09, 2024 at 09:47:28AM +0300, Mike Rapoport wrote:
> diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c
> index 8da0e66ca22d..563d9a890ce2 100644
> --- a/arch/x86/kernel/ftrace.c
> +++ b/arch/x86/kernel/ftrace.c
> @@ -654,4 +656,15 @@ void ftrace_graph_func(unsigned long
On Sat, Jun 15, 2024 at 03:28:14AM +0200, Peter Zijlstra wrote:
> On Fri, Jun 14, 2024 at 12:48:37PM +0200, Vincent Guittot wrote:
> > The main problem is that need_resched becomes somewhat meaningless
> > because it doesn't only mean "I need to resched a task" and
On Fri, Jun 14, 2024 at 12:48:37PM +0200, Vincent Guittot wrote:
> The main problem is that need_resched becomes somewhat meaningless
> because it doesn't only mean "I need to resched a task" and we have
> to add more tests around even for those not using polling
The converse problem is that you
On Fri, Jun 14, 2024 at 12:48:37PM +0200, Vincent Guittot wrote:
> On Fri, 14 Jun 2024 at 11:28, Peter Zijlstra wrote:
> > > Vincent [5] pointed out a case where the idle load kick will fail to
> > > run on an idle CPU since the IPI handler launching the ILB will check
&
On Thu, Jun 13, 2024 at 06:15:59PM +, K Prateek Nayak wrote:
> Effects of call_function_single_prep_ipi()
> ==
>
> To pull a TIF_POLLING thread out of idle to process an IPI, the sender
> sets the TIF_NEED_RESCHED bit in the idle task's thread info in
>
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. Mos
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 is allocated
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)
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 __init_or_m
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,
> +
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,
> +
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 an
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 ?
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
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 g
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 , masks
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
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 the
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)"
> https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=363368&
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/ker
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 classifie
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
>
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
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.
>
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 objtool_
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 is
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
>
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
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
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
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.
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
> > ge
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 __dead_end_functi
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 {
> + mutex_lo
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 auto-init
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 -- effectiv
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 the
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 changed
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
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 per-c
on to 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 Zijlstr
er than that,
Acked-by: Peter Zijlstra (Intel)
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
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
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
> >
>
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:
> > >
> > >
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 reall
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),
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
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 v
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
> > > complete
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();
> tlb_remove_table_
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 thought
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 s
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(&ct->state);
> > > + /* will return true only for cpus in ke
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
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 walk
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 deliver
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
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
> >
> > Arguably
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 ou
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
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 string (on
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(&csd->node.u_flags, 0);
> }
>
> +static __always_inline void
> +raw_smp_call_single_queue(int cpu, struc
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
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
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
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
> io_
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
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 {
>
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
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
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
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 inc/de
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
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
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
rom NMI context 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,
()
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
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
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 rcuid
1 - 100 of 1025 matches
Mail list logo
