Re: struct statfs/statfs64 in linux-generic

[Chris Metcalf <cmetcalf at tilera dot com>]

On 11/4/2013 2:18 AM, Chung-Lin Tang wrote:
> Hi,
>
> I'm currently working on the glibc port for Altera Nios II, and per the
> kernel upstreaming requirements, we're making it a user of linux-generic
> in glibc.
>
> I've come across an issue about struct statfs/statfs64, where I've
> listed the struct definitions in both glibc and the kernel below.
>
> In linux-generic, both struct statfs/statfs64 has some fields as 64-bit
> words, padded properly if need on 32-bit targets. Effectively, they have
> to be same-format, to pass to the statfs64 syscall uniformly.
>
> __SWORD_TYPE appears to be int/long on 32/64-bit targets. This means
> that for 32-bit targets, struct statfs[64] will be made of 32-bit words,
> with a few 64-bit fields embedded in the middle.
>
>
> In the kernel however, the fields of importance in struct statfs is made
> up of entirely '__statfs_word', defined to be 64-bit or 32-bit depending
> on target (putting aside signedness for now).

I have to carefully swap all this stuff back into my head every time I look at this issue :-)

For native 32-bit (for us that means tilepro) the constraint is that the kernel's "struct statfs64" has to match the two structs in glibc's <bits/statfs.h>.  Most of the statfs types are fixed-size (fsid_t and the __u64 types), with __statfs_word/__SWORD_TYPE being the exception.  For tilepro both of those kernel and glibc types are 32-bit types.

For 32-bit userspace in a 64-bit kernel (for us that means tilegx -m32) the constraint is that the kernel's "struct compat_statfs64" match the <bits/statfs.h> types, which again, it seems that they should.  (Note that tilegx -m32 is explicitly a "compat" syscall model.)

A quick look suggests that nios2 is a pure 32-bit architecture, so more like the tilepro model.

Andrew Pinski's email was a bit confusing since __SYSCALL_SLONG_TYPE seems to be the same size as __SWORD_TYPE, and I don't see any redefinitions of it for aarch64.  I believe his usecase is the 32-bit userspace on 64-bit kernel model.  One thing to watch out for is that some architectures (like x32) actually use the 64-bit syscalls natively (no compat_statfs64) so they need to use "long long" types to match the 64-bit fields, etc., so it's a different problem.  In retrospect that might have been a cleaner model for tilegx -m32, but I suspect that ship has sailed for us.

In your followup email you write:

> Still, I'm not sure if using full 64-bit fields should be the intended
> solution. A full 32-bit target should be able to have those fields as
> 32-bit (which means a kernel patch to differentiate the current uses of
> '__statfs_word' into 32/64-bit words)

I have a guess as to what the problem you're seeing is: are you looking at "struct statfs" in the kernel?  That structure is completely unused on 32-bit platforms, since it's only relevant for the 64-bit platform's sys_statfs/sys_fstatfs syscalls, whereas on 32-bit platforms you only get sys_statfs64/sys_fstatfs64.  In other words there is no syscall that fills in a structure with 32-bit "f_blocks" (for example).  See the __NR3264_statfs macro in <asm-generic/unistd.h> and how it resolves with the __SC_COMP_3264() macro, to the __SC_3264() macro, to the 32-bit version of the syscall.

-- 
Chris Metcalf, Tilera Corp.
http://www.tilera.com