On Wed, Dec 06, 2023 at 10:37:33AM -0600, Madhavan T. Venkataraman wrote:
>
>
> On 11/30/23 05:33, Peter Zijlstra wrote:
> > On Wed, Nov 29, 2023 at 03:07:15PM -0600, Madhavan T. Venkataraman wrote:
> >
> >> Kernel Lockdown
> >> ---
>
On Wed, Nov 29, 2023 at 03:07:15PM -0600, Madhavan T. Venkataraman wrote:
> Kernel Lockdown
> ---
>
> But, we must provide at least some security in V2. Otherwise, it is useless.
>
> So, we have implemented what we call a kernel lockdown. At the end of kernel
> boot, Heki
On Mon, Nov 27, 2023 at 10:48:29AM -0600, Madhavan T. Venkataraman wrote:
> Apologies for the late reply. I was on vacation. Please see my response below:
>
> On 11/13/23 02:19, Peter Zijlstra wrote:
> > On Sun, Nov 12, 2023 at 09:23:24PM -0500, Mickaël Salaün wrote:
> &
On Mon, Nov 27, 2023 at 11:05:23AM -0600, Madhavan T. Venkataraman wrote:
> Apologies for the late reply. I was on vacation. Please see my response below:
>
> On 11/13/23 02:54, Peter Zijlstra wrote:
> > On Sun, Nov 12, 2023 at 09:23:25PM -0500, Mickaël Salaün wrote:
> &
On Sun, Nov 12, 2023 at 09:23:25PM -0500, Mickaël Salaün wrote:
> From: Madhavan T. Venkataraman
>
> Implement a hypervisor function, kvm_protect_memory() that calls the
> KVM_HC_PROTECT_MEMORY hypercall to request the KVM hypervisor to
> set specified permissions on a list of guest pages.
>
>
On Sun, Nov 12, 2023 at 09:23:24PM -0500, Mickaël Salaün wrote:
> From: Madhavan T. Venkataraman
>
> X86 uses a function called __text_poke() to modify executable code. This
> patching function is used by many features such as KProbes and FTrace.
>
> Update the permissions counters for the text
cpuidle
stuff) but I've not yet gone through the whole hotplug thing :/
This seems right, at this point everything, including RCU is very much
gone, any instrumentation is undesired.
Acked-by: Peter Zijlstra (Intel)
>
> drivers/acpi/processor_idle.c | 2 +-
> 1 file change
On Fri, Sep 15, 2023 at 02:16:50AM +0100, andrew.coop...@citrix.com wrote:
> Juergen has already done the work to delete one of these two patching
> mechanisms and replace it with the other.
>
> https://lore.kernel.org/lkml/a32e211f-4add-4fb2-9e5a-480ae9b9b...@suse.com/
>
> Unfortunately, it's
On Thu, Jun 08, 2023 at 04:03:31PM +0200, Juergen Gross wrote:
> As a preparation for replacing paravirt patching completely by
> alternative patching, move some backend functions and #defines to
> alternative code and header.
>
> Signed-off-by: Juergen Gross
Acked-by: Peter Zijlstra (Intel)
On Fri, Aug 04, 2023 at 05:35:11PM +, Li, Xin3 wrote:
> > > The IDT event delivery of X86_TRAP_DF, X86_TRAP_TS, X86_TRAP_NP,
> > > X86_TRAP_SS, X86_TRAP_GP, X86_TRAP_AC and X86_TRAP_CP pushes an error
> > > code into the orig_ax member of the pt_regs structure, and the error
> > > code is
On Fri, Aug 04, 2023 at 12:57:34AM -0700, Xin Li wrote:
> The IDT event delivery of X86_TRAP_DF, X86_TRAP_TS, X86_TRAP_NP,
> X86_TRAP_SS, X86_TRAP_GP, X86_TRAP_AC and X86_TRAP_CP pushes an error
> code into the orig_ax member of the pt_regs structure, and the error
> code is passed as the second
On Tue, Aug 01, 2023 at 07:01:15PM +, Sean Christopherson wrote:
> The spec I have from May 2022 says the NMI bit colocated with CS, not SS. And
> the cover letter's suggestion to use a search engine to find the spec ain't
> exactly helpful, that just gives me the same "May 2022 Revision 3.0"
On Tue, Aug 01, 2023 at 12:52:36PM +0200, Peter Zijlstra wrote:
> I also believe there is a kernel.org service for sending patch series,
> but i'm not sure I remember the details.
https://b4.docs.kernel.org/en/latest/contributor/send.html
On Tue, Aug 01, 2023 at 01:32:42AM -0700, Xin Li wrote:
> Resend because the mail system failed to deliver some messages yesterday.
Well, you need to figure out how to send patches, because both yesterday
and today are screwy.
The one from yesterday came in 6 thread groups: 0-25, 26, 27, 28, 29,
On Mon, Jul 24, 2023 at 05:43:10PM +0800, Qi Zheng wrote:
> +void shrinker_unregister(struct shrinker *shrinker)
> +{
> + struct dentry *debugfs_entry;
> + int debugfs_id;
> +
> + if (!shrinker || !(shrinker->flags & SHRINKER_REGISTERED))
> + return;
> +
> +
On Thu, Jun 22, 2023 at 02:05:13PM +0100, Andrew Cooper wrote:
> On 22/06/2023 9:26 am, Peter Zijlstra wrote:
> > On Thu, Jun 22, 2023 at 07:22:53AM +0200, Juergen Gross wrote:
> >
> >> The hypercalls we are talking of are synchronous ones. They are running
> >>
On Thu, Jun 22, 2023 at 12:33:31PM +0200, Juergen Gross wrote:
> On 22.06.23 10:26, Peter Zijlstra wrote:
> > > The downside would be that some workloads might see worse performance
> > > due to backend I/O handling might get preempted.
> >
> > Is that an a
On Thu, Jun 22, 2023 at 07:22:53AM +0200, Juergen Gross wrote:
> The hypercalls we are talking of are synchronous ones. They are running
> in the context of the vcpu doing the call (like a syscall from userland is
> running in the process context).
(so time actually passes from the guest's pov?)
On Wed, Jun 21, 2023 at 07:19:21PM +, Per Bilse wrote:
> On 6/21/2023 5:40 PM, Peter Zijlstra wrote:
> > I don't understand it -- fundamentally, how can linux schedule when the
> > guest isn't even running? Hypercall transfers control to the
> > host/hypervisor and leave
On Wed, Jun 21, 2023 at 03:14:42PM +, Per Bilse wrote:
> Some Xen hypercalls issued by dom0 guests may run for many 10s of
> seconds, potentially causing watchdog timeouts and other problems.
> It's rare for this to happen, but it does in extreme circumstances,
> for instance when shutting
On Fri, May 12, 2023 at 11:07:56PM +0200, Thomas Gleixner wrote:
> From: Thomas Gleixner
>
> Implement the validation function which tells the core code whether
> parallel bringup is possible.
>
> The only condition for now is that the kernel does not run in an encrypted
> guest as these will
On Tue, May 09, 2023 at 10:11:05PM +0200, Thomas Gleixner wrote:
> On Tue, May 09 2023 at 12:04, Peter Zijlstra wrote:
> > On Mon, May 08, 2023 at 09:43:39PM +0200, Thomas Gleixner wrote:
> > Not to the detriment of this patch, but this barrier() and it's comment
> > see
On Mon, May 08, 2023 at 09:44:23PM +0200, Thomas Gleixner wrote:
> + /* APIC ID not found in the table. Drop the trampoline lock and bail.
> */
> + movqtrampoline_lock(%rip), %rax
Again:
movl$0, (%rax)
is sufficient for unlock.
> + lock
> + btrl$0, (%rax)
On Mon, May 08, 2023 at 09:44:22PM +0200, Thomas Gleixner wrote:
> @@ -252,6 +252,17 @@ SYM_INNER_LABEL(secondary_startup_64_no_
> movqTASK_threadsp(%rax), %rsp
>
> /*
> + * Now that this CPU is running on its own stack, drop the realmode
> + * protection. For the boot
On Tue, May 09, 2023 at 01:07:23PM +0200, Peter Zijlstra wrote:
> On Mon, May 08, 2023 at 09:43:55PM +0200, Thomas Gleixner wrote:
>
> > +static inline void cpuhp_ap_update_sync_state(enum cpuhp_sync_state state)
> > +{
> > + atomic_t *st = this_cpu_ptr(_state.ap_sync_
On Mon, May 08, 2023 at 09:43:55PM +0200, Thomas Gleixner wrote:
> +static inline void cpuhp_ap_update_sync_state(enum cpuhp_sync_state state)
> +{
> + atomic_t *st = this_cpu_ptr(_state.ap_sync_state);
> + int sync = atomic_read(st);
> +
> + while (!atomic_try_cmpxchg(st, , state));
On Mon, May 08, 2023 at 09:43:49PM +0200, Thomas Gleixner wrote:
> From: Thomas Gleixner
>
> There is no harm to hold sparse_irq lock until the upcoming CPU completes
> in cpuhp_online_idle(). This allows to remove cpu_online() synchronization
> from architecture code.
Uhh.. damn. Can you
On Mon, May 08, 2023 at 09:43:47PM +0200, Thomas Gleixner wrote:
> --- a/arch/x86/kernel/smpboot.c
> +++ b/arch/x86/kernel/smpboot.c
> @@ -167,21 +166,16 @@ static inline void smpboot_restore_warm_
> */
> static void smp_callin(void)
> {
> - int cpuid;
> + int cpuid =
And since I'm commenting on existing things anyway, let me continue...
On Mon, May 08, 2023 at 09:43:39PM +0200, Thomas Gleixner wrote:
> +static int wait_cpu_cpumask(unsigned int cpu, const struct cpumask *mask)
> +{
> + unsigned long timeout;
>
> + /*
> + * Wait up to 10s for
Again, not really this patch, but since I had to look at this code
On Mon, May 08, 2023 at 09:43:39PM +0200, Thomas Gleixner wrote:
> @@ -1048,60 +1066,89 @@ static int do_boot_cpu(int apicid, int c
/*
* AP might wait on cpu_callout_mask in cpu_init() with
*
On Mon, May 08, 2023 at 09:43:39PM +0200, Thomas Gleixner wrote:
> @@ -233,14 +237,31 @@ static void notrace start_secondary(void
> load_cr3(swapper_pg_dir);
> __flush_tlb_all();
> #endif
> + /*
> + * Sync point with wait_cpu_initialized(). Before proceeding through
> +
On Sat, Apr 15, 2023 at 01:44:13AM +0200, Thomas Gleixner wrote:
> Background
> --
>
> The reason why people are interested in parallel bringup is to shorten
> the (kexec) reboot time of cloud servers to reduce the downtime of the
> VM tenants. There are obviously other interesting use
On Tue, Feb 14, 2023 at 12:47:00PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> The following commits are also in the tip tree as different commits
> (but the same patches):
>
> 415dab3c1796 ("drivers/xen/hypervisor: Expose Xen SIF flags to userspace")
> 336f560a8917 ("x86/xen: don't let
On Thu, Jan 19, 2023 at 11:35:06AM -0800, H. Peter Anvin wrote:
> On January 18, 2023 1:45:44 AM PST, Peter Zijlstra
> wrote:
> >On Mon, Jan 16, 2023 at 03:25:34PM +0100, Peter Zijlstra wrote:
> >> The boot trampolines from trampoline_64.S have code flow like:
&g
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 Mon, Jan 16, 2023 at 03:25:34PM +0100, Peter Zijlstra wrote:
> The boot trampolines from trampoline_64.S have code flow like:
>
> 16bit BIOS SEV-ES 64bit EFI
>
> trampoline_start() sev_es_trampoline_start()
> t
On Sun, Jan 15, 2023 at 08:27:50PM -0800, Srivatsa S. Bhat wrote:
> I see that's not an issue right now since there is no other actual
> user for these callbacks. But are we sure that merging the callbacks
> just because the current user (Xen PV) has the same implementation for
> both is a good
On Tue, Jan 17, 2023 at 10:31:05AM +0100, Ingo Molnar wrote:
>
> * Peter Zijlstra wrote:
>
> > + /*
> > +* Definitely wrong, but at this point we should have at least enough
> > +* to do CALL/RET (consider SKL callthunks) and this avoids having
> >
Since we can't do CALL/RET until GS is restored and CR[04] pinning is
of dubious value in this code path, simply write the stored values.
Fixes: e81dc127ef69 ("x86/callthunks: Add call patching for call depth
tracking")
Reported-by: Joan Bruguera
Signed-off-by: Peter Zijlstra (Intel)
Ensure no compiler instrumentation sneaks in while restoring the CPU
state. Specifically we can't handle CALL/RET until GS is restored.
Signed-off-by: Peter Zijlstra (Intel)
---
arch/x86/power/cpu.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
--- a/arch/x86/power
Hi all,
Patches to address the various callthunk fails reported by Joan.
The first two patches are new (and I've temporarily dropped the
restore_processor_state sealing).
It is my understanding that AP bringup will always use the 16bit trampoline
path, if this is not the case, please holler.
call patching for call depth
tracking")
Reported-by: Joan Bruguera
Signed-off-by: Peter Zijlstra (Intel)
---
arch/x86/kernel/head_64.S | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
--- a/arch/x86/kernel/head_64.S
+++ b/arch/x86/kernel/head_64.S
@@ -185
From: Joan Bruguera
When resuming from suspend we don't have coherent CPU state, trying to
do callthunks here isn't going to work. Specifically GS isn't set yet.
Fixes: e81dc127ef69 ("x86/callthunks: Add call patching for call depth
tracking")
Signed-off-by: Joan Bruguera
Signed-off
Since Xen PV doesn't use restore_processor_state(), and we're going to
have to avoid CALL/RET until at least GS is restored, de-paravirt the
easy bits.
Fixes: e81dc127ef69 ("x86/callthunks: Add call patching for call depth
tracking")
Reported-by: Joan Bruguera
Signed-off-by: Pete
n from secondary_startup_64()
renders the whole secondary_startup_64_no_verify() thing moot, so
remove that too.
Cc: jroe...@suse.de
Cc: h...@zytor.com
Fixes: e81dc127ef69 ("x86/callthunks: Add call patching for call depth
tracking")
Reported-by: Joan Bruguera
Signed-off-by: Peter Zijlstra (Intel
When resuming there must not be any code between swsusp_arch_suspend()
and restore_processor_state() since the CPU state is ill defined at
this point in time.
Signed-off-by: Peter Zijlstra (Intel)
---
kernel/power/hibernate.c | 30 +++---
1 file changed, 27 insertions
pv_play_dead() return
> x86/xen: mark xen_pv_play_dead() as __noreturn
>
> arch/x86/xen/smp.h | 2 ++
> arch/x86/xen/smp_pv.c | 17 -
> arch/x86/xen/xen-head.S | 7 +++
> tools/objtool/check.c | 1 +
> 4 files changed, 14 insertions(+), 13 deletions(-)
Acked-by: Peter Zijlstra (Intel)
On Fri, Jan 13, 2023 at 02:16:44PM +0100, Ingo Molnar wrote:
>
> * Peter Zijlstra wrote:
>
> > Since we can't do CALL/RET until GS is restored and CR[04] pinning is
> > of dubious value in this code path, simply write the stored values.
> >
> > Sig
On Fri, Jan 13, 2023 at 10:17:46AM +0100, Peter Zijlstra wrote:
> > (2) Tracing with QEMU I still see two `sarq $5, %gs:0x1337B33F` before
> > `%gs` is restored. Those correspond to the calls from
> > `secondary_startup_64` in `arch/x86/kernel/head_64.S` to
&
On Fri, Jan 13, 2023 at 07:39:38AM +, Joan Bruguera wrote:
> Hi Peter,
>
> I tried your patches on both QEMU and my two (real) computers where
> s2ram with `retbleed=stuff` was failing and they wake up fine now.
Yay \o/
> However, I think some minor reviews are needed:
>
> (1) I got a
Since Xen PV doesn't use restore_processor_state(), and we're going to
have to avoid CALL/RET until at least GS is restored, de-paravirt the
easy bits.
Signed-off-by: Peter Zijlstra (Intel)
---
arch/x86/power/cpu.c | 24
1 file changed, 12 insertions(+), 12 deletions
Ensure no compiler instrumentation sneaks in while restoring the CPU
state. Specifically we can't handle CALL/RET until GS is restored.
Signed-off-by: Peter Zijlstra (Intel)
---
arch/x86/power/cpu.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
--- a/arch/x86/power
Since we can't do CALL/RET until GS is restored and CR[04] pinning is
of dubious value in this code path, simply write the stored values.
Signed-off-by: Peter Zijlstra (Intel)
---
arch/x86/power/cpu.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/x86/power/cpu.c
+++ b
From: Joan Bruguera
When resuming from suspend we don't have coherent CPU state, trying to
do callthunks here isn't going to work. Specifically GS isn't set yet.
Signed-off-by: Joan Bruguera
Signed-off-by: Peter Zijlstra (Intel)
Link: https://lkml.kernel.org/r/20230109040531.7888-1-joanbrugue
Disallow indirect branches to restore_processor_state().
Signed-off-by: Peter Zijlstra (Intel)
---
arch/x86/include/asm/suspend_64.h |4
arch/x86/power/cpu.c |2 +-
arch/x86/power/hibernate_asm_64.S |4
include/linux/suspend.h |4
4 files
When resuming there must not be any code between swsusp_arch_suspend()
and restore_processor_state() since the CPU state is ill defined at
this point in time.
Signed-off-by: Peter Zijlstra (Intel)
---
kernel/power/hibernate.c | 30 +++---
1 file changed, 27 insertions
Hi,
I'm thinking these few patches should do the trick -- but I've only compiled
them and looked at the resulting asm output, I've not actually ran them.
Joan, could you kindly test?
The last (two) patches are optional fixes and should probably not go into
/urgent.
On Tue, Nov 22, 2022 at 05:23:50PM -0800, Josh Poimboeuf wrote:
> On Tue, Nov 22, 2022 at 09:35:17AM +0100, Peter Zijlstra wrote:
> > On Mon, Nov 21, 2022 at 09:16:05PM -0800, Josh Poimboeuf wrote:
> >
> > > It's complaining about an unreachable
On Thu, Nov 10, 2022 at 03:45:21PM +, Ross Philipson wrote:
> On allocation failures, panic() was used since this seemed
> to be the action taken on other failures in the modules
> touched by this patch.
How is the panic() more useful than the obvious NULL deref that also
splats?
On Thu, Sep 01, 2022 at 10:32:19AM -0400, Kent Overstreet wrote:
> On Thu, Sep 01, 2022 at 08:51:31AM +0200, Peter Zijlstra wrote:
> > On Tue, Aug 30, 2022 at 02:48:52PM -0700, Suren Baghdasaryan wrote:
> > > +static void lazy_percpu_counter_switch_to_pcpu(struct
> > >
On Thu, Sep 01, 2022 at 09:05:36AM +0200, Peter Zijlstra wrote:
> On Wed, Aug 31, 2022 at 11:59:41AM -0400, Kent Overstreet wrote:
>
> > Also, ftrace can drop events. Not really ideal if under system load your
> > memory
> > accounting numbers start to drift.
>
On Wed, Aug 31, 2022 at 01:46:29PM -0400, Kent Overstreet wrote:
> Because all the counters are statically allocated, without even a pointer
> deref
> to get to them in the allocation path (one pointer deref to get to them in the
> deallocate path), that makes this _much, much_ cheaper than
On Tue, Aug 30, 2022 at 02:49:16PM -0700, Suren Baghdasaryan wrote:
> From: Kent Overstreet
>
> This adds the ability to easily instrument code for measuring latency.
> To use, add the following to calls to your code, at the start and end of
> the event you wish to measure:
>
>
On Wed, Aug 31, 2022 at 11:59:41AM -0400, Kent Overstreet wrote:
> Also, ftrace can drop events. Not really ideal if under system load your
> memory
> accounting numbers start to drift.
You could attach custom handlers to tracepoints. If you were to replace
these unconditional code hooks of
On Wed, Aug 31, 2022 at 11:19:48AM +0100, Mel Gorman wrote:
> It's also unclear *who* would enable this. It looks like it would mostly
> have value during the development stage of an embedded platform to track
> kernel memory usage on a per-application basis in an environment where it
> may be
On Tue, Aug 30, 2022 at 02:48:52PM -0700, Suren Baghdasaryan wrote:
> +static void lazy_percpu_counter_switch_to_pcpu(struct
> raw_lazy_percpu_counter *c)
> +{
> + u64 __percpu *pcpu_v = alloc_percpu_gfp(u64, GFP_ATOMIC|__GFP_NOWARN);
Realize that this is incorrect when used under a
On Tue, Aug 30, 2022 at 02:48:49PM -0700, Suren Baghdasaryan wrote:
> ===
> Code tagging framework
> ===
> Code tag is a structure identifying a specific location in the source code
> which is generated at compile time and can be embedded in an
tance of the SWAPGS macro.
>
> Cc: # 5.19
> Fixes: c89191ce67ef ("x86/entry: Convert SWAPGS to swapgs and remove the
> definition of SWAPGS")
> Signed-off-by: Juergen Gross
It's a little unfortunate int80 is different from the other compat entry
points, but that's l
On Mon, Jun 13, 2022 at 07:23:13PM +, Nadav Amit wrote:
> On Jun 13, 2022, at 11:48 AM, Srivatsa S. Bhat wrote:
>
> > ⚠ External Email
> >
> > On 6/8/22 4:27 PM, Peter Zijlstra wrote:
> >> vmlinux.o: warning: objtool: acpi_idle_enter_s2idle+0xde: call to wb
On Tue, Jun 14, 2022 at 05:13:16PM +0100, Mark Rutland wrote:
> On Wed, Jun 08, 2022 at 04:27:38PM +0200, Peter Zijlstra wrote:
> > All callers should still have RCU enabled.
>
> IIUC with that true we should be able to drop the RCU_NONIDLE() from
> drivers/perf/arm_pmu.c,
On Tue, Jun 14, 2022 at 01:41:13PM +0100, Mark Rutland wrote:
> On Wed, Jun 08, 2022 at 04:27:37PM +0200, Peter Zijlstra wrote:
> > --- a/kernel/time/tick-broadcast.c
> > +++ b/kernel/time/tick-broadcast.c
> > @@ -622,9 +622,13 @@ struct cpumask *tick_get_broadcast_onesh
&g
On Tue, Jun 14, 2022 at 12:19:29PM +0100, Mark Rutland wrote:
> On Wed, Jun 08, 2022 at 04:27:23PM +0200, Peter Zijlstra wrote:
> > Hi All! (omg so many)
>
> Hi Peter,
>
> Sorry for the delay; my plate has also been rather full recently. I'm
> beginning
> to page t
On Mon, Jun 13, 2022 at 03:39:05PM +0300, Tony Lindgren wrote:
> 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.
On Mon, Jun 13, 2022 at 04:26:01PM +0800, Lai Jiangshan wrote:
> On Wed, Jun 8, 2022 at 10:48 PM Peter Zijlstra wrote:
> >
> > Now that arch_cpu_idle() is expected to return with IRQs disabled,
> > avoid the useless STI/CLI dance.
> >
> > Per the specs this is sup
On Thu, Jun 09, 2022 at 04:49:21PM -0700, Jacob Pan wrote:
> Hi Peter,
>
> On Wed, 08 Jun 2022 16:27:27 +0200, Peter Zijlstra
> wrote:
>
> > Commit c227233ad64c ("intel_idle: enable interrupts before C1 on
> > Xeons") wrecked intel_idle in two ways:
>
On Wed, Jun 08, 2022 at 06:28:33PM +0200, Arnd Bergmann wrote:
> On Wed, Jun 8, 2022 at 4:27 PM Peter Zijlstra wrote:
> >
> > arch_cpu_idle() is a very simple idle interface and exposes only a
> > single idle state and is expected to not require RCU and not do any
> &
On Thu, Jun 09, 2022 at 10:39:22AM +0300, Tony Lindgren wrote:
> * Arnd Bergmann [220608 18:18]:
> > On Wed, Jun 8, 2022 at 4:27 PM Peter Zijlstra wrote:
> > >
> > > arch_cpu_idle() is a very simple idle interface and exposes only a
> > > single idle stat
On Thu, Jun 09, 2022 at 11:16:46AM +0200, Petr Mladek wrote:
> On Wed 2022-06-08 16:27:47, Peter Zijlstra wrote:
> > The problem, per commit fc98c3c8c9dc ("printk: use rcuidle console
> > tracepoint"), was printk usage from the cpuidle path where RCU was
> >
On Wed, Jun 08, 2022 at 05:01:05PM +0200, Rafael J. Wysocki wrote:
> On Wed, Jun 8, 2022 at 4:47 PM Peter Zijlstra wrote:
> >
> > Commit c227233ad64c ("intel_idle: enable interrupts before C1 on
> > Xeons") wrecked intel_idle in two ways:
> >
> >
On Wed, Jun 08, 2022 at 04:27:57PM +0200, Peter Zijlstra wrote:
> @@ -254,11 +255,18 @@ void omap_sram_idle(void)
>*/
> if (save_state)
> omap34xx_save_context(omap3_arm_context);
> +
> + if (rcuidle)
> + cpuidle_rcu_enter();
>
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
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)
---
arch/alpha/kernel/vmlinux.lds.S |1 -
arch/arc/kernel/vmlinux.lds.S|1 -
arch/arm/include/asm/vmlinux.lds.h |1 -
arch/arm64
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)
---
arch/arm/mach-omap2/cpuidle44xx.c | 29 ++---
1 file changed, 18 insertions(+), 11 deletions
All the idle routines are called with RCU disabled, as such there must
not be any tracing inside.
Signed-off-by: Peter Zijlstra (Intel)
---
drivers/acpi/processor_idle.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
--- a/drivers/acpi/processor_idle.c
+++ b
() leaves .noinstr.text section
Signed-off-by: Peter Zijlstra (Intel)
---
arch/x86/include/asm/paravirt.h |6 --
arch/x86/include/asm/special_insns.h |4 ++--
arch/x86/include/asm/xen/hypercall.h |2 +-
arch/x86/kernel/paravirt.c | 14 --
arch/x86/xen
Signed-off-by: Peter Zijlstra (Intel)
---
arch/x86/include/asm/nospec-branch.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/include/asm/nospec-branch.h
+++ b/arch/x86/include/asm/nospec-branch.h
@@ -310,7 +310,7 @@ static __always_inline void mds_user_cle
*
* Clear
No callers left that have already disabled RCU.
Signed-off-by: Peter Zijlstra (Intel)
---
kernel/time/tick-broadcast-hrtimer.c | 29 -
1 file changed, 12 insertions(+), 17 deletions(-)
--- a/kernel/time/tick-broadcast-hrtimer.c
+++ b/kernel/time/tick-broadcast
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)
---
include
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
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
() leaves .noinstr.text section
Signed-off-by: Peter Zijlstra (Intel)
---
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/x86/include/asm/shared/io.h
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)
---
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
@@ -17,7 +17,7 @@ static int __cpuidle
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)
---
arch/arm64/kernel/smp.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/arm64/ke
All callers should still have RCU enabled.
Signed-off-by: Peter Zijlstra (Intel)
---
kernel/cpu_pm.c |9 -
1 file changed, 9 deletions(-)
--- a/kernel/cpu_pm.c
+++ b/kernel/cpu_pm.c
@@ -30,16 +30,9 @@ static int cpu_pm_notify(enum cpu_pm_eve
{
int ret
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
Current rcu_idle_exit() is terminally broken because it uses
local_irq_{save,restore}(), which are traced which uses RCU.
However, now that all the callers are sure to have IRQs disabled, we
can remove these calls.
Signed-off-by: Peter Zijlstra (Intel)
Acked-by: Paul E. McKenney
---
kernel
to __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
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
Hi All! (omg so many)
These here few patches mostly clear out the utter mess that is cpuidle vs
rcuidle.
At the end of the ride there's only 2 real RCU_NONIDLE() users left
arch/arm64/kernel/suspend.c:RCU_NONIDLE(__cpu_suspend_exit());
drivers/perf/arm_pmu.c:
1 - 100 of 198 matches
Mail list logo
