This started as a rather simple problem. glibc uses fstat64() internally when making a stat() call. If the st_ino field returned by this call does not fit in the buffer allocated by the program, glibc (rightly) generates an EOVERFLOW in userspace. This is generally only a problem when the program is compiled without -D_FILE_OFFSET_BITS=64. The kernel declares ino_t to be an unsigned long which is generally 32-bits on 32-bit kernels and 64-bits on 64-bit kernels. The new_inode function has a static unsigned long counter that it uses to assign out i_ino values. On a 64-bit kernel, the value in this counter eventually becomes too large to fit in 32-bits, and glibc starts throwing EOVERFLOW errors to programs compiled without large file offsets. This creates a situation where such a program will work fine on a 32-bit kernel, but when run on a 64-bit kernel it will eventually start falling down. We can't do much about this on filesystems that have true 64-bit inodes, but on filesystems that get "pseudo_inode" values via new_inode or iunique, we should attempt to make them fit in a 32-bit value. While fixing this, we discovered that many filesystems seem to blindly accept the i_ino value given by new_inode. new_inode makes no actual check to see if an i_ino value is unique, so once the counter overflows you can end up with more than one inode with the same i_ino value. The following set of patches should remedy both of these problems. While these are arguably security-related, these patches are probably better suited to 2.6.20 than anything earlier. -- Jeff - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
