mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Josh Poimboeuf <jpoimboe@kernel.org>
To: Andrew Cooper <Andrew.Cooper3@citrix.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	"sfr@canb.auug.org.au" <sfr@canb.auug.org.au>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"jgross@suse.com" <jgross@suse.com>,
	"sstabellini@kernel.org" <sstabellini@kernel.org>,
	"boris.ostrovsky@oracle.com" <boris.ostrovsky@oracle.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: objtool warning for next-20221118
Date: Wed, 23 Nov 2022 18:39:34 -0800	[thread overview]
Message-ID: <20221124023934.nft3udxelth4lvai@treble> (raw)
In-Reply-To: <20221123170337.keacggyvn4ykbtsw@treble>

On Wed, Nov 23, 2022 at 09:03:40AM -0800, Josh Poimboeuf wrote:
> On Wed, Nov 23, 2022 at 10:52:09AM +0000, Andrew Cooper wrote:
> > > Well, if you return from arch_cpu_idle_dead() you're back in the idle
> > > loop -- exactly where you would be if you were to bootstrap the whole
> > > CPU -- provided you have it remember the whole state (easier with a
> > > vCPU).
> 
> play_dead() really needs sane semantics.  Not only does it introduce a
> surprise to the offlining code in do_idle(), it also skips the entire
> hotplug state machine.  Not sure if that introduces any bugs, but at the
> very least it's subtle and surprising.
> 
> > > But maybe I'm missing something, lets add Xen folks on.
> > 
> > Calling VCPUOP_down on oneself always succeeds, but all it does is
> > deschedule the vCPU.
> > 
> > It can be undone at a later point by a different vcpu issuing VCPUOP_up
> > against the previously-downed CPU, at which point the vCPU gets rescheduled.
> > 
> > This is why the VCPUOP_down hypercall returns normally.  All state
> > really is intact.
> > 
> > As for what Linux does, this is how xen_pv_cpu_up() currently behaves. 
> > If you want to make Xen behave more everything else, then bug a BUG()
> > after VCPUOP_down, and adjust xen_pv_cpu_up() to skip its initialised
> > check and always use VCPUOP_initialise to bring the vCPU back online.
> 
> Or we could do what sev_es_play_dead() does and just call start_cpu0()
> after the hypercall returns?

Something like so (untested).  This is only the x86 bits.

I think I convinced myself that start_cpu0() isn't buggy.  I'm looking
at other cleanups, e.g. converging cpu_bringup_and_idle() with
start_secondary().

I can pick it up again next week, post-turkey.

diff --git a/arch/x86/include/asm/smp.h b/arch/x86/include/asm/smp.h
index b4dbb20dab1a..e6d1d2810e38 100644
--- a/arch/x86/include/asm/smp.h
+++ b/arch/x86/include/asm/smp.h
@@ -93,9 +93,10 @@ static inline void __cpu_die(unsigned int cpu)
 	smp_ops.cpu_die(cpu);
 }
 
-static inline void play_dead(void)
+static inline void __noreturn play_dead(void)
 {
 	smp_ops.play_dead();
+	BUG();
 }
 
 static inline void smp_send_reschedule(int cpu)
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 26e8f57c75ad..8e2841deb1eb 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -700,7 +700,7 @@ EXPORT_SYMBOL(boot_option_idle_override);
 static void (*x86_idle)(void);
 
 #ifndef CONFIG_SMP
-static inline void play_dead(void)
+static inline void __noreturn play_dead(void)
 {
 	BUG();
 }
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 55cad72715d9..d8b12ac1a7c5 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -1833,9 +1833,12 @@ void native_play_dead(void)
 	play_dead_common();
 	tboot_shutdown(TB_SHUTDOWN_WFS);
 
-	mwait_play_dead();	/* Only returns on failure */
+	mwait_play_dead();	/* Only returns if mwait is not supported */
+
 	if (cpuidle_play_dead())
 		hlt_play_dead();
+
+	BUG();
 }
 
 #else /* ... !CONFIG_HOTPLUG_CPU */
diff --git a/arch/x86/xen/smp_pv.c b/arch/x86/xen/smp_pv.c
index 480be82e9b7b..30dc904ca990 100644
--- a/arch/x86/xen/smp_pv.c
+++ b/arch/x86/xen/smp_pv.c
@@ -385,17 +385,9 @@ static void xen_pv_play_dead(void) /* used only with HOTPLUG_CPU */
 {
 	play_dead_common();
 	HYPERVISOR_vcpu_op(VCPUOP_down, xen_vcpu_nr(smp_processor_id()), NULL);
-	cpu_bringup();
-	/*
-	 * commit 4b0c0f294 (tick: Cleanup NOHZ per cpu data on cpu down)
-	 * clears certain data that the cpu_idle loop (which called us
-	 * and that we return from) expects. The only way to get that
-	 * data back is to call:
-	 */
-	tick_nohz_idle_enter();
-	tick_nohz_idle_stop_tick_protected();
 
-	cpuhp_online_idle(CPUHP_AP_ONLINE_IDLE);
+	/* FIXME: converge cpu_bringup_and_idle() and start_secondary() */
+	cpu_bringup_and_idle();
 }
 
 #else /* !CONFIG_HOTPLUG_CPU */
diff --git a/include/linux/cpu.h b/include/linux/cpu.h
index 314802f98b9d..7fbbd1572288 100644
--- a/include/linux/cpu.h
+++ b/include/linux/cpu.h
@@ -185,7 +185,7 @@ void arch_cpu_idle(void);
 void arch_cpu_idle_prepare(void);
 void arch_cpu_idle_enter(void);
 void arch_cpu_idle_exit(void);
-void arch_cpu_idle_dead(void);
+void __noreturn arch_cpu_idle_dead(void);
 
 int cpu_report_state(int cpu);
 int cpu_check_up_prepare(int cpu);
diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c
index f26ab2675f7d..097afe98e53e 100644
--- a/kernel/sched/idle.c
+++ b/kernel/sched/idle.c
@@ -71,7 +71,7 @@ static noinline int __cpuidle cpu_idle_poll(void)
 void __weak arch_cpu_idle_prepare(void) { }
 void __weak arch_cpu_idle_enter(void) { }
 void __weak arch_cpu_idle_exit(void) { }
-void __weak arch_cpu_idle_dead(void) { }
+void __weak __noreturn arch_cpu_idle_dead(void) { BUG(); }
 void __weak arch_cpu_idle(void)
 {
 	cpu_idle_force_poll = 1;

  reply	other threads:[~2022-11-24  2:39 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-21  4:07 Paul E. McKenney
2022-11-21 11:31 ` Peter Zijlstra
2022-11-21 14:52   ` Paul E. McKenney
2022-11-22  5:16     ` Josh Poimboeuf
2022-11-22  8:35       ` Peter Zijlstra
2022-11-23  0:22         ` Paul E. McKenney
2022-11-23  1:48           ` Josh Poimboeuf
2022-11-23 17:49             ` Paul E. McKenney
2022-11-23 18:19               ` Josh Poimboeuf
2022-11-23 19:12                 ` Paul E. McKenney
2022-11-23 22:32                   ` Josh Poimboeuf
2022-11-23 23:06                     ` Paul E. McKenney
2023-01-28 19:06                       ` Paul E. McKenney
2023-02-01  0:02                         ` Josh Poimboeuf
2023-02-01  0:33                           ` Paul E. McKenney
2023-02-01  4:21                             ` Paul E. McKenney
2022-11-23  1:23         ` Josh Poimboeuf
2022-11-23  8:55           ` Peter Zijlstra
2022-11-23 10:52             ` Andrew Cooper
2022-11-23 17:03               ` Josh Poimboeuf
2022-11-24  2:39                 ` Josh Poimboeuf [this message]
2022-11-24  5:28                   ` Juergen Gross
2022-11-24  7:47                     ` Juergen Gross
2022-11-24 16:39                       ` Josh Poimboeuf
2022-11-25  5:30                         ` Juergen Gross
2022-11-29 19:56                           ` Paul E. McKenney
2022-12-02  0:27                             ` Paul E. McKenney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20221124023934.nft3udxelth4lvai@treble \
    --to=jpoimboe@kernel.org \
    --cc=Andrew.Cooper3@citrix.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=jgross@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=sfr@canb.auug.org.au \
    --cc=sstabellini@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®