linux-kernel - Re: [PATCH] kvm: no need to check return value of debugfs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <1dc2d59b-a178-59cc-42bd-4b09289240dc@de.ibm.com>
Date:   Wed, 23 Jan 2019 09:28:08 +0100
From:   Christian Borntraeger <borntraeger@...ibm.com>
To:     Paolo Bonzini <pbonzini@...hat.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     linux-kernel@...r.kernel.org,
        Radim Krčmář <rkrcmar@...hat.com>,
        kvm@...r.kernel.org, Stefan Raspl <raspl@...ux.vnet.ibm.com>
Subject: Re: [PATCH] kvm: no need to check return value of debugfs_create
 functions



On 23.01.2019 00:11, Paolo Bonzini wrote:
> On 22/01/19 21:48, Greg Kroah-Hartman wrote:
>>> This also brings the question: shall we move these counters out of debugfs into something else?
>> If you have code that relies on debugfs, yes, you need to move that out
>> of debugfs because more and more systems are trying to disable it due to
>> the obvious problems with it (i.e. leaking tons of debugging
>> information).
>>
>> debugfs is for DEBUG information, not for "statistics about how my VM is
>> working".  That sounds like something you need to rely on, so debugfs is
>> not the place for it.
> 
> Yes, we know that and tracepoints are already one replacement.  However,
> they are slower that just a lock-free "vcpu->stats.foo_happened++".

Yes, the tracepoints are not a proper replacement for the counters (especially 
the capability to get numbers after-the-fact. So I would really like to keep
both.

> Another idea that Steven Rostedt and I discussed a while ago is some
> kind of "statfs" which would already provide some code, similar to the
> one that KVM uses to accumulate statistics from multiple VMs or multiple
> VCPUs into a single counter.


I think that would make a lot of sense to have a common filesystem to avoid
code duplication bugs.