Received: by 2002:a25:1104:0:0:0:0:0 with SMTP id 4csp688980ybr; Fri, 22 May 2020 17:07:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzvsjysjakKnQ/K57bs+UcyirFxvDok0QUXcVlUxlQ6YguUaosClrgXlUC7FPTB9utqnW9Z X-Received: by 2002:a50:e696:: with SMTP id z22mr4868980edm.231.1590192478127; Fri, 22 May 2020 17:07:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590192478; cv=none; d=google.com; s=arc-20160816; b=Ti3Ji2lvJV0izDxrfc7zGu7rzUMEANrmTs1ZQ3UtWuyPtX+EKWomzrGWcZ8PWaK4Rp 8jUdM5ZUiR+XM7W1gWgH7FlSVXp0v67PJFD0jKWuC27fEx+Tc8jFx213/LvMGbF0ZiMc i9QQrmutKFxq50uSyt7zIlYVYBHP+GoE3EdQU0NUQ+SZPYSnsBHnduSMmWWDWPhb+0ep e6aKuK7U0/WUOUXb1aTIEAuFmSqDjH4Ot0ff+1tJhVL/tQ/KmSEEf7VTBzQzgzcI7K1l rbRGPmwZiY16G6ppPMZhr296Cw/rssX5IWj5DBp2EVUGLved/D3zHyLQQ+wmQsYiNa/F 6rwg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=I4oTDZ0SG8/GIH3rBRxYfT2nbMLHgnXLkHQH9l1K6YU=; b=RiI7zfoKUH5l3iW7oComQqHCJjh8Fg8yAErFk5ow0hOqoCTvNOj5ebfop4giobL98X amp2UuednG2oyQefsYgREorT7jUReEzeIb8UWCNYNriKMVRudb4wA+TcuUUn+IjsxnAz wT2NKzqx09fkgneDEUrzGhw50PiCJstl7TikwmFSL9HtF3a90HeJzMZ62nigklXRoK4s zAG2xah3zJvf6edtsNFmjF4ZTDvJV2MmBVhFXJsqj65p1splF3WKBlZtDbtTbmS2sgC0 3eCZndkhRUHQ3BEjnre61g9N+CESrF3My3rMsK6k1sG9YzxsOUvhIKhnz8bV7yh0icXX iKFA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@lca.pw header.s=google header.b=bnZAzu4N; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a3si5304245eds.355.2020.05.22.17.07.18; Fri, 22 May 2020 17:07:58 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@lca.pw header.s=google header.b=bnZAzu4N; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387412AbgEWAEd (ORCPT + 99 others); Fri, 22 May 2020 20:04:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58718 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731169AbgEWAEc (ORCPT ); Fri, 22 May 2020 20:04:32 -0400 Received: from mail-qk1-x742.google.com (mail-qk1-x742.google.com [IPv6:2607:f8b0:4864:20::742]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 07B62C05BD43 for ; Fri, 22 May 2020 17:04:30 -0700 (PDT) Received: by mail-qk1-x742.google.com with SMTP id b6so12433560qkh.11 for ; Fri, 22 May 2020 17:04:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lca.pw; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=I4oTDZ0SG8/GIH3rBRxYfT2nbMLHgnXLkHQH9l1K6YU=; b=bnZAzu4NWL2RpGBJiOTgnhW2jCEDO4kCGJ8mnreKdfAoKaC6WrSt42wURXU5i9UsLZ JePMyKjwSe0VE+6ugiGdNhyAk6t3JEbONSsQnk8WV5YClGpOQscl37m6GaGlSMYOpjmE o1WA3n9doz1R2c1XlzFmgtgN0I/uucEzSuZAMc+5zIPrDdc5kHRH5/NMQ875Kkh3r7rm Ab/GaftOEy8+NPcLZmXMt4+FumMitEyQirGh7Bz8wInF0WudbHW2d4WhfTBIdHMci6dI n+1NvCJt/F1XfAbbh6emJmp5Y4DALy8yQn2r6MV/9rhtusFCvCC/x813HTRpawUkuRJD j/5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=I4oTDZ0SG8/GIH3rBRxYfT2nbMLHgnXLkHQH9l1K6YU=; b=RRreUbj6W+BWO9a7R6tdEPN5O98Bxy5pzFgK5DmoOncdk4lFOG9ZI7+fSwy98AC5mF i+O36OXV85qvd+1HkpeWp0ccqZ1le/7xgIBgh2d3QvoknkjY6vNNNb771hf/ocUV7zrI hPmquhFSb4Gb+mZSVfOKWZmuL5tGoJow58caZdEvKZWDMHhd+cyhBmuAsSX8EtuAQ7iM mKtvWAa7m9RETyvJgbnmeKZ0yrPz4F9YAsFEXU59GgPy/PmDpjBHd66WwqbeNu6Cz+Ya msyEWr2AimszbrQ5JsNQ3+vlqjKM7CJIHYHIQBKAsipt2J8nyiVZ56yce/LUTYaoOhUR sAeg== X-Gm-Message-State: AOAM532lc7NQ9doQcwLRhrjRuZr17bVlCeX12lFxYrZEBAyakojh0xA2 0tp/5LGK6cZOrGARzyJ9AW3u6Q== X-Received: by 2002:a37:bc7:: with SMTP id 190mr17264764qkl.286.1590192269906; Fri, 22 May 2020 17:04:29 -0700 (PDT) Received: from Qians-MacBook-Air.local (pool-71-184-117-43.bstnma.fios.verizon.net. [71.184.117.43]) by smtp.gmail.com with ESMTPSA id k20sm8395865qkk.30.2020.05.22.17.04.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 May 2020 17:04:29 -0700 (PDT) Date: Fri, 22 May 2020 20:04:27 -0400 From: Qian Cai To: "Rafael J. Wysocki" Cc: Linux PM , Len Brown , LKML , Zhang Rui , "Rafael J. Wysocki" , Chen Yu , clang-built-linux@googlegroups.com Subject: Re: [PATCH 3/9] intel_idle: Relocate definitions of cpuidle callbacks Message-ID: <20200523000427.GF1337@Qians-MacBook-Air.local> References: <2960689.qre192dJKD@kreacher> <2912140.PDVJEUYNKe@kreacher> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2912140.PDVJEUYNKe@kreacher> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 13, 2020 at 11:00:26PM +0100, Rafael J. Wysocki wrote: > From: "Rafael J. Wysocki" > > 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 > --- > 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; > +}