linux-kernel - Re: [d_path 0/7] Fixes to d

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 for Android: free password hash cracker in your pocket

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

Message-Id: <200704221748.31830.agruen@suse.de>
Date:	Sun, 22 Apr 2007 17:48:31 +0200
From:	Andreas Gruenbacher <agruen@...e.de>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	Ulrich Drepper <drepper@...il.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>, jjohansen@...e.de,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, chrisw@...s-sol.org,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [d_path 0/7] Fixes to d_path: Respin

On Sunday 22 April 2007 11:10, Christoph Hellwig wrote:
> So what about stopping the flaming here and implementing real statvfs/
> fstatvfs syscalls instead of these horrible hacks glibc has to do
> currently?

I could imagine two approaches to that: either add statvfs and fstatvfs 
syscalls, or use one of the reserved fields in struct statfs, and return the 
missing flags in there.

Here is a very rough shot at the latter (i386 and x86_64 only so far). One of 
the uglinesses with that is that all those flags could be cleared at the same 
time, and so we can't tell whether the field is used from the flags alone and 
need some other mechanism like an extra bit, or a successive field that is 
guaranteed to be nonzero. Not sure whether that's acceptable considering the 
alternative of adding two syscalls and duplicating all the ugly compatibility 
scaffolding.

struct statvfs also defines a f_favail field, the ``number of file serial 
numbers available to non-privileged process''. Glibc currently sets this to 
the same value as f_ffree, the ``total number of free file serial numbers''. 
We don't seem to have this information, so adding this field wouldn't help 
immediately.

Andreas

View attachment "statvfs.diff" of type "text/x-diff" (10762 bytes)