64-bit stat (or not) in 32-bit Fedora binaries

[Richard W.M. Jones]

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