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 mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by smtp.lore.kernel.org (Postfix) with ESMTP id 63B61C433EF for ; Wed, 6 Apr 2022 17:59:11 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id B00C949EF8; Wed, 6 Apr 2022 13:59:10 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Authentication-Results: mm01.cs.columbia.edu (amavisd-new); dkim=softfail (fail, message has been altered) header.i=@google.com Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ktKIAV+zdBC; Wed, 6 Apr 2022 13:59:09 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 9C22D49EBA; Wed, 6 Apr 2022 13:59:09 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id C86CC49E20 for ; Wed, 6 Apr 2022 13:59:08 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgoz9djslRtz for ; Wed, 6 Apr 2022 13:59:07 -0400 (EDT) Received: from mail-io1-f45.google.com (mail-io1-f45.google.com [209.85.166.45]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id C71D649E1A for ; Wed, 6 Apr 2022 13:59:07 -0400 (EDT) Received: by mail-io1-f45.google.com with SMTP id h63so3857028iof.12 for ; Wed, 06 Apr 2022 10:59:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=uzEOiJ6yDVmM4HwbN1L4uOpeHV1JQRyCSJYZVvMlr1o=; b=motzZ0l4IuCGRfjFIbn/j/l6b/79dg82LGotCDSKTUlBOlU79sQkFVQlJY/zgNuuGO qrc6E+V7IDoo1WNAtR9oz02dK3FVRHsx6cwF+L0lbfMjdJbKqLzRmKJQQOFZ/18+f9Wv ywS3sVrMYOheluSEb1K9sTiCJQi1PCOVm+iFMXiGqwXKzB1W57TZgXccUUBHE71bGQif aJFn1HhosoMK2BV6YkjK9rprCz8cEHwbJgky7RalXATFkXLSHLjc4fG7u3xTBzdIurXC kyyZrWzB34DR1pRnhgCsaopxNoUTmGkQ6d0llq+91D1FtRqZAS+HSJMP4ZQUhGkhYe1h MRRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=uzEOiJ6yDVmM4HwbN1L4uOpeHV1JQRyCSJYZVvMlr1o=; b=6Ig2R8F/ytpw73X7Q0v4gn6LrICdhWYwumL3bfF0d5CaqacjU5gIDpb6POHuE8eqOb 361ZBLwQfS4dWJOhUlywIHfHrnTPTUjWkdoSjoeoA4fevxceP0bIF5gI5F5JvzgyuEOw cEFjPTFpE1QY+zuZDykbUsjw5zsLGlxL1PZM3xiJKjbucDxYefgYCHDevI2zyR1U1g1/ nvdPMlYC3UwWdEuN55/v+MbSonE7WW/6xYaSI6F1tn/C7HONiRtzanBIjqdAFHhAXZVh 5L9Z4oqochlGzAh02624ggXCzfJBpagcdTeXDXFaAnmq6nmnzUN8iud9GkMLacVdu6H6 j1wg== X-Gm-Message-State: AOAM533Xhu0bIOnQebHZ1kuofL7Agqs+3porst27DWaDW9S+k4LAaFbj W+yur4ESFIvUqeDhuwlYCq/HbQ== X-Google-Smtp-Source: ABdhPJxLKN+3WYbccJPvru/x2ek/ZrRCnqaiXkp6CDMNszfPgh1LY5ykqVNoCgkQNqIn3Xt1jtTcLA== X-Received: by 2002:a5e:c702:0:b0:64d:1640:9f8c with SMTP id f2-20020a5ec702000000b0064d16409f8cmr180542iop.176.1649267946850; Wed, 06 Apr 2022 10:59:06 -0700 (PDT) Received: from google.com (194.225.68.34.bc.googleusercontent.com. [34.68.225.194]) by smtp.gmail.com with ESMTPSA id t8-20020a056e02010800b002ca36a382c5sm6339873ilm.52.2022.04.06.10.59.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Apr 2022 10:59:06 -0700 (PDT) Date: Wed, 6 Apr 2022 17:59:02 +0000 From: Oliver Upton To: Marc Zyngier Subject: Re: [PATCH v2 1/3] KVM: Don't create VM debugfs files outside of the VM directory Message-ID: References: <20220404182119.3561025-1-oupton@google.com> <20220404182119.3561025-2-oupton@google.com> <87fsmqvgaf.wl-maz@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <87fsmqvgaf.wl-maz@kernel.org> Cc: kvm@vger.kernel.org, Peter Shier , stable@kernel.org, Paolo Bonzini , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu On Wed, Apr 06, 2022 at 08:10:00AM +0100, Marc Zyngier wrote: > Hi Oliver, > > On Mon, 04 Apr 2022 19:21:17 +0100, > Oliver Upton wrote: > > > > Unfortunately, there is no guarantee that KVM was able to instantiate a > > debugfs directory for a particular VM. To that end, KVM shouldn't even > > attempt to create new debugfs files in this case. If the specified > > parent dentry is NULL, debugfs_create_file() will instantiate files at > > the root of debugfs. > > > > For arm64, it is possible to create the vgic-state file outside of a > > VM directory, the file is not cleaned up when a VM is destroyed. > > Nonetheless, the corresponding struct kvm is freed when the VM is > > destroyed. > > > > Nip the problem in the bud for all possible errant debugfs file > > creations by initializing kvm->debugfs_dentry to -ENOENT. In so doing, > > debugfs_create_file() will fail instead of creating the file in the root > > directory. > > > > Cc: stable@kernel.org > > Fixes: 929f45e32499 ("kvm: no need to check return value of debugfs_create functions") > > Signed-off-by: Oliver Upton > > --- > > virt/kvm/kvm_main.c | 10 ++++++++-- > > 1 file changed, 8 insertions(+), 2 deletions(-) > > > > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c > > index 70e05af5ebea..04a426e65cb8 100644 > > --- a/virt/kvm/kvm_main.c > > +++ b/virt/kvm/kvm_main.c > > @@ -932,7 +932,7 @@ static void kvm_destroy_vm_debugfs(struct kvm *kvm) > > int kvm_debugfs_num_entries = kvm_vm_stats_header.num_desc + > > kvm_vcpu_stats_header.num_desc; > > > > - if (!kvm->debugfs_dentry) > > + if (!IS_ERR(kvm->debugfs_dentry)) > > return; > > Shouldn't this condition be inverted? It certainly looks odd. Err... Yep, this is plain wrong. Let me fix this obvious mistake. -- Thanks, Oliver _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id D5E6BC433F5 for ; Wed, 6 Apr 2022 18:00:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=/k9y+KRHGuM5i8ZNbSxHEovUKwBhIlE179XO6c8H8CQ=; b=sXTMnORx0SoeZj 9WFPpEdMXnjkEK1ER6a/oMQJvrP3iMmKoR57BrJlahOSAmoiFLJjCq+YjiHhJMyG8eZH5O+cr0CmM uvI/RX28sB1d/HzBau4K/sT4mjcfu8C0U7pJod8O72nTUO4sSoQ0fF3YgM4fendLHBft8DmHwkiU6 0YF4rKG0SNPqRtgF8/O1AmAfMosddWDCZbZaQTVrK8T92Ux7xCYJY8korONQErNWTlnPmtBJSo3ns PAhAFYCMUoNwpV2bdngOrp53I/PSDjzQ84mHI9GvIMQ6Hm8hFY2qtUaOMs3OfocfH1hwcOh6lwUAg UXbHawBrHAY2ZCX7Pr/Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nc9w2-007R7x-Gs; Wed, 06 Apr 2022 17:59:14 +0000 Received: from mail-io1-xd35.google.com ([2607:f8b0:4864:20::d35]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nc9vz-007R7a-RY for linux-arm-kernel@lists.infradead.org; Wed, 06 Apr 2022 17:59:13 +0000 Received: by mail-io1-xd35.google.com with SMTP id p21so3923807ioj.4 for ; Wed, 06 Apr 2022 10:59:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=uzEOiJ6yDVmM4HwbN1L4uOpeHV1JQRyCSJYZVvMlr1o=; b=motzZ0l4IuCGRfjFIbn/j/l6b/79dg82LGotCDSKTUlBOlU79sQkFVQlJY/zgNuuGO qrc6E+V7IDoo1WNAtR9oz02dK3FVRHsx6cwF+L0lbfMjdJbKqLzRmKJQQOFZ/18+f9Wv ywS3sVrMYOheluSEb1K9sTiCJQi1PCOVm+iFMXiGqwXKzB1W57TZgXccUUBHE71bGQif aJFn1HhosoMK2BV6YkjK9rprCz8cEHwbJgky7RalXATFkXLSHLjc4fG7u3xTBzdIurXC kyyZrWzB34DR1pRnhgCsaopxNoUTmGkQ6d0llq+91D1FtRqZAS+HSJMP4ZQUhGkhYe1h MRRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=uzEOiJ6yDVmM4HwbN1L4uOpeHV1JQRyCSJYZVvMlr1o=; b=QHpdqZmtNR9KS5LgAajWS+IQ5JQgvfKfP6BpRW/OXcrTBjV/CgOyJDLpExknQdWXJl gdTCcAPrZnYg/HH8D+ycuPhuTqVliCsRoHvYxWFPQT3OcBtVkJx2ofzEss9Fnb4aUR4N 4wVzAw4aktWX8qnhSHV60pd1U9m4e/OM7hAwQFJEm/NTWYiBt2pqUDaJKXFLNt3FMjB6 utfJZgWdSWPqQ/sNVP0x6oNSMJUeV/D/wmt49C1Yhpq/MUoDN3ZKGRwF20x2hrTQMzyz hPlR02TMHjgaFm6WY2017CmyzYpt+x8PLFpkCG1xj/DXFzvKvm4J8irXBBCrKQwoumr9 bwlQ== X-Gm-Message-State: AOAM5332Jsktc4qH5cJejPt05tGG+TBpub7jBjyuPSMtoEDpw8RcKQSd aRt/vltL6/oZ6zUGQOknO/DgHw== X-Google-Smtp-Source: ABdhPJxLKN+3WYbccJPvru/x2ek/ZrRCnqaiXkp6CDMNszfPgh1LY5ykqVNoCgkQNqIn3Xt1jtTcLA== X-Received: by 2002:a5e:c702:0:b0:64d:1640:9f8c with SMTP id f2-20020a5ec702000000b0064d16409f8cmr180542iop.176.1649267946850; Wed, 06 Apr 2022 10:59:06 -0700 (PDT) Received: from google.com (194.225.68.34.bc.googleusercontent.com. [34.68.225.194]) by smtp.gmail.com with ESMTPSA id t8-20020a056e02010800b002ca36a382c5sm6339873ilm.52.2022.04.06.10.59.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Apr 2022 10:59:06 -0700 (PDT) Date: Wed, 6 Apr 2022 17:59:02 +0000 From: Oliver Upton To: Marc Zyngier Cc: kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, James Morse , Alexandru Elisei , Suzuki K Poulose , linux-arm-kernel@lists.infradead.org, Peter Shier , Ricardo Koller , Reiji Watanabe , Paolo Bonzini , Sean Christopherson , stable@kernel.org Subject: Re: [PATCH v2 1/3] KVM: Don't create VM debugfs files outside of the VM directory Message-ID: References: <20220404182119.3561025-1-oupton@google.com> <20220404182119.3561025-2-oupton@google.com> <87fsmqvgaf.wl-maz@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <87fsmqvgaf.wl-maz@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220406_105912_336238_D1144707 X-CRM114-Status: GOOD ( 26.93 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Apr 06, 2022 at 08:10:00AM +0100, Marc Zyngier wrote: > Hi Oliver, > > On Mon, 04 Apr 2022 19:21:17 +0100, > Oliver Upton wrote: > > > > Unfortunately, there is no guarantee that KVM was able to instantiate a > > debugfs directory for a particular VM. To that end, KVM shouldn't even > > attempt to create new debugfs files in this case. If the specified > > parent dentry is NULL, debugfs_create_file() will instantiate files at > > the root of debugfs. > > > > For arm64, it is possible to create the vgic-state file outside of a > > VM directory, the file is not cleaned up when a VM is destroyed. > > Nonetheless, the corresponding struct kvm is freed when the VM is > > destroyed. > > > > Nip the problem in the bud for all possible errant debugfs file > > creations by initializing kvm->debugfs_dentry to -ENOENT. In so doing, > > debugfs_create_file() will fail instead of creating the file in the root > > directory. > > > > Cc: stable@kernel.org > > Fixes: 929f45e32499 ("kvm: no need to check return value of debugfs_create functions") > > Signed-off-by: Oliver Upton > > --- > > virt/kvm/kvm_main.c | 10 ++++++++-- > > 1 file changed, 8 insertions(+), 2 deletions(-) > > > > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c > > index 70e05af5ebea..04a426e65cb8 100644 > > --- a/virt/kvm/kvm_main.c > > +++ b/virt/kvm/kvm_main.c > > @@ -932,7 +932,7 @@ static void kvm_destroy_vm_debugfs(struct kvm *kvm) > > int kvm_debugfs_num_entries = kvm_vm_stats_header.num_desc + > > kvm_vcpu_stats_header.num_desc; > > > > - if (!kvm->debugfs_dentry) > > + if (!IS_ERR(kvm->debugfs_dentry)) > > return; > > Shouldn't this condition be inverted? It certainly looks odd. Err... Yep, this is plain wrong. Let me fix this obvious mistake. -- Thanks, Oliver _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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 84121C433EF for ; Wed, 6 Apr 2022 19:41:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232006AbiDFTnj (ORCPT ); Wed, 6 Apr 2022 15:43:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41830 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233453AbiDFTnG (ORCPT ); Wed, 6 Apr 2022 15:43:06 -0400 Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B2D572C49A3 for ; Wed, 6 Apr 2022 10:59:07 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id g21so3850529iom.13 for ; Wed, 06 Apr 2022 10:59:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=uzEOiJ6yDVmM4HwbN1L4uOpeHV1JQRyCSJYZVvMlr1o=; b=motzZ0l4IuCGRfjFIbn/j/l6b/79dg82LGotCDSKTUlBOlU79sQkFVQlJY/zgNuuGO qrc6E+V7IDoo1WNAtR9oz02dK3FVRHsx6cwF+L0lbfMjdJbKqLzRmKJQQOFZ/18+f9Wv ywS3sVrMYOheluSEb1K9sTiCJQi1PCOVm+iFMXiGqwXKzB1W57TZgXccUUBHE71bGQif aJFn1HhosoMK2BV6YkjK9rprCz8cEHwbJgky7RalXATFkXLSHLjc4fG7u3xTBzdIurXC kyyZrWzB34DR1pRnhgCsaopxNoUTmGkQ6d0llq+91D1FtRqZAS+HSJMP4ZQUhGkhYe1h MRRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=uzEOiJ6yDVmM4HwbN1L4uOpeHV1JQRyCSJYZVvMlr1o=; b=ZhUHa5vuSw/qaMILjO2e+w5YBGyA1eD4TdEcG8CijIoIcBQxSTkIg9vXXoQDzyji2q pvn0uezn5d5iWjV2NCrMJJIibXBb9xWkP8dvlgi9qR6jxhb4Pzr8fuVTBKCrlnmP+RPA kCOpeTHOiAZrHFstvuOPKG3wQ2TW+jLaUV4sH7EbfLeMhKPxhuhb9iFrNubT0Eg3vq+g LFi92BHjVEVpbPle9brrpg1LGI609Fyi+k0btkZUiEEcc1SXjsKEUCh0yXbOLGgE0VQU eoOP1PIa4bHDBIjYS/pwtJNCw41rqVyb8gsb9w13jB71+5370oXyHqjXb2EPOglISbr/ iuNg== X-Gm-Message-State: AOAM531Xs+lDYqDT/GYB1SMN6LXP4mzin0zolvp2F1rcD1YhQN6D/jgh ByUN0+sxUKYcuEtgNtyKd9OM1ix7zsA2/A== X-Google-Smtp-Source: ABdhPJxLKN+3WYbccJPvru/x2ek/ZrRCnqaiXkp6CDMNszfPgh1LY5ykqVNoCgkQNqIn3Xt1jtTcLA== X-Received: by 2002:a5e:c702:0:b0:64d:1640:9f8c with SMTP id f2-20020a5ec702000000b0064d16409f8cmr180542iop.176.1649267946850; Wed, 06 Apr 2022 10:59:06 -0700 (PDT) Received: from google.com (194.225.68.34.bc.googleusercontent.com. [34.68.225.194]) by smtp.gmail.com with ESMTPSA id t8-20020a056e02010800b002ca36a382c5sm6339873ilm.52.2022.04.06.10.59.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Apr 2022 10:59:06 -0700 (PDT) Date: Wed, 6 Apr 2022 17:59:02 +0000 From: Oliver Upton To: Marc Zyngier Cc: kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, James Morse , Alexandru Elisei , Suzuki K Poulose , linux-arm-kernel@lists.infradead.org, Peter Shier , Ricardo Koller , Reiji Watanabe , Paolo Bonzini , Sean Christopherson , stable@kernel.org Subject: Re: [PATCH v2 1/3] KVM: Don't create VM debugfs files outside of the VM directory Message-ID: References: <20220404182119.3561025-1-oupton@google.com> <20220404182119.3561025-2-oupton@google.com> <87fsmqvgaf.wl-maz@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87fsmqvgaf.wl-maz@kernel.org> Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Wed, Apr 06, 2022 at 08:10:00AM +0100, Marc Zyngier wrote: > Hi Oliver, > > On Mon, 04 Apr 2022 19:21:17 +0100, > Oliver Upton wrote: > > > > Unfortunately, there is no guarantee that KVM was able to instantiate a > > debugfs directory for a particular VM. To that end, KVM shouldn't even > > attempt to create new debugfs files in this case. If the specified > > parent dentry is NULL, debugfs_create_file() will instantiate files at > > the root of debugfs. > > > > For arm64, it is possible to create the vgic-state file outside of a > > VM directory, the file is not cleaned up when a VM is destroyed. > > Nonetheless, the corresponding struct kvm is freed when the VM is > > destroyed. > > > > Nip the problem in the bud for all possible errant debugfs file > > creations by initializing kvm->debugfs_dentry to -ENOENT. In so doing, > > debugfs_create_file() will fail instead of creating the file in the root > > directory. > > > > Cc: stable@kernel.org > > Fixes: 929f45e32499 ("kvm: no need to check return value of debugfs_create functions") > > Signed-off-by: Oliver Upton > > --- > > virt/kvm/kvm_main.c | 10 ++++++++-- > > 1 file changed, 8 insertions(+), 2 deletions(-) > > > > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c > > index 70e05af5ebea..04a426e65cb8 100644 > > --- a/virt/kvm/kvm_main.c > > +++ b/virt/kvm/kvm_main.c > > @@ -932,7 +932,7 @@ static void kvm_destroy_vm_debugfs(struct kvm *kvm) > > int kvm_debugfs_num_entries = kvm_vm_stats_header.num_desc + > > kvm_vcpu_stats_header.num_desc; > > > > - if (!kvm->debugfs_dentry) > > + if (!IS_ERR(kvm->debugfs_dentry)) > > return; > > Shouldn't this condition be inverted? It certainly looks odd. Err... Yep, this is plain wrong. Let me fix this obvious mistake. -- Thanks, Oliver