[PATCH v2 28/46] statfs: Use statfs64 if arch does not have the statfs syscall

Rich Felker dalias at aerifal.cx
Wed Nov 28 13:10:53 UTC 2012


On Wed, Nov 28, 2012 at 09:27:15AM +0000, Markos Chandras wrote:
> On 27 November 2012 23:36, Rich Felker <dalias at aerifal.cx> wrote:
> >
> > The claim of "ABI break" is nonsense. There is presently NO WAY to use
> > this legacy stat structure on no-legacy-syscall kernels. So there is
> > no way anything could be using it. Really, on no-legacy-syscall
> > kernels, _FILE_OFFSET_BITS should always be 64 and the legacy structs
> > should not even exist. But if you insist on providing them anyway, you
> > should use the same layout as the 64-bit struct that the syscall
> > supports, rather than writing nasty bloat to convert to a completely
> > non-native legacy structure that has nothing to do with the kernel.
> 
> You seem to ignore part of my replies. I explained that 32-bit
> syscalls need to be present
> so existing applications can link and work as expected. For example,
> many applications still use
> stastfs() instead of statfs64(). As a result of which, we still need
> the 32-bit structures around.

On 64-bit machines, statfs and statfs64 are the same function.
Moreover, whenever _FILE_OFFSET_BITS is defined to 64 (which should
always be done; mixing programs compiled with different settings can
lead to subtle and dangerous bugs with file descriptor inheritance)
statfs is statfs64. Nobody should ever be calling statfs64 by name.

> And the 32-bit structure you will pass to the INLINE_SYSCALL() will
> end up in kernel space so it has to

It never ends up in kernelspace on no-legacy-syscall archs because
THERE IS NO SUCH SYSCALL. You have to make the statfs64 syscall
instead, and the 32-bit structure only exists by virtue of whatever
translations you do in userspace.

> have a similar layout with the kernel statfs structure which ( I
> already said that ) is always defined in new architectures
> in $KERNEL/include/asm-generic/statfs.h. So even if we provide our own
> in uClibc, we can't change the kernel one.
> Do I miss something?

Yes. You miss that THERE IS NO KERNEL ONE on these archs.

> > There is no such thing as a "positive pointer". Pointers do not have
> > sign.
> 
> OK I meant an arbitrary positive integer that the user can pass in the
> statfs(). Many LTP tests does that. The only different is that
> these tests will crash libc in new architectures but will return -1
> on old ones.

Your proposed "test that the pointer is positive" nonsense makes it
impossible to use statfs. *Most* uses of statfs involve a pointer
which, when cast to int, becomes a negative number (due to being on
the stack).

Rich


More information about the uClibc mailing list