linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Oliver Upton <oupton@google.com>
To: Sean Christopherson <seanjc@google.com>
Cc: kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org,
	Marc Zyngier <maz@kernel.org>, James Morse <james.morse@arm.com>,
	Alexandru Elisei <alexandru.elisei@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	linux-arm-kernel@lists.infradead.org,
	Peter Shier <pshier@google.com>,
	Ricardo Koller <ricarkol@google.com>,
	Reiji Watanabe <reijiw@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	stable@kernel.org
Subject: Re: [PATCH 2/4] KVM: Only log about debugfs directory collision once
Date: Mon, 4 Apr 2022 17:57:14 +0000	[thread overview]
Message-ID: <Yksxeo7IhzyFS8AM@google.com> (raw)
In-Reply-To: <Yksr6etwnN0iW8ZH@google.com>

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 <oupton@google.com>
> > ---
> >  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

  reply	other threads:[~2022-04-04 17:58 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-02 17:40 [PATCH 0/4] KVM: arm64: Fix use-after-free in debugfs Oliver Upton
2022-04-02 17:40 ` [PATCH 1/4] KVM: arm64: vgic: Don't assume the VM debugfs directory exists Oliver Upton
2022-04-02 22:39   ` Oliver Upton
2022-04-02 17:40 ` [PATCH 2/4] KVM: Only log about debugfs directory collision once Oliver Upton
2022-04-04 17:33   ` Sean Christopherson
2022-04-04 17:57     ` Oliver Upton [this message]
2022-04-02 17:40 ` [PATCH 3/4] selftests: KVM: Don't leak GIC FD across dirty log test iterations Oliver Upton
2022-04-02 19:26   ` Jing Zhang
2022-04-02 17:40 ` [PATCH 4/4] selftests: KVM: Free the GIC FD when cleaning up in arch_timer Oliver Upton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Yksxeo7IhzyFS8AM@google.com \
    --to=oupton@google.com \
    --cc=alexandru.elisei@arm.com \
    --cc=james.morse@arm.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=maz@kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=pshier@google.com \
    --cc=reijiw@google.com \
    --cc=ricarkol@google.com \
    --cc=seanjc@google.com \
    --cc=stable@kernel.org \
    --cc=suzuki.poulose@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).