From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id AE855C43334 for ; Mon, 11 Jul 2022 23:28:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230283AbiGKX21 (ORCPT ); Mon, 11 Jul 2022 19:28:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48118 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231608AbiGKX2Y (ORCPT ); Mon, 11 Jul 2022 19:28:24 -0400 Received: from mail-pl1-x64a.google.com (mail-pl1-x64a.google.com [IPv6:2607:f8b0:4864:20::64a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 662C78AB1F for ; Mon, 11 Jul 2022 16:28:16 -0700 (PDT) Received: by mail-pl1-x64a.google.com with SMTP id c18-20020a170903235200b0016c37f6d48cso4016487plh.19 for ; Mon, 11 Jul 2022 16:28:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=reply-to:date:in-reply-to:message-id:mime-version:references :subject:from:to:cc; bh=l1YVI1jymWKPwtQYaErfNq6OCrckplvwfXfah/8A/rc=; b=SVmaSc+lEZoy1vyMnxQkmZX7Wb3FG6N+CBqp55C3XwrUZ33I51/VK8pLmMruirVuhl z+Mxx1RY+uXt8Nj17/lLRC/NMw6LZlLUmrjDVupkRHj52stwdyergUPLjOnoeiM1Bhw1 JyUdkak654zIqYhT1QsApidufgOzzlNHcW9pGtbuQKv6mU5pWGmx+dFYm19CXpOpZt9B wLFC4Ykc9rohW/Q4YHFEpyMN/CencJi4JOKSdSQkLa5C688mjx8lTKrwZSTGM3FSgAl6 1+Ppb7K6Dx4e2fPDH3isw/w9weHrROniS6nUzTv8XOEPRLqIXEZf7ES5nhlyAeckGmES BMZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:reply-to:date:in-reply-to:message-id :mime-version:references:subject:from:to:cc; bh=l1YVI1jymWKPwtQYaErfNq6OCrckplvwfXfah/8A/rc=; b=UBlMu8kNHx+Px4VqDdWdY/+IZIFdSxRqh1S4HlEWTK4zZF7227Wp8p9NPbP5DMNIHF 92GOsLPp4zz5m9PywosczkF0YyzsCahhrncwLHVxjVHOeKRTzmO0qn5SxAeOExVuqQf1 AHsULWU707NJ9T35ZzVX53TomdxIuhIGdxloBFm7HosSYhCJZEzncdZG9//Jp9HaTZOA +8iJY6BpV13gRM+LuREhVc4wVg15KOOg/6SC9CF9V6pwcHD402LftC2RNZevqxMpe7OK Ztlb85cAKWidWtr91X+LaLi6gxZAkqAZuUGPKuUX+RJ5X191HhLIP+lOjtpUCcd9SAIc sfuw== X-Gm-Message-State: AJIora+EcXn6okF5rKCay4pN9+z0QgHCLTDc/hI/eA1QvanbcfBHaU/r MEmrAhWLhnsxfOIdod/8h6f+eieBYvw= X-Google-Smtp-Source: AGRyM1v0IgBIRDYDSdN+eimreeKt668f69l4v8Y/nJf+NT6IYH6M7hCBXRbqo0rXXs5/PS7XjbVfSNZUSjU= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:90a:474c:b0:1ec:f898:d85b with SMTP id y12-20020a17090a474c00b001ecf898d85bmr895865pjg.11.1657582095847; Mon, 11 Jul 2022 16:28:15 -0700 (PDT) Reply-To: Sean Christopherson Date: Mon, 11 Jul 2022 23:27:50 +0000 In-Reply-To: <20220711232750.1092012-1-seanjc@google.com> Message-Id: <20220711232750.1092012-4-seanjc@google.com> Mime-Version: 1.0 References: <20220711232750.1092012-1-seanjc@google.com> X-Mailer: git-send-email 2.37.0.144.g8ac04bfd2-goog Subject: [PATCH 3/3] KVM: x86: WARN only once if KVM leaves a dangling userspace I/O request From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, syzbot+760a73552f47a8cd0fd9@syzkaller.appspotmail.com, Tetsuo Handa , Hou Wenlong Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Change a WARN_ON() to separate WARN_ON_ONCE() if KVM has an outstanding PIO or MMIO request without an associated callback, i.e. if KVM queued a userspace I/O exit but didn't actually exit to userspace before moving on to something else. Warning on every KVM_RUN risks spamming the kernel if KVM gets into a bad state. Opportunistically split the WARNs so that it's easier to triage failures when a WARN fires. Deliberately do not use KVM_BUG_ON(), i.e. don't kill the VM. While the WARN is all but guaranteed to fire if and only if there's a KVM bug, a dangling I/O request does not present a danger to KVM (that flag is truly truly consumed only in a single emulator path), and any such bug is unlikely to be fatal to the VM (KVM essentially failed to do something it shouldn't have tried to do in the first place). In other words, note the bug, but let the VM keep running. Signed-off-by: Sean Christopherson --- arch/x86/kvm/x86.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 567d13405445..50dc55996416 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -10847,8 +10847,10 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu) r = cui(vcpu); if (r <= 0) goto out; - } else - WARN_ON(vcpu->arch.pio.count || vcpu->mmio_needed); + } else { + WARN_ON_ONCE(vcpu->arch.pio.count); + WARN_ON_ONCE(vcpu->mmio_needed); + } if (kvm_run->immediate_exit) { r = -EINTR; -- 2.37.0.144.g8ac04bfd2-goog