Re: x86_64: 32bit emulation problems

[Trond Myklebust]

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.

> The old stat interface doesn't check that case currently either
> (will fix that), but that's not the problem here.
> 
> But in general the emulation layer cannot do truncation because
> it doesn't know if it is ok to do for the low level file system.
> If anything this has to be done in the fs.

Inode numbers are provided for informational reasons only. There are no
POSIX or SUSv3 interfaces that take an inode number as an argument. The
only processing you can do with an inode number is to compare it for
equality to another inode number.

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.

Cheers,
  Trond

-- 
Trond Myklebust <trond.myklebust@xxxxxxxxxx>

-
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/