Re: Handling of 32/64 bit off_t by getdents64()

[Miklos Szeredi <miklos@szeredi.hu>]

On Wed, Nov 27, 2019 at 10:33 AM Nikolaus Rath <Nikolaus@rath.org> wrote:
>
> Hello,
>
> For filesystems like ext4, the d_off values returned by getdents64()
> seem to depend on the kind of process that issues the syscall.
>
> For example, if I compile test program with -m32 I get:
>
> $ ./readdir32
> --------------- nread=616 ---------------
> inode#    file type  d_reclen  d_off   d_name
> 32253478  ???          40  770981411  test_readlog.py
> 32260181  ???          24  776189020  ..
> [...]
>
> If I compile for 64 bit, I get:
>
> $ ./readdir64
> --------------- nread=616 ---------------
> inode#    file type  d_reclen  d_off   d_name
> 32253478  ???          40 3311339950278905338  test_readlog.py
> 32260181  ???          24 3333706456980390508  ..
> [...]
>
> This is despite d_off being declared as ino64_t in the linux_dirent64
> struct.
>
>
> This is presumably intentional, because (again as far as I can tell), if
> getdents64 returns a full 64 bit value for a 32 bit system, libc's
> readdir() will return an error because it cannot fit the value into
> struct dirent.
>
>
> As far as I know, there is no way for a FUSE filesystem to tell if the
> client process is 64 bit or 32 bit. So effectively, a FUSE filesystem is
> limited to using only the lower 32 bits for readdir offsets. Is that
> correct?
>
> This would be quite annoying because it means that passthrough
> filesystems cannot re-use the underlying filesystems d_off values
> (since they will be full 64 bit for a 64 bit FUSE process).
>
>
> Is there a way for a 64 bit process (in this case the FUSE daemon) to
> ask for 32 bit d_off values from getdents64()?

Looking at ext4 d_off encoding, it looks like the simple workaround is
to use the *high* 32 bits of the offset.

Just tried, and this works.  The lower bits are the "minor" number of
the offset, and no issue with zeroing those bits out, other than
increasing the chance of hash collision from practically zero to very
close to zero.

> Would it be feasible to extend the FUSE protocol to include information
> about the available bits in d_off?

Yes.

The relevant bits from ext4 are:

static inline int is_32bit_api(void)
{
#ifdef CONFIG_COMPAT
    return in_compat_syscall();
#else
    return (BITS_PER_LONG == 32);
#endif
}

and:

    if ((filp->f_mode & FMODE_32BITHASH) ||
        (!(filp->f_mode & FMODE_64BITHASH) && is_32bit_api()))
        /* 32bits offset */;
    else
        /* 64bits offset */;

Thanks,
Miklos