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 X-Spam-Level: X-Spam-Status: No, score=-21.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT, USER_IN_DEF_DKIM_WL autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D1623C433E0 for ; Wed, 31 Mar 2021 02:31:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9F3A7619D2 for ; Wed, 31 Mar 2021 02:31:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233234AbhCaCbC (ORCPT ); Tue, 30 Mar 2021 22:31:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59896 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232805AbhCaCa3 (ORCPT ); Tue, 30 Mar 2021 22:30:29 -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 6E59CC06175F for ; Tue, 30 Mar 2021 19:30:29 -0700 (PDT) Received: by mail-yb1-xb4a.google.com with SMTP id y13so664287ybk.20 for ; Tue, 30 Mar 2021 19:30:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=reply-to:date:message-id:mime-version:subject:from:to:cc; bh=gQCuwGLAfsbw/UNMTMJ5GJMFsizewCkNOypdYowqK48=; b=wSryiJNO0/HtB5GXTbVL00PPqna6O7GlK+7E34vVtFEfl/ee5FOWHf36YgIP+5Kthy pcea+iq0lPtzOiZN1WlKxV81tK+ZNbYmP5nv2I6GpglqgMLax8hw7w0M6lLKSAXSVFZb Tv13wHHoE5JHQ3mUOnZRugmnalesT78gxOj/lkw0Amx4xiVXUSzHNaJ2XTEpFmk3+oqL S5cBspBO1WxvwGZnZS+WTiR7kCQR0a0SXT9N/RCNQIwnW9d0mWn0nvXrh6AvFhPkcLZd NaS1qsXm02OE9DfD3en6WKSs6Gqh0Syj+o8cTsw5AuKSaP5Oroc7NQORIsb047C4z0NL lItg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:reply-to:date:message-id:mime-version:subject :from:to:cc; bh=gQCuwGLAfsbw/UNMTMJ5GJMFsizewCkNOypdYowqK48=; b=PCjsaUZd1pYgrHxENJ2gu5fsu1BYMfkWvBcppvvTStEN4e8sVysPNIHp8eDie6zuA4 Qs9HAn6m5MXkSPUkbYC37TChV7KRCFbdYM4PRMTDSJvvCVxm1BeqvXKPYobSwWHE25Em wAMhdh2QwQEPrPFzB1pd2jL+Ifqsju89SRUcXPzN4L4La2ebMbscOCRjx6sFVAexNmJZ ZPZ0JCPDjjAxugZafzfVkVIoS4eqvbZv2/sH+SdDTtDj29K2U99yhqajT/vAyAZ48JT4 FMWgHoBiEaaFFSqqIWlzToSrNhJyhogiAvuR2CnyJvG7uxgokOsf1yMuXSpUL0z0eEyj a8Yw== X-Gm-Message-State: AOAM5308dfgLuZBgTaE5wvGcyk7ihnYzPJvZUloLo8e0DedkTf1Et3Ui ujCqP3NrniaEBcNA/MJRv2j2RW0MhjA= X-Google-Smtp-Source: ABdhPJzIBEctIXJVpThNi6OlflzTn7FgBN15h3E04Il0jjJ+PmqaPLPHYW1WqIwC6phByJXcquT8AMP5OvE= X-Received: from seanjc798194.pdx.corp.google.com ([2620:15c:f:10:6c6b:5d63:9b3b:4a77]) (user=seanjc job=sendgmr) by 2002:a25:ce13:: with SMTP id x19mr1522852ybe.235.1617157828611; Tue, 30 Mar 2021 19:30:28 -0700 (PDT) Reply-To: Sean Christopherson Date: Tue, 30 Mar 2021 19:30:23 -0700 Message-Id: <20210331023025.2485960-1-seanjc@google.com> Mime-Version: 1.0 X-Mailer: git-send-email 2.31.0.291.g576ba9dcdaf-goog Subject: [PATCH 0/2] KVM: Fix missing GFP_KERNEL_ACCOUNT usage From: Sean Christopherson To: Paolo Bonzini Cc: Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , kvm@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Fix (almost) all cases in KVM x86 where allocations that are tied to a task/VM are not correctly accounted. There are a handful of allocations in SEV code that I intentionally didn't fix in this series. I'm 95% certain those allocations can be eliminated completely, changing them in this series only to delete them seemed pointless. The allocations in questions are for structs that are used to communicate with the PSP; they are temporary (freed in the same function that does the allocation) and small (some are _tiny_, e.g. 4 bytes). AFAICT, the sole reason they are dynamically allocated is because the CCP driver uses __pa() to retrieve the physical address that is passed to the PSP, and __pa() does not work for vmalloc'd memory, which is in play when running with CONFIG_VMAP_STACKS=y. I have functional code that uses a scratch buffer as a bounce buffer to cleanly handle vmalloc'd memory in the CCP driver. I'll hopefully get that posted tomorrow. Sean Christopherson (2): KVM: Account memory allocations for 'struct kvm_vcpu' KVM: x86: Account a variety of miscellaneous allocations arch/x86/kvm/svm/nested.c | 4 ++-- arch/x86/kvm/svm/sev.c | 6 +++--- arch/x86/kvm/vmx/vmx.c | 2 +- virt/kvm/kvm_main.c | 2 +- 4 files changed, 7 insertions(+), 7 deletions(-) -- 2.31.0.291.g576ba9dcdaf-goog