Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp2324582rwb; Fri, 2 Dec 2022 08:17:36 -0800 (PST) X-Google-Smtp-Source: AA0mqf5opiJuy4sf7TeLVeL4x31VHWbWnr4u3AwTHZdRWRs65ceKvxxGNxMSX+jsRvXjUqIB860I X-Received: by 2002:a17:906:698f:b0:78d:93b1:b3ba with SMTP id i15-20020a170906698f00b0078d93b1b3bamr62517671ejr.66.1669997855851; Fri, 02 Dec 2022 08:17:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669997855; cv=none; d=google.com; s=arc-20160816; b=1K4TLn8TNmNc6qqSwQ6/sKWsTwRnM97hfeIEK2bn1JMAEr6wFsBo7K7uFH3XcHhOLp pFkBvIyqKoMYp+1Vm+sIKKB0GEi3cBI1nr6wYANy1zAC+f0cyF3xKKOOfuHruj++dEvC hriiBLOsfFqPajmX1Y9Dm+Ysyget/lz5qIEjx4y0dkKdHrj4VlJ90oZ+kM1skwkr7+P7 spQv5u+BbRu3rsadlzxPPO9DsBW2qhp0mwbidCdGBxoS96ndqBzKjU1k6uZT+upG1zfE gT3xUu6OG0jqcAXnFeafHG1mFHcoD7YmvMICc08Xs3tTFaBVYorDq2Ksd2BdxUY9Y8nj 1UlA== 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=uXUuqbYPWAo0e3SfziJ9q3Uvez640/WBQSFJuuCG+jA=; b=awHkd+9HN0MhTVHBnXsC/JHaFigxJ1qUFUz3zqXCJG82DoIhYjcGlIER2OuaqhakL4 4h35GTBQ4shoOkKCVilpaYPjF2CNB5jkUPWoKQQ3XfP6PitieayHdC1tkO7zzPUBjomW hz5SxG+uNpmky4c5X8eexcJBjA0PVzBXKzX3NbnlYAdVSp8o7TYNQZ40jrs9Dhy6DjI6 UBsgAo5djKebi/uBtu/NQ7tAEraJa/6kFYmi1lICMXb+wRkSgCL3ViZzuYElQ4zAQfwa m11kEiCtX79NsowM/MCli8bfXzyfjVl0M74+qPYXPVKLazUorXiAVhOQ+5OGp+5VV6xu j2aQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=KjipsMnK; 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 hz4-20020a1709072ce400b007c0c0cb9f25si2187677ejc.3.2022.12.02.08.17.15; Fri, 02 Dec 2022 08:17:35 -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=KjipsMnK; 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 S233679AbiLBPoO (ORCPT + 82 others); Fri, 2 Dec 2022 10:44:14 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48694 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232723AbiLBPoM (ORCPT ); Fri, 2 Dec 2022 10:44:12 -0500 Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 393A1D4AF0 for ; Fri, 2 Dec 2022 07:44:10 -0800 (PST) Received: by mail-pl1-x631.google.com with SMTP id d3so4957261plr.10 for ; Fri, 02 Dec 2022 07:44:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=uXUuqbYPWAo0e3SfziJ9q3Uvez640/WBQSFJuuCG+jA=; b=KjipsMnKbBOqlmR9iEYkjoW1t+nkBJuZnixDinUZqw7JWWIxWGcuL7cN3ZoaGkrjO/ cEfYg48wEe4ZNPurP83hila+K8klWIcJ1bO+ATwT/5EnivKUTZHKHIPv1Jg0Rh3+Yp9S 2M7wmP3U3PFF+1vwZvNAdgY3Hd4NwdT/Jyh2HRunQFk4Tqm6ZXGF0N99icZtSOI3NczZ qZSYmdQQclv1Hmh+57Y/a1+hsPl+WJi2j1fqq98S6UcYaktFoenD+71UAdIyAVHAreJt NIOyxjEQI1ialks3HJ5R/oZzmZR1nO9TousAOhXig05OiYg8YwTtvf+r0WXZHQ52/Bn6 Smpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=uXUuqbYPWAo0e3SfziJ9q3Uvez640/WBQSFJuuCG+jA=; b=gtzLcqIe6hNdfgQIdqJi/lVW7YYk16kAI/1sS6yTLYqN5iYFwHvM3urs31bIR0qLLG gfHqGyJYtvO9R1o+q0lGcCw2AnMuFCjF7ukejN90jWWn5uqGLOc29YW2M5Eq7DrTy/BZ VvYVoMKxwo4ixvE2x1/wk1p/Y5i1VnbRzTE9qysnM1Hg9dJN9cDNsD5q6bLGtTZNfbvK D+jF4nmtbXY4IlgA6l32dk7Jdg5GGpAUAf0CeHZ8ZDtDdpIy26aZqbcNSPtdPFSHaD7j 3cSkBgRU0DTLJB8FAszFIHYhkKeH5X8FUp4a//dqBgOfb8YuQa9eL4C911/NNA3v4kt/ QLjw== X-Gm-Message-State: ANoB5pmq1qq1mfvmqTMNehJ18OAQow6SePJRyy9BRdwqsj3zhcsBOe+6 vLFHRRW8visDfagoZsR1T6QfMg== X-Received: by 2002:a17:902:ab5e:b0:189:56ab:ab69 with SMTP id ij30-20020a170902ab5e00b0018956abab69mr45367903plb.106.1669995849555; Fri, 02 Dec 2022 07:44:09 -0800 (PST) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id b10-20020a170902d88a00b001868981a18esm5754075plz.6.2022.12.02.07.44.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 Dec 2022 07:44:07 -0800 (PST) Date: Fri, 2 Dec 2022 15:44:04 +0000 From: Sean Christopherson To: Vitaly Kuznetsov Cc: kvm@vger.kernel.org, Paolo Bonzini , Wanpeng Li , Jim Mattson , Maxim Levitsky , coverity-bot , linux-kernel@vger.kernel.org Subject: Re: [PATCH] KVM: x86: hyper-v: Fix 'using uninitialized value' Coverity warning Message-ID: References: <20221202105856.434886-1-vkuznets@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221202105856.434886-1-vkuznets@redhat.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, USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham 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 On Fri, Dec 02, 2022, Vitaly Kuznetsov wrote: > In kvm_hv_flush_tlb(), 'data_offset' and 'consumed_xmm_halves' variables > are used in a mutually exclusive way: in 'hc->fast' we count in 'XMM > halves' and increase 'data_offset' otherwise. Coverity discovered, that in > one case both variables are incremented unconditionally. This doesn't seem > to cause any issues as the only user of 'data_offset'/'consumed_xmm_halves' > data is kvm_hv_get_tlb_flush_entries() -> kvm_hv_get_hc_data() which also > takes into account 'hc->fast' but is still worth fixing. If those calls aren't inlined, then 32-bit Hyper-V will be "consuming" uninitialized data when pushing parameters onto the stack. It won't cause real problems, but checkers might complain. What about shoving this metadata into "struct kvm_hv_hcall" as a union? That'd help convey that the two are mutually exclusive, would provide a place to document said exclusion, and would yield a nice cleanup too by eliminating multiple params from various functions.