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

Eric Sandeen sandeen at redhat.com
Wed Apr 3 14:58:38 UTC 2013


On 4/3/13 3:49 AM, Florian Weimer wrote:
> On 02/19/2013 12:15 AM, Eric Sandeen wrote:
>> On 2/18/13 5:11 PM, John Reiser wrote:
>>> It would be useful to have a "backward compatibility" LD_PRELOAD shared
>>> library which intercepts the caller of stat32, and sets .st_ino to 0,
>>> without generating EOVERFLOW, whenever the actual inode number exceeds
>>> 32 bits.  This would allow the *option* of continued operation
>>> (postponing the work of portability enhancements) for the vast majority
>>> of packages which do use stat() but do not inspect .st_ino.
>>
>> Yep, that would make some sense as a workaround.  FWIW, here's a systemtap
>> script which intercepts ext4 stat & bumps the inode nr past 2^32
>> (line numbers work on F18/kernel 3.7-8-ish at least)
> 
> Do you have something similar for readdir?  Do you know what the kernel does in this case?
> 
> It would be quite annoying if the result was a truncated or incomplete directory listing.

I haven't tested readdir but changing the stap script to do it probably wouldn't be
too tough, I think just doing something similar to bump up fname->inode
early in ext3/4's call_filldir() would do the trick at least for hashed dirs.

Looking at filldir() in the kernel, it does look like you'd get EOVERFLOW:

static int filldir(void * __buf, const char * name, int namlen, loff_t offset,
                   u64 ino, unsigned int d_type)
{
...
        unsigned long d_ino;
...
        d_ino = ino;
        if (sizeof(d_ino) < sizeof(ino) && d_ino != ino) {
                buf->error = -EOVERFLOW;
                return -EOVERFLOW;
        }

(note again that although we're talking about ext3/4 here, they will never(tm)
have > 32-bit inodes; they're just convenient to test on since everyone is running
them today).

-Eric


More information about the devel mailing list