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 C2EA8C433EF for ; Mon, 4 Apr 2022 17:57:23 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 4CB754B2AB; Mon, 4 Apr 2022 13:57:23 -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 PuLD8Lfpe3yL; Mon, 4 Apr 2022 13:57:22 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 340D64B156; Mon, 4 Apr 2022 13:57:22 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 5B1D749F55 for ; Mon, 4 Apr 2022 13:57:21 -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 Fp0J14Zvtns9 for ; Mon, 4 Apr 2022 13:57:20 -0400 (EDT) Received: from mail-il1-f181.google.com (mail-il1-f181.google.com [209.85.166.181]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 4045D49EE4 for ; Mon, 4 Apr 2022 13:57:20 -0400 (EDT) Received: by mail-il1-f181.google.com with SMTP id x9so7458295ilc.3 for ; Mon, 04 Apr 2022 10:57:20 -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=GmQMDW9Kl2RXHFpra8Cb+yFdRaCEgtk0WeuxWIun/PE=; b=T/YID3m7jqfMsZdI5yipTxP6mq1tBCIPkkaeRZEOGXJXCRTNAVRLgO6d3oGPKiaIsM hB1IuYXuYvxwGnm/jAntlYOH177EGDJShNXiQsKuSX5zmuTfztgeEwn8fCn3X5foUENF tSPmbGrEqNTLnjaKU1LnFelmOozabOJ/CJhjHjgSpIDgJsIVglglRlphqOF6I5tZB4fN RjXIJozATO4FyKzOy/3PbchB4/uuHz062rsh7sbqfMMWRA2/+03t3OuXgIyBsGiXxQuP s6lHlTJrjRufZd9tiwr5+a8oqSI3d98djdhUvx2xfaAT94UiQ2BSWSf8Or0aJ0TjXzUY Cssw== 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=GmQMDW9Kl2RXHFpra8Cb+yFdRaCEgtk0WeuxWIun/PE=; b=Hq88tu4Hgew4AhKK0M7mK1Cjpu3cEkHTIJ54LL6LsTwSKWy1U1WJ3EgBjzZzmmfUq/ mP4fYvDT0Zo6HouTaDqM0l0xft1Uhd9RVi8e/c/6wFt8Vn1JeM8S0EZO67JR7JEcXDdI 8dhVP1cB0ExG77JEmOoaDilANUe/ijnuVG1fd8Sy8kcrGwAGKiQ1H00zC/MrO/1Rl7oT bwzDmiyXKvFNxTt2+n8bQhwCCgSUfkJgIOPtnFqyxmwAvKZyzJpKwBS2D1B1W5RJoBpR IJnjXtz1/8y2iWrDYNLPgmgIC2bI0zInZHY4bG2wjuNXV3XORKqAfc/U3oTWwYZbc5IK xakQ== X-Gm-Message-State: AOAM5338EKYiDPa/cyYJm0aCaDRw9nd6tFVBjT470bHZ8bQsnByQGq8j UJI6cMCdhJkatVWMpE8Cu5o7fw== X-Google-Smtp-Source: ABdhPJyxcxrXm46aKYYcD84LuHXVzCCX7Rui8hCXMmO19c75bw55+ZX3BLOKGyUKxAuIXD3PlAjPvg== X-Received: by 2002:a92:3405:0:b0:2c8:70ad:fa86 with SMTP id b5-20020a923405000000b002c870adfa86mr483750ila.268.1649095039360; Mon, 04 Apr 2022 10:57:19 -0700 (PDT) Received: from google.com (194.225.68.34.bc.googleusercontent.com. [34.68.225.194]) by smtp.gmail.com with ESMTPSA id d15-20020a92d78f000000b002ca4c409d1asm1036438iln.83.2022.04.04.10.57.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Apr 2022 10:57:18 -0700 (PDT) Date: Mon, 4 Apr 2022 17:57:14 +0000 From: Oliver Upton To: Sean Christopherson Subject: Re: [PATCH 2/4] KVM: Only log about debugfs directory collision once Message-ID: References: <20220402174044.2263418-1-oupton@google.com> <20220402174044.2263418-3-oupton@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Cc: kvm@vger.kernel.org, Marc Zyngier , 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 Hi Sean, On Mon, Apr 04, 2022 at 05:33:29PM +0000, Sean Christopherson wrote: > On Sat, Apr 02, 2022, Oliver Upton wrote: > > In all likelihood, a debugfs directory name collision is the result of a > > userspace bug. If userspace closes the VM fd without releasing all > > references to said VM then the debugfs directory is never cleaned. > > > > Even a ratelimited print statement can fill up dmesg, making it > > particularly annoying for the person debugging what exactly went wrong. > > Furthermore, a userspace that wants to be a nuisance could clog up the > > logs by deliberately holding a VM reference after closing the VM fd. > > > > Dial back logging to print at most once, given that userspace is most > > likely to blame. Leave the statement in place for the small chance that > > KVM actually got it wrong. > > > > Cc: stable@kernel.org > > Fixes: 85cd39af14f4 ("KVM: Do not leak memory for duplicate debugfs directories") > > I don't think this warrants Cc: stable@, the whole point of ratelimiting printk is > to guard against this sort of thing. If a ratelimited printk can bring down the > kernel and/or logging infrastructure, then the kernel is misconfigured for the > environment. Good point. > > Signed-off-by: Oliver Upton > > --- > > virt/kvm/kvm_main.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c > > index 69c318fdff61..38b30bd60f34 100644 > > --- a/virt/kvm/kvm_main.c > > +++ b/virt/kvm/kvm_main.c > > @@ -959,7 +959,7 @@ static int kvm_create_vm_debugfs(struct kvm *kvm, int fd) > > mutex_lock(&kvm_debugfs_lock); > > dent = debugfs_lookup(dir_name, kvm_debugfs_dir); > > if (dent) { > > - pr_warn_ratelimited("KVM: debugfs: duplicate directory %s\n", dir_name); > > + pr_warn_once("KVM: debugfs: duplicate directory %s\n", dir_name); > > I don't see how printing once is going to be usefull for a human debugger. If we > want to get rid of the ratelimited print, why not purge it entirely? I'd really like to drop it altogether. I've actually looked at several instances of this printk firing internally, and all of it had to do with some leak in userspace. I'll pull this patch out of the series for v2 and maybe just propose we drop it altogether. -- 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 64086C433EF for ; Mon, 4 Apr 2022 17:58:28 +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=pDx4q0nRDsnYyZ35PU41C2a4psknJJfhwNzQio0TocI=; b=PrvfvIruq8zcAB wvCKcKedt5GLZpbMfwEXO5duZtOK+/V2/sQSd40FSh/Y13vmRrDfdz+ycAjsiiGd2gl/g9Enr1h+V tTIPDU7YNODnRJlOCV8sVrV98MNDSLWiA4hY+a24apUGuAIWwMsNFzkWXEJ90qN1e8rjZDIZiJuW0 5F2Kb/WW3KsRtTN6vZSgpdPBolTDDbj+9L75vIc7qo91xrTnQa6CG1DUW4+3caurhLJwBjcTBDzDb 9azmL7cmFRS0g+e7zJ+Ddrriqv7qf0yhjIP+FL15VU+C4P+3Yw15Xw6HnMDKx8zcdiB8hka0erbTo f/lqkGlLiaPxJJYm+8pQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nbQxA-00G4Ox-4n; Mon, 04 Apr 2022 17:57:24 +0000 Received: from mail-il1-x131.google.com ([2607:f8b0:4864:20::131]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nbQx7-00G4OK-Mc for linux-arm-kernel@lists.infradead.org; Mon, 04 Apr 2022 17:57:23 +0000 Received: by mail-il1-x131.google.com with SMTP id d3so7442492ilr.10 for ; Mon, 04 Apr 2022 10:57:20 -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=GmQMDW9Kl2RXHFpra8Cb+yFdRaCEgtk0WeuxWIun/PE=; b=T/YID3m7jqfMsZdI5yipTxP6mq1tBCIPkkaeRZEOGXJXCRTNAVRLgO6d3oGPKiaIsM hB1IuYXuYvxwGnm/jAntlYOH177EGDJShNXiQsKuSX5zmuTfztgeEwn8fCn3X5foUENF tSPmbGrEqNTLnjaKU1LnFelmOozabOJ/CJhjHjgSpIDgJsIVglglRlphqOF6I5tZB4fN RjXIJozATO4FyKzOy/3PbchB4/uuHz062rsh7sbqfMMWRA2/+03t3OuXgIyBsGiXxQuP s6lHlTJrjRufZd9tiwr5+a8oqSI3d98djdhUvx2xfaAT94UiQ2BSWSf8Or0aJ0TjXzUY Cssw== 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=GmQMDW9Kl2RXHFpra8Cb+yFdRaCEgtk0WeuxWIun/PE=; b=JEQYCkJUKjOt93i5y7o+7Hgp4No8WlpRDFcojtN6jUy7OBLCc1iqDIIcOn+LotuEVl N1tv1JjeOnHwZxDaQy6Rp3y7h8etEFrdkdGsYyMiwrw+fsi/Wu6meTjAOvqKd7jT9fm6 RkiwLN0gfPqE87Njq/3TBEXTGvgG3ROyDUlDv3Q6cWlaxfUTLxbvMGQWhVLXY/4yxZRr wM9wm99RcpFXx05eBU06t6hWef1tspT8LPepuKguVsW0qnjvzsg/j52TZU2wRo9ZYsgs dAljjqgYFjEKmHzLpW3PIs/8K+sheBXtoRUqn7tALD477Rf6mpDHq/m1wDUE2fcOtdSD qaQg== X-Gm-Message-State: AOAM532wJSdgbK+OeIjkoNvlXv1aRv1FCp3DIX5Gmoju6QjYnUTIacBA vHPKiapupxi6MQOK3C7UAxQ+dw== X-Google-Smtp-Source: ABdhPJyxcxrXm46aKYYcD84LuHXVzCCX7Rui8hCXMmO19c75bw55+ZX3BLOKGyUKxAuIXD3PlAjPvg== X-Received: by 2002:a92:3405:0:b0:2c8:70ad:fa86 with SMTP id b5-20020a923405000000b002c870adfa86mr483750ila.268.1649095039360; Mon, 04 Apr 2022 10:57:19 -0700 (PDT) Received: from google.com (194.225.68.34.bc.googleusercontent.com. [34.68.225.194]) by smtp.gmail.com with ESMTPSA id d15-20020a92d78f000000b002ca4c409d1asm1036438iln.83.2022.04.04.10.57.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Apr 2022 10:57:18 -0700 (PDT) Date: Mon, 4 Apr 2022 17:57:14 +0000 From: Oliver Upton To: Sean Christopherson Cc: kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, Marc Zyngier , James Morse , Alexandru Elisei , Suzuki K Poulose , linux-arm-kernel@lists.infradead.org, Peter Shier , Ricardo Koller , Reiji Watanabe , Paolo Bonzini , stable@kernel.org Subject: Re: [PATCH 2/4] KVM: Only log about debugfs directory collision once Message-ID: References: <20220402174044.2263418-1-oupton@google.com> <20220402174044.2263418-3-oupton@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220404_105721_775783_67FE12E6 X-CRM114-Status: GOOD ( 28.50 ) 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 Hi Sean, On Mon, Apr 04, 2022 at 05:33:29PM +0000, Sean Christopherson wrote: > On Sat, Apr 02, 2022, Oliver Upton wrote: > > In all likelihood, a debugfs directory name collision is the result of a > > userspace bug. If userspace closes the VM fd without releasing all > > references to said VM then the debugfs directory is never cleaned. > > > > Even a ratelimited print statement can fill up dmesg, making it > > particularly annoying for the person debugging what exactly went wrong. > > Furthermore, a userspace that wants to be a nuisance could clog up the > > logs by deliberately holding a VM reference after closing the VM fd. > > > > Dial back logging to print at most once, given that userspace is most > > likely to blame. Leave the statement in place for the small chance that > > KVM actually got it wrong. > > > > Cc: stable@kernel.org > > Fixes: 85cd39af14f4 ("KVM: Do not leak memory for duplicate debugfs directories") > > I don't think this warrants Cc: stable@, the whole point of ratelimiting printk is > to guard against this sort of thing. If a ratelimited printk can bring down the > kernel and/or logging infrastructure, then the kernel is misconfigured for the > environment. Good point. > > Signed-off-by: Oliver Upton > > --- > > virt/kvm/kvm_main.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c > > index 69c318fdff61..38b30bd60f34 100644 > > --- a/virt/kvm/kvm_main.c > > +++ b/virt/kvm/kvm_main.c > > @@ -959,7 +959,7 @@ static int kvm_create_vm_debugfs(struct kvm *kvm, int fd) > > mutex_lock(&kvm_debugfs_lock); > > dent = debugfs_lookup(dir_name, kvm_debugfs_dir); > > if (dent) { > > - pr_warn_ratelimited("KVM: debugfs: duplicate directory %s\n", dir_name); > > + pr_warn_once("KVM: debugfs: duplicate directory %s\n", dir_name); > > I don't see how printing once is going to be usefull for a human debugger. If we > want to get rid of the ratelimited print, why not purge it entirely? I'd really like to drop it altogether. I've actually looked at several instances of this printk firing internally, and all of it had to do with some leak in userspace. I'll pull this patch out of the series for v2 and maybe just propose we drop it altogether. -- 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 AB1E4C43219 for ; Mon, 4 Apr 2022 21:23:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1380746AbiDDVV6 (ORCPT ); Mon, 4 Apr 2022 17:21:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52426 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1379723AbiDDR7Q (ORCPT ); Mon, 4 Apr 2022 13:59:16 -0400 Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3722B34BB9 for ; Mon, 4 Apr 2022 10:57:20 -0700 (PDT) Received: by mail-il1-x12a.google.com with SMTP id y16so7444976ilq.6 for ; Mon, 04 Apr 2022 10:57:20 -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=GmQMDW9Kl2RXHFpra8Cb+yFdRaCEgtk0WeuxWIun/PE=; b=T/YID3m7jqfMsZdI5yipTxP6mq1tBCIPkkaeRZEOGXJXCRTNAVRLgO6d3oGPKiaIsM hB1IuYXuYvxwGnm/jAntlYOH177EGDJShNXiQsKuSX5zmuTfztgeEwn8fCn3X5foUENF tSPmbGrEqNTLnjaKU1LnFelmOozabOJ/CJhjHjgSpIDgJsIVglglRlphqOF6I5tZB4fN RjXIJozATO4FyKzOy/3PbchB4/uuHz062rsh7sbqfMMWRA2/+03t3OuXgIyBsGiXxQuP s6lHlTJrjRufZd9tiwr5+a8oqSI3d98djdhUvx2xfaAT94UiQ2BSWSf8Or0aJ0TjXzUY Cssw== 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=GmQMDW9Kl2RXHFpra8Cb+yFdRaCEgtk0WeuxWIun/PE=; b=pQP1lZzFSbjd00Ei4gFqylUzj1VHncfVUDhzDSCQlrVeOY2UbMQjlbaaeyEezrrT6v RJbdx23H5GstkLB6lvo2DN/7KuW+fC0UAIzNf9gV5TZiCu1kmIx0dpyMOgG7a5FfAhPr USkh2GnmYxOb7h4IHi6m7NUyQ8Bv6/f1NP9tqZEsd1qaFEhgZ9cSV+KxWk7+L/nfVdxA 5GLxI+grIhIxDtgVyM1fu5ZYWOmeFLndh4lbPc4SLFKTlH9aaEWPySCCKrTY/qfVRvyO iZER1qydLxf7x2+/pft9S9k2zQdQFOc0/tYd2k7U5aW3FTfFnZR3+X9/9gwNoKvMBFpV SjjA== X-Gm-Message-State: AOAM532mM2s6QP4h6TZVeubMF3IQSLKcnL+hW63fCxh1wG/jcwjMrZZa jcRHX96ouQ/G4MqwKgKMG+iDfA== X-Google-Smtp-Source: ABdhPJyxcxrXm46aKYYcD84LuHXVzCCX7Rui8hCXMmO19c75bw55+ZX3BLOKGyUKxAuIXD3PlAjPvg== X-Received: by 2002:a92:3405:0:b0:2c8:70ad:fa86 with SMTP id b5-20020a923405000000b002c870adfa86mr483750ila.268.1649095039360; Mon, 04 Apr 2022 10:57:19 -0700 (PDT) Received: from google.com (194.225.68.34.bc.googleusercontent.com. [34.68.225.194]) by smtp.gmail.com with ESMTPSA id d15-20020a92d78f000000b002ca4c409d1asm1036438iln.83.2022.04.04.10.57.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Apr 2022 10:57:18 -0700 (PDT) Date: Mon, 4 Apr 2022 17:57:14 +0000 From: Oliver Upton To: Sean Christopherson Cc: kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, Marc Zyngier , James Morse , Alexandru Elisei , Suzuki K Poulose , linux-arm-kernel@lists.infradead.org, Peter Shier , Ricardo Koller , Reiji Watanabe , Paolo Bonzini , stable@kernel.org Subject: Re: [PATCH 2/4] KVM: Only log about debugfs directory collision once Message-ID: References: <20220402174044.2263418-1-oupton@google.com> <20220402174044.2263418-3-oupton@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org Hi Sean, On Mon, Apr 04, 2022 at 05:33:29PM +0000, Sean Christopherson wrote: > On Sat, Apr 02, 2022, Oliver Upton wrote: > > In all likelihood, a debugfs directory name collision is the result of a > > userspace bug. If userspace closes the VM fd without releasing all > > references to said VM then the debugfs directory is never cleaned. > > > > Even a ratelimited print statement can fill up dmesg, making it > > particularly annoying for the person debugging what exactly went wrong. > > Furthermore, a userspace that wants to be a nuisance could clog up the > > logs by deliberately holding a VM reference after closing the VM fd. > > > > Dial back logging to print at most once, given that userspace is most > > likely to blame. Leave the statement in place for the small chance that > > KVM actually got it wrong. > > > > Cc: stable@kernel.org > > Fixes: 85cd39af14f4 ("KVM: Do not leak memory for duplicate debugfs directories") > > I don't think this warrants Cc: stable@, the whole point of ratelimiting printk is > to guard against this sort of thing. If a ratelimited printk can bring down the > kernel and/or logging infrastructure, then the kernel is misconfigured for the > environment. Good point. > > Signed-off-by: Oliver Upton > > --- > > virt/kvm/kvm_main.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c > > index 69c318fdff61..38b30bd60f34 100644 > > --- a/virt/kvm/kvm_main.c > > +++ b/virt/kvm/kvm_main.c > > @@ -959,7 +959,7 @@ static int kvm_create_vm_debugfs(struct kvm *kvm, int fd) > > mutex_lock(&kvm_debugfs_lock); > > dent = debugfs_lookup(dir_name, kvm_debugfs_dir); > > if (dent) { > > - pr_warn_ratelimited("KVM: debugfs: duplicate directory %s\n", dir_name); > > + pr_warn_once("KVM: debugfs: duplicate directory %s\n", dir_name); > > I don't see how printing once is going to be usefull for a human debugger. If we > want to get rid of the ratelimited print, why not purge it entirely? I'd really like to drop it altogether. I've actually looked at several instances of this printk firing internally, and all of it had to do with some leak in userspace. I'll pull this patch out of the series for v2 and maybe just propose we drop it altogether. -- Thanks, Oliver