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: <20191126100737.GA1416107@kroah.com>
Date:   Tue, 26 Nov 2019 11:07:37 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Alexey Dobriyan <adobriyan@...il.com>
Cc:     Paolo Bonzini <pbonzini@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: "statsfs" API design

On Mon, Nov 11, 2019 at 11:40:32PM +0300, Alexey Dobriyan wrote:
> On Sun, Nov 10, 2019 at 09:58:14PM +0100, Paolo Bonzini wrote:
> > On 10/11/19 16:34, Alexey Dobriyan wrote:
> > > In the other direction: describe every field of /proc/*/stat file
> > > without looking to the manpage:
> > > 
> > > $ cat /proc/self/stat
> > > 5349 (cat) R 5342 5349 5342 34826 5349 4210688 91 0 0 0 0 0 0 0 20 0 1 0 864988 9183232 184 18446744073709551615 94352028622848 94352028651936 140733810522864 0 0 0 0 0 0 0 0 0 17 5 0 0 0 0 0 94352030751824 94352030753376 94352060055552 140733810527527 140733810527547 140733810527547 140733810532335 0
> > 
> > That's why this is not what I am proposing, and also not what Greg has
> > mentioned.
> 
> The argument was that text is somehow superior to binary. Experiment shows
> that userspace can make a mess of both modes therefore preferring one
> to another should be based on something else (preferably objective).

No, that was NOT what my argument was.

My argument is that you have to have self-describing data somehow,
otherwise you will always get out of sync with what the kernel is
exporting and what userspace expects.  The above crazy procfs example
proves my point very well :)

sysfs "solves" this problem by requiring one value per file.  If the
file is not present, userspace "knows" that the value isn't there at
all.  It a simple solution for the problem that procfs has with multiple
values in single files and is why we did it that way.

Now that's not to say this is the only way to solve the issue here, it's
just the one that we decided to use at the time.  statfs can choose to
do it differently, but it can NOT just ignore the problem here,
otherwise we end up with the old procfs problems as you show above.

> /proc have these two problems:
> First, noticeably slow:
> 
> 	https://news.ycombinator.com/item?id=21414882

Yes, opening thousands of files is "slow", that's known :)

> Second, overinstantiating inodes and dentries:
> 
> 	https://lore.kernel.org/lkml/20180424022106.16952-1-jeffm@suse.com/

Exporting hundreds of thousands of files, what could go wrong? :)

> statfs maybe never get to that level but it is not hard to see what lies
> at the end of the tunnel.

Those are nice things to think about while doing this, but I think we
are a long ways off from these types of issues.

thanks,

greg k-h