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
/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
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
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
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
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
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)
---
arc
() 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/shared/io.h |4 ++--
drivers/acpi/processor_idle.c|2 +-
include/linux/cpumask.h
The PM notifiers should no longer be ran with RCU disabled (per the
previous patches), as such this hack is no longer required either.
Signed-off-by: Peter Zijlstra (Intel)
Acked-by: Rafael J. Wysocki
Acked-by: Frederic Weisbecker
Tested-by: Tony Lindgren
Tested-by: Ulf Hansson
---
drivers
nable-disable' dance.
Therefore, push this IRQ disabling into the idle function, meaning
that those architectures can avoid the pointless IRQ state flipping.
Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Gautham R. Shenoy
Acked-by: Mark Rutland [arm64]
Acked-by: Rafael J. Wysocki
Ack
vmlinux.o: warning: objtool: acpi_idle_enter_s2idle+0x45: call to
__this_cpu_preempt_check() 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
---
include/linux/percpu
complicated idle states for the cpuidle driver.
Signed-off-by: Peter Zijlstra (Intel)
Acked-by: Tony Lindgren
Acked-by: Rafael J. Wysocki
Acked-by: Frederic Weisbecker
Tested-by: Tony Lindgren
Tested-by: Ulf Hansson
---
arch/arm/mach-omap2/pm34xx.c |2 +-
1 file changed, 1 insertion(+), 1
Make cpuidle_enter_state() consistent with the s2idle variant and
verify ->enter() always returns with interrupts disabled.
Signed-off-by: Peter Zijlstra (Intel)
Acked-by: Rafael J. Wysocki
Acked-by: Frederic Weisbecker
Tested-by: Tony Lindgren
Tested-by: Ulf Hansson
---
drivers/cpui
cpuidle_state::enter() methods should be IRQ invariant.
Additionally make sure to use raw_local_irq_*() methods since this
cpuidle callback will be called with RCU already disabled.
Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Rafael J. Wysocki
Reviewed-by: Frederic Weisbecker
Tested-by
e for smp_cross_call() tracepoints"), that
cpuidle_enter_state_coupled() already had RCU disabled, but that's
long been fixed by commit 1098582a0f6c ("sched,idle,rcu: Push rcu_idle
deeper into the idle path").
Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Ulf Hansson
Ac
All the idle routines are called with RCU disabled, as such there must
not be any tracing inside.
While there; clean-up the io-port idle thing.
Signed-off-by: Peter Zijlstra (Intel)
Acked-by: Rafael J. Wysocki
Acked-by: Frederic Weisbecker
Tested-by: Tony Lindgren
Tested-by: Ulf Hansson
section
vmlinux.o: warning: objtool: intel_idle+0x78: call to
test_ti_thread_flag.constprop.0() leaves .noinstr.text section
vmlinux.o: warning: objtool: acpi_safe_halt+0xf: call to
test_ti_thread_flag.constprop.0() leaves .noinstr.text section
Signed-off-by: Peter Zijlstra (Intel)
Acked-by
On Wed, Nov 16, 2022 at 10:16:34AM -0800, Linus Torvalds wrote:
> Following the history of it is a big of a mess, because there's a
> number of renamings and re-organizations, but it seems to go back to
> 2007 and commit b6a2fea39318 ("mm: variable length argument support").
I went back and read p
On Fri, Nov 18, 2022 at 01:34:12PM +0100, Ahmed S. Darwish wrote:
> On Wed, Nov 16, 2022 at 10:23:22AM -0600, Bjorn Helgaas wrote:
> > On Fri, Nov 11, 2022 at 02:54:51PM +0100, Thomas Gleixner wrote:
> ...
> > > +
> > > +/**
> > > + * pci_alloc_irq_vectors_affinity() - Allocate multiple device inte
On Thu, Nov 17, 2022 at 02:45:29PM +, Valentin Schneider wrote:
> > + if (trace_ipi_send_cpumask_enabled()) {
> > + call_single_data_t *csd;
> > + smp_call_func_t func;
> > +
> > + csd = container_of(node, call_single_data_t, node.llist);
> > +
> > + f
On Wed, Nov 02, 2022 at 06:33:36PM +, Valentin Schneider wrote:
> The newly-introduced ipi_send_cpumask tracepoint has a "callback" parameter
> which so far has only been fed with NULL.
>
> While CSD_TYPE_SYNC/ASYNC and CSD_TYPE_IRQ_WORK share a similar backing
> struct layout (meaning their c
Sorry; things keep getting in the way of finishing this :/
As such, I need a bit of time to get on-track again..
On Tue, Oct 04, 2022 at 01:03:57PM +0200, Ulf Hansson wrote:
> > --- a/drivers/acpi/processor_idle.c
> > +++ b/drivers/acpi/processor_idle.c
> > @@ -1200,6 +1200,8 @@ static int acp
On Wed, Nov 02, 2022 at 06:33:34PM +, Valentin Schneider wrote:
> diff --git a/kernel/smp.c b/kernel/smp.c
> index c4d561cf50d45..44fa4b9b1f46b 100644
> --- a/kernel/smp.c
> +++ b/kernel/smp.c
> @@ -167,6 +167,14 @@ send_call_function_ipi_mask(const struct cpumask *mask)
> arch_send_call
On Wed, Nov 02, 2022 at 06:33:33PM +, Valentin Schneider wrote:
> IPIs sent to remove CPUs via irq_work_queue_on() are now covered by
> trace_ipi_send_cpumask(), add another instance of the tracepoint to cover
> self-IPIs.
>
> Signed-off-by: Valentin Schneider
> ---
> kernel/irq_work.c | 14
On Wed, Nov 02, 2022 at 06:33:32PM +, Valentin Schneider wrote:
> This simply wraps around the arch function and prepends it with a
> tracepoint, similar to send_call_function_single_ipi().
>
> Signed-off-by: Valentin Schneider
> ---
> kernel/smp.c | 9 -
> 1 file changed, 8 insertio
On Wed, Nov 02, 2022 at 12:35:07PM +, Christophe Leroy wrote:
>
>
> Le 28/10/2022 à 16:33, Sathvika Vasireddy a écrit :
> > In a subsequent patch, we would want to annotate powerpc assembly functions
> > with SYM_FUNC_START_LOCAL macro. This macro depends on __ALIGN macro.
> >
> > The defaul
On Wed, Oct 26, 2022 at 09:02:28AM +0200, Greg Kroah-Hartman wrote:
> On Wed, Oct 26, 2022 at 12:07:01PM +0530, Vishal Chourasia wrote:
> > On Tue, Oct 18, 2022 at 01:04:40PM +0200, Greg Kroah-Hartman wrote:
> >
> > > Why do you need to? What tools require these debugfs files to be
> > > present?
On Thu, Oct 20, 2022 at 12:36:56PM +0530, Athira Rajeev wrote:
> commit 838d9bb62d13 ("perf: Use sample_flags for raw_data")
> added check for PERF_SAMPLE_RAW in sample_flags in
> perf_prepare_sample(). But while copying the sample in memory,
> the check for sample_flags is not added in perf_output
On Fri, Oct 14, 2022 at 03:26:07PM +0530, Ravi Bangoria wrote:
> On 13-Oct-22 4:29 PM, Peter Zijlstra wrote:
> > On Thu, Oct 13, 2022 at 03:37:23PM +0530, Ravi Bangoria wrote:
> >
> >>> - refcount_t refcount;
> >>> + refcount_t
On Thu, Oct 13, 2022 at 03:37:23PM +0530, Ravi Bangoria wrote:
> > - refcount_t refcount;
> > + refcount_t refcount; /* event <-> ctx */
>
> Ok. We need to remove all those // XXX get/put_ctx() from code
> which we added to make refcount a pmu_ctx <->
On Wed, Oct 12, 2022 at 02:16:29PM +0200, Peter Zijlstra wrote:
> That's the intent yeah. But due to not always holding ctx->mutex over
> put_pmu_ctx() this might be moot. I'm almost through auditing epc usage
> and I think ctx->lock is sufficient, fingers crossed.
S
On Wed, Oct 12, 2022 at 02:09:00PM +0530, Ravi Bangoria wrote:
> > @@ -3366,6 +3370,14 @@ static void perf_event_sync_stat(struct
> > }
> > }
> >
> > +#define list_for_each_entry_double(pos1, pos2, head1, head2, member)
> > \
> > + for (pos1 = list_first_entry(head1, typeof(*pos1),
On Tue, Oct 11, 2022 at 04:02:56PM +0200, Peter Zijlstra wrote:
> On Tue, Oct 11, 2022 at 06:49:55PM +0530, Ravi Bangoria wrote:
> > On 11-Oct-22 4:59 PM, Peter Zijlstra wrote:
> > > On Sat, Oct 08, 2022 at 11:54:24AM +0530, Ravi Bangoria wrote:
> >
On Tue, Oct 11, 2022 at 06:49:55PM +0530, Ravi Bangoria wrote:
> On 11-Oct-22 4:59 PM, Peter Zijlstra wrote:
> > On Sat, Oct 08, 2022 at 11:54:24AM +0530, Ravi Bangoria wrote:
> >
> >> +static void perf_event_swap_task_ctx_data(struct perf_event
On Sat, Oct 08, 2022 at 11:54:24AM +0530, Ravi Bangoria wrote:
> +static void perf_event_swap_task_ctx_data(struct perf_event_context
> *prev_ctx,
> + struct perf_event_context *next_ctx)
> +{
> + struct perf_event_pmu_context *prev_epc, *next_epc;
> +
>
On Tue, Sep 06, 2022 at 11:20:53AM +0530, Ravi Bangoria wrote:
> This one was simple enough so I prepared a patch for this. Let
> me know if you see any issues with below diff.
I've extraed this as a separate patch since it's not strictly required
for correctness and the patch is a quite large en
On Wed, Sep 07, 2022 at 04:58:49PM +0530, Ravi Bangoria wrote:
> > -static void
> > -ctx_flexible_sched_in(struct perf_event_context *ctx,
> > - struct perf_cpu_context *cpuctx)
> > +/* XXX .busy thingy from Peter's patch */
> > +static void ctx_flexible_sched_in(struct perf_event_c
Because Nadav asked about tracing/kprobing idle, I had another go around
and noticed not all functions calling ct_cpuidle_enter are __cpuidle.
Basically all cpuidle_driver::enter functions should be __cpuidle; i'll
do that audit shortly.
For now this is ct_cpuidle_enter / CPU_IDLE_ENTER users.
On Mon, Sep 19, 2022 at 04:21:23PM +0200, Frederic Weisbecker wrote:
> On Mon, Sep 19, 2022 at 11:59:47AM +0200, Peter Zijlstra wrote:
> > Doing RCU-idle outside the driver, only to then temporarily enable it
> > again, at least twice, before going idle is daft.
>
> Hmm,
On Mon, Sep 19, 2022 at 03:19:27PM +0200, Frederic Weisbecker wrote:
> On Mon, Sep 19, 2022 at 11:59:42AM +0200, Peter Zijlstra wrote:
> > cpuidle_state::enter() methods should be IRQ invariant
>
> Got a bit confused with the invariant thing since the first chunck I
> see
On Mon, Sep 19, 2022 at 04:31:42PM +0200, Frederic Weisbecker wrote:
> On Mon, Sep 19, 2022 at 11:59:48AM +0200, Peter Zijlstra wrote:
> > Doing RCU-idle outside the driver, only to then teporarily enable it
> > again before going idle is daft.
>
> That doesn't
On Mon, Sep 19, 2022 at 04:49:41PM +0200, Frederic Weisbecker wrote:
> On Mon, Sep 19, 2022 at 11:59:47AM +0200, Peter Zijlstra wrote:
> > Doing RCU-idle outside the driver, only to then temporarily enable it
> > again, at least twice, before going idle is daft.
> >
>
On Mon, Sep 19, 2022 at 04:49:41PM +0200, Frederic Weisbecker wrote:
> On Mon, Sep 19, 2022 at 11:59:47AM +0200, Peter Zijlstra wrote:
> > Doing RCU-idle outside the driver, only to then temporarily enable it
> > again, at least twice, before going idle is daft.
> >
>
On Mon, Sep 19, 2022 at 04:21:23PM +0200, Frederic Weisbecker wrote:
> On Mon, Sep 19, 2022 at 11:59:47AM +0200, Peter Zijlstra wrote:
> > Doing RCU-idle outside the driver, only to then temporarily enable it
> > again, at least twice, before going idle is daft.
>
> Hmm,
nable-disable' dance.
Therefore, push this IRQ disabling into the idle function, meaning
that those architectures can avoid the pointless IRQ state flipping.
Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Gautham R. Shenoy
Acked-by: Mark Rutland [arm64]
Acked-by: Rafael J. Wysocki
---
Make cpuidle_enter_state() consistent with the s2idle variant and
verify ->enter() always returns with interrupts disabled.
Signed-off-by: Peter Zijlstra (Intel)
---
drivers/cpuidle/cpuidle.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
--- a/drivers/cpuidle/cpuidl
For testing purposes.
Signed-off-by: Peter Zijlstra (Intel)
---
drivers/idle/intel_idle.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/drivers/idle/intel_idle.c
+++ b/drivers/idle/intel_idle.c
@@ -1787,6 +1787,9 @@ static bool __init intel_idle_verify_cst
return
()
leaves .noinstr.text section
Signed-off-by: Peter Zijlstra (Intel)
---
arch/x86/include/asm/fpu/xcr.h |4 ++--
arch/x86/include/asm/special_insns.h |2 +-
arch/x86/kernel/fpu/core.c |4 ++--
3 files changed, 5 insertions(+), 5 deletions(-)
--- a/arch/x86/include/asm/fpu
/restore and whitelist the thing.
Signed-off-by: Peter Zijlstra (Intel)
---
lib/ubsan.c |5 -
tools/objtool/check.c |1 +
2 files changed, 5 insertions(+), 1 deletion(-)
--- a/lib/ubsan.c
+++ b/lib/ubsan.c
@@ -340,9 +340,10 @@ void __ubsan_handle_load_invalid_value(v
Hi All!
At long last, a respin of the cpuidle vs rcu cleanup patches.
v1: https://lkml.kernel.org/r/20220608142723.103523...@infradead.org
These here patches clean up the mess that is cpuidle vs rcuidle.
At the end of the ride there's only on RCU_NONIDLE user left:
arch/arm64/kernel/suspend.
No callers left that have already disabled RCU.
Signed-off-by: Peter Zijlstra (Intel)
Acked-by: Mark Rutland
---
kernel/time/tick-broadcast-hrtimer.c | 29 -
1 file changed, 12 insertions(+), 17 deletions(-)
--- a/kernel/time/tick-broadcast-hrtimer.c
+++ b/kernel
x false positive RCU splats due to
incorrect hardirqs state")
Signed-off-by: Peter Zijlstra (Intel)
---
drivers/idle/intel_idle.c |8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
--- a/drivers/idle/intel_idle.c
+++ b/drivers/idle/intel_idle.c
@@ -168,13
Ever since commit d3afc7f12987 ("arm64: Allow IPIs to be handled as
normal interrupts") this function is called in regular IRQ context.
Signed-off-by: Peter Zijlstra (Intel)
Acked-by: Mark Rutland
Acked-by: Marc Zyngier
---
arch/arm64/kernel/smp.c |4 ++--
1 file changed, 2
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)
---
arch/x86/lib/memcpy_64.S |5 ++---
arch/x86/lib/memmove_64.S |4 +++-
arch/x86/lib/memset_64.S |4
Doing RCU-idle outside the driver, only to then temporarily enable it
again, at least twice, before going idle is daft.
Signed-off-by: Peter Zijlstra (Intel)
---
arch/arm/mach-imx/cpuidle-imx6sx.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/arch/arm/mach-imx/cpuidle
e for smp_cross_call() tracepoints"), that
cpuidle_enter_state_coupled() already had RCU disabled, but that's
long been fixed by commit 1098582a0f6c ("sched,idle,rcu: Push rcu_idle
deeper into the idle path").
Signed-off-by: Peter Zijlstra (Intel)
---
arch/arm/kernel/smp.c |
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)
---
arch/x86/events/amd/brs.c | 13 +
arch/x86/include/asm/perf_event.h |2 +-
2 files changed, 6 insertions(+), 9 deletions
The PM notifiers should no longer be ran with RCU disabled (per the
previous patches), as such this hack is no longer required either.
Signed-off-by: Peter Zijlstra (Intel)
---
drivers/perf/arm_pmu.c | 11 +--
drivers/perf/riscv_pmu_sbi.c |8 +---
2 files changed, 2
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
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)
---
arch/arm/mach-omap2
complicated idle states for the cpuidle driver.
Signed-off-by: Peter Zijlstra (Intel)
Acked-by: Tony Lindgren
---
arch/arm/mach-omap2/pm34xx.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -294,7 +294,7 @@ static
__monitor.constprop.0()
leaves .noinstr.text section
vmlinux.o: warning: objtool: mwait_idle+0x88: call to clflush() leaves
.noinstr.text section
Signed-off-by: Peter Zijlstra (Intel)
---
arch/x86/include/asm/mwait.h | 12 ++--
arch/x86/include/asm/special_insns.h |2 +-
2 files changed
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)
---
arch/x86/kernel/cpu/bugs.c |2
vmlinux.o: warning: objtool: acpi_idle_enter_s2idle+0x45: call to
__this_cpu_preempt_check() leaves .noinstr.text section
Signed-off-by: Peter Zijlstra (Intel)
---
include/linux/percpu-defs.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/include/linux/percpu-defs.h
+++ b
Idle code is very like entry code in that RCU isn't available. As
such, add a little validation.
Signed-off-by: Peter Zijlstra (Intel)
Acked-by: Geert Uytterhoeven
---
arch/alpha/kernel/vmlinux.lds.S |1 -
arch/arc/kernel/vmlinux.lds.S|1 -
arch/arm/includ
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)
---
arch/arm/mach-imx/cpuidle-imx6q.c|4 +--
arch/arm/mach-imx
OMAP was the one and only user.
Signed-off-by: Peter Zijlstra (Intel)
---
arch/arm/mach-omap2/powerdomain.c | 10 +-
drivers/base/power/runtime.c | 24
2 files changed, 17 insertions(+), 17 deletions(-)
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b
() leaves .noinstr.text section
Signed-off-by: Peter Zijlstra (Intel)
Acked-by: Rafael J. Wysocki
---
arch/x86/include/asm/shared/io.h |4 ++--
drivers/acpi/processor_idle.c|2 +-
include/linux/cpumask.h |4 ++--
3 files changed, 5 insertions(+), 5 deletions(-)
--- a/arch
section
vmlinux.o: warning: objtool: intel_idle+0x78: call to
test_ti_thread_flag.constprop.0() leaves .noinstr.text section
vmlinux.o: warning: objtool: acpi_safe_halt+0xf: call to
test_ti_thread_flag.constprop.0() leaves .noinstr.text section
Signed-off-by: Peter Zijlstra (Intel)
---
include
OMAP was the one and only user.
Signed-off-by: Peter Zijlstra (Intel)
---
drivers/clk/clk.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -978,12 +978,12 @@ static void clk_core_disable(struct clk_
if (--core
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
CONFIG_GENERIC_ENTRY disallows any and all tracing when RCU isn't
enabled.
XXX if s390 (the only other GENERIC_ENTRY user as of this writing)
isn't comfortable with this, we could switch to
HAVE_NOINSTR_VALIDATION which is x86_64 only atm.
Signed-off-by: Peter Zijlstra (Intel)
--
.noinstr.text section
Signed-off-by: Peter Zijlstra (Intel)
---
arch/x86/boot/compressed/vmlinux.lds.S |1 +
arch/x86/coco/tdx/tdcall.S |2 ++
arch/x86/coco/tdx/tdx.c|5 +++--
3 files changed, 6 insertions(+), 2 deletions(-)
--- a/arch/x86/boot/compressed
ave 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)
---
arch/arm/mach-omap2/pm24xx.c | 51 +--
1 file changed, 2 insertions(+), 49 deletions(-)
--- a
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)
---
arch/x86/coco/tdx/tdcall.S
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
All the idle routines are called with RCU disabled, as such there must
not be any tracing inside.
While there; clean-up the io-port idle thing.
Signed-off-by: Peter Zijlstra (Intel)
---
drivers/acpi/processor_idle.c | 24 +---
1 file changed, 13 insertions(+), 11
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
---
drivers/cpuidle/poll_state.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/drivers/cpuidle/poll_state.c
Doing RCU-idle outside the driver, only to then temporarily enable it
again, some *four* times, before going idle is daft.
Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Tony Lindgren
Tested-by: Tony Lindgren
---
arch/arm/mach-omap2/cpuidle44xx.c | 29 ++---
1
Doing RCU-idle outside the driver, only to then teporarily enable it
again before going idle is daft.
Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Tony Lindgren
Tested-by: Tony Lindgren
---
arch/arm/mach-omap2/cpuidle34xx.c | 16
1 file changed, 16 insertions
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
---
arch/x86/kernel/process.c | 50 +-
1 file changed, 28 insertions(+), 22
Doing RCU-idle outside the driver, only to then temporarily enable it
again before going idle is daft.
Signed-off-by: Peter Zijlstra (Intel)
---
drivers/cpuidle/cpuidle-mvebu-v7.c |7 +++
1 file changed, 7 insertions(+)
--- a/drivers/cpuidle/cpuidle-mvebu-v7.c
+++ b/drivers/cpuidle
cpuidle_state::enter() methods should be IRQ invariant
Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Rafael J. Wysocki
---
drivers/cpuidle/poll_state.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/cpuidle/poll_state.c
+++ b/drivers/cpuidle/poll_state.c
Doing RCU-idle outside the driver, only to then temporarily enable it
again, at least twice, before going idle is daft.
Signed-off-by: Peter Zijlstra (Intel)
---
drivers/cpuidle/cpuidle-tegra.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
--- a/drivers/cpuidle
Doing RCU-idle outside the driver, only to then temporarily enable it
again, at least twice, before going idle is daft.
Signed-off-by: Peter Zijlstra (Intel)
---
drivers/cpuidle/cpuidle-psci.c |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
--- a/drivers/cpuidle/cpuidle
Doing RCU-idle outside the driver, only to then temporarily enable it
again, at least twice, before going idle is daft.
Signed-off-by: Peter Zijlstra (Intel)
---
drivers/cpuidle/cpuidle-riscv-sbi.c |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
--- a/drivers/cpuidle/cpuidle
On Thu, Sep 15, 2022 at 10:56:58AM +0800, Chen Zhongjin wrote:
> We have found some anonymous information on x86 in .rodata.
Well yes, but that's still a bunch of heuristics on our side.
> I'm not sure if those are *all* of Josh wanted on x86, however for arm64 we
> did not found that in the sam
On Wed, Sep 14, 2022 at 02:28:26PM +, Michael Matz wrote:
> Hello,
>
> On Wed, 14 Sep 2022, Peter Zijlstra wrote:
>
> > > Maybe this is semantics, but I wouldn't characterize objtool's existence
> > > as being based on the mistrust of tools. It&#
On Wed, Sep 14, 2022 at 01:04:16AM +0100, Josh Poimboeuf wrote:
> > I will mention that objtool's existence is based on mistrust, of persons
> > (not correctly annotating stuff) and of tools (not correctly heeding those
> > annotations). The mistrust in persons is understandable and can be deal
On Mon, Sep 12, 2022 at 01:50:04PM +0530, Sathvika Vasireddy wrote:
> Christophe Leroy (4):
> objtool: Fix SEGFAULT
> objtool: Use target file endianness instead of a compiled constant
> objtool: Use target file class size instead of a compiled constant
> Sathvika Vasireddy (12):
> objtool
On Tue, Sep 13, 2022 at 12:21:51PM +, Christophe Leroy wrote:
> > Like mentioned last time; I'm fixing this (but you're right to not wait
> > on that), that said, would it make sense to write it like:
> >
> > #define __ALIGN .balign 4
> > #define __ALIGN_STR __stringify(__ALIGN)
>
On Mon, Sep 12, 2022 at 01:50:06PM +0530, Sathvika Vasireddy wrote:
> In a subsequent patch, we would want to annotate powerpc assembly functions
> with SYM_FUNC_START_LOCAL macro. This macro depends on __ALIGN macro.
>
> The default expansion of __ALIGN macro is:
> #define __ALIGN .a
On Fri, Sep 09, 2022 at 11:07:04AM -0700, Josh Poimboeuf wrote:
> Alternatives
>
>
> Another idea which has been floated in the past is for objtool to read
> DWARF (or .eh_frame) to help it figure out the control flow. That
> hasn't been tried yet, but would be considerably more diff
On Mon, Aug 29, 2022 at 11:22:09AM +0530, Sathvika Vasireddy wrote:
> Powerpc instructions must be word-aligned. Currently,
> there is an alignment of 16 bytes (by default), and it is
> much more than what is required for powerpc (4 bytes).
>
> The default expansion of __ALIGN() macro is:
> #defin
On Mon, Aug 29, 2022 at 11:22:10AM +0530, Sathvika Vasireddy wrote:
> objtool does not add STT_NOTYPE symbols with size 0 to the
I suspect we can fix that once:
https://lkml.kernel.org/r/20220902130949.789826...@infradead.org
lands.
On Fri, Sep 02, 2022 at 08:06:28AM +, Christophe Leroy wrote:
>
>
> Le 01/09/2022 à 21:20, Peter Zijlstra a écrit :
> > On Mon, Aug 29, 2022 at 11:22:15AM +0530, Sathvika Vasireddy wrote:
> >> From: Christophe Leroy
> >>
> >> find_insn() will ret
On Thu, Sep 01, 2022 at 10:34:48AM -0700, Suren Baghdasaryan wrote:
> This is a proof of concept for per-vma locks idea that was discussed
> during SPF [1] discussion at LSF/MM this year [2], which concluded with
> suggestion that “a reader/writer semaphore could be put into the VMA
> itself; that
and R_ABS64.
>
> For x86 that corresponds to R_X86_64_PC32.
> For powerpc it is R_PPC_REL32/R_PPC64_REL32.
>
> Signed-off-by: Christophe Leroy
Acked-by: Peter Zijlstra (Intel)
On Mon, Aug 29, 2022 at 11:22:20AM +0530, Sathvika Vasireddy wrote:
> Make relocation types architecture specific.
>
> Signed-off-by: Sathvika Vasireddy
Acked-by: Peter Zijlstra (Intel)
e sure that --mnop can be passed as an option
> to objtool only when --mcount is passed.
>
> Signed-off-by: Sathvika Vasireddy
IIRC you want to nop the things yourself because PLT entries or
something?
Anyway, patch looks fine, even though the Changelog doesn't relaly
justify the c
101 - 200 of 1008 matches
Mail list logo
