From: Qian Cai <cai@lca.pw>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Linux PM <linux-pm@vger.kernel.org>,
Len Brown <len.brown@intel.com>,
LKML <linux-kernel@vger.kernel.org>,
Zhang Rui <rui.zhang@intel.com>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Chen Yu <yu.c.chen@intel.com>,
clang-built-linux@googlegroups.com
Subject: Re: [PATCH 3/9] intel_idle: Relocate definitions of cpuidle callbacks
Date: Fri, 22 May 2020 20:04:27 -0400 [thread overview]
Message-ID: <20200523000427.GF1337@Qians-MacBook-Air.local> (raw)
In-Reply-To: <2912140.PDVJEUYNKe@kreacher>
On Thu, Feb 13, 2020 at 11:00:26PM +0100, Rafael J. Wysocki wrote:
> From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
>
> Move the definitions of intel_idle() and intel_idle_s2idle() before
> the definitions of cpuidle_state structures referring to them to
> avoid having to use additional declarations of them (and drop those
> declarations).
>
> No functional impact.
>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
> drivers/idle/intel_idle.c | 154 ++++++++++++++++++++++------------------------
> 1 file changed, 75 insertions(+), 79 deletions(-)
>
> diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c
> index 5adc058c705d..e0332d567735 100644
> --- a/drivers/idle/intel_idle.c
> +++ b/drivers/idle/intel_idle.c
[]
> +/**
> + * intel_idle - Ask the processor to enter the given idle state.
> + * @dev: cpuidle device of the target CPU.
> + * @drv: cpuidle driver (assumed to point to intel_idle_driver).
> + * @index: Target idle state index.
> + *
> + * Use the MWAIT instruction to notify the processor that the CPU represented by
> + * @dev is idle and it can try to enter the idle state corresponding to @index.
> + *
> + * If the local APIC timer is not known to be reliable in the target idle state,
> + * enable one-shot tick broadcasting for the target CPU before executing MWAIT.
> + *
> + * Optionally call leave_mm() for the target CPU upfront to avoid wakeups due to
> + * flushing user TLBs.
> + *
> + * Must be called under local_irq_disable().
> + */
> +static __cpuidle int intel_idle(struct cpuidle_device *dev,
> + struct cpuidle_driver *drv, int index)
> +{
> + struct cpuidle_state *state = &drv->states[index];
> + unsigned long eax = flg2MWAIT(state->flags);
> + unsigned long ecx = 1; /* break on interrupt flag */
> + bool uninitialized_var(tick);
This will generate an UBSAN warning because Clang could poison all
uninitialized stack variables to 0xAA due to CONFIG_INIT_STACK_ALL=y, so one
issue is that,
bool uninitialized_var(x);
would always broken on Clang like this,
[ 92.140611] UBSAN: invalid-load in drivers/idle/intel_idle.c:135:7
[ 92.143111] load of value 170 is not a valid value for type 'bool' (aka '_Bool')
[ 92.145657] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.7.0-rc6-next-20200522+ #3
[ 92.147424] Hardware name: HP ProLiant BL660c Gen9, BIOS I38 10/17/2018
[ 92.149869] Call Trace:
[ 92.149869] dump_stack+0x10b/0x17f
[ 92.149869] __ubsan_handle_load_invalid_value+0xd2/0x110
[ 92.149869] intel_idle+0x54/0xf0
[ 92.156202] cpuidle_enter_state+0x120/0x4f0
[ 92.156202] cpuidle_enter+0x5b/0xa0
[ 92.156202] call_cpuidle+0x25/0x50
[ 92.156202] do_idle+0x1eb/0x2c0
[ 92.156202] cpu_startup_entry+0x25/0x30
[ 92.156202] rest_init+0x26f/0x280
[ 92.156202] arch_call_rest_init+0x17/0x1e
[ 92.156202] start_kernel+0x598/0x633
[ 92.156202] x86_64_start_reservations+0x24/0x26
[ 92.156202] x86_64_start_kernel+0x116/0x1c1
[ 92.156202] secondary_startup_64+0xb6/0xc0
However, I am wondering if it is correct to let "tick" uninitialized to begin
with. If this condition is true,
!static_cpu_has(X86_FEATURE_ARAT) && lapic_timer_always_reliable
Then, we could in the final branch to use the uninitialized value.
if (!static_cpu_has(X86_FEATURE_ARAT) && tick)
Isn't that possible?
> + int cpu = smp_processor_id();
> +
> + /*
> + * leave_mm() to avoid costly and often unnecessary wakeups
> + * for flushing the user TLB's associated with the active mm.
> + */
> + if (state->flags & CPUIDLE_FLAG_TLB_FLUSHED)
> + leave_mm(cpu);
> +
> + if (!static_cpu_has(X86_FEATURE_ARAT) && !lapic_timer_always_reliable) {
> + /*
> + * Switch over to one-shot tick broadcast if the target C-state
> + * is deeper than C1.
> + */
> + if ((eax >> MWAIT_SUBSTATE_SIZE) & MWAIT_CSTATE_MASK) {
> + tick = true;
> + tick_broadcast_enter();
> + } else {
> + tick = false;
> + }
> + }
> +
> + mwait_idle_with_hints(eax, ecx);
> +
> + if (!static_cpu_has(X86_FEATURE_ARAT) && tick)
> + tick_broadcast_exit();
> +
> + return index;
> +}
next prev parent reply other threads:[~2020-05-23 0:04 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-13 21:58 [PATCH 0/9] intel_idle: More assorted cleanups Rafael J. Wysocki
2020-02-13 21:59 ` [PATCH 1/9] intel_idle: Simplify LAPIC timer reliability checks Rafael J. Wysocki
2020-02-13 21:59 ` [PATCH 2/9] intel_idle: Clean up definitions of cpuidle callbacks Rafael J. Wysocki
2020-02-13 22:00 ` [PATCH 3/9] intel_idle: Relocate " Rafael J. Wysocki
2020-05-23 0:04 ` Qian Cai [this message]
2020-02-13 22:01 ` [PATCH 4/9] intel_idle: Add __initdata annotations to init time variables Rafael J. Wysocki
2020-02-13 22:01 ` [PATCH 5/9] intel_idle: Annotate init time data structures Rafael J. Wysocki
2020-02-13 22:02 ` [PATCH 6/9] intel_idle: Reorder declarations of static variables Rafael J. Wysocki
2020-02-13 22:03 ` [PATCH 7/9] intel_idle: Clean up kerneldoc comments of multiple functions Rafael J. Wysocki
2020-02-13 22:03 ` [PATCH 8/9] intel_idle: Define CPUIDLE_FLAG_TLB_FLUSHED as BIT(16) Rafael J. Wysocki
2020-02-13 22:04 ` [PATCH 9/9] intel_idle: Update copyright notice, known limitations and version Rafael J. Wysocki
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=20200523000427.GF1337@Qians-MacBook-Air.local \
--to=cai@lca.pw \
--cc=clang-built-linux@googlegroups.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=rjw@rjwysocki.net \
--cc=rui.zhang@intel.com \
--cc=yu.c.chen@intel.com \
/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;
as well as URLs for NNTP newsgroup(s).