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