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 CDB94CDB483 for ; Wed, 18 Oct 2023 20:46:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232167AbjJRUqh (ORCPT ); Wed, 18 Oct 2023 16:46:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34226 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229757AbjJRUqe (ORCPT ); Wed, 18 Oct 2023 16:46:34 -0400 Received: from mail-yb1-xb4a.google.com (mail-yb1-xb4a.google.com [IPv6:2607:f8b0:4864:20::b4a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 97278FE for ; Wed, 18 Oct 2023 13:46:32 -0700 (PDT) Received: by mail-yb1-xb4a.google.com with SMTP id 3f1490d57ef6-d9a397a7c1cso10118047276.2 for ; Wed, 18 Oct 2023 13:46:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1697661991; x=1698266791; darn=vger.kernel.org; h=cc:to:from:subject:message-id:mime-version:date:reply-to:from:to:cc :subject:date:message-id:reply-to; bh=YCKlkz4R2Q6RU5vodf+rWJY1o344ijixhxmOi/luL3I=; b=K85kBLV8EULs9R1khIPPnbT9jHWvSZj2v4ju/jHnqAt7cRtCuP1qbhAal+B+JLDpsh 4DJ7Tdx26Mzfvj4R/QOQlP5gStlK+3dK9Pt4XYrDrvYjA2qPxfGW4eEkk2JPPM4wN8iT 2/ybukWxaU1eVA0pQE1P1F84XbCqd6nQtJxtOpuOuYLQmvDumXybtslxRn0DinSpPyQm t5dkqdpUFPGwjxzW2xS2V56+b3IGKDl9swAdvWCB/+ag/m6+YBbg4NUHks8T2QlbVSMQ msHtOKW2qW6GePgNDDhrRzS2/Y408gB/us4laXNg9GpkTnDDRZVaJre0ZAZzYJAVXB6M 94yA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697661991; x=1698266791; h=cc:to:from:subject:message-id:mime-version:date:reply-to :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=YCKlkz4R2Q6RU5vodf+rWJY1o344ijixhxmOi/luL3I=; b=rbxWtxsEbDGRB6/P0Ag00zLmwlWXBXjtS1iux7kMrNeO4JcYCIsBroTX0YE2+kVm7i 81ryRrxqXx0UAlVODgrHSKcf4iD/hXGsLaXLCQ3N6bulJL1pGiuiLz67YM6lkce71QD7 Nb69Pd6Tyisqjc7v8OhYtXyH+N2YeJYmIO2y+fPRm/hrO38cnvvFM6GLN9kdND5pQaWw D17MORZnG4MZBi3E4qepSS1ZA2A84msMrGrOeFFBqbMgZ2Zwrf+2aM3LWPZEsmSd7zNJ 2GBU/O1Q1YSoHtodj3nrRPjOHmvnhR8IRyJHGQnRSzMkWVbVIWFbUzaUEILb/RoGYLrS 29hw== X-Gm-Message-State: AOJu0Yyjfqsx5aWmGEdX12UUliizhUkAU2XUqWdME4hxmMYwq1v6qvF9 SP4UzlcL1owCzHvmbWUZHnwI0haRl54= X-Google-Smtp-Source: AGHT+IEvWcULir+fy3kukn4lCaSrU2SEZY1rlzQWn4K6zYhDP3EK+lSGeXZ2L94lVbOF6m7rXneINQWJqGk= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a25:76cc:0:b0:d9a:3f67:672c with SMTP id r195-20020a2576cc000000b00d9a3f67672cmr13828ybc.3.1697661991383; Wed, 18 Oct 2023 13:46:31 -0700 (PDT) Reply-To: Sean Christopherson Date: Wed, 18 Oct 2023 13:46:21 -0700 Mime-Version: 1.0 X-Mailer: git-send-email 2.42.0.655.g421f12c284-goog Message-ID: <20231018204624.1905300-1-seanjc@google.com> Subject: [PATCH 0/3] KVM: Fix KVM-owned file refcounting of KVM module(s) From: Sean Christopherson To: Sean Christopherson , Paolo Bonzini Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Al Viro , David Matlack Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Clean up a KVM module refcounting mess that Al pointed out in the context of the guest_memfd series. The worst behavior was recently introduced by an ill-fated attempt to fix a bug in x86's async #PF code. Instead of fixing the underlying bug of not flushing a workqueue (see patch 2), KVM fudged around the bug by gifting every VM a reference to the KVM module. That made the reproducer happy (hopefully there was actually a reproducer at one point), but it didn't fully fix the use-after-free bug, it just made the bug harder to hit. E.g. as pointed out by Al, if kvm_destroy_vm() is preempted after putting the last KVM module reference, KVM can be unloaded before kvm_destroy_vm() completes, and scheduling back in the associated task will explode (preemption isn't strictly required, it's just the most obvious path to failure). Then after applying that "fix", we/I made an even bigger goof by relying on the nonexistent "protection" provided by the VM's reference and removed the code which guaranteed that the KVM module would be pinned until *after* the last reference to a KVM-owned file was put. Undo the mess we created and fix the original async #PF workqueue bug. Sean Christopherson (3): KVM: Set file_operations.owner appropriately for all such structures KVM: Always flush async #PF workqueue when vCPU is being destroyed Revert "KVM: Prevent module exit until all VMs are freed" arch/x86/kvm/debugfs.c | 1 + virt/kvm/async_pf.c | 15 ++++++++++++--- virt/kvm/kvm_main.c | 18 ++++++++---------- 3 files changed, 21 insertions(+), 13 deletions(-) base-commit: 437bba5ad2bba00c2056c896753a32edf80860cc -- 2.42.0.655.g421f12c284-goog