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  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]
Date:	Sun, 22 Apr 2007 17:48:31 +0200
From:	Andreas Gruenbacher <>
To:	Christoph Hellwig <>
Cc:	Ulrich Drepper <>,
	Alan Cox <>,,,,,,
	Andrew Morton <>
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 

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 


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

Powered by blists - more mailing lists