Received: by 2002:a05:6a10:7420:0:0:0:0 with SMTP id hk32csp1515008pxb; Fri, 18 Feb 2022 09:17:45 -0800 (PST) X-Google-Smtp-Source: ABdhPJwyjcYnWRkzPRSRqQuiLgHHXerMeZIEU+v2Qm/Nuyeuc28B7jfB/6yKRE4Y7FizdYXVeRCo X-Received: by 2002:a17:906:aad7:b0:6cc:c9aa:d9ad with SMTP id kt23-20020a170906aad700b006ccc9aad9admr7367780ejb.726.1645204665506; Fri, 18 Feb 2022 09:17:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1645204665; cv=none; d=google.com; s=arc-20160816; b=OTG1TneC6aavKbjJ0TfRAkGboLangG7M4simsc+eZXU13sx5Ewwpe4uBLoTcirJFbv YIdB/0CY4T/Dr2EPX8PMdieR6FVyDAB5YAlkYwUv9SGLOcCP136Gh93sLuRZ1BIU0L04 WaSjXSYs9VoCIsi6w1U4Ky+wCqbLyYDaWUgym9vFQVsUKGEDCWRuRb0G6DLOuoOWJeQJ KZOUXwhjE2JrF8nOQ+wGmuy1omXM3XF91wTU0dhA3ZxNMN+LSbVzQiB8VajI2IbWflcJ M1jRKQ03qgR2aW9j4ZLNxb7ukmZoM2y5hJw/NYksK9zXJIRw/tbT/OzLGeBqdQhn0atH mpJg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=HAYrDphdekGq8Y2YdxSlByL5fP4/mKHO4xQXVEQlRIA=; b=fRHvTr8h/a3igqzcTEczF1iXxdoyBWsp/xJiOeX5mBat23fIjSTsn/a2TfLk8jlzGd geKRl6jgPO/tmVmkUvxSBOXE8pZ5Wmv/3RDtUdKNXfg9ktq3KSpuAV6pI+dFXwhH49sJ EwlZ3rLL7YNQhn2z9Ah+A44Im3GF6IcFf2RdZmEMGBHLJifkbNNb2tVGjjPNxsh3F+9o vAkSo9dWF3KpbrVY3OH3e2R+w9U57esYQdSz32wue53COIAw7VMHRefs5pq/5QPyB91L QlyM8lZDH32FzwLSnTJX0qZNVf7eWHBvKOyDvN8Lw6vMzl92WUKK0etjfgVuQN4YKLYI sWoQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=WtOl1Gg2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id e13si7907466edz.46.2022.02.18.09.17.21; Fri, 18 Feb 2022 09:17:45 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=WtOl1Gg2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237508AbiBRQKq (ORCPT + 99 others); Fri, 18 Feb 2022 11:10:46 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:48056 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237493AbiBRQKp (ORCPT ); Fri, 18 Feb 2022 11:10:45 -0500 Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8D33F105AAA for ; Fri, 18 Feb 2022 08:10:28 -0800 (PST) Received: by mail-pg1-x533.google.com with SMTP id 139so8292245pge.1 for ; Fri, 18 Feb 2022 08:10:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=HAYrDphdekGq8Y2YdxSlByL5fP4/mKHO4xQXVEQlRIA=; b=WtOl1Gg29/RXqP6+l0OXUA7jj3EGFt3yNmclK999v8XN6uBArMXVClQ5BwJBGv27IT BGn5tyTnaQM8s8Qt0IZ8zzJS53z8duXCnHVMmXMw0O1+eMscP65VAWsOENGj/inhp5OX 9XBhFpnpSCPLMN57fyFbWCoLfruG34fNyaahsdlRtnAUzM3nNq3twp27QmFVPCpfUtgE UrzW9dtFrptd+xjnw0PsjCJDIKKnP569LFbWwej8zp3ObBjJshq3lJhweZSBAAIncxrp JcegXpKPzjQqLOyNPkT4/G76KEAzNhs744LP+1r+cdV7yKCv/aSyCTBnTNlcHe0WkE34 /4bQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=HAYrDphdekGq8Y2YdxSlByL5fP4/mKHO4xQXVEQlRIA=; b=oERm8L+y6WBhwjMn1JpeWVMJuqEezESc2MCkVAgzsQZ/d102Jh9/qO5py90pXtzccH 3/tJckmfe8iToXiJ3pzVNkODbsrTRqNHCmthMFCQiGHHDmeg/mxL2qR6T/PWVZdjvCoY JGNDfDCILsdAo7dsxvf/v00GQCi+M0PUiTU/F0Nz4aRyVA2oVb7nQzIWGPfIOZUC+tJF 9AoAyVOuzdf1kaoxlwXHctK9L8EQfi/ifn6/TlBttQkcAPY05fgUQGQfDIjeAwr6PngW H7nCD1O6SmdlIq0eBh0kc3AUJTFXut63hYScm5tu7M9FefTKLmFnja25zq+XSSHe43w9 1mzw== X-Gm-Message-State: AOAM532iw0nTTTv4WAMevpYBzmri1XEFd+8zEfP9AJhIs1NC63B1UTBs o9YKXwgvqnIp/S00eciQCWZWRA== X-Received: by 2002:a63:5911:0:b0:36c:4394:5bfa with SMTP id n17-20020a635911000000b0036c43945bfamr6763463pgb.519.1645200627893; Fri, 18 Feb 2022 08:10:27 -0800 (PST) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id x5sm5130665pjr.37.2022.02.18.08.10.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Feb 2022 08:10:27 -0800 (PST) Date: Fri, 18 Feb 2022 16:10:23 +0000 From: Sean Christopherson To: Peng Hao Cc: pbonzini@redhat.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/4] x86/kvm: remove a redundant variable Message-ID: References: <20220218110747.11455-1-flyingpeng@tencent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220218110747.11455-1-flyingpeng@tencent.com> X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Similar comments to the other patch. "KVM: VMX:" for the scope, and a more descriptive shortlog. Also, this patch isn't part of a series, it should be simply "PATCH", not "patch 1/4". On Fri, Feb 18, 2022, Peng Hao wrote: > variable 'cpu' is defined repeatedly. The changelog should make it clear why it's ok to remove the redundant variable. E.g. KVM: VMX: Remove scratch 'cpu' variable that shadows an identical scratch var Remove a redundant 'cpu' declaration from inside an if-statement that that shadows an identical declaration at function scope. Both variables are used as scratch variables in for_each_*_cpu() loops, thus there's no harm in sharing a variable. With that, Reviewed-by: Sean Christopherson > Signed-off-by: Peng Hao > --- > arch/x86/kvm/vmx/vmx.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c > index ba66c171d951..6101c2980a9c 100644 > --- a/arch/x86/kvm/vmx/vmx.c > +++ b/arch/x86/kvm/vmx/vmx.c > @@ -7931,7 +7931,6 @@ static int __init vmx_init(void) > ms_hyperv.hints & HV_X64_ENLIGHTENED_VMCS_RECOMMENDED && > (ms_hyperv.nested_features & HV_X64_ENLIGHTENED_VMCS_VERSION) >= > KVM_EVMCS_VERSION) { > - int cpu; > > /* Check that we have assist pages on all online CPUs */ > for_each_online_cpu(cpu) { > -- > 2.27.0 >