On Mon, Feb 18, 2013 at 03:33:33PM -0600, Eric Sandeen wrote:
XFS recently defaulted to allowing > 32 bit inode numbers, and
btrfs
can let inode numbers creep past 2^32 as well.
While most applications don't care one bit about st_ino returned
from a stat() call, the sad fact is that you'll get EOVERFLOW from
stat32 if the inode number is too big to fit in 32 bits, even if you
just wanted to get the file size.
I have a script (
http://sandeen.net/misc/summarise_stat.pl) which
Greg Banks wrote; it can check a path or list of filenames for
binaries which contain non-64bit-safe stat calls. A quick look over
my F18 install finds the situation to be only slightly in favor of
executables using 64-bit variants:
# ./summarize-stat.pl /usr
270229 91.5% are scripts (shell, perl, whatever)
22633 7.7% don't use any stat() family calls at all
913 0.3% use 32-bit stat() family interfaces only
1335 0.5% use 64-bit stat64() family interfaces only
73 0.0% use both 32-bit and 64-bit stat() family interfaces
and it's not just weird obscure packages:
# ./summarize-stat.pl `rpm -ql sendmail`
69 78.4% are scripts (shell, perl, whatever)
2 2.3% don't use any stat() family calls at all
17 19.3% use 32-bit stat() family interfaces only
Anyway, if you want to check your package(s) and maybe make them
64-bit-stat safe, the perl script above might help. It's more than
just -DFILE_OFFSET_BITS=64, since you'll need to be sure not to
overflow any large values you get back from stat64 etc.
Might be nice to get out ahead of this before, say, btrfs comes into
wide use. I don't know if there could be any more of a formal
effort in this direction?
Eric, I've read this email and the summarise_stat script a couple of
times, and I admit I'm confused.
(1) Just ensuring the code is compiled with -DFILE_OFFSET_BITS=64 is
sufficient to ensure the 32 bit stat will never be called, right?
(2) If my code never mentions st_ino, it's safe?
[I assume the answer to this is *no* because you seem to be saying
that -EOVERFLOW could be returned from an innocent-looking stat
call, even if the code never looks at st_ino.]
(3) For my code that uses st_ino, I need to ensure this is never
assigned to a 32 bit integer (eg. 'int', 'int32_t', 'long' on 32
bit, etc.)?
(4) Is doing (1) & (3) sufficient to fix all stat32-related problems
in my code?
(5) With -DFILE_OFFSET_BITS=64, is st_ino a 64 bit value?
Also a note that the current man page for stat(2) doesn't mention this
problem, doesn't mention that EOVERFLOW could be returned in this
surprising situation, and also has an example that casts st_ino to a
long which I assume would be unsafe behaviour on a 32 bit
architecture. These are all bugs that the man-pages maintainers would
no doubt be interested in.
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW