All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Xen-devel <xen-devel@lists.xenproject.org>,
	Jan Beulich <JBeulich@suse.com>,
	Anthony PERARD <anthony.perard@vates.tech>,
	Michal Orzel <michal.orzel@amd.com>,
	Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>
Subject: Re: [PATCH 1/6] x86/idle: Remove broken MWAIT implementation
Date: Thu, 3 Jul 2025 18:01:52 +0200	[thread overview]
Message-ID: <aGapcEcSfZHURMrL@macbook.local> (raw)
In-Reply-To: <20250702144121.1096448-2-andrew.cooper3@citrix.com>

On Wed, Jul 02, 2025 at 03:41:16PM +0100, Andrew Cooper wrote:
> cpuidle_wakeup_mwait() is a TOCTOU race.  The cpumask_and() sampling
> cpuidle_mwait_flags can take a arbitrary period of time, and there's no
> guarantee that the target CPUs are still in MWAIT when writing into
> mwait_wakeup(cpu).
> 
> The consequence of the race is that we'll fail to IPI targets.  Also, there's
> no guarantee that mwait_idle_with_hints() will raise a TIMER_SOFTIRQ on it's
> way out.
> 
> The fundamental bug is that the "in_mwait" variable needs to be in the
> monitored line in order to do this in a race-free way.

I assume in_mwait being in the same monitored line is required so that
you can do an atomic exchange and ensure the remote CPU was either in
the monitor state, or just getting out of it but before processing
softirqs when the softirq is set?

That means that a CPU getting out of mwait would also need to do an
atomic exchange to clear in_mwait and fetch the pending softirqs?

> Arranging for this while keeping the old implementation is prohibitive, so
> strip it out in order to implement the new one cleanly.  In the interim, this
> causes IPIs to be used unconditionally which is safe albeit suboptimal.
> 
> Fixes: 3d521e933e1b ("cpuidle: mwait on softirq_pending & remove wakeup ipis")
> Fixes: 1adb34ea846d ("CPUIDLE: re-implement mwait wakeup process")
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

Thanks, Roger.


  reply	other threads:[~2025-07-03 16:02 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-02 14:41 [PATCH 0/6] x86/idle: Multiple MWAIT fixes Andrew Cooper
2025-07-02 14:41 ` [PATCH 1/6] x86/idle: Remove broken MWAIT implementation Andrew Cooper
2025-07-03 16:01   ` Roger Pau Monné [this message]
2025-07-03 16:19     ` Andrew Cooper
2025-07-02 14:41 ` [PATCH 2/6] x86/idle: Convert force_mwait_ipi_wakeup to X86_BUG_MONITOR Andrew Cooper
2025-07-02 14:41 ` [PATCH 3/6] xen/softirq: Rework arch_skip_send_event_check() into arch_pend_softirq() Andrew Cooper
2025-07-03  8:11   ` Jan Beulich
2025-07-03 10:36     ` Andrew Cooper
2025-07-03 11:24       ` Jan Beulich
2025-07-03 16:21   ` Roger Pau Monné
2025-07-04  7:23     ` Jan Beulich
2025-07-04  7:55       ` Roger Pau Monné
2025-07-04  8:25         ` Jan Beulich
2025-07-04 16:00           ` Andrew Cooper
2025-07-02 14:41 ` [PATCH 4/6] x86/idle: Implement a new MWAIT IPI-elision algorithm Andrew Cooper
2025-07-03  9:01   ` Jan Beulich
2025-07-03 11:59     ` Andrew Cooper
2025-07-03 14:07       ` Jan Beulich
2025-07-03 17:29         ` Andrew Cooper
2025-07-03 16:36   ` Roger Pau Monné
2025-07-03 17:48     ` Andrew Cooper
2025-07-04  7:24       ` Roger Pau Monné
2025-07-04 16:13         ` Andrew Cooper
2025-07-04  7:52   ` Roger Pau Monné
2025-07-04 16:14     ` Andrew Cooper
2025-07-02 14:41 ` [PATCH 5/6] x86/idle: Drop incorrect smp_mb() in mwait_idle_with_hints() Andrew Cooper
2025-07-03  9:24   ` Jan Beulich
2025-07-03 12:37     ` Andrew Cooper
2025-07-03 13:30       ` Jan Beulich
2025-07-04 15:45         ` Andrew Cooper
2025-07-02 14:41 ` [PATCH 6/6] x86/idle: Fix buggy "x86/mwait-idle: enable interrupts before C1 on Xeons" Andrew Cooper
2025-07-03  9:35   ` Jan Beulich
2025-07-03  9:43   ` Jan Beulich
2025-07-03 12:10     ` Andrew Cooper
2025-07-03 13:11       ` Jan Beulich

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=aGapcEcSfZHURMrL@macbook.local \
    --to=roger.pau@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=anthony.perard@vates.tech \
    --cc=julien@xen.org \
    --cc=michal.orzel@amd.com \
    --cc=sstabellini@kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.