Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp6643454pxv; Thu, 29 Jul 2021 21:34:01 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxEJOckMM2u3CTZo4Pmm1sfHP/3kib1FbttetSGsfFpQ84ly1V4QRTXvAkPhW7QYtoXgr+b X-Received: by 2002:a02:331e:: with SMTP id c30mr560113jae.94.1627619641124; Thu, 29 Jul 2021 21:34:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627619641; cv=none; d=google.com; s=arc-20160816; b=t8ljatd/PzLl7R9A/zlDkwOQ2Hfcc6370v4aeav0gHcx+9wB2SqcnKz8Yh8Y9VouH6 7yVJIZIeQIhVLZ08Vk6dEe9LyDLQS2plrWWe3pFAVgGtBdG4C8f/N/Yh+coEmef1hZf5 cixzHrdLSd1/kpTghsqK8i6lUP7qGtRJQvdJUO1BI33+gmJ1Jdcnwk/CK8aGUjlu0ENA GaL/TinO9sZWddK3fds97fkksYZJfJAvNQp6kPFRUCkfKre4/0BxItSgm3iXq5KSW1uc UndtPHAvf/KHmBX/w73h5ShbYXIHEMm/IjQ+x3RNq7eJtWbriyYsGaUnQNc1M0WmhzkA i3bg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=1YGxc1MEZ1J3AiZOt8ktcUTrqv4uRspn9Ua1lu9DTJ8=; b=SERNkVDVvzi27vYnqygtUH1a3yjjD3ymcl6rylT1ASHtfU+mVNbHW6CUiXlHy6vK6n 626Nu3W+eX/CqRAreGpKWUlSfsGa3IXMhp2MhtERd+vTr1xlMSWFTCUjITDwfDMnIiyP +armDciHgxUIW0YrQvlH5yz+pMnxX5aHwjl0nym72JWEIEPmbDE014Vr6gsLBd2fVcR0 P+a8XX2EBJjCDLCo7Veer40QyyhMvzNhMO/JIoqslzoTaNhOqEnpbl4WoxRMvtOyj55B iNSAn/LnzST5J0QG9cJNYRJg7pXeEUbSrESWmKETvKGTzDDWIqZcNrCQknPlxXYbSqvC krHA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b11si470037ile.42.2021.07.29.21.33.47; Thu, 29 Jul 2021 21:34:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229849AbhG3EdC (ORCPT + 99 others); Fri, 30 Jul 2021 00:33:02 -0400 Received: from ozlabs.ru ([107.174.27.60]:34640 "EHLO ozlabs.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229609AbhG3EdB (ORCPT ); Fri, 30 Jul 2021 00:33:01 -0400 Received: from fstn1-p1.ozlabs.ibm.com. (localhost [IPv6:::1]) by ozlabs.ru (Postfix) with ESMTP id 37EE5AE80062; Fri, 30 Jul 2021 00:32:21 -0400 (EDT) From: Alexey Kardashevskiy To: linux-kernel@vger.kernel.org Cc: Alexey Kardashevskiy , kvm@vger.kernel.org, Paolo Bonzini Subject: [RFC PATCH kernel] KVM: Stop leaking memory in debugfs Date: Fri, 30 Jul 2021 14:32:17 +1000 Message-Id: <20210730043217.953384-1-aik@ozlabs.ru> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The debugfs folder name is made of a supposedly unique pair of the process pid and a VM fd. However it is possible to get a race here which manifests in these messages: [ 471.846235] debugfs: Directory '20245-4' with parent 'kvm' already present! debugfs_create_dir() returns an error which is handled correctly everywhere except kvm_create_vm_debugfs() where the code allocates stat data structs and overwrites the older values regardless. Spotted by syzkaller. This slow memory leak produces way too many OOM reports. Signed-off-by: Alexey Kardashevskiy --- I am pretty sure we better fix the race but I am not quite sure what lock is appropriate here, ideas? --- virt/kvm/kvm_main.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 986959833d70..89496fd8127a 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -904,6 +904,10 @@ static int kvm_create_vm_debugfs(struct kvm *kvm, int fd) snprintf(dir_name, sizeof(dir_name), "%d-%d", task_pid_nr(current), fd); kvm->debugfs_dentry = debugfs_create_dir(dir_name, kvm_debugfs_dir); + if (IS_ERR_OR_NULL(kvm->debugfs_dentry)) { + pr_err("Failed to create %s\n", dir_name); + return 0; + } kvm->debugfs_stat_data = kcalloc(kvm_debugfs_num_entries, sizeof(*kvm->debugfs_stat_data), -- 2.30.2