linux-kernel - Re: "statsfs" API design

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: <20191126141830.GA1446708@kroah.com>
Date:   Tue, 26 Nov 2019 15:18:30 +0100
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Paolo Bonzini <pbonzini@...hat.com>
Cc:     KVM list <kvm@...r.kernel.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Christian Borntraeger <borntraeger@...ibm.com>,
        Alex Williamson <alex.williamson@...hat.com>,
        Peter Feiner <pfeiner@...gle.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: "statsfs" API design

On Tue, Nov 26, 2019 at 11:50:29AM +0100, Paolo Bonzini wrote:
> On 26/11/19 11:09, Greg Kroah-Hartman wrote:
> > So I think there are two different things here:
> > 	- a simple data structure for in-kernel users of statistics
> > 	- a way to export statistics to userspace
> > 
> > Now if they both can be solved with the same "solution", wonderful!  But
> > don't think that you have to do both of these at the same time.
> > 
> > Which one are you trying to solve here, I can't figure it out.  Is it
> > the second one?
> 
> I already have the second in KVM using debugfs, but that's not good.  So
> I want to do:
> 
> - a simple data structure for in-kernel *publishers* of statistics
> 
> - a sysfs-based interface to export it to userspace, which looks a lot
> like KVM's debugfs-based statistics.
> 
> What we don't have to do at the same time, is a new interface to
> userspace, one that is more efficient while keeping the self-describing
> property that we agree is needed.  That is also planned, but would come
> later.

Ok, I have no objection to tying these to sysfs entries for now, but we
should be careful in how you handle the sysfs hierarchy to not make it
too complex or difficult to parse from userspace (lots of little files
does not make gathering stats easy as was already pointed out.)

for in-kernel stats, here's a note that I had that I finally found from
a different kernel developer saying what they wanted to see in something
like this:
	(Accurate) statistics counters need RMW ops, don't need memory
	ordering, usually can't be locked against writes, and may not
	care about wrapping.

thanks,

greg k-h