Re: x86_64: 32bit emulation problems

[Andi Kleen]

On Thu, Mar 03, 2005 at 01:37:26PM -0800, Trond Myklebust wrote:
> to den 03.03.2005 Klokka 10:19 (+0100) skreiv Andi Kleen:
> > The problem here is that glibc uses stat64() which supports
> > 64bit inode numbers. But glibc does the overflow checking itself
> > and generates the EOVERFLOW in user space. Nothing we can do
> > about that. The 64bit inodes work under 32bit too, so your
> > code checking for 64bitness is totally bogus.
> 
> As far as the kernel is concerned, asm/posix_types defines
> __kernel_ino_t as "unsigned long" on most platforms (except a few which
> define is as "unsigned int). We don't care what size type glibc itself
> uses.

That could easily be changed and even pass out 64bit inodes
on 32bit systems.  The stat64 syscall ABI allows this.

Perhaps that should be done and then you could drop the truncation
code. 

Of couse this would expose the glibc Bug Bernd ran into on 32bit
too, but at some point they have to fix that bogosity anyways.


> So I don't see how the file system would be able to do a better job of
> truncation here. In principle you should *never* truncate inode numbers.

Agreed, except we are stuck with broken user land here.

But - if you ever chose to truncate you should do it on 64bit
system too to avoid problems with the 32bit emulation.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/