[PATCH 2/7] df: Use statvfs instead of non-standard statfs

Eugene Rudoy gene.devel at gmail.com
Sun Oct 22 21:32:15 UTC 2017


Hi all,

just wanted to point out that besides making the code more portable
the change suggested by James has another positive side effect. It
eliminates the need for the uClibc related and as of now unreliable
workaround added in the second hunk of e184a88 [1].

Why unreliable? "statfs s"-variable is allocated on stack and is not
initialized (=zeroed) at all, neither on the caller nor on the callee
side. So the workaround works only in those cases where the stack (by
chance) contain zeros (bytes corresponding to f_frsize would be
enough).

For the sake of completeness... The problem the code tries to
workaround could (as of now) be observed only on mips. See mips
specific libc/sysdeps/linux/mips/bits/statfs.h [2]. It contains
f_frsize in all its statfs* structs but doesn't signal it by defining
_STATFS_F_FRSIZE like e.g. libc/sysdeps/linux/common/bits/statfs.h [3]
does. This in turn results in libc/misc/statfs/statfs64.c [4] ignores
the field and doesn't copy it (like the comment to the workaround
states).

statvfs doesn't have this problem, it always sets f_frsize (s. [5]).

Cheers,
Gene

[1] https://git.busybox.net/busybox/commit/coreutils/df.c?id=e184a883567ee3fd735644416e4bd683f1894ac5
[2] https://cgit.openadk.org/cgi/cgit/uclibc-ng.git/tree/libc/sysdeps/linux/mips/bits/statfs.h
[3] https://cgit.openadk.org/cgi/cgit/uclibc-ng.git/tree/libc/sysdeps/linux/common/bits/statfs.h#n66
[4] https://cgit.openadk.org/cgi/cgit/uclibc-ng.git/tree/libc/misc/statfs/statfs64.c?id=7cfd2112acbc7a9dfcd9f8a23e550672934a2545#n48
[5] https://cgit.openadk.org/cgi/cgit/uclibc-ng.git/tree/libc/misc/statfs/internal_statvfs.c#n24

On Sat, Oct 7, 2017 at 7:53 PM, James Clarke <jrtc27 at jrtc27.com> wrote:
> Platforms differ on what their implementations of statfs include.
> Importantly, FreeBSD's does not include a f_frsize member inside struct
> statfs. However, statvfs is specified by POSIX and includes everything
> we need, so we can just use that instead.


More information about the busybox mailing list