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] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 11 Nov 2019 23:40:32 +0300
From:   Alexey Dobriyan <adobriyan@...il.com>
To:     Paolo Bonzini <pbonzini@...hat.com>
Cc:     Greg KH <gregkh@...uxfoundation.org>, linux-kernel@...r.kernel.org
Subject: Re: "statsfs" API design

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).

/proc have these two problems:
First, noticeably slow:

	https://news.ycombinator.com/item?id=21414882

Second, overinstantiating inodes and dentries:

	https://lore.kernel.org/lkml/20180424022106.16952-1-jeffm@suse.com/

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