Handling of 32/64 bit off_t by getdents64()

Handling of 32/64 bit off_t by getdents64()

[Nikolaus Rath]

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()?


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


Best,
-Nikolaus

-- 
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

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

[Miklos Szeredi]

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

Re: [fuse-devel] Handling of 32/64 bit off_t by getdents64()

[Nikolaus Rath]

On Nov 27 2019, Miklos Szeredi <miklos@szeredi.hu> wrote:
>> 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
> }

Thanks for the quick response!

Is there a way to do the same without relying on ext4 internals, i.e. by
manually calling getdents64() in such a way that in_compat_syscall()
gives true even if the caller is 64 bit?



Best,
-Nikolaus

-- 
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

Re: [fuse-devel] Handling of 32/64 bit off_t by getdents64()

[Miklos Szeredi]

On Wed, Nov 27, 2019 at 9:52 PM Nikolaus Rath <Nikolaus@rath.org> wrote:
>
> On Nov 27 2019, Miklos Szeredi <miklos@szeredi.hu> wrote:
> >> 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
> > }
>
> Thanks for the quick response!
>
> Is there a way to do the same without relying on ext4 internals, i.e. by
> manually calling getdents64() in such a way that in_compat_syscall()
> gives true even if the caller is 64 bit?

Generally that's not doable.   Might be able to do a 32bit syscall
specifically on x86_64, but I don't know the details.

Thanks,
Miklos